Four Ways to Be a Requester (and What Each One Costs You)
The word "requester" hides four different kinds of person, each stored differently, each with a different set of things they can do — and one kind you probably assumed existed and does not. Which one raised a ticket decides whether they can reply, whether they can rate you, and whether the ticket ever counts against a customer.
Every helpdesk screen shows a field called Requester with a name in it, and the name makes it look like a solved problem. Underneath, that single word is standing in for four genuinely different situations: a colleague with a login, a colleague without one, a stranger who filled in your public form, and an administrator account that is not a person on your payroll at all. They are stored differently, they can do different things, and the reports count them differently.
This matters more in Kenya than the design of most helpdesk software assumes, because a large share of the people who need to raise a request — site staff, drivers, technicians, cleaners, security, casuals — will never hold a system login, and a large share of the customers who need support will never create an account to do it. If your identity model only handles logged-in users, most of your real requesters are locked out or misfiled.
The four kinds, and what each one can do
A ticket carries five separate fields that could identify who asked: a login reference, an employee reference, a plain name, a plain email address, and a customer reference. Which combination is filled is decided entirely by the door the request came through.
The four requester shapes, from most to least connected
Logged-in employee
Both the login and the employee record are stored, the employee resolved by matching the login. This person gets the complete experience: a self-service list of their own tickets, in-app notifications, a reply box, an attachment at intake, any custom fields you have configured on tickets, and the ability to rate the ticket once resolved. Source is recorded as web.
Employee with no login, on the tokenized portal
The employee record is stored; the login field takes whatever the employee has, which for this person is nothing. They reach the portal by their own tokenized link, unlock with a PIN, and can raise and follow tickets — but there is no conversation on that page and no rating. Source is recorded as portal.
External customer, via your public form
No login and no employee record — just the name and email they typed, plus a customer reference if the email matched one of your customer records exactly. They get a signed tracking link by email, valid 90 days and reissued on every reply, and a full reply loop. They cannot rate. Source is recorded as portal.
A login that is not an employee
An administrator, a finance user, a director's account — anyone with a login and no matching employee record. Everything functions: they raise, reply and rate normally. But with no employee reference, they are absent from anything that groups requests by department or staff, so the request exists and the requester does not appear in your people reporting.
A ticket raised by an agent for a caller
There is no route in the product, on the web or the API, that lets an agent create a ticket. Every intake path files the ticket against the person using it. When somebody phones in, the agent has no way to raise it as that caller — see below, because this is the gap with the largest practical consequence.
The pill on each row is about the requester's own capabilities, not about the desk's. An agent sees and works all four kinds identically; the differences are entirely on the requester's side of the glass.
The gap: the phone call
Here is the one to know before you design your process around this module. An agent cannot raise a ticket on behalf of somebody else. There is no create action on the agent side at all — not in the interface, not in the API. Tickets are created by the person who needs help, through one of three self-service doors.
On a Kenyan support desk, where a great deal of intake arrives as a phone call or a walk-in, that is a real constraint. What people do instead is the wrong thing: the agent opens their own self-service form and types the customer's problem into it, which produces a ticket whose requester is the agent. The thread then has no route back to the person who actually asked — no notification, no tracking link, no rating — and every report that counts tickets by requester now says your busiest customer is your own support agent.
A ticket raised by an agent on their own account is not a record of a customer request. It is a record of an agent typing.
Why the workaround costs you the reporting
The honest workaround, until we build agent-side intake, is to make the customer the author even when the request arrived by phone: stay on the line and walk them through your public form, or send them the link and call back. It feels like extra friction and it buys you the entire downstream chain — their email address on the ticket, the customer link, the tracking page, the reply loop, and a support volume figure that means something. If the caller genuinely cannot use a form, raise it yourself and put their name and phone number in the first line of the description, then accept that the reporting on that ticket is approximate.
How a ticket becomes a customer's ticket
There is exactly one moment when a ticket gets attached to a customer record, and it is worth knowing precisely, because per-customer support volume is one of the most useful numbers a business can have and it depends entirely on this.
-
A stranger submits your public support form
The form asks for a name, an email address, a subject, a description and a priority. Nothing else. This deliberate minimalism is the right call for intake — every extra field costs you requests — but it means the email address is the only identifier you get.
-
The email is matched against your customer records
An exact match on the customer's email address, within your organization. Match found, the ticket is linked to that customer. No match, the ticket keeps the typed name and email and no customer link.
-
That link is permanent, and it is the only one
It is never retried. A customer who writes from a personal address today and their work address next month produces one linked ticket and one unlinked ticket, and nothing joins them later. There is no merge and no re-match.
-
Every other intake path skips this entirely
A logged-in employee, a portal employee, an agent — none of these routes attempt a customer match, because they are all internal people. Which is correct, and means only tickets from your public form can ever be counted per customer.
The five-minute exercise that pays for itself
Before you publish your support form, go and check that the email addresses on your customer records are the addresses your customers actually write from. Not the accounts-payable address on the invoice, not the director's, but the one that emails you about problems. Every mismatch is a support ticket that will never be countable against that account, forever, and correcting a customer record takes ten seconds today and is unfixable after the fact.
Who can rate you, and why that skews your CSAT
Satisfaction rating is available on a resolved or closed ticket, as a score out of five with an optional comment, and the requester can change their rating afterwards. It is a good, simple design with one structural limit that you must know before you read the average: rating requires a login.
Both routes that submit a rating — the web page and the mobile API — authenticate the requester and check the ticket is theirs by login reference. An employee on the tokenized portal has no login to authenticate. An external customer on a signed tracking link has no login either. Neither can rate, ever.
A desk reading a satisfaction average that describes a quarter of its work
Illustrative, and the mechanism is exact. The number is not wrong, it is narrow: it describes twelve internal requests by people who hold logins. If your desk is mostly customer-facing, the satisfaction figure on the dashboard is measuring your staff experience and quietly presenting it as your customer experience. Read it as an internal-support signal until customer rating exists, and gather customer sentiment the old way — read the low-scoring threads and the free-text replies.
Reading a queue where all four kinds are mixed
The queue tells you which is which if you know where to look. Any ticket whose source is not web carries a badge, so portal arrivals stand out from staff raising requests at their desk. The requester name resolves through a fallback chain — employee name first, then the login's name, then the typed name, then the typed email, and only Unknown if truly nothing was recorded. An external requester is additionally flagged on the ticket itself.
What to check when a requester looks wrong
- Name shows as an email address. Normal for an external requester who left the name blank on an older form, or where only the email was recorded. Nothing is broken.
- Name shows as Unknown. No employee, no login, no name, no email. In practice this means the ticket was created by something other than a person filling in a form — check your imports and integrations.
- The requester is one of your own agents on a customer's problem. The phone-call workaround. Put the real caller's details in the description and stop counting that ticket as customer volume.
- A customer you know is not linked to their tickets. Their email on the form did not match their customer record. Fix the customer record so future tickets link; the existing ones will not backfill.
- A staff request with no department in the reports. Almost always a login with no matching employee record — an admin or finance account. Create the employee record if that person is genuinely staff.
What we do and do not do
What AWRA OpsHub does today
- Four working intake identities: logged-in employee, employee without a login via a tokenized PIN portal, external customer via a public form with a signed email trail, and a login with no employee record.
- A requester label that falls through employee name, login name, typed name and typed email in that order, so a ticket always shows the best identifier it holds.
- Automatic linking of a public-form ticket to a customer record when the email address matches exactly.
- A source stamp on every ticket, badged in the queue, so portal arrivals are visually distinct from staff raising requests internally.
- A per-organization switch controlling whether your public support form accepts requests at all, so intake can be turned off without dismantling anything.
- Satisfaction rating with a score, an optional comment and the ability to revise it, for requesters who hold a login.
What it does not do
- No agent-side ticket creation. There is no way for an agent to raise a ticket for a caller, on the web or the API. Phone and walk-in intake either goes through the customer's own hands or is filed against the agent.
- No rating for requesters without a login. Portal staff and external customers cannot rate, which means the satisfaction average describes only the logged-in share of your work.
- No email-to-ticket intake. The system has an email source value defined and nothing ever writes it — there is no mailbox that turns an incoming message into a ticket. Email arrives in a mailbox and somebody re-types it.
- No re-matching or merging of requesters. The customer link happens once, at intake, on an exact email match. A customer writing from a second address is a second unlinked requester permanently.
- No conversation on the tokenized staff portal. Employees without logins can submit and track, not reply.
- No requester-side view of tickets raised by a colleague, and no concept of a requester who represents a department rather than a person.
Two of these carry real weight and we would take them in this order: agent-side intake, because it is the difference between a support system and a support system with a phone workaround; then rating on the signed customer link, because a satisfaction number that excludes customers is a number most desks would rather not publish. Both are contained pieces of work rather than architecture. If either is blocking you, say so.
Designing around it, today
None of this is a reason to wait. It is a reason to be deliberate about which door each group of people uses, and to write that down before you launch rather than discovering it in the reports three months later.
For staff with logins, use the self-service form and enable the custom fields you actually need — asset tag, site, cost centre — because this is the only intake path that carries them. For staff without logins, issue the tokenized portal link with their payslip or their induction pack, and accept that clarifying questions travel by phone. For customers, publish the public form, make sure your customer email addresses are right first, and treat the signed tracking link as the channel rather than trying to get them to create accounts. For phone calls, decide as a team whether you walk the caller through the form or file it yourself with their details in the description — either is defensible, but the two produce very different reports and you should not be doing both by accident.
Our take
Requester identity is the least glamorous part of a helpdesk and the part that decides what your reports can ever tell you. Four kinds of person can raise a ticket here, two of them cannot rate it, one connection to a customer record is made once and never retried, and an agent cannot raise a ticket for a caller at all. Know those four facts, route each group of people through the right door on purpose, and get your customer email addresses right before you publish the form. Do that and the module is honest and useful. Skip it and you will spend next year reading a satisfaction score that describes six per cent of your work.
Read alongside this: a support portal people will actually use covers the intake design decisions in detail, the internal helpdesk covers the staff-without-logins case, who gets told maps the notifications each identity can receive, and support metrics that are not vanity covers how to read the numbers once the identities are right.
One desk, four kinds of requester
A public form with automatic customer linking, a tokenized PIN portal for staff without logins, signed email tracking with no account required, and a source stamp on every ticket.
See intake & portalsFrequently asked questions
Can an agent raise a ticket on behalf of a customer who phoned in?
No. There is no create action on the agent side, in the interface or the API — every intake path files the ticket against the person using it. The practical options are to walk the caller through your public form while they are on the line, send them the link and call back, or raise it from your own account and put their name and number in the first line of the description. The last option works but it makes you the requester, so that ticket cannot notify them, cannot be tracked by them, cannot be rated, and will not be counted against their customer record. Agent-side intake is the gap on this module we would build first.
Why can our customers not rate their tickets?
Because rating requires a login. Both endpoints that accept a rating authenticate the requester and confirm the ticket belongs to them by login reference. An external customer on a signed tracking link has no login, and neither does an employee using the tokenized portal, so neither can submit a score. The consequence is worth stating plainly: the satisfaction average on your dashboard describes only tickets raised by people holding logins. On a customer-facing desk that can be a small minority of the work.
How does a ticket get linked to a customer record?
Only one way: when someone submits your public support form, the email address they type is matched exactly against your customer records, and a match links the ticket to that customer. It happens once, at intake, and is never retried. No other intake path attempts it, because the others are all internal people. The practical implication is that per-customer support volume is only ever as good as the email addresses on your customer records — go and check them before you publish the form, because a mismatch cannot be corrected retroactively on tickets that already exist.
Can we accept support requests by email?
Not as tickets. There is no mailbox that converts an incoming email into a ticket — the system even has an *email* source value defined for it, and nothing writes it. Email that arrives in your support inbox has to be re-typed, or the sender pointed at the form. The nearest thing that does work is the outbound half: external requesters receive email with a signed link, and their replies through that link land in the thread properly. If inbound email intake is essential to you, it is a fair request and it is not currently built.
What does it mean when the requester shows as an email address?
That the ticket holds an email and nothing better. The requester label falls through four candidates in order — the employee's name, the login's name, the typed name, then the typed email — and only says *Unknown* if none of them holds anything. Seeing an email address is normal for external requests and is not a fault. Seeing *Unknown* is worth investigating, because it means no person was recorded at all, which in practice points at an import or an integration rather than a form submission.
One of our directors raises tickets but never appears in the department reports. Why?
Because they have a login but no employee record. Everything works for them — they raise, reply and rate normally — but the employee reference on the ticket is empty, and that reference is what every report grouping by department or staff relies on. The fix is to create the employee record, after which their new tickets carry both references. Existing tickets keep the reference they were created with; nothing backfills.
Should we make everyone use one intake door to keep the data clean?
No, and this is the mistake we see most often. Forcing everyone through the logged-in form means either buying a login for every casual and technician, or excluding them from raising requests, and both are worse than a slightly untidier dataset. Route each group through the door that matches them — logins to self-service, staff without logins to the tokenized portal, customers to the public form — and use the source badge on the queue to tell them apart. The identity model exists precisely so you do not have to choose between clean reporting and reachable people.
