How to fix products (how to execute content insights for fixing products)

While reviewing the tickets your ICs working on (e.g. during EQB exercise), you might generate content insights for solving a specific problem for your customers in a better way. There are different levels of execution and not all of them have the same affect. Let's take a specific example and examine the execution methods.

Example

Insight: For Symphony Commerce, we receive 10 tickets/week where ICs have to cancel an order and then ask the customer to create a new order, if the customer wants to change the address when the order already went to the warehouse - due to a Symphony Commerce product limitation.

Solution: You found a way for ICs to update the address by cancelling the order and then re-adding it themselves without requiring customer to cancel and recreate an order.

Impact: End to end ticket resolution time decreases from 3 days to 4 hours. Risk of losing sales eliminated (1 sales lost in 10 tickets past week where customers decided not to create a new order after cancellation).

How can you execute your solution? You might coach your ICs . This might help your customers. However the rest of the ICs on the TR may not benefit from your coaching, because you are not managing them. Also, when you leave the team, your solution would disappear.

You can document your coaching, create a best practices guide or create a new "how to" article for your ICs. If you have a knowledge base, you can add your document there so that your solution is searchable, and when ICs face such issues, they can find & apply the solution. This way, it would be a permanent asset for your TR. Entire TR can benefit from it. This is not the ideal solution, as there is still a problem for which your customers opening a ticket. You can create a how to / knowledge base (KB) article that your customers can find & read so that they can solve their problem without opening a ticket. This can deflect the support tickets, but still, there is a problem affecting your customers, requiring them to search and follow a KB article.

While executing all of the previous solutions above, you can wok in parallel to fix your product and enable customers do the change directly on the product. For this, you should understand the cost of the fix, and approach the business unit or the VP of the TR (make sure you check with TR owner, before approaching BUs. e.g. Support TR's have a specific process) and provide your insight to them. BU / VP of the TR can then decide to fix the problem depending on their priorities.

Even in this case, BU/VP may not decide on the fix, because they may not have a prioritized list of of fixes. You can create a prioritized list of limitations/bugs/customer issues etc. and report this to BU/VP to allow them decide easily. This way, you can ensure your products get fixed.

Here is a stack rank of solutions (first is the best):

  1. Fix the product: Get a prioritized list of limitations/bugs/customer issues etc. and report this to BU/VP and let them decide on which fixes to have. Make sure you include the following info on your report: -Ticket type -Quantity of tickets / week -Simplified explanation -Customer expectation / solution and its impact

  2. Deflect the tickets: Create customer-facing KB article allowing customers to solve tickets on their own.

  3. Fix the tickets, in a cheap way: Create a KB article that allows Level 1 support to solve the ticket at their level without escalating.

  4. Fix the tickets, in an expensive way: Create a KB article that allows Level 2 support to solve the ticket at their level without escalating.

For #3 and #4, even if you don't manage to shift left, you can find a better solution (i.e. better KB article) that would decrease the end to end resolution time of the ticket (e.g. resolve the ticket in 2 touches in 1 day instead of 20 touches in 1 week, or better troubleshooting steps taking 15 mins instead of 4 hours). This would allow your customers to be served better & faster.

Please note that, during MRU, you might have limited time to get your insights executed. You may not see your product getting fixed permanently. Still, this shouldn't prevent you from executing #1. You can apply #2, #3 or #4 to get your insight executed, and in parallel, you can keep working on #1.

Note that we haven't included undocumented coaching in the stack rank, because it is not a permanent solution. You should document your coaching to create a permanent solution.

Last updated