A day of small requests
It is Monday morning and the support inbox has a dozen emails from customers. A new starter at the accountancy firm needs a user, a handset and a DDI. The dental group wants reception calls to ring the back office after six. A leaver at the estate agents has gone, so their user needs removing and their number pointing at the main line. Someone wants a new welcome message recorded. Someone else rings to say their hunt group is not working, and it turns out a colleague changed it themselves on Friday.
Your support engineers are good at this. Each change takes minutes on the hosted platform. The trouble is everything around it. The request came from someone you do not recognise, so is it authorised? The new user is a new seat, so does billing know? The removed user was on a rented handset, so where is it? The request that arrived by phone on Friday afternoon was scribbled on a note and is still not done.
At month end, the number of seats on the platform and the number of seats on the bill are different, and nobody can say exactly why.
Why moves, adds and changes leak
The phone platform and the billing platform are separate systems, and the change request itself is a message in an inbox.
- Requests arrive by email, phone, chat and in passing during other calls, so there is no single list of what was asked for.
- Customers do not always say what they need: 'add Sarah' could mean a user, a handset, a number, a licence tier and a voicemail box.
- It is not always clear who at the customer is allowed to request changes, particularly for removals and diversions.
- Chargeable changes (new seats, extra numbers, call recording licences) rely on the engineer remembering to tell billing.
- Removals reduce your supplier cost only if the seat is also removed from the wholesaler, which is a separate step.
Each request is trivial. The volume and the three separate follow-ups are what make it hard.
What the leak costs
| Gap | Cost |
|---|---|
| New seat added, not billed | Supplier cost with no revenue |
| User removed, still billed | Customer dispute and credit |
| Diversion changed without authority | Awkward call with the customer's director |
| Phone request never logged | Customer chases, trust drops |
| Seat count and bill never reconciled | Nobody knows which is right |
There is a time cost too. Engineers go back to customers to clarify vague requests, and account managers get pulled in when changes are disputed.
A change request flow built around your platform
- Customers get a simple request form, on your website or a small portal, with the common changes laid out: new user, remove user, change a call flow, new number, recording or voicemail. The form asks the right questions for each type, so 'add Sarah' arrives complete.
- Each customer has a list of authorised requesters. A request from anyone else is held for confirmation by an authorised contact before work starts.
- Requests from email and phone go into the same queue, with a quick form for engineers to log a phone request in seconds.
- Where your hosted platform has an API, routine changes (a new user, a diversion) can be prepared automatically for an engineer to check and apply.
- When a change is completed, anything chargeable updates the customer's services in your billing platform, and any removal creates the matching task to reduce seats with the wholesaler.
- At month end, seat counts on the platform, the wholesaler and the bill are compared per customer, and differences are listed.
The portal can also show customers what they currently have (users, numbers, handsets), which cuts the number of 'what have we got?' calls.
The support desk afterwards
Engineers work one queue of complete, authorised requests. The vague ones have already been clarified by the form. Billing changes follow the work, so month end is a check, not an investigation. Customers see their request logged, see when it is done, and can look up their own set-up.
And when someone asks 'who changed our out of hours diversion', there is a record of who asked, who authorised it and who did it.
Is your support inbox like this?
- Hosted phone changes arrive by email and phone with no single list.
- Seat counts on your platform and on your bills do not match.
- Engineers regularly go back to customers to find out what they meant.
- You are not sure who at each customer is allowed to request changes.
- Removed users are not always removed from the wholesaler.