May 7, 2020 9:46:04 AM
Solvemate is still a fairly young company—we were founded in 2015—but we have dozens of chatbots in action internationally by now. The majority of them went live within the last 1.5 years. Yes, “that escalated quickly”. 😉
With having these chatbots out there, a lot of learning took place, a lot of feature requests from our customers came in, and a lot adjustments were made. And still the journey is just at the beginning.
At first, feature requests were handled by our customer success team in close collaboration with the product managers. In the very early days, it was a great position for the product managers to be in - in close proximity to our customers, learning first hand what they needed and how they used our product.
Now, with a multitude of customers live and a more mature product, product managers needed more time to analyse the data, do the research, run user tests, and so on. Thus, their main role no longer allowed them to spend loads of time on calls and meetings with all of our customers. On the other hand, the need for technical assistance of the customer success team was still there.
To solve this conundrum we recently—early 2020—hired our first support engineer. Spoiler alert: We should have done it way earlier. 😉
A Solvemate support engineer is almost 100% dedicated to resolving any technical issues our customers face. She uses her skills and knowledge as a developer to support our customers. Not every customer service team can get in-house developer support, so even something as “simple” as building an API call to get customer information might be out of their reach - and that’s where our support engineer would come in! She also reacts to bug reports, fixing them or—if this is not immediately possible—at least categorising them for her developer colleagues to address.
Buckle up! I’ll now go into the five reasons why we should have hired a support engineer much earlier and how important the role is, especially for our customers.
Let’s face it: at the pace companies – like Solvemate – move, there will be bugs on the platform. We always strive for high code quality on our deployments and automated tests, but in a tech-world that is constantly moving, a bug here and there is inevitable.
Before having put a support engineer in place, bugs reported by customers and the customer success managers landed on the desk of the product managers. This caused multiple problems:
...Ultimately, this resulted in lower level of quality for a longer period of time
Now, with our support engineer in place, we’re proud of our bug process. Bug reporters get a super fast reply (usually under two working hours response time for non-critical bugs). And it does not stop there. Since a support engineer also has more development skills than a product manager, some bugs can be simply “fixed on the fly” as they arise and if that is not possible, the support engineer pre-qualifies the bugs, which decreases the time-to-fix significantly.
A support engineer who takes charge of the end-to-end bug process is first and foremost a big win for your customers, but also your team and your platform.
Customer service teams have a hard time getting developer capacity. That’s why Solvemate is on a mission to become a non-code platform. But—just like Rome—a non-code platform isn’t built in a day.
In the meantime, we offer our customers support to develop their “Routines” (an additional feature of ours), ultimately bringing more personalisation capabilities to their chatbots.
Why is that important? Chatbots without automations are–in most cases–a slightly condensed and improved version of the FAQs. The main value drivers of chatbots lie in well-executed automations that help personalise the customer requests. This can be achieved with our routines, which ensure that the customers of our customers get their issues solved as fast as possible – without needing a customer service agent to get involved. Personalisation with chatbots can help execute tasks that would normally require the service team to step in.
It is Tuesday evening. You order a gift for a friend or new running shoes in an online shop. You receive an order confirmation, but then… dead silence.
Three days later you come home from work and wonder why the parcel wasn’t delivered yet. You want to reach out to the shop’s customer service, but the hotline is already off.
Sure, the FAQ-like chatbot would tell you that you should call between 10:00 and 18:00 from Monday to Friday—and of course today is Friday–or send an email and they will reply within two business days.
Bad luck… you will not be able to give that birthday present to your friend or you take advantage of the nice weather this weekend to use those new running shoes.
A chatbot powered with routines would instead allow you to enter your order ID and by submitting it, quickly find out where your delivery is hiding, using the most up-to-date information directly from the carrier, e.g., DHL or RoyalMail. And it turns out that the gift for your friend or your feet 😉 was delivered to your neighbour. The mailman—also just being human—just forgot to place a notification in your postbox.
Another classic case of weekend saved and contact deflected. 👏
In the weeks after we hired a solution engineer, we tripled the amount of personalisation automations in place. On the chatbots where we added a routine, the self-service rate increased by more than 35%.
Documentation can be of tremendous value, period. Nevertheless, moving in a high paced environment with a small team, we often neglected our documentation.
A perfect example are our release notes. As mentioned, we move at a high pace. This means there are oftentimes significant changes applied to our product—in the widget as well as in the web app. Lately, there have been cases where we missed informing customers of these changes and they got caught by surprise.
This kind of situation came to an end in early 2020. Part of the role of a support engineer is to document technical knowledge in the form of notes and manuals - or, in this case, release notes. And that is exactly what happened. In February 2020 we released our product documentation.
Since then, it was put to heavy use by our customer success and sales team, while it constantly keeps growing as we add more and more information.
When interacting with customer service, people want their problems solved as fast as possible. Our customers are no different. And although we have always strived to provide fast answers in the past, we weren’t always able to live up to that—especially when there were very technical questions.
So, we had some catching up to do to help our customer success team. We did this by putting a support engineer in place. Now, when technical questions come up, our support engineer directly gets on the first call with the customer and the customer success team. This way, our customers already receive a first technical estimation and an outline on what a solution for the issue they reported could look like.
The support engineer will also from time to time jump on a sales call to clarify (technical) questions so the prospect can get all the information they need to make a more informed purchase decision. This is also a good example of how we live up to our culture deck core value of transparency.
Mix a constantly changing environment with the goal to deliver high-value solutions and a small team, and you have to be very strict with your resources. Often you focus on the big topics and end up dropping the details.
That changed for us once our support engineer joined and got up to speed. The best example of this are the improvements we’ve made on the regular expressions—in short RegEx, a method for pattern matching—for input fields of the automations she built.
For those who don’t know, in our routines you can use RegExes for the input fields. For example, when you want to use an order ID to get the according tracking information and your order IDs always follow a certain pattern, you can then add a RegEx that only allows your customer to add a string that matches that pattern. This reduces the chances of entering an incorrect order ID, and by doing so getting no information about the shipment.
Tweaking and testing these RegExes was kicked down the road because of other topics with higher priorities. But a few weeks after our support engineer joined, she took care of these RegExes and some other optimisations in one of our customer’s routine code, resulting in self-service rate on that chatbot increasing by 3% and as well as CSAT increasing by 5%. Details matter - and when we were able to pay attention to them, we made quite a few customers happier!
A support engineer can be “unleashed” to offer a lot of value.
In our case, having her on the team has led to improving existing automations and adding plenty of new automations. For example, thanks to her, we’ve already added an integration with parcelLab to track shipments, which ultimately led to a higher deflection and higher customer satisfaction of the customers of our customers. The faster bug response times and time-to-fix also increased our customer satisfaction.
Patrick is product manager at Solvemate. Although not being a developer himself, he is fascinated by both code and technology and how they can be used to solve problems. He is well aware of the challenges in customer service these days and he is eager to tackle them machine learning and automation.