When the topic is complicated, threads are often long, stale, or both. Often, support is distributed across the globe. It’s not surprising to see several people participating in the discussion.
If I am a support person in Europe, I may wake up and start working on a thread that starts in North America. The thread continues being worked in Asia Pacific. It then ends up in my hands without a resolution.
I may not able to resolve it myself. Maybe I don’t know how to resolve it. I may also not have the engineering teams available in my timezone. Instead of leaving the thread untouched for the North America folks to handle, I can drop a summary for my colleagues to see.
Here are a few characteristics of a good summary:
- It has a cleaned up version of the original problem
- It includes all the things folks have checked and discovered so far, along with any assumptions
- It lists what remains to be checked or any unanswered questions
- Reading the summary should be a lot faster than reading the whole thread
Why would you want to spend time doing that:
- Sometimes it helps you reach a resolution yourself
- It saves a huge amount of time from whoever tries to move the thread forward, especially if they weren’t involved before
- It helps engineers help Support as they don’t have to read a long thread to understand what’s left to be addressed
- It promotes team work
- It helps future readers (new hires), learn how the team thinks about and investigates problems because you leave a nice trail of summaries and prior art
What can go wrong:
- It takes time to write a good summary so often folks avoid doing it, especially if they are under pressure
- If you interpret something wrong, or you leave something crucial out, you may derail the whole thread and the result may be the opposite of what you were hoping for
In some cases, it even makes sense to create a version of the summary for the customer. Instead of just creating a summary for the next support shift, you also update your customer. That way, you double the value of your work. I have found progress reports is a valuable tool when the resolution takes time.
Leaving a summary is not just useful in support threads. You can also try it when you communicate in writing. For example, if you are about to add a long comment to a GitHub issue, you can include a summary of your main points as the last paragraph.
Summarizing the interactions and findings in a support thread may help you figure out the solution. It may help your colleagues in Support save time before continuing the investigation. You can share a tweaked version with the customer as a progress report.