The traffic bot reduces customer wait times and assists support team members by gathering preliminary complaint data - allowing them to immediately focus on problem solving.

Project type
Service design
Timeline
2 weeks
My role
Bot architecture, logic + implementation
Deliverables
Chat traffic bot

Project brief

Vermeer introduced a support chat feature with the launch of their new customer and dealer portal. This was a big step for the team, as support scenarios had previously only been handled through phone calls and emails. As the userbase steadily grew, the customer support team started to feel the pains of managing different contact channels. Especially the two immediate contact methods - phone and chat. The team approached UX and asked if there was any way to streamline the process and make chat less disruptive.

Process

I started off by combing through historical chats to identify the most common support inquiries and themes. Throughout my discovery, I also noticed frequent inefficiencies in the current setup:

- Support team members were spending a lot of time going back and forth with customers to gather initial complaint details. Often, these steps were repeatable. I also found that any lag in response during initial inquiry would cause frustration for the user.

- Chats would go through multiple rounds of hand offs before arriving at the support person that could answer the question. This seemed to be caused by a combination of eager team members wanting to empty the support queue and a lack of context when starting a chat.

I arrived at the idea of creating a basic bot to help gather initial chat details and direct traffic. However, I knew I would face some headwind, as there was a general apprehension towards bots amongst our customers and within the company. I was often reminded that “customers don’t want a bot” and that “they would rather speak to a real human.” While I recognized these hesitancies, I also couldn’t forget about the humans that were supporting the chat and struggling to keep up. Customers didn’t not want a bot - they just didn’t want an unhelpful bot.

I knew I needed to create a solution that would satisfy all parties.

The Solution

The end result was what I dubbed a “dumb bot.” I made this distinction to illustrate the point to our internal team that this bot had been manually created with very strict logic and was not the open-ended bot they were worried about. I pitched the bot as an additional member of our support team - one that helps automate the chat intake process. The traffic bot helps gather initial complaint data and directs traffic to the appropriate team.

<
Stanley app
>