Map the outcome, not the screens
Start with a bounded onboarding outcome: the service has the agreed information and authority to begin a defined piece of work. Then map the path from request, through requirements and readiness, to delivery handoff and closeout. At each stage, name the authoritative artifact, current owner, waiting condition, exception, and recovery contact. This is broader than a recurring missing-document map: it follows the whole client journey through the decision to start and the handoff to delivery.
A file folder can answer “where did we put this?” It may not answer “is this the current requested item?” or “who can decide whether it is sufficient?” Those differences matter more than whether the records sit in email, a shared drive, a spreadsheet, or an approved client portal.
Make the waiting visible
Use the accompanying representative client-onboarding map for a ten-item owner walkthrough. Simulated cases can test whether the worksheet is understandable, but they cannot qualify a portal decision. Before choosing a portal, walk ten real or appropriately redacted observed cases with a second qualified operator. Stop the selection if any consequential case lacks a current authoritative artifact, waiting owner, exception rule, or start-authorisation boundary. The point is not to force every client through the same path. It is to discover when the team cannot tell which party is waiting, what would permit work to start, or how a changed request is routed.
Keep sensitive client material out of the map itself. The map should link to the authoritative, appropriately controlled location and record only the minimal status needed for an operator to continue safely.
Choose the smallest coherent improvement
The first improvement may be a versioned checklist, a named readiness owner, one standard reminder, or a clear “waiting on client” state. A portal may be a reasonable later choice, but only after the team can articulate the current decision and exception rules it would need to support.
This representative map does not prove faster onboarding, better client experience, or compliance. A real service owner must replace every assumption with observed work and decide how client information may be handled. For a specific missing-document path, see Map Missing-Document Work Before Choosing a Client Portal; for visible waiting and follow-up ownership, see Map Stale Client Follow-Ups Before Choosing a CRM.
Is a portal required before we can track missing client items?
No. A shared, owned checklist can expose a missing item. Add a portal only if a real walkthrough shows it solves a defined access, visibility, or handoff need.
When is a client ready to start?
When the accountable service owner can identify the agreed starting condition, the current authoritative items, and the next recovery contact if a condition changes. Do not replace that decision with an automatic green status.