Map a customer handoff before building the portal

Find the missing context before choosing the screen

A customer portal can look organized while the work behind it remains unclear. The files are neatly displayed, but nobody knows who can approve them. A status says “complete,” while the customer is still waiting for instructions. Before building a new interface, trace one real handoff from the person releasing work to the person expected to act on it. The resulting map can show whether the problem is a missing tool, an unclear responsibility, or a decision that has never been defined.

Choose a bounded exchange. “Improve customer communication” is too broad to observe in one sitting. “Send a revised presentation for approval and deliver the final files” has a start, an end, and identifiable participants. A narrow example makes it possible to ask detailed questions and compare the intended process with what actually happened.

Observe the exchange as it happens

Start with the people doing the work. Ask them to walk through a recent handoff using the messages and documents they actually consulted, with permission and sensitive details removed where necessary. If possible, observe another handoff as it happens. Retrospective explanations can omit small workarounds because those workarounds have become routine.

Nielsen Norman Group’s account of task analysis describes gathering information through observation and conversation, then examining the tasks and their sequence. It distinguishes a single user’s tasks from a workflow involving several people. For a customer handoff, use both views: examine what each person needs to do, then connect the moments where responsibility changes. The example below is a hypothetical agency workflow, intended as a practical exercise rather than a reported case study.

Do not begin by asking what features people want. Ask what they were trying to accomplish and what they needed at each point. A request for a new notification may conceal uncertainty about who owns the task. A request for a dashboard may reflect difficulty finding one current file. Understanding that distinction gives a product team more options.

Write down five things at each step

For every step, identify the actor, the artifact, the decision or action, the next owner, and the evidence that the handoff succeeded. The actor is the person doing the work now. The artifact is the file, record, or message they use. The action should be a verb, such as review, approve, revise, send, or confirm. The next owner is the person expected to continue. Evidence explains how the current person knows the exchange is complete.

These fields expose gaps that a vague status can hide. “With client” names a location in the process but not the client’s action. “Awaiting approval from the marketing lead on version three” is more useful. It identifies both the responsible role and the object of the decision. If the marketing lead can delegate that decision, record how the delegation becomes visible to the agency.

Write the map in ordinary language first. A table on paper is enough. Formal diagram notation can wait until there is a shared understanding of the exchange. The people responsible for the work should be able to correct the description without needing to learn a modeling tool.

Walk through a worked example

An account manager receives a revised presentation from a designer. The manager checks it against the client’s last request and sends a review link. The client’s marketing lead forwards the link to a director. The director replies to the marketing lead, who summarizes the feedback in a new email. The manager asks whether that message is approval or a request for further changes. Two days later, the designer learns that one slide needs a correction.

The visible delay occurred while the manager waited. The map reveals several possible causes. The designated approver was unclear. Feedback moved through a person who had to interpret it. The decision was not attached to a specific version. The final reply did not state what should happen next. Building a comment box would address only a small part of that sequence.

Now rewrite the same exchange with explicit responsibilities. The manager sends version three to the marketing lead and names the decision required. The lead either approves that version or delegates approval to the director. If delegated, the manager can see the new owner. The decision records whether the presentation can go to final delivery or which change is required. The designer receives an assigned revision only when the requested work is clear.

This is a proposed improvement to test, not a conclusion that every agency needs the same process. Some clients require several independent approvals. Others have a single person who can decide immediately. The map should reflect those differences rather than forcing them into one convenient product model.

Mark the waits and workarounds

Add a note wherever work pauses. Is someone waiting for information, permission, access, or availability? Those waits call for different responses. A reminder can help with an overlooked request, but it cannot supply a missing file or give someone authority they do not have. Naming the dependency helps the team avoid automating a series of unhelpful nudges.

Also record the side channels. A phone call that resolves an ambiguous comment is part of the workflow even if the existing software never sees it. A spreadsheet used to track approvals may be doing essential work behind the official system. Ask why people chose those tools and what information they preserve there. A new portal should be designed with that work in view.

Use timestamps only where they are available and relevant. Separate active work time from waiting time. If a review takes ten minutes but waits three days for a decision, a faster upload screen may have little effect on the total exchange. The map does not prove the cause of every delay, but it helps the team choose what to investigate next.

Pick one small intervention

After mapping the exchange, choose the smallest change that tests the most important uncertainty. If approval ownership is unclear, try a named approver and a standard decision request before building account roles. If version confusion is common, try a consistent version label and a single current review link. If delivery instructions are missing, add a short completion note to the existing message.

Run that change through several suitable handoffs and record what happens. Did the recipient know what to do? Did the sender still need a separate explanation? Could another team member take over without reconstructing the conversation? These observations can establish a more useful pilot scope than a list of features borrowed from competing portals.

The first software release might then include a current artifact, a named decision owner, a clear next action, and a record of the response. Other features can wait until there is evidence they help this exchange. The team should also decide how to handle corrections, absent approvers, and reopened work, because real handoffs do not always follow the ideal path.

Keep the map useful after the pilot

Treat the map as a working explanation that people can challenge. Review one successful exchange and one troublesome exchange after the pilot. If the same step behaves differently, ask what condition changed. A new client, an unfamiliar deliverable, or an absent team member may reveal a branch that the first map missed.

Finish with a short record of the chosen boundary, the observed gaps, the change tested, and the unresolved questions. Assign someone to maintain the process description when responsibilities change. A beautiful diagram that no longer matches the work is less useful than a plain table people trust.

Before building the portal, observe one customer handoff and mark its owner, artifact, and next action at every step. That exercise can turn a broad software idea into a focused product decision. It also gives the team a concrete way to judge whether the eventual portal helps people complete the exchange they came to make.