Self-service portal development

Choosing what to make self-service

1. 01

   Categorise requests

   Tag a few weeks of support contacts by type.

   Output: Request breakdown

2. 02

   Score each type

   Volume, simplicity and risk of doing it unaided.

   Output: Shortlist

3. 03

   Design tasks

   Turn the top types into guided self-service steps.

   Output: Task designs

4. 04

   Launch and measure

   Watch completion and remaining contacts.

   Output: Evidence

Good and poor candidates

Do the task, do not just explain it

Many self-service areas are really help articles: they explain how to request something, and the customer still has to email. Real self-service completes the task: the invoice downloads, the return label is generated, the address changes and the confirmation arrives. That requires connecting the portal to the systems that hold the data and applying the same rules staff would. Where a task needs approval, the portal can submit it in a structured form that staff process quickly.

Help content still matters, but alongside transactions, not instead of them.

Designing tasks customers complete

Handing over to a person

• Context carried

  The person sees what the customer tried.

• Right team

  Requests routed by type, not to a general inbox.

• Expectations

  Customers told when to expect a reply.

• Learn

  Frequent handovers reveal tasks to improve.

Measuring the effect

Track how many customers start and complete each self-service task, where they abandon it and whether contacts of that type fall. Also watch customer feedback, because self-service that frustrates people can shift effort rather than remove it. Review the figures monthly at first and improve the tasks with the highest abandonment.

Verifying who is asking

Self-service tasks that change accounts or reveal information need appropriate identity checks: signing in, a one-time code to a known email or phone, or details only the customer would know. Match the strength of the check to the risk; downloading a public guide needs none, while changing a delivery address or bank details needs much more. Weak verification on sensitive tasks can let someone take over an account, so design these steps carefully and test them.

Tell customers clearly why a check is needed.

Help content alongside tasks

Some questions are about information rather than transactions: what a policy means, how to use a product, what to do in a particular situation. Short, well-organised help articles answer these. Link them to related tasks, so a customer reading the returns policy can start a return immediately. Update articles when policies change, and remove outdated ones.

Linking from other channels

Include links to self-service tasks in order confirmations, invoices and automated replies, so customers find them when they need them.

Accessible self-service

Self-service must work for customers using assistive technology, older devices or slow connections, and for those less confident online. Accessible forms, clear language and a visible alternative route, such as phone, keep self-service from excluding anyone. Test key tasks with keyboard-only use and a screen reader before launch.

Where to start

Pick the single most frequent simple request and make it fully self-service first. Its effect on contacts shows whether to extend.