# What needs to be handed over before a process can move to the next step?

- Author: Andrew David W.Y.
- Source: https://yutengfei.com/en/journal/process-handover-and-entry-conditions/
- Version: R1
- Published: 2026-11-04
- Revised: 2026-11-04
- Content status: Full text published
- Content type: Models (models)
- Research topics: Stakeholder Capital Governance (stakeholder-governance)
- Ecosystem perspectives: Operations & Management Ecosystem (operations) · Resource Ecosystem (resource)

## Use this resource

**Purpose**: Separate the previous process's deliverable, the acceptance decision, and the conditions for starting the next process. Explain how to handle handover problems and how a shared objective sets limits on what each stage can call complete.

**Conditions for use**: Check that the subject, objective and constraints fit the task. Confirm any conditions that the article does not specify.

**Models · Elements, relationships and assumptions**

**Evidence and validation limits**: The example illustrates how to analyze the situation and use the approach. When applying it, substitute actual business records for the example conditions and check the judgment and outcome. No separate external-validation result is recorded for this article. Publication does not establish effectiveness; check the evidence, assumptions and limits in the text.

This is a readable, citable knowledge resource, not an installed Skill. When using it with AI, retain its sources and limits and review the output.

## Full article

Sales passes the customer's requirements to the person preparing the quote and marks the task “complete.” That person opens the file, only to find that the quantity, delivery date, and operating conditions have not been confirmed. They have to go back and ask again. Work has certainly been done upstream, but the next stage still cannot begin.

The same thing happens when a proposal goes to design, a design goes to production, or development hands work over to testing. It also happens between a company and its suppliers, channels, and customers.

The question I care more about is this: can the result from one stage become a usable starting point for the next?

Once that is clear, the arrows in a flowchart start to mean something in practice.

## 1\. Separate two decisions: the deliverable meets the requirements, but can the next step begin?

A workflow can consist of several related processes. Each process has its own purpose and also supplies a result to the broader business chain. That result might be a product, a proposal, a set of data, a confirmed requirement, or a decision.

ISO's explanation of the process approach describes a process as a set of related activities that uses inputs to produce an intended result. It also stresses the inputs, outputs, and dependencies between processes. This article takes that basic understanding and proposes a working model for everyday handovers. [Explanation of the process approach](https://www.iso.org/iso/iso9001_2015_process_approach.pdf)

The model starts from a shared objective: **the previous process produces a result → check it against the next process's needs → state the acceptance decision → check the start conditions → enter the next process.**

Two things need to be considered separately here.

First, does the result being handed over meet the agreement? Have the requirements been confirmed? Is the drawing the current version? Do the data have sources? Is the deliverable within the agreed scope? This answers, “Can we use what has been delivered?”

Second, are the conditions for starting the next process in place? Can the responsible person take on the work? Are the necessary materials and resources available? Have the relevant decisions been confirmed? This answers, “Can we start now?”

A drawing that meets the requirements may still be unable to move into production because the materials have not arrived. The status should then be “deliverable accepted; production awaiting start,” while the materials issue is addressed. Not every delay should be sent back to the designer. Nor should production be recorded as started simply because the drawing has been accepted.

Scroll sideways to explore, or open the full diagram.

[![Figure 1: Conditions for a deliverable to become the next process's starting point. Checking the deliverable and confirming readiness to start are separate; acceptance does not automatically mean work has started.](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/01-handover-to-next-process.svg)](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/01-handover-to-next-process.svg)

Figure 1: Shared objectives and constraints apply throughout. The arrows show the sequence of handovers and decisions. They do not mean customer or economic outcomes have already been achieved.

[Open full diagram ↗](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/01-handover-to-next-process.svg)[Download editable SVG ↓](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/01-handover-to-next-process.svg)

## 2\. Describe what is being handed over in terms of its next use

“Requirements compiled” and “proposal submitted” are both easy to interpret differently.

If the next step is to prepare a quote, it needs at least to know what is being quoted, how much, when delivery is expected, and which conditions are confirmed or still estimates. If the next step is only a preliminary proposal, some information may be allowed to remain missing. The assumptions must still be identified, along with the decisions that cannot yet be made.

The same material can be subject to different standards at different stages. The relevant roles should therefore agree on handover requirements before the work begins. If the business situation changes, adjust them in the agreed way. The receiving party should not wait until handover and then keep adding requirements that were never agreed.

I suggest clarifying the following six things first. They can go into an existing task record, document description, or system field. There is no need to create another thick set of forms.

| What needs to be clear | What the handover should answer |
| --- | --- |
| Purpose and boundaries | Which process will use it, which decisions it supports, and what scope it covers |
| Result and version | Where the deliverable is, which version is current, and when it was produced |
| Basis for checking | How key facts were confirmed, and where the sources and necessary check records are |
| Acceptance criteria | What must be met for acceptance, and which version of the criteria applies |
| Responsibility and timing | Who submits, who checks, who takes the next action, and when a response is due |
| Gaps and handling | What remains unconfirmed, what it affects, and who must fill the gaps or decide by when |

The result and the evidence supporting it also need to be kept separate. A communication record may show that the parties discussed a condition. It may not show that the condition was confirmed. A seemingly complete AI-generated proposal does not necessarily establish that its prices, specifications, or delivery dates are real and valid.

After receiving the deliverable, the recipient should be able to see what they can act on, what still needs checking, and what use would require renewed confirmation.

## 3\. “Please accept this” is not enough to say who checks what

The submitting party first checks its own work against the agreement. The receiving party checks the inputs relevant to its work. Specialist judgments, external commitments, and matters outside the original authorization then go to someone with the appropriate authority for confirmation.

In a small team, one person may hold several roles. The basis for each judgment and the responsibility still need to be clear. When a key matter involves an obvious conflict of interest, an appropriate separate review is needed. Routine handovers that are inexpensive and easy to correct can use a brief confirmation or a sample check. Add checks where risks or correction costs are higher. Requiring layers of signatures at every step can make coordination cost more than the original problem.

The acceptance decision should be specific. For example: “Requirements sheet V2 has been checked against the quotation input criteria. The specifications and quantity may be used for calculation. The firm delivery date still requires supply confirmation and must not be promised to the customer on this basis.” That gives the next person more to work with than “received” or “no problem.”

“Received” only means the material has arrived. “Accepted” means the deliverable has passed checks for the specified scope. “Started” means the practical conditions for the next step are also in place. A task system may use different status names, but participants should be able to see these distinctions.

Agree on a response time as well. If it passes without a reply, reminders and coordination should follow; silence is not approval. If the recipient rejects the handover, they should identify the unmet criteria and the specific gaps. Both sides are responsible for reducing avoidable waiting and repeated exchanges that have no clear basis.

## 4\. If the handover does not work, first identify the kind of problem

When a handover goes wrong, the easiest response is often “send it back and do it again.” Some problems, though, are not in the delivered work itself. Repeating the work will not solve them.

Start with three categories.

**There is a gap in the result.** Agreed specifications may be missing, key data may be impossible to verify, or document versions may be inconsistent. Identify the gap and its effects. The responsible person then adds or corrects what is needed, followed by another check against the applicable criteria. Parts that already meet the requirements and are unaffected do not all need to be discarded.

**There is disagreement over criteria or authority.** The parties may have different meanings for “confirmed,” or a delivery commitment may be needed that was never authorized. Return to the original agreement. Where necessary, an authorized role decides the applicable criteria, scope, and responsibilities. Recipients should not add conditions based only on personal preference. Submitters should not make commitments on someone else's behalf just to keep the schedule moving.

**Business conditions have changed.** The customer may have changed the requirements, supply capacity may have shifted, or resources for the next step may temporarily be unavailable. First identify what is affected. The relevant role then decides whether to add resources, change the scope or timing, pause, or terminate the affected work. A result can meet its criteria yet no longer be suitable for current use.

Scroll sideways to explore, or open the full diagram.

[![Figure 2: Three routes for handling handover problems. After the problem is addressed, work intended to continue returns to verification; paused work requires confirmation of the conditions for resuming.](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/02-exception-and-revalidation.svg)](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/02-exception-and-revalidation.svg)

Figure 2: Classifying a problem helps find the right handling route. Correcting a result, interpreting criteria, and adjusting business conditions have different responsibilities. They should not all be treated as poor execution.

[Open full diagram ↗](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/02-exception-and-revalidation.svg)[Download editable SVG ↓](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/en/02-exception-and-revalidation.svg)

Where necessary, a deliverable can be accepted conditionally within a defined scope. For example, internal calculations might proceed while confirmation is completed. This requires the appropriate authority. Record what is permitted, what must not be done on that basis, the deadline for filling the gaps, and how to stop or roll back if the conditions are not met. After these arrangements are confirmed, recheck the inputs and start conditions for the restricted work.

Conditional acceptance does not allow mandatory requirements to be skipped. Actions should still be paused where there is no authority to decide, consequences cannot be controlled, or a necessary prior check remains incomplete. Someone must follow up on the pause, stating the conditions for resuming and the review time. Obligations already assumed for performance, costs, and follow-up remain subject to the agreement. Changing the status to “paused” does not make them disappear.

## 5\. See how the model works in a quotation handover

The following is a fictional situation written to explain the model. It is not a record of an actual company.

A customer requests a batch of custom equipment. The requirements coordinator passes the material to the quotation lead. They have agreed in advance that a formal quote needs confirmed specifications, quantity, delivery location, and desired delivery date, with unresolved matters identified.

In the first submission, specifications and quantity are confirmed, but there are still two possible delivery locations. The quotation lead points out the gap and explains that transport costs cannot yet be determined. The requirements coordinator then confirms the location, submits V2, and retains the previous version and a note of the changes.

After V2 is checked, the inputs needed for the quote meet the agreement, but the supplier has not yet confirmed capacity. A further distinction is needed: internal cost calculations can begin; the conditions for sending the customer a formal quote with a firm delivery date are not yet in place.

An authorized lead permits internal calculations within a limited scope first. The task record identifies who must confirm capacity, the deadline, and the restriction against promising a delivery date to the customer. The internal calculations begin after the relevant inputs and resources are checked again.

If the supplier later reports that the desired date cannot be met, the relevant roles confirm an adjustment with the customer. If the customer changes the specifications, identify the affected calculations and material, then recheck them against the new version. “V2 accepted” cannot remain the basis for continuing to issue an external quote.

In this example, the model helps distinguish missing information, readiness to take on the next task, and external decisions. It also preserves some work that can proceed first. It does not guarantee that the customer will buy. Nor can one smooth handover prove that the whole workflow has improved business performance.

## 6\. A shared objective should constrain what each stage calls “complete”

Sales wants speed. The quotation team wants complete information. The supplier wants stable conditions. There are practical reasons for all these needs. A shared objective lets the relevant roles discuss trade-offs around the same piece of business: what problem the customer needs solved; how timing, cost, quality, and performance conditions should be balanced; and which commitments must not be made.

It does not require everyone's interests to be identical. It cannot justify adding unlimited tasks to one party. Additional work, waiting, and rework have costs. It should be clear who bears them and who decides when they exceed the original agreement.

These handovers can occur across all four ecosystems: resources, operations and management, customers, and capital. Different roles may contribute proactively or respond to a need. Specific matters still follow the relevant business relationships and authorization. A lean operations and management team is responsible for the relevant decisions, rules, and coordination, connecting value production, sales channels, and customer relationships. It does not replace every specialist's judgment.

This model deals with delivery and taking on the next stage of work. Delivery records can provide facts for later evaluation, but they do not automatically represent the whole contribution or create rights to pay, equity, dividends, or decision-making. Relevant rights and arrangements need to be handled separately according to the actual business and applicable agreements.

To use it, start with a handover that repeatedly causes trouble. Record information gaps, reasons for waiting, rework, checking costs, and effects on fulfilling customer commitments. After a trial, look at which checks helped, which criteria were too burdensome, and whether problems found a responsible person sooner. Without a comparison and sufficient records, retain the observations first rather than rushing to attribute the results.

If a piece of business ultimately falls short, first look for the problem along the performance chain: customer needs, product and price, fulfillment, channels, and payment collection. Then decide which SOPs need adjustment at the business-process, functional-task, or individual-action level. Handover is only one part of that chain. It cannot explain every business outcome.

Before the workflow moves to the next step, the deliverable should tell the recipient what they can do on its basis now, what they still cannot do, and whom to contact if things change. Connecting those conditions makes it possible to see how far the workflow has really progressed.

* * *

### Sources and optional further reading

-   Basis for the model: the early team document _Methodology for Mapping and Designing SOPs_, especially pages 6–9 on prerequisite tasks, onward routing, handover, exceptions, trials, and iteration. Two early relationship diagrams covering role responsibilities, work manuals, SOPs, and performance assessment supplied the research lead of “verifying prerequisite results.” This article reconstructs the handover and exception mechanisms as a working model. Its effects still need to be tested in specific business settings.
-   Conceptual reference: [ISO: The process approach in ISO 9001:2015](https://www.iso.org/iso/iso9001_2015_process_approach.pdf). Used to explain process inputs, outputs, and dependencies. This article is not an interpretation of standard clauses or a certification guide.

-   [A ten-step approach to business planning: connecting direction, resources, and execution (in Chinese)](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/): explore interdependent collaboration commitments through objectives and resource arrangements.

-   [The four-ecosystem governance model: contributions, rights, and the collaboration loop (in Chinese)](https://yutengfei.com/zh/journal/four-ecology-governance-model/): move from adjacent-process handovers to relationships among multiple parties and authority over specific matters.

-   [Contribution records and review: grounding evaluation in evidence while allowing objections (in Chinese)](https://yutengfei.com/zh/journal/contribution-record-review/): how to record and review each person's actual involvement after delivery.

## Related reading

- [From Job Responsibility Analysis to Role Handbooks: Helping Contributors Understand Their Work](https://yutengfei.com/en/journal/co-builder-role-handbook/)
- [Routine, Periodic, SOP-Triggered, and Received from Others: How Role Tasks Enter a Workflow](https://yutengfei.com/en/journal/role-task-entry/)

[CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/)

Applies to original text unless otherwise stated; excludes third-party materials. Downloading or machine reading does not extend the existing license or separately authorize derivatives, commercial use or model training.

[AI usage guide](https://yutengfei.com/en/journal/ai/)