The vast majority of questions we get at Olark are pretty simple, or at least quick for our talented team to resolve. A few times a day we get questions that are mind-boggling, unusual, new, or just plain hard to figure out. We have some unique and not-so unique strategies to unravel tough problems and reduce the wait time for our customers, all while thriving as a remote team. Let’s follow the path of one of these questions to see what happens!
The question
Roughly half of our support interactions start as chats on our site. Our questions begin here with a user running into some trouble and clicking on the chat bubble.
- For a question the Olarker isn’t sure about, they may use the command !slack in the chat to send that transcript immediately into our support channel, #support-stegosaurus. We affectionately call it Stego, for short.
- They also add some notes for the team like “why isn’t this user able to get transcripts to webhooks?” with a link to our internal tool “Olarkacle” (Oracle of Olark, get it? :joy: ) which is where we keep all our customer account information.
- If possible, we also share screenshots of what we see, as well as screenshots from the visitor and relevant site links.
Teamwork
Since we’ve organized our Slack into groups, adding a @cs to a message alerts the entire customer service team so they know someone is having some trouble. At this point, there are several sets of eyes on the problem. It’s even faster than getting folks out of a desk and off their headphones!
Upon release of a new feature, the development team picks a point person to hang out in “stego” to monitor things. The support team will ping them from Stego, or they simply watch for chatter about their feature to surface. This lets them catch any issues right away, or give more context for how to use the new feature.
Ideally with a few heads together, the problem is found, a fix described, and the customer has their issue resolved quickly. Occasionally though we find a bigger issue. It could be a bug in our software, a communications issue between tools, or something that just needs more resources to solve. In this case the chat is escalated to our Triage team.
The Escalation
In the chat, the Olarker uses the !tag command with details. In our webhooks example, that looks like !tag triage webhooks. The visitor is given information about what will happen next, and the chat ends.
With that triage tag, the conversation is sent immediately to our Triage Team (tier 2, or support engineering team) folder in Help Scout, where it’s marked active and ready for a note from the agent. The agent provides a link to the customer’s account, website, logs, the Slack conversation, and any other important information.
The support engineer now owns the ticket and starts by running through some debugging steps, searching documentation, and applying their own knowledge about Olark. If they are unable to solve the issue, they message the product team which owns the component(s) affected in their Slack room. At Olark we have a front-end team, a back-end team, and an integrations team, all with on-call slack rooms designed for this sort of troubleshooting.
Most often the engineer or developer responsible for the component spends a few minutes looking into the issue and has a solution. If not, Triage passes the JIRA ticket (made directly from the Help Scout ticket--slick!) to the engineer who volunteers to take point on it.
Triage follows up with the customer at this point to let them know what is happening, ask for any additional information (if needed) and then monitors the Help Scout conversation for future updates. In the case of a bug which affects multiple accounts, as the JIRA ticket is updated, those Help Scout conversations are reopened and the customers are contacted.
The component team may decide to speak to the customer directly to solve the issue, or they may just need a day or so to fix the bug. The team might do this via email, or through a video and screen share using Zoom.
Sometimes though, a component just doesn’t do what a customer is asking for, and the Triage team has the sad task of telling the customer the issue cannot be fixed now. However, we keep the Jira ticket and always contact the customer if we are able to deploy a related feature request.
Regardless of what happens, we always update the customer with as much information as possible. And that update is available by clicking on the JIRA ticket which has been the main document for the issue all along.
Some teams might look at this process and wonder where the remote struggles come in. The truth is we don’t know. Olark is a pretty tight group, who all work well together. With our mission statement for focus, and our values to direct our actions, working as a team remotely comes much more easily. Remote support doesn’t flow like this without intention and work from all team members, but we think it’s worth it for a super talented, diverse, dedicated company.
Want content like this delivered straight to your inbox?
