Problem
Our support team was falling short of response time and resolution SLAs. This caused escalations, user frustration and churn.
Solution
To write and launch an auto-assistant to instantly answer most commonly asked questions.
KPIs:
To reduce the time support agents spent giving basic troubleshooting by 50%, only escalating to agents if unsuccessful.
To auto-escalate certain ticket types to CSMs, removing the need for manual escalations.
To direct users to the right resources and training material for FAQs.
To improve our CSAT (Customer Satisfaction) score by 30%
Outcome:
Agents providing basic troubleshooting decreased by 60%.
A 44% decrease in users contacting Support to request schedule changes.
CSAT score - in progress.
Learnings:
Capitalisation in buttons isn’t consistent. Some is sentence case some is title case. A style guide may have helped me ensure consistency, as well as more time.
Context
As a SAAS business for retail clients globally, our customers are time-poor and across different time-zones. Troubleshooting needs to instantly-available and non-technical. Our support agents were stretched and data revealed they were spending a lot of time repeating initial steps to users (a reboot fixed 70% of playback problems). To save time and resources, we decided to provide initial troubleshooting via a bot.
Approach
I had a meeting with our Integration Specialist and we walked through how to create an auto-assistant. I decided to:
Start with the most common reasons users contact us, and group them into categories: Curation, Billing, Playback and General Account queries.
I would create a flow using https://app.diagrams.net/, as the UX in Freshdesk was clunky, and it would be easier to edit.
We would capture as many details as possible from the user in the bot, reducing the manual time spent by agents.
Give users the option to "connect to a real person" at various touchpoints to minimise frustration.
Auto-assign certain tickets straight to CSMs.
Challenge 1: How to fix the problem
The design and support teams discussed why and when users experience issues, and if it would be better to try and mitigate these in-product by:
Adding an FAQ page
Writing tooltips or pop ups to provide helpful information when users are setting up
Revisiting onboarding
Rewriting our Help Pages
But as a mature start-up our design team was stretched, roadmap was full and we needed an immediate fix with minimal resource.
Solution:
I offered to write and launch the chatbot with a 2 week turnaround.
Challenge 2: Establishing tone of voice
We needed a consistent tone of voice for the bot but we didn’t yet have formal voice & tone guidelines existed at business level. We scoped putting one together that would need the directors’ sign-off on, but due to time restraints I was asked to write the bot first. We knew this wasn’t ideal from a content strategy perspective, but the director wanted a quick win.
Solution:
Data showed that user types contacting Support weren’t technical. Using my frontline knowledge of how users speak and the language they use to describe issues, I created a conversational flow without jargon. Time restraints meant we were limited to hallway tests and team members worked through different flows. This allowed me to check language and grammar, spot errors, and launch quickly.
Challenge 3: Freshdesk limitations
Freshdesk couldn't detect natural language for agent escalation—tickets could only be routed after a user selected a predefined option.
Solution:
I carefully chose touchpoints where the user might experience frustration. There, I provided the option via a button to connect to a ‘real person’ or tell us if this had not answered their question, connecting them to an agent. These optional exits ensured fast escalation when needed without relying on NLP triggers.
Challenge 4: Handling permission-based curation requests
Curation Requests made up 40% of conversations, but only some users were allowed to make these changes. The bot couldn’t verify users’ identity.
Solution:
I added a question to the flow —“Are you authorised to make these changes?”—with options “Yes” and “Not Sure.”
“Yes” triggered a data capture flow that we could store for refrence
“Not Sure” asked users to have their Admin contact us.
This simple gating mechanism reduced unauthorised requests and allowed us to record who’d requested changes.