What Is a Process? Start, Finish, Customer and Outcome

A process connects a need with a result through a series of related activities. Its boundaries should make sense to the person who needs the result, not only to the teams performing the work.

A task can be finished while the process is still incomplete. That distinction is the starting point for useful improvement.

A request that crosses three teams

Consider a fictional service desk handling requests for access to a customer account portal. The service desk checks the request, an authorised business team decides whether access is appropriate, and a technical team configures it.

Assume the request can be traced between teams and the organisation has defined approval rules. No actual customer records, waiting times or service commitments are used in this teaching case.

The service desk says it has forwarded the request. The business team says it has approved it. The technical team says an account has been configured. Yet the customer still cannot sign in.

All three statements could be accurate. They describe local activities, not necessarily the result the customer needs.

Start with an observable trigger

For this example, choose receipt of the customer's request as the start. Record what was requested and when it arrived. If information is missing, show the clarification step instead of making that request invisible.

The input is more than a ticket number. The teams may need enough information to identify the customer, specify the access needed and apply the relevant approval rules. Do not collect personal information simply because a form has room for it.

A different analysis could begin when a complete, eligible request is accepted. That boundary may be useful, but it answers a different question. State the boundary before comparing performance.

Show the work and the handovers

A simple map might read: receive the request, clarify its scope, obtain the required approval, configure access, verify the result and communicate the outcome.

At each handover, ask what the next team needs and how responsibility moves. “Email sent” does not establish that a complete request reached the right queue or that someone accepted responsibility for it.

A department chart tells us where people sit. A process map tells us how the work moves. One process can cross several departments, and one department can participate in several processes.

Separate an output from an outcome

An output is something the process produces. In the case, outputs include a recorded approval, configured account and completion message. The intended outcome is that an appropriately authorised customer can use the requested portal access.

These are connected but different. A completion message can be sent even when the access does not work. Equally, technical access alone does not establish that it was properly authorised.

Define a finish condition that can be checked. For an eligible, approved request, this might include verification that the requested access works and clear communication to the customer. No response from the customer is not, by itself, proof that access works. Specify acceptable verification evidence and keep unresolved items visible with an owner. A rejected request requires a clear decision and communication, not a claim that access was delivered.

Look beyond local speed

Suppose a team wants to reduce its handling time by forwarding incomplete requests immediately. Its local number may improve while clarification and waiting increase elsewhere.

Before calling that an improvement, examine the whole request path. Where does the customer wait? Where does work return for correction? Which handover loses essential information? A map helps organise those questions; it does not prove the answers.

Talk to the people doing the work and check actual records. A neatly drawn sequence may show the intended process rather than everyday practice. Distinguish those two views before changing responsibilities or setting targets.

Practice: draw the boundary and the result

Place the customer's need at the top of a page. Mark the start, the finish and the main handovers. Label one input, one output and the outcome. Add who receives the result and one point where further evidence is needed.

Self-check: is “forward the ticket to the technical team” the customer's outcome? No. It is a step that may contribute to delivering appropriately authorised, usable access.

This high-level map is a learning tool. It will not capture every exception, security requirement or dependency. Show clarification, rejection and reopened-request paths where relevant; the real process may include loops rather than a single straight line. Use the map to agree what process is being discussed, then add the detail needed for the particular decision.

Improvement becomes more meaningful when the question moves from “Did my team finish?” to “Did the process deliver the right result?”