The Internal Helpdesk: IT, Facilities & Admin Requests That Stop Getting Lost
The largest pile of untracked work in most Kenyan organizations is not customer support — it is colleagues asking colleagues for things. Why internal requests are the best place to start, and what becomes visible the moment you log them.
There is a person in your organization who fixes things. They are not necessarily in IT. They know how the printer works, which cable goes where, who to call about the generator, and how to get a system permission changed. Everybody messages them directly, they handle it, and none of it is recorded anywhere.
That person is simultaneously the most useful and the most invisible resource in the business. Nobody knows how much of their week goes on it, whether they are drowning, what keeps breaking, or what happens when they resign. And because it is all internal, there is no customer complaining, so there is no pressure to find out.
Why start internally rather than with customers
Most organizations introduce a helpdesk for customer support first, which is the harder rollout. Internal is the better starting point for four practical reasons.
- Your colleagues are forgiving. You can adjust categories, targets and workflow in month one without damaging a client relationship while you learn.
- The volume is genuinely unmeasured. Customer support usually has some record — an inbox, a shared mailbox. Internal requests typically have none, so the reporting gain is larger.
- The cause is inside your control. When you discover a category generating thirty tickets a month, it is your printer, your process or your permissions — you can actually fix it.
- It protects a person. The colleague who quietly absorbs all of this gets a defensible record of their workload, which is often the first time anyone sees it.
Nobody is going to escalate an internal request to a manager. That is exactly why it goes unmeasured for years — and why the numbers, when they finally exist, tend to surprise everybody.
What internal requests actually look like
It helps to name them, because "IT support" undersells the range and leads organizations to define too few categories.
| Type | Typical request | What logging it reveals |
|---|---|---|
| IT — access | A permission change, a new user, a password reset | How much time goes on access admin; often a case for role templates |
| IT — equipment | A laptop, a printer, a scanner, a device that stopped working | Which equipment fails repeatedly — a procurement and asset decision |
| Facilities | Power, water, air conditioning, a repair at a branch | Which sites consume the most attention, and which landlords do not respond |
| Finance requests | A payment status, an invoice copy, a budget question | How much finance time goes on internal lookups people could self-serve |
| HR requests | A letter, a payslip copy, a leave query | Usually a case for self-service rather than more HR capacity |
| System issues | Something in the ERP behaving unexpectedly at a branch | Whether it is a bug, a training gap, or a process nobody agreed |
The last two rows tend to produce the most actionable finding. A high volume of internal lookups — payslip copies, payment statuses, leave balances — is almost never a capacity problem. It is a self-service problem, and it is cheaper to give people access to their own information than to keep answering. That is precisely what the employee self-service and no-login portals exist for.
Route by category, not by whoever answers
The default state of internal support is that requests go to a person because that person helped last time. It works until they are on leave, and it means workload distribution is an accident of social history.
Categories fix this structurally. Each category carries a default department and a default assignee, so a facilities request at a branch routes to facilities without the requester needing to know who that is. It also means the SLA clock attached to that category starts automatically — an access request and a broken generator get different promises because they are different categories, which is more honest than pretending one target fits both.
-
Define six to ten categories, not thirty
Enough to route and to analyse; few enough that people pick the right one. You can split a category later once volume tells you it contains two different things.
-
Set a default department and assignee per category
So routing is a property of the request rather than of who the requester happens to know.
-
Give each category its own response and resolution minutes
A password reset and a site power failure should not share a target. Category-level SLAs make the promise credible.
-
Log direct messages instead of refusing them
The person who receives a WhatsApp creates the ticket. This is the whole behaviour change and it takes about three weeks.
-
Read volume by category monthly and fix causes
The point is not faster handling. It is generating fewer requests.
Watch for the request that should not exist
The most valuable ticket in an internal helpdesk is the one that reveals a request nobody should have needed to make — a permission that should have come with the role, a report someone could run themselves, a document that should live where people look. Those tickets are not support work; they are a design brief.
Staff without logins still need a door
A real constraint in Kenyan organizations: a large share of the workforce has no system login. Drivers, casuals, production staff, site teams. If raising an internal request requires an account, those staff are excluded — and they are frequently the ones closest to the problems worth hearing about.
AWRA handles this with tokenized portals that work without a login, the same pattern used for leave and attendance self-service. A site supervisor with a link and a PIN can raise a facilities issue without occupying a licence or being handed credentials they will not remember. That is covered further in a support portal people will actually use.
What we do and do not do
What AWRA OpsHub does today
- Categories with default department and assignee routing, applied at intake.
- Per-category SLA targets (first response and resolution), with a pausable resolution clock.
- Owners, watchers, comments, internal notes and attachments on every ticket.
- No-login intake via tokenized portals for staff without accounts.
- Agent dashboard and queues, so workload is visible per person.
- Slack notification, so tickets surface where a team already works.
- Volume and resolution reporting by category — the report that lets you fix causes.
What it does not do
- No asset-request or change-management workflow in the ITIL sense — no change advisory board, no release management.
- No device management or remote support tooling — we track the request, not the machine.
- No public knowledge base for self-service articles.
- No telephony, so a phone call is logged by whoever takes it.
For equipment that recurs in tickets, the asset side lives in the asset register with custody and service schedules — the helpdesk records the request, the asset module records the thing.
The number that justifies the whole exercise
After a month, you will be able to answer a question nobody could answer before: how many internal requests does this organization generate, and what are they about. In our experience the volume is two to four times what management expected, and it is concentrated in a handful of categories.
That concentration is the opportunity. Three or four causes usually account for most of the volume, and they are almost always fixable — a role template that grants the right permissions at hire, a piece of equipment that should be replaced rather than repeatedly repaired, a report published rather than requested, a process written down. Each fix removes a recurring stream of work permanently, which is a different and better outcome than handling the same requests faster.
Our take
Start here, not with customer support. Define eight categories, route each to a department, log direct messages rather than refusing them, and read volume by category after a month. The finding you are looking for is the request that should never have needed to exist — and there will be several.
See internal requests that stop getting lost
Categories that route themselves, per-category SLA targets, no-login intake for staff without accounts, and the volume-by-category report that tells you what to fix.
Explore tickets & queuesFrequently asked questions
Why start with internal support rather than customers?
Because colleagues are forgiving while you refine categories and targets, the volume is genuinely unmeasured so the reporting gain is larger, and the causes are inside your control — when a category generates thirty tickets a month it is your printer, your permissions or your process, and you can actually fix it. It also gives the colleague who quietly absorbs all of this a defensible record of their workload, often for the first time.
How many categories should we create?
Six to ten. Enough to route requests to the right department and to analyse volume meaningfully, few enough that people pick the right one without thinking hard. Thirty categories means most are used once and the reporting is noise. Start narrow and split a category later when volume shows it contains two genuinely different kinds of work.
Can staff without system logins raise requests?
Yes, through tokenized portals that work without an account — the same pattern used for leave and attendance self-service. This matters more than it sounds in Kenyan organizations, because drivers, casuals, production and site staff often have no login and are frequently closest to the problems most worth hearing about. Requiring an account excludes exactly the people whose reports you want.
Does it route requests automatically?
Each category carries a default department and a default assignee, applied when the ticket is created unless the ticket already specifies its own. So a facilities request routes to facilities without the requester needing to know who handles it, and the category's SLA clock starts at the same moment. What it does not do is dynamic load-balancing or skills-based routing — assignment is by category default and then adjusted by a human.
What is the most useful thing we will learn?
Which requests should never have needed to be made. A high volume of access requests usually means role templates are wrong at hire; repeated internal lookups for payslips or leave balances mean self-service is missing rather than capacity; equipment appearing repeatedly is a procurement decision, not a support one. Three or four causes typically account for most of the volume, and each fix removes a recurring stream of work permanently.
