Merge branch 'main' into rrhyne-patch-3

content/departments/technical-success/support/process/product-feedback-process.md

@@ -0,0 +1,9 @@
+# Product feedback
+
+We frequently receive feedback through tickets or upon their resolution. It's important to distinguish this feedback from bugs and [product gaps](../../../product/process/feedback/surfacing_product_requests.md#what-is-a-product-gap). Product feedback refers to prospects' or customers' observations, comments, or opinions about the product experience. It may relate to the product's implementation or areas that are unclear or could be enhanced. For more information on product feedback, please refer to the [Surfacing Product Feedback](../../../product/process/feedback/surfacing_product_requests.md#what-is-a-product-gap) section in our handbook.
+
+**Where to Share Feedback:**
+
+- Post the feedback in either the #feedback-cody or #feedback-code-search channels.
+- Include a link to the original feedback and tag the account’s Technical Advisor to ensure they have the full context.
+- If you're unsure whether the feedback is a product gap or product feedback, reach out to the account’s Technical Advisor or #team-support-engineering for guidance.

content/departments/technical-success/support/process/support-workflow.md

@@ -44,8 +44,9 @@
     2. We identify a workaround to get the customer on their way `AND` we file a defect or product improvement (in the public GitHub tracker) to address the underlying root cause and share the link with the customer.
     3. We help the customer figure out what they need to do and they stop responding. After a couple of attempts, if we are confident the issue would be solved, `AND` we complete any internal tasks born from working on the ticket (like updating documentation), we go ahead and consider it resolved. Often in these situations we give the CE a heads-up of our decision.
     4. We identify a defect, engineering fixes it, the customer confirms the issue is resolved `OR` we share the public defect link with the customer (always do this when possible instead of keeping the case open) `AND` we complete any internal tasks born from working on the ticket (like updating documentation). Until then, we consider the case open and while engineering prioritizes the defect for a fix, we place the case "on-hold" in Zendesk.
-    5. We confirm the ticket is a product gap and follow the [product gap process](product-gap-process.md) to engage the account's Technical Advisor (TA) or the Scaled Success team..
-    6. If we are still working on finding the answer and the customer stops responding, we email a couple more times to see if they had a chance to look at our last response. If they still don't respond, and they have a CE, talk with them to see if they have another way to get in touch and see what's going on. If not, or if the customer does not have a CE, `AND` we complete any internal tasks born from working on the ticket (like updating documentation), then it's okay to close the ticket at this point.
+    5. We confirm the ticket is a product gap and follow the [product gap process](product-gap-process.md) to engage the account's Technical Advisor (TA) or the Scaled Success team.
+    6. We confirm the ticket is product feedback and follow the [product feedback process](product-feedback-process.md) to share this feedback with the product team.
+    7. If we are still working on finding the answer and the customer stops responding, we email a couple more times to see if they had a chance to look at our last response. If they still don't respond, and they have a CE, talk with them to see if they have another way to get in touch and see what's going on. If not, or if the customer does not have a CE, `AND` we complete any internal tasks born from working on the ticket (like updating documentation), then it's okay to close the ticket at this point.
 
 11. **While we work, we keep Zendesk, Slack, and/or Salesforce up-to-date.** If a ticket originates in Slack, you'll still need to keep Zendesk up to date. Switch the requestor to the person asking for help in Slack so that the issue ties to the right customer. Assign ticket priority and estimated level-of-effort(LoE) tags. The level-of-effort is dynamic and can change over a tickets' lifetime. Use the internal notes function in Zendesk to leave notes for yourself to track your progress and decisions (these will also appear in Salesforce for others to see). A summary of what happened should be obvious in Zendesk even if all the work happened in Slack. Also, we will often learn details about a customer's environment, etc that we should keep in Salesforce and Vitally. We update it in the account info doc in [the customer notes folder](https://drive.google.com/drive/u/0/folders/1gjXWQ1l0Fnt2pVS2ohx3w0cw-gaJ_Ez0), if one exists (be sure to talk to the CE as part of updating it, in the event that what you are updating ends up being invaluable information to them for what else may be happening with the account). This data is then rendered in Zendesk so we don't have to ask the customer for it again. Zendesk also always reflects where we are at in our process by using the status function.