Remember my last article about how we monitor flespi network availability from multiple locations? We created a special backend tool for this on top of flespi that uses HASD technology to store availability data and a special frontend application to visualize it.
Today I would like to open a backdoor and show you another application — the one that we use on a daily basis to support our users. From the customer side, it is called HelpBox and from ours it’s TeamBox.
TeamBox is integrated with flespi via internal and external API, heavily uses MQTT for events and data processing, relies on Telegram to deliver notifications 24/7/365, consists of backend and frontend parts, and is driven by HASD.
Harbingers of change: the story
Last spring during the “break” between the second and third waves of COVID-19, the flespi team was overloaded with incoming requests from our users. We were bombarded with versatile questions — from device selection advice and protocol parsing schema adjustments to the integration of new devices and fine-tuning of analytics configuration.
As you may know, our support is provided not by dedicated people but by the entire team which is 80% engineers. And as an engineer, you always want to work on “serious staff” and see the results of your work. The customer support process with a lot of incoming questions (often in parallel) and constant context switching makes it difficult to concentrate and solve complex tasks. Having worked in such a hectic mode on a regular basis for weeks and even months, we noticed that our scheduled deep tasks kept being delayed further and further.
We found the situation very upsetting and Jan even wrote an article with a flespi developer confession to convince everybody that this is normal. But even though the article is really good and honest, this is not a normal situation. There were three ways out of it:
expand flespi team with new people;
deprive flespi users of instant high-quality support service, or restrict access to it for non-commercial customers;
change the support process
I didn’t like the first two options. They are counter-efficient in our rapidly developing and highly competitive world. I believe in the third way — in order to be more productive, you need to evolve. The demand that was higher than our throughput was a great opportunity and stimulus to change, optimize, and become better.
The change: dispatching
So, we decided to change our support process. We introduced a dedicated dispatcher role that is assigned to a team member who will
communicate with users,
empathize with their emotional distress when needed (yep, sometimes we work as psychiatrists),
solve basic tasks,
and collect all the relevant information about complex tasks that will require assistance from other teammates more competent or familiar with the subject area.
The person during the dispatching process is free from any other flespi-related work except support. The primary task is to communicate. When there is nobody to communicate with, they can study something new — AI usage in telematics or a new approach in frontend application development for example. Meanwhile, all other members of our team will concentrate on their scheduled tasks, will dive as deep as the task at hand demands, and will operate in a super-productive interruption-free mode.
We also modified our support tools accordingly and added the dispatcher mode for a supporter. When one of us enables the dispatcher mode, all others exhale with relief will only receive new support requests if the dispatcher doesn’t react to incoming messages within the preset time (the reaction time, as well as the delay time, are configurable). The role of the dispatcher for each workday is distributed among team members depending on the workload, eagerness, vacation, and other factors.
And it worked!
Being a dispatcher is an interesting role requiring constant multitasking, agility, and broad awareness of all aspects of the flespi platform. On the other hand, this role helps the person develop these three competencies by working in a dynamic and unpredictable environment.
At the same time, the productivity of our team has significantly increased. According to our internal logs for the last 12 months, we integrated on average 1-2 (rarely 3) new protocols per month. In June, after introducing the new support process, we integrated 6 new protocols with the same team followed by another 6 in July. Basically, we doubled our productivity in this area with a simple change in the way we support our users.
The tool: TeamBox
Here is how our tool looks like during an ordinary support process:
The left vertical pane shows chats with flespi users. Based on their region and Commercial/Free status or extended SLA level they have a bezel of a different color around their avatar.
The central part of the screen shows an active chat with the user. Gray messages are from users, blue messages are from flespi support, and orange messages are internal comments (that users cannot see).
The right vertical pane includes extended information about the customer (company info, project details, etc.) and handy support tools. We instantly see account counters on the same dashboard as you see in your flespi.io account. We have quick access to all media posted into the chat. We can pin posts with important information, link flespi users between each other, generate a support token for the account, and use it to access various flespi applications to visually explore the issue.
The system: Flespi CRM
This year we also started to build our own CRM right inside the TeamBox support tool. For me, customer relationships are inseparable from support. Moreover, good relationships with the technical product companies can only be based on a stable history of technical communication between the two parties. That’s why from the very beginning we focus on the quick and efficient support of our users. That’s why the support team and the engineering team are the same team — the guys who initially created the platform and maintain its operation on a daily basis. It’s hard to be the judge to self, but I believe that the support level we are providing is excellent in terms of quality and agility. It was so initially and the recent change of the support process allowed us to keep it at the same level for a much larger volume of communication.
Our CRM is quite simple — it includes organizations, activities, links, and some additional information stored in order to effectively organize the sales pipeline:
We decided to develop it in-house because flespi HASD is an extremely good technology to quickly create applications. Efforts required to integrate any third-party CRM tool into our processes will be more or less the same. And of course, our requirements for the CRM are quite minimalistic.
HASD technology is not only about making efficient event-driven web applications. No, we have quite a few backend-only services that use it instead of storing data in standard SQL-type databases like PostgreSQL. For example, our automatic parsing errors detection and reporting tool is also based on HASD. From year to year, we see clear benefits of this technology, and each day we make it more and more usable in the application development process — be it GUI applications or backend-only services.
***
Guess what can bring more satisfaction to the developer than quick application creation on their own platform? What can be more fascinating than becoming a flespi user yourself and using your own platform in the same way as your customers do? Nothing can compare with this feeling of proudness that we feel. This is the best motivation to change from day to day to a more and more convenient tool for everybody. Because there is no limit to perfection.