Client

Ambie

www.ambie.fm

Project

Our external support team was falling short of first response and resolution time SLAs in 28% of live chats.

I was tasked with planning, writing, and launching an auto-assistant to provide immediate answers to 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.

As a SAAS business supporting non-technical users globally, it’s important for us to provide immediate answers to FAQs and expedite troubleshooting for those needing instant support. For example, a reboot fixed 70% of simple problems. We would save time and resource walking users through this in a bot.

Approach

I had a meeting with our Integration Specialist, and we walked through how to create an auto-assistant. I decided to:

  1. Start with the most common reasons users contact us across Curation, Account queries, Billing and Technical

  2. Split those groups into subgroups related to those reasons

  3. Capture as much information from the user in the bot as possible, reducing the amount of manual verification needed by Support

  4. Offer troubleshooting in the bot, while giving the customer the option to "connect to a real person" at various touchpoints

  5. Auto-assign certain tickets straight to the CSM Team

We could have created these flows directly in Freshdesk but the UX isn't straightforward, so I started creating flows using https://app.diagrams.net/.

Challenge:
My first challenge was establishing our tone of voice. I knew we could convey our 'friendly, informal' voice using contractions and interjections, and change tone depending on where the user is in their journey. For example:

  • “Fun/Excited” during onboarding vs

  • “Neutral/serious guiding through setup

But we needed voice / tone guidelines at business level that we could stick to. Since the bot facilitates a conversation, I felt it was a good opportunity to establish this now.

I offered to put together a voice and tone framework that we would need the directors’ sign-off on, but due to time restraints it was decided that the bot would be done first. I was given creative control.


Solution:
As the main point-of-contact and the escalation point for customers, I knew how our users spoke, what language they used, and their needs at different touch-points. I knew that the bot would mostly be used by Ops Directors and Managers (rather than IT staff) so with limited time, I created a conversational flow that kept language simple, friendly, and without technical jargon.

Challenge:
One of Freshdesk's limitations is that you can only assign a ticket to a group e.g. "a real person" or "Customer Team" once the user has selected an answer. At the time, we couldn't set a rule that allowed the user's natural language to be detected which would trigger a connection to an agent. 

Solution:

I carefully chose touchpoints where the user might experience frustration. At those points, I gave them the option to connect to a real person or tell us if this had not answered their question, instantly connecting them to an agent.

Challenge:
A Curation Request was one of users' most common contact reasons (42%) so we needed to process these via the bot. Our challenge is that some users are allowed to make these changes and some aren’t. In live chat, an agent can check whether they have this permission; in the bot there was no way of knowing for sure.

  
Solution: 
I decided that if a user chooses "Curation Request" as the contact reason, the first thing they're asked is "Are you authorised to make these changes?" This tells them that only certain people can take this action. We gave them two options, avoiding "No" as it sounds like it leads to a dead end.

  • Yes

  • Not Sure 

If the user selects "Yes", we capture their details, recording who’s made the change. If they select "Not Sure" we apologise, and tell them their Admin user needs to contact us.

(Of course, the user could open a new conversation and choose "Yes" so it's not fail-safe, but we already knew that junior staff don't tend to make changes they're not authorised to. This has been successful so far.

Outcome:

The auto-assistant has been live for one week; we're monitoring performance over the next month. Outcome to follow.

More projects