How was MuniSight able to double its client base within a year, without losing that person-person interaction? This post explains MuniSight’s POD based service model, and how we arrived at that solution.
About our business, and our client’s requests
Municipal governments have unique needs – they don’t behave like businesses, and they certainly don’t behave like consumers.
Based on MuniSight’s experience, Municipalities require person-person interactions to help advise their decision making. Although we do receive many “transactional” requests that are quite simple to execute, we also receive a relatively high number of complex requests that cannot be solved by following a step-by-step guide. In a sense, a lot of these requests are almost like consulting activities – giving advice on how to tackle a specific problem. It is not uncommon for us to receive requests that take 20 man-hours to resolve. For this reason, the person-person interaction is key, and therefore MuniSight has always serviced its customers in a way that is a bit different than most other software or service companies.
Before – large pool support model
Since MuniSight’s start in 2002, and up until last year, the way that we served our clients remained relatively unchanged. The process was quite simple – a client request would come into our support line (phone or email), it would be triaged by a Technician, and then the request would be assigned to another Technician for completion. The triage part was the only step with any degree of complexity, and involved a Technician reviewing the request as soon as it came in and writing guidelines on how to solve the request after trying to understand what the client was asking for. The triage step was critical in ensuring that our team prioritized requests properly, and processed requests most efficiently.
Before: Large Pool Support Model
This model worked very well when we had a small number of clients, and when that number of clients did not change (in other words, when we were not growing). The model worked because we were able to quickly dispatch requests into a large pool of technicians, with different areas of expertise and focus, so we could always find the right person for the job. In addition, having a small client base enabled us to maintain strong person-person relationships, to make sure that our clients got the most out of our services.
The large pool model came under strain when our business started to grow. In early 2018 our business started to gain traction with new clients across Canada. Consequentially, our service team had to grow from 6 technicians to 11 technicians in one year to keep up with the demand. When this growth happened, the person-person relationships were lost, causing clients to become frustrated with how we communicated with them. Many things got lost in correspondence, causing MuniSight to drop the ball on many service requests.
After – POD support model
MuniSight’s service team started to see signs of a decrease in service quality as early as April 2018, due to the team’s inability to keep up with our growth. Our business did a good job of hiring talented team members as we grew, but no matter how many team members we hired, we could never seem to keep up.
“In the POD model, each client has access to a dedicated set of Technicians.”
After consultation with our clients, and senior members of our service staff, we concluded that the person-person interactions had been lost as our business grew. Because we know that the person-person interaction is so important to Municipal Governments, we decided that we had to try to find a way to find that place again – and along came the idea of a POD model.
The concept of the POD model is quite simple. We asked ourselves this: instead of channeling all requests through one technician and then delegating tasks to specialist technicians (large pool model), why don’t we pair up teams of technicians with teams of clients? So, we took our team of 13 technicians, divided them into 3 balanced groups, and then paired each of these groups with a set of clients. We then built a system to process incoming client emails and phone calls, so that they would be automatically routed to the correct group of technicians. Emails from clients in the 2nd POD, go to the POD-2 Technicians, while phone calls from the 3rd POD, go to Technicians in POD-3, etc, etc.
In the POD model, each client has access to a dedicated set of Technicians.
Now: POD Service Model
This change was beneficial for a few reasons:
-
Better Client-Technician communication – It enabled technicians to work directly with clients, instead of having to go through a request dispatcher;
-
Improved Technician knowledge – Technicians became more familiar with the unique considerations of each client’s deployment, so their solutions were better tailored to the client’s needs;
-
Building Client-Technician relationships – Clients were able to develop a better relationship with our technicians because they interacted with them on a more frequent basis;
-
Increased “Time on Tools” – our Technicians now spend more time doing work, rather than trying to figure out what work to do;
-
Better Client empathy – strong person-person interactions enable our Technicians to get to know the challenges that our customers face, and adapt solutions to best meet those needs; and
-
Improved Technician collaboration – now that our technicians are in small teams, they work better as a team. Communication in a group of 4, seems much more effective than communication in a group of 13.
We took the time to strategically design each client POD, by grouping clients with similar needs together (Albertan Towns together, Manitoban Rural Municipalities together, etc), which helps our technicians become familiar with the differences between client regions. On the Technician side, we designed each group to be well-rounded by putting technicians with varying skillsets, and experience, together.
Even though the POD model has made a significant net-positive impact on our clients, there have been some downsides, including:
-
Email first response time has gotten longer – because we no longer have a dedicated dispatch technician, it usually takes longer for us to get back to a client when they file a request;
-
Technician training requirements have increased – to ensure that each POD has qualified and capable technicians, MuniSight has had to invest more resources into training our Technicians on various areas of support and service. For example, now all Technicians need to be trained at how to communicate properly with clients, instead of just one Technician being capable in the large pool model;
-
Lower work-rate efficiency – because Technicians are no longer pigeon-holed into specific tasks, they are now generally less efficient at doing specific tasks; and
-
Customer support cost has increased – increased training requirements, and a lower work-rate efficiency, have increased the overall cost that MuniSight has to pay to support its clients.
It is worthwhile to note that we also experimented and considered other support/service models, such as tier-based support. In a tier-based system, requests are gradually escalated through tiers of technicians to help try and make service delivery more effective. Although this would have lowered MuniSight’s customer support cost, we found that it was very impersonal, and therefore would not meet our client’s needs.
Getting better today, then we were yesterday
Even though we have made improvements to how we deliver service to our clients, we are still hungry to improve. So, we openly invite any Client, or anyone for that matter, to weigh in with their thoughts on our new customer support model. So far, both MuniSight’s Clients and the company itself have been happy with the change, and we look forward to hearing any ideas on how to further improve. Contact us with any comments or questions that you may have.
