Customer portals and workflow applications

Choose a useful self-service task

Portals can support quotations, requests, orders, documents, approvals and status updates. The starting point should be the task people struggle to complete today, not a collection of dashboard widgets.

For an illustrative service business, letting a customer submit a request is only useful if staff can identify it, handle exceptions and communicate the outcome. The customer-facing page and the internal workflow need to be designed together.

Access rules before screen design

We define the relationships between accounts, organisations, contacts and records. A customer may have several users; a staff member may support more than one organisation. Those relationships determine what the application must allow and prevent.

Permissions need checking on the server for each relevant operation. Hiding a button in the interface is not an access-control mechanism. Sensitive changes may also need explicit confirmation and a record of who made them.

A workflow that handles exceptions

• Define stages and what allows an item to move between them.
• Assign responsibility for new, overdue and rejected work.
• Keep the customer-visible status consistent with internal progress.
• Handle amendments, cancellations and duplicate submissions.
• Record useful history without collecting unnecessary information.
• Connect notifications with the action required, not just the fact something happened.

Integrate without hiding the process

The portal may need information from a CRM, payment service, database or another operational system. We identify the authoritative source and the acceptable delay between updates. Where an external service fails, staff need an understandable exception rather than a record that silently disappears.

Usability also includes mobile access, keyboard use, clear errors and meaningful status messages. A visually attractive dashboard is not enough if the person cannot finish the task.

Build and hand over a defined release

We scope a first useful journey with its access rules, data, integrations and acceptance criteria. Additional roles and workflows can follow without making the first release depend on every future idea.

Send your current forms, sample documents, roles and the systems holding the information. We can turn those into a process map and a development scope, including hosting, ownership, backup and support arrangements.

Test representative roles separately: a successful administrator journey says little about what an ordinary customer can access.