Support With a Clock on It
Every request in one queue with an owner and a deadline, response times measured against the commitment you actually made, and a knowledge base that reduces the volume rather than just organising it.
Support work has an unusual property: when it is done well nobody notices, and when it fails the failure is visible to a customer. That asymmetry means support teams are judged on their worst cases, and the worst cases are almost never the hard technical problems. They are the requests that were received and then forgotten.
Requests get forgotten for a structural reason. They arrive by email to an individual, by Zalo to a mobile phone, by telephone to whoever picked up, and through a form on the website. Four inboxes, no shared queue, no owner, no clock. The team can be working hard and still lose one in ten, and nobody can say which ten.
iGlobal implements helpdesk so that every channel lands in one queue, every ticket has an owner and a due time derived from the service level you committed to, and anything approaching its deadline is visible before it breaches rather than after a customer complains.
Why support feels busier than the numbers suggest
A large share of support volume is the same few questions asked repeatedly. Without categorisation nobody can prove this, so the response is to hire another agent rather than to fix the cause. Three months later the queue is the same length with one more salary attached to it.
The second drain is status chasing. When a customer cannot see what is happening with their request, they ask, and the asking is itself work. Support teams frequently spend a quarter of their capacity answering questions about work rather than doing the work.
The third is that knowledge stays in heads. The agent who has been there four years resolves in minutes what takes a new colleague an afternoon, and when that agent is on leave the queue lengthens visibly. Nothing is written down because writing it down was never part of closing a ticket.
- Requests arriving in four places with no shared queue
- No reliable measure of how long a response actually takes
- Customers telephoning to ask what is happening
- The same question answered from scratch every time
What the helpdesk system covers
One queue for every channel
Email, web form, Zalo, telephone logged by the agent and tickets raised internally all arrive in the same list, with the customer recognised automatically where possible.
Service levels with a visible clock
First response and resolution targets by priority and by contract, counted against your working calendar, with tickets approaching breach escalated before the deadline rather than after.
Routing and ownership rules
Tickets assigned by product, customer tier or skill the moment they arrive, so nothing waits in a shared pile for somebody to volunteer.
Knowledge base that reduces volume
Articles written from resolved tickets, searchable by customers on the portal and suggested to agents while they type, so the answer is reused rather than recreated.
Customer portal with real status
Customers see their open requests, the history and the expected response time, which removes the status telephone call rather than redirecting it.
Reporting that points at causes
Volume by category and by product, repeat contacts, resolution time by agent and the service level achievement rate, so a recurring cause can be fixed instead of absorbed.
How we deliver it
-
1
Service level and category design 1 to 2 weeks
We agree the priorities, the response commitments you can actually meet, and a category list short enough that agents will use it honestly.
-
2
Configuration and channel capture 2 to 3 weeks
Queues, routing, escalation, templates and the connections to email, the website form and Zalo, tested with real traffic before the team depends on it.
-
3
Agent rollout 2 weeks
Training at the desk on live tickets rather than in a classroom, with the old inboxes redirected rather than left open so there is no quiet route back to the old habit.
-
4
Portal and knowledge base launch 2 to 4 weeks
The first articles are written from the most repeated tickets, and the customer portal opens once the internal process is reliable enough to be seen from outside.
Who this is for
- Companies selling equipment or software with a support obligation
- Service businesses with contracted response times
- Teams receiving requests through four or five channels at once
- Internal IT or administration departments serving staff
Why iGlobal
We set commitments you can keep
A service level that is routinely breached teaches everyone to ignore the clock. We would rather configure a target you meet ninety per cent of the time and tighten it than publish an ambitious one nobody respects.
Connected to the customer record
Because support shares a database with sales and operations, an agent sees what the customer bought, when it was delivered and what they were promised, without asking another department.
Aimed at reducing volume, not managing it
The reporting we build is designed to surface recurring causes. A helpdesk that only organises tickets makes a problem tidier; it does not make it smaller.
The best balance of cost, quality, and service
No charge per agent seat that discourages you from giving access to the people who should have it, and no limit on tickets or contacts.
Three ways to do this, compared
| What you are comparing | By hand, on spreadsheets | Off-the-shelf software | With iGlobal |
|---|---|---|---|
| Where a customer request arrives | A personal inbox and somebody's mobile number | A portal that customers quietly refuse to use | Email, Zalo, phone and portal landing in one queue |
| The promise about response time | An intention that nobody ever measures | A field on the ticket that nothing actually enforces | A clock that escalates the case before it breaches |
| Problems that keep coming back | Solved again from scratch every single time | Tickets get closed, but the pattern stays invisible | Causes grouped, with the top three put in front of management |
| Cost across three years | Hidden inside salaries, so it never appears in a budget | A predictable licence per user, plus the work it cannot do | Quoted per phase and reviewed with you before each one starts |
| Who holds your data | Scattered across files, inboxes and personal phones | On the vendor platform, exported on the vendor's terms | Your own database, exportable in full whenever you ask |
| When something breaks | The person who built the file, if they still work here | A ticket queue, often in another language and time zone | A named engineer in Hanoi you can reach the same working day |
The two middle columns describe approaches that genuinely work for some companies. Where they win, they win, and we have tried to say so.
What changes after go live
The first change is that requests stop disappearing. A single queue with an owner means the ten per cent that used to be lost in somebody's personal inbox are now simply late at worst, and late is a problem you can see and manage.
The second shows up in the volume figures after a quarter. Once categories are reliable, the two or three causes generating most of the contacts become obvious, and fixing one of them at source removes more tickets than a new hire would have absorbed.
The third is that the team stops being hostage to its most experienced member. With answers written down as they are discovered, a new agent reaches useful productivity in weeks, and the senior agent spends their time on the problems that genuinely need them.
- Every request owned, with a deadline, in one queue
- Service level achievement measured instead of assumed
- Status telephone calls replaced by the customer portal
- Recurring causes identified and fixed at source
Frequently asked questions
Can customers send requests through Zalo?
Yes, and for Vietnamese customers this is often the channel they actually use regardless of what the contract says. Messages from a Zalo Official Account become tickets in the same queue as email, and replies can go back through Zalo so the customer stays in the channel they chose.
How do we stop agents choosing the wrong category?
Keep the list short. Most category schemes fail because they have forty options and an agent in a hurry picks the first plausible one, which makes the reporting worse than useless. We start with eight to twelve categories, review the distribution after a month, and split only the ones that have earned it.
Does the customer portal create more work?
It reduces work, but only if the status shown there is genuine. A portal that says in progress for four days teaches customers to telephone again, so we do not open it until ticket updates are a reliable habit internally. Launching the portal too early is the most common way this project disappoints.
Can we use this for internal IT support too?
Yes, and many clients run both with separate queues and different service levels. Internal support benefits particularly from the reporting, because an IT department that can show where its hours actually go is in a much stronger position at budget time.
What if our team resists logging every request?
Then the logging is too slow, and that is a design fault rather than a discipline fault. Creating a ticket from an email or a telephone call should take seconds, not a form with twelve fields. We cut the mandatory fields to the minimum that makes the reporting work and leave the rest optional.
Related solutions
Talk to a senior consultant, not a call centre
Tell us what you are trying to fix and we will tell you honestly whether we are the right team for it.