A Support Portal People Will Actually Use (Including Without a Login)
Most support portals fail because they ask people to create an account before they can complain. What makes an intake channel people actually use — including the ones who will never register — and the honest limits of a portal.
Consider what you are asking of somebody with a problem. They are already mildly annoyed. You want them to find your portal, create an account, verify an email, choose a password they will forget, log in, and then describe their issue in a form. The alternative available to them is sending a WhatsApp to whoever they dealt with last time.
They will send the WhatsApp. Every time. And then the request sits in an individual's phone, invisible to the organization, which is the exact problem the portal was bought to solve.
Friction is the whole design problem
A support portal competes against the easiest thing the requester could do instead. If it is harder than a message, it loses — and losing does not look like a failed rollout, it looks like a portal with low volume and a support team still working out of a phone.
Portals people avoid
- Registration required before you can report anything
- A long form asking for information the requester does not have
- Mandatory fields that make sense to you and not to them
- No confirmation that anything was received
- No way to see what happened afterwards without logging in again
Portals people use
- A link and, at most, a PIN — no account creation
- Three or four fields; you categorise afterwards
- The requester describes the problem in their own words
- Immediate confirmation with a reference
- A way back to their own request without registering
A portal that requires registration is not an intake channel. It is a filter that admits only the most determined complaints — which are rarely the most useful ones.
The no-login route matters more here than anywhere
AWRA handles portal access through tokenized links with a PIN rather than accounts — the same pattern used for leave and attendance self-service. A requester gets a link, enters a short PIN, and raises or checks a ticket. No registration, no password reset flow, no licence consumed.
This is not only a convenience choice. In a Kenyan context a large share of the people who need to raise something have no reason to hold an account with you: a customer's storekeeper reporting a short delivery, a site supervisor with a facilities issue, a member of staff without a login, a supplier querying a payment. Requiring an account excludes all of them, and they are frequently the people closest to the problem worth knowing about.
Ask for less at intake, not more
The instinct is to collect everything up front so agents do not have to chase. It backfires: long forms reduce submissions, and the information you most want — a proper description of the problem — gets shorter as the form gets longer, because people ration their effort.
-
Ask who they are and how to reach them
A name and one contact method. Not an address, not an account number they will have to look up.
-
Ask what is wrong, in their words
One open field, generously sized. This is the field that determines whether the ticket is workable, so give it room and ask nothing that competes with it.
-
Let them attach something if it helps
A photo of a damaged delivery or an error message is worth more than three structured fields you designed in advance.
-
Categorise on your side, not theirs
Requesters routinely pick the wrong category, and a wrong category is worse than none because it drives routing and the SLA clock. Take one guess at intake and let an agent correct it.
-
Confirm immediately with a reference
Silence after submission is why people follow up by phone an hour later. An instant acknowledgement removes most duplicate contact.
The confirmation is not a courtesy
The single most common reason a support team gets chased is that the requester does not know whether their message arrived. An immediate acknowledgement with a reference eliminates a large share of follow-up contact, which means it reduces your workload rather than adding to it. It is the cheapest thing on this list and the most frequently skipped.
Keep every channel, but land them in one place
A portal is not a replacement for email or phone or a message — it is one more door. The requirement is not that everyone uses the portal; it is that every door leads to the same queue.
Which means the rule for your team is the one from the helpdesk guide: a request that arrives directly gets logged rather than answered in place. The requester keeps their preferred channel and the organization keeps the record. Trying to force channel behaviour is how helpdesk rollouts fail; absorbing every channel into one queue is how they succeed.
What we do and do not do
What AWRA OpsHub does today
- Tokenized intake portals — a link plus a PIN, no account creation or licence consumed.
- Attachments at intake, so a photo or screenshot arrives with the request.
- Tickets landing in the same queue as every other channel, with category routing and SLA clock applied.
- Comments back to the requester on the ticket, with internal notes kept separate.
- Watchers, so colleagues who need to follow a request can without owning it.
What it does not do
- No live chat widget for your website.
- No public knowledge base of self-service help articles.
- No customer satisfaction survey after resolution.
- No social-media inbox integration (WhatsApp Business API, Facebook, Instagram).
- No telephony — phone calls are logged by whoever takes them.
The WhatsApp point is worth stating plainly since it is the dominant channel in Kenya: there is no WhatsApp Business API integration, so WhatsApp requests are logged by the person who receives them rather than flowing in automatically. If automatic WhatsApp intake is essential, you need a channel tool alongside this.
What a portal will not fix
Worth being clear, because portals are often bought with unrealistic expectations attached.
- It will not reduce request volume. It makes requests visible, which usually makes volume look like it went up. That is the portal working.
- It will not make slow resolution acceptable. Visibility raises expectations; if you were slow before and now the requester can see the ticket sitting there, you have made slowness legible.
- It will not stop people messaging you. It gives them a better option; the discipline of logging what arrives elsewhere is still yours.
- It will not categorise itself accurately. Requesters guess wrong. Plan for an agent to correct category and priority at triage.
- It will not replace a phone call for anything genuinely urgent, and it should not try to.
The second point is the one that catches organizations out. A portal converts an invisible backlog into a visible one, and for the first month that can feel like the system created a problem. It did not — it revealed one, and the honest response is to staff or re-target rather than to reduce visibility.
Our take
Use tokenized links rather than accounts, ask three questions instead of ten, categorise on your side, and confirm receipt immediately. Then keep every other channel open and log what arrives through them. A portal earns its place by being easier than a WhatsApp message, not by being mandatory.
See intake without account creation
Tokenized portals with a PIN, attachments at intake, every channel landing in one queue with category routing and the SLA clock already running.
Explore intake portalsFrequently asked questions
Do requesters need to create an account?
No. Access is through a tokenized link plus a short PIN, so a customer, supplier, site supervisor or member of staff without a login can raise and check a ticket without registering, resetting a password or consuming a licence. This matters because a portal competes against sending a WhatsApp message — if it is harder than that, people will send the message and the request stays invisible to your organization.
Does it integrate with WhatsApp?
No — there is no WhatsApp Business API integration, and since WhatsApp is the dominant channel in Kenya that is worth stating plainly rather than leaving you to discover it. WhatsApp requests are logged as tickets by whoever receives them, which works well in practice provided the team treats logging as the habit. If automatic WhatsApp intake is essential to you, pair us with a channel tool.
How many fields should the intake form have?
Three or four. Who they are, how to reach them, what is wrong in their own words, and optionally an attachment. Long forms reduce submissions and, worse, shorten the description of the problem — which is the one field that determines whether the ticket is workable. Collect the rest by asking on the ticket once it exists.
Should requesters choose the category and priority?
Take a guess from them if it is cheap, but plan to correct it at triage. Requesters routinely pick the wrong category, and a wrong category is worse than none because it drives both routing and the SLA clock. Everything is also urgent when the requester sets priority. Treat their input as a hint and let an agent set the values that actually control behaviour.
Will a portal reduce our support volume?
No — it will usually make volume appear to increase, because requests that were previously invisible in individual inboxes and phones become visible in a queue. That is the portal working correctly. What reduces volume is reading the volume-by-category report and fixing the causes behind the biggest categories, which the portal makes possible for the first time.
