A workflow audit for teams considering a client portal, beginning with the spreadsheets, WhatsApp threads, email approvals, files and exceptions the new system must responsibly replace.
The feature list is usually the wrong place to start
'We need a dashboard' sounds decisive, but it often describes the screen rather than the work. The real problem may be that a client sends details on WhatsApp, a coordinator copies them into a spreadsheet, a manager approves by email, files live in several drives, and nobody can tell the client what changed without asking three colleagues. A portal should remove that ambiguity. If it merely adds a login above the same ambiguity, it has become another place to check.
Run a one-week workflow inventory
Choose one representative process and follow real work from request to completion. Record every handoff, tool, decision, wait, correction and exception. Do not tidy the story for the workshop. The duplicated spreadsheet and the voice note that saves the day are exactly the evidence the portal needs.
| Prompt | What to record | Why it matters |
|---|---|---|
| Trigger | Who starts the work, through which channel and with what minimum information | Defines intake and validation |
| Authoritative record | Where the accepted facts live after conflicts are resolved | Prevents competing sources of truth |
| Roles | Who may view, create, edit, approve, download, assign or delete | Shapes permissions and auditability |
| States | The meaningful stages from new to complete, cancelled or archived | Gives clients and staff a shared language |
| Handoffs | What moves between people or systems and how receipt is confirmed | Exposes delays and notification needs |
| Exceptions | Missing data, rejected work, duplicates, timeouts and disputed decisions | Prevents a happy-path-only build |
| Evidence | Files, notes, approvals, timestamps and messages needed later | Defines history, retention and reporting |
| Completion | Who decides the work is done and what the client receives | Creates acceptance and closure |
Choose one source of truth for each fact
A portal does not need to own every record, but the architecture must know which system does. Client identity might belong to a CRM. Payment status might belong to a payment provider and a finance ledger. Project tasks might belong to an operations system. The portal can present and coordinate those facts without becoming an uncontrolled duplicate database.
- Name the authoritative system for each important field.
- Define which direction data moves and when it is allowed to change.
- Record how conflicts are resolved if two systems disagree.
- Design for temporary integration failure without silently losing work.
- Give staff a visible way to identify and repair exceptions.
Permissions are business rules
Do not stop at administrator, staff and client. Ask whether one client may see several organisations, whether an organisation has billing and operational contacts, whether a staff member can reassign work, whether a reviewer can approve without editing, and whether former users retain access to exported files. Enforce those rules on the server. Hiding a button in the browser is not access control.
The OWASP Application Security Verification Standard can help procurement and technical teams turn security expectations into testable requirements. For personal data, the Office of the Data Protection Commissioner guidance is the appropriate Kenyan starting point for consent, impact assessment and sector-specific questions.
Design the exception queue before the celebration screen
Every workflow has cases that do not fit. A document is unreadable. A client submits twice. An approval expires. An external service is unavailable. A staff member leaves with assigned work. The portal needs a named state, owner, explanation and recovery action for each material exception. Otherwise the team returns to private messages, and the clean dashboard becomes a decorative summary of incomplete records.
A sensible first release
- One well-defined workflow with a clear owner and measurable delay or error problem.
- Role-aware sign-in and server-enforced access to the right records.
- Validated intake with draft, submission and correction states.
- A shared status model for clients and staff.
- Files with type, size, access and retention rules.
- Notifications that point back to the record instead of becoming the record.
- An activity history and an exception queue for staff.
- A handover and support plan for the people who will operate it.
Signs you are not ready to build
Pause if nobody can name the process owner, the team disagrees about the real stages, the data has no agreed source, the business expects the portal to fix an unresolved policy, or every exception is described as 'we will handle that manually' without saying who and how. A short audit is cheaper than encoding a disagreement into software.
A Web App or Client Portal should make the work more visible, controlled and supportable than the channels it replaces. That outcome begins with observation, not a dashboard template.
Map a Portal Workflow