One of the keys to MuniSight’s success was the person-person interaction that we were able to maintain with our customers. Our customers valued this interaction greatly, and it was a differentiator for us in the market. So obviously we were a bit worried when our customer base doubled within a year, and we had to find a way to ensure that we kept this person-person feel. This post describes the POD service model that we built to solve the problem, and some of its advantages and disadvantages. This post was originally posted on munisight.com in January of 2019.
About MuniSight, and requests from their clients
MuniSight services Municipal government and these 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 the company received many “transactional” requests that are quite simple to execute, MuniSight also received 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 use 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 2018, the way that the clients were served remained relatively unchanged. The process was quite simple – a client request would come into the 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 basically 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 the team prioritized requests properly, and processed requests most efficiently.
This model worked very well when MuniSight had a small number of clients, and when that number of clients did not change (in other words, when the company was not growing). The model worked because MuniSight was able to quickly dispatch requests into a large pool of technicians, with different areas of expertise and focus, so MuniSight could always find the right person for the job. In addition, having a small client base enabled the company to maintain strong person-person relationships, to make sure that the clients got the most out of MuniSight’s services.
The large pool model came under strain, when the business started to grow. In early 2018 the business started to gain traction with new clients across Canada. Consequentially the service team had to grow from 6 technicians to 13 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 MuniSight communicated with them, and many things got lost in correspondence, causing the company 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 team’s inability to keep up with the growth. The business did a good job of hiring talented team members as the company grew, but no matter how many team members were hired, MuniSight could never seem to keep up.
After consultation with clients, and senior members of the company’s service staff, MuniSight concluded that the person-person interactions had been lost as the business grew. Because MuniSight knew that the person-person interaction is so important to Municipal Governments, they decided to try a way to get that – and along came the idea of a POD model.
The concept of the POD model is quite simple – instead of channelling all of the requests through one technician and delegating tasks to specialist technicians (large pool model), why don’t we pair up teams of technicians with teams of clients? So, MuniSight took a team of 13 technicians, divided them into 3 balanced groups, and then paired these groups with a set of clients. MuniSight then built a system to process incoming client emails and phone calls, so that they would be automatically routed to 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 POD3, etc, etc.
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 the technicians because they interacted with them on a more frequent basis;
Increased “Time on Tools” – the Technicians now spend more time doing work, rather than trying to figure out what work to do;
Better Client Empathy – strong person-person interactions enabled the Technicians to get to know the challenges that the customers faced, and adapt solutions to best meet those needs; and
Improved Technician collaboration – now that the technicians are in small teams, they work better as a team. Communication in a group of 4, seems much more effective that communication in a team of 13.
MuniSight 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 helped the technicians become familiar with the differences between client regions. On the Technician side, MuniSight 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 clients, there have been some downsides including:
Email first response time has gotten longer – because MuniSight no longer had a dedicated dispatch technician, it usually took longer for the company to get back to a client when they file a request;
Technician training requirements has increased – to ensure that each POD has qualified and capable technicians, MuniSight has had to invest more resources into training 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 would therefore not meet the client’s needs.