# Task: Document a task for human–AI collaboration Start with the required result, then connect tasks, roles, handover conditions and checks. ## Prepare Choose a recurring real task. Prepare its objectives and result requirements, authorized inputs, current practices, participating roles and known exceptions, with sources, versions and gaps. ## Produce Draft the relationships supporting the result, closed-loop tasks, role responsibilities and handover conditions. Identify actions for possible AI assistance, acceptance checks and exception handover. ## Check Check inputs, outputs, owners and completion criteria. Trial complete, missing, conflicting and out-of-scope inputs; record human review, rework and unresolved issues, then examine the business result. ## Conditions This reading pathway helps document work and plan trials; it does not establish a universal approach for every role. A role may hold several closed-loop tasks, and a process may cross departments. Check task completion separately from business performance. Confirm inputs, conditions, sources and versions. List missing information; do not invent it. Identify goals, budgets, rights, permissions and final decisions that require human confirmation. ## Original text and version - Models: Four-Way SOP: Connecting Performance, Business Processes, Functional Tasks, and Actions | R1 | https://yutengfei.com/en/journal/four-way-sop/ Markdown: https://yutengfei.com/en/journal/resources/four-way-sop.md Identify the business and performance results that the work is intended to support. - Methods: How to Use Four-Way SOP: Connecting Business Results, Processes, People, and Daily Work | R1 | https://yutengfei.com/en/journal/four-way-sop-practical-guide/ Markdown: https://yutengfei.com/en/journal/resources/four-way-sop-practical-guide.md Break one business process into closed-loop tasks and specific actions. - Methods: From Job Responsibility Analysis to Role Handbooks: Helping Contributors Understand Their Work | R1 | https://yutengfei.com/en/journal/co-builder-role-handbook/ Markdown: https://yutengfei.com/en/journal/resources/co-builder-role-handbook.md Clarify role responsibilities and organize multiple tasks in a work handbook. - Models: What needs to be handed over before a process can move to the next step? | R1 | https://yutengfei.com/en/journal/process-handover-and-entry-conditions/ Markdown: https://yutengfei.com/en/journal/resources/process-handover-and-entry-conditions.md Check handover outputs, entry conditions and acceptance responsibilities. - Methods: From SOP to Skill: Where AI Can Help and How to Verify and Accept Its Outputs | R1 | https://yutengfei.com/en/journal/sop-to-ai-skill/ Markdown: https://yutengfei.com/en/journal/resources/sop-to-ai-skill.md Select possible AI assistance and define inputs, acceptance and exception handover. - Methods: We followed the SOP. Why aren’t we seeing business results? | R1 | https://yutengfei.com/en/journal/sop-business-outcome-diagnosis/ Markdown: https://yutengfei.com/en/journal/resources/sop-business-outcome-diagnosis.md Review actual results to distinguish action, collaboration and business-assumption issues. ## Associated Skill No installable Skill accompanies this pathway. Reading or downloading the pack does not install a Skill, connect AI tools or authorize execution. Further Skill development requires format, tool and permission checks, followed by trials and acceptance. ## Record results, deviations and knowledge or steps that need revision. Version: V1.0 · 2026-11-05 https://yutengfei.com/en/journal/pathways/sop-human-ai/ --- Select resources and sections as needed instead of indiscriminately loading every document. Exports retain existing licenses and third-party notices. Downloading grants no additional adaptation, commercial-use or training rights. --- # Four-Way SOP: Connecting Performance, Business Processes, Functional Tasks, and Actions - Author: Andrew David W.Y. - Source: https://yutengfei.com/en/journal/four-way-sop/ - 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**: Start with customer outcomes and economic results, then connect the key business processes, closed-loop tasks, and specific actions that support them. Four-Way SOP provides a supporting structure that can be developed downward and checked upward. It helps people understand why a task is needed and helps an organization see what still needs to be verified after a process is 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 shows how to map a four-way SOP. To assess its use, check whether downstream teams can use the deliverable and whether customer and economic outcomes change. 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 A quotation has been sent, but the customer has still not confirmed it. Sales says the quotation is complete. Purchasing says it has provided the supply conditions. The person preparing the quotation has also worked through the figures in the worksheet. Everyone has a completion record, yet the business has not moved forward. At this point, I would not rush to ask who has failed to finish. First, look at the problem the customer needs to solve. Does the quotation meet that need? Can the business deliver what it promises? Which result do all these completed tasks actually support? Four-Way SOP seeks to clarify the relationship between specific work and operating results. It divides SOPs into four levels: performance, business processes, functional tasks, and actions. During design, we can work downward from the result. After the work has been carried out, we can check upward from the actions. Following these relationships helps us keep asking why a task is needed, what standard it must meet, and how it connects with other people's work. ## 1\. Four levels, four questions SOP stands for Standard Operating Procedure. The Four-Way model discussed here classifies work procedures by their scope and level of detail. It does not require four separate documents for every piece of work, and the four levels are not four tiers of an organization. | Level | Main question | What it focuses on | Simplified example | | --- | --- | --- | --- | | Performance SOP | How does customer value translate into the business's economic results? | Key stages and results closely connected with customers | An order chain from confirming requirements to fulfilling the order and collecting payment | | Business Process SOP | What processes need to be organized to move a key stage forward? | A business result produced through several coordinated tasks | Preparing a quotation the business can honor | | Functional Task SOP | What single closed-loop task must a position or role complete? | A task with inputs, processing, outputs, and completion criteria | Calculating a quotation | | Action SOP | How is this task carried out in practice? | Preparation, operations, checks, exceptions, and handover requirements | Checking quantities and pricing units | **A Performance SOP starts with customer outcomes and economic results.** For an order-based business, we can map key stages such as confirming requirements, confirming the proposal and quotation, clarifying contract terms, fulfilling the order and completing acceptance, and settling and collecting payment. Different businesses have different sequences, branches, and parallel activities. One illustrative chain cannot be treated as a fixed route for every company. Performance also cannot be judged only by the number of deals closed. Whether the customer accepts the delivery, whether the business collects payment, and whether the work covers the necessary costs may all affect the assessment. A business should first define the scope of this performance chain, the observation period, and how its results will be measured, then choose the relevant records. **A Business Process SOP organizes work around a business result.** Getting a customer to confirm a quotation may require organizing requirements, verifying supply conditions, calculating the quotation, and having it reviewed by an authorized person. The Business Process SOP connects this work so that it produces a result the next stage can use. One department may be responsible for it, or it may involve collaboration across departments and organizations. **A Functional Task SOP covers one closed-loop task.** Here, “functional task” means a single task undertaken by a position or role, such as calculating a quotation, issuing an invoice, or verifying a supply lead time. It does not mean a functional department such as Finance or Purchasing, nor does it cover all the responsibilities of a position. To judge whether a task forms a complete loop, look at the conditions under which it starts, what it processes, what it delivers, and how completion is confirmed. **An Action SOP turns a task into instructions people can follow.** When calculating a quotation, for example, first read the confirmed version of the requirements, then check quantities and pricing units, calculate according to the authorized pricing rules, record the basis and unresolved matters, and finally submit the pricing worksheet. Where errors are likely, handovers are needed, or specific risks exist, the operating standards and handling of exceptions should be clear. There is no need to turn every familiar action into a lengthy tutorial. Scroll sideways to explore, or open the full diagram. [![The supporting relationships across the four SOP levels: work downward to specify the necessary work, and check upward to verify the basis for the results.](https://yutengfei.com/journal/four-way-sop/materials/en/01-four-layer-support.svg)](https://yutengfei.com/journal/four-way-sop/materials/en/01-four-layer-support.svg) Figure 1. The four levels describe the scope of work and its supporting relationships. Arrows indicate relationships that need to be explained and tested. They do not mean that completing a lower level necessarily produces the result at the level above. [Open full diagram ↗](https://yutengfei.com/journal/four-way-sop/materials/en/01-four-layer-support.svg)[Download editable SVG ↓](https://yutengfei.com/journal/four-way-sop/materials/en/01-four-layer-support.svg) ## 2\. Working downward means finding the processes that are actually needed Start with a real business activity. Look at where the customer makes a choice, where the business makes a commitment, and how delivery and payment are carried through. Then select one key stage and ask what results it needs and which tasks must jointly produce them. Take “confirming the proposal and quotation.” The fact that a customer can receive a quotation does not, by itself, establish that this stage has achieved its purpose. The quotation should address confirmed requirements. The supply, delivery, and commercial conditions on which it relies should be verifiable. Terms beyond the existing authorization need a decision from the appropriate decision-maker. The internal work to organize depends on what is needed to support these conditions. Working further downward, the business process of “preparing a quotation the business can honor” may include organizing requirements, verifying supply, calculating the quotation, and review by an authorized person. Each task has its own output and its own interfaces with other work. Organizing requirements cannot be marked complete just because “we have spoken.” It should produce a statement of requirements that can be checked. Verifying supply cannot stop at “it should be in stock.” It should state the conditions that have been confirmed and the limits within which they are valid. Now select the functional task of “calculating a quotation.” Its inputs might be confirmed requirements, valid supply conditions, and the currently applicable pricing rules. Its output might be an accurately calculated pricing worksheet that identifies its version and calculation basis for subsequent review. Missing information that blocks calculation should first be returned for confirmation. Items that do not block calculation but require later review can be listed with the worksheet. Any unresolved conditions affecting a commitment to the customer must be resolved before that commitment is made. At this level, the specific operating actions need to be explained in more detail. Each time we develop the next level down, we need to answer one question: **How does the additional work help produce the result needed at the level above?** If that cannot be explained, the task may be unnecessary, the higher-level objective may be unclear, or a process may be missing between the two. Document numbers alone cannot connect them. Scroll sideways to explore, or open the full diagram. [![How a quotation connects four SOP levels: a key stage in the order chain is developed into a business process, closed-loop tasks, and operating requirements.](https://yutengfei.com/journal/four-way-sop/materials/en/02-quotation-expansion.svg)](https://yutengfei.com/journal/four-way-sop/materials/en/02-quotation-expansion.svg) Figure 2. A fictional order-business example. Only part of the support for “confirming the proposal and quotation” is developed here. Solid arrows show illustrative flow; dashed lines show a selected part being developed in more detail. Actual business activities may run in parallel, branch, or require rework. [Open full diagram ↗](https://yutengfei.com/journal/four-way-sop/materials/en/02-quotation-expansion.svg)[Download editable SVG ↓](https://yutengfei.com/journal/four-way-sop/materials/en/02-quotation-expansion.svg) ## 3\. Checking upward: completed actions do not establish performance results Clear downward analysis must be matched by upward checking. Completing a check of pricing units shows only that one operating requirement has been met. Completing the quotation calculation means a worksheet meeting the task requirements has been produced. Only after requirements, supply, and authorization have been reviewed together may there be a quotation ready to offer the customer. Whether the customer accepts it, and whether the business can later fulfill the order and collect payment, still need to be observed. The four levels therefore cannot be expressed as simple equations between results. Several correctly completed actions can provide conditions for a closed-loop task. Several tasks can jointly support a business result. Several business processes can move a performance chain forward. But market changes, customer choices, product fit, resource constraints, and business judgment still affect the final result. If a customer has not accepted a quotation, first examine the customer's feedback and the relevant records in this performance chain. The problem may involve response time, the understanding of requirements, or an error in the quotation. It may also involve an unsuitable product, an unacceptable lead time, an uncompetitive price, or even a change in the customer's purchasing plan. After locating the problem, decide whether to adjust business coordination, a particular task, or operating requirements, or to reconsider the product and market. Develop the level that needs attention; there is no need to work through all four levels every time. Four-Way SOP helps us follow these relationships, ask further questions, and trace the supporting evidence. A layered diagram alone cannot prove a cause. Nor can below-target performance be attributed directly to one person's poor execution. ## 4\. Related to the organization, but not confined by its chart In practice, the four levels do not usually map one-to-one onto a company, its departments, its positions, and individuals. One person may undertake several functional tasks. One business process may require several roles. The same task of “verifying the supply lead time” may support both a new quotation and an order change. When mapping SOPs, retain two sets of relationships: which result a task supports, and who holds the relevant responsibility, authority, and resources. The first explains the logic of the work. The second explains who organizes and completes it. They are connected, but neither can replace the other. Shared tasks also need version and scope management. If supply conditions change, for example, which quotations remain valid, and which need to be reconfirmed? Copying the same task into several documents without maintaining its source can easily lead to work being carried out according to the process while relying on inconsistent information. We can observe a business through four kinds of participation relationships: Resource, Operations and Governance, Customer, and Capital—the four ecosystems. Participants can offer contributions proactively or respond to needs. A lean operations and governance team is responsible for decisions, rules, and the coordination of value production, sales channels, and customer relationships. Roles that contribute value enter business collaboration through the relevant tasks, while role handbooks explain how to use these processes. Customers acting only as consumers and investors acting only as investors follow their respective processes. Neither status alone requires a handbook for a co-creation role. The focus here is on how work connects. How contributions are assessed and rights and benefits are agreed still requires separate rules based on the actual business. These cannot be derived automatically from task completion records. ## 5\. Test one chain before deciding where to expand Using this model does not require starting with a company-wide document exercise. Select a real, recurring business chain whose results can be observed, and begin with three things. First, state which customer outcomes and economic results the chain should produce and which conditions cannot be omitted. Second, choose one key stage, develop the necessary business processes and closed-loop tasks, and connect inputs, outputs, responsibilities, and the basis for acceptance. Third, follow the work as it actually happens. Record missing items, waiting, rework, and customer feedback, then decide which operations need further standardization. A concise guide may be enough where people are already proficient, the work is stable, and handovers are simple. For new business, frequently changing requirements, or work that depends heavily on judgment, first clarify the objectives, decision conditions, and feedback arrangements, then develop procedures over time. Adding forms and approvals merely to fill all four levels can obstruct the business. Supporting work such as training and equipment maintenance may not relate directly to an individual sale. It may support several performance chains or affect capabilities and risks over a longer period. Explaining that support requires relevant records and judgment. We cannot force an allocation of revenue onto every action. The process approach already has an established body of work. ISO's technical guidance on the process approach in ISO 9001:2015 likewise emphasizes inputs, outputs, interfaces, responsibilities, and checks between processes. It also recommends determining the documentation needed in light of the organization's context and risks.\[1\] The purpose of the Four-Way model in this article is to use four levels of observation to work from customer outcomes and economic results down to specific tasks and actions. Its applicability still needs to be tested in actual business. To assess whether a trial is useful, look at whether participants can explain which result their delivery supports, whether the next stage can use that result, and whether relevant records can be found when a problem occurs. It is also worth observing whether handover omissions, rework, and waiting decrease, while recording changes in business volume and the complexity of requirements. Even if results improve, a single trial is not enough to establish that the model caused the improvement. The value of Four-Way SOP ultimately lies in whether work and results can explain each other. Working downward should show what needs to be organized. Checking upward should show what has been delivered and what has not yet been established. Repeatedly testing these relationships in the business gives procedures a chance to become a lasting way of working. ## Sources and further reading The model draws on the early research document supplied by the author, _Methodology for Mapping and Designing SOPs_ (《SOP梳理设计方法论》), particularly sections 2, 4, and 5. Its version record lists a training-related revision on March 9, 2023, and the development of the basic theory and model with the participation of Yang Jing (杨婧) on May 11, 2023. This article explains the four-level relationships afresh. Its diagrams are original reconstructions for this article and do not carry over the appraisal or allocation mechanisms in the historical diagrams. The quotation business described here is fictional. \[1\] ISO/TC 176/SC 2, _The Process Approach in ISO 9001:2015_, N1289, pp. 1 and 4–5. [Official technical guidance](https://www.iso.org/iso/iso9001_2015_process_approach.pdf). The reference here concerns the process approach. It does not present the Four-Way classification as an ISO requirement or imply that this model has been certified. Further reading: [Complexity, Simplicity, Clarity, and Diagrams: A Way to Think About Business Logic Design (Chinese)](https://yutengfei.com/zh/journal/fan-jian-yi-tu/); [Ten Steps in Enterprise Planning: Connecting Direction, Resources, and Execution (Chinese)](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/). ## Related reading - [How to Use Four-Way SOP: Connecting Business Results, Processes, People, and Daily Work](https://yutengfei.com/en/journal/four-way-sop-practical-guide/) - [We followed the SOP. Why aren’t we seeing business results?](https://yutengfei.com/en/journal/sop-business-outcome-diagnosis/) [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/) --- # How to Use Four-Way SOP: Connecting Business Results, Processes, People, and Daily Work - Author: Andrew David W.Y. - Source: https://yutengfei.com/en/journal/four-way-sop-practical-guide/ - Version: R1 - Published: 2026-11-04 - Revised: 2026-11-04 - Content status: Full text published - Content type: Methods (methods) - Research topics: Stakeholder Capital Governance (stakeholder-governance) - Ecosystem perspectives: Operations & Management Ecosystem (operations) · Resource Ecosystem (resource) · Customer Ecosystem (customer) ## Use this resource **Purpose**: Start with one path to business results, then clarify processes, resources and partners, role responsibilities, and daily actions. A hypothetical brand design company shows how Four-Way SOP can help startups test revenue paths, find and develop people, and preserve working methods for collaboration between people and AI. **Conditions for use**: Check that the subject, objective and constraints fit the task. Confirm any conditions that the article does not specify. **Methods · Steps, inputs and completion criteria** **Evidence and validation limits**: The example shows how to map a four-way SOP. To assess its use, check whether downstream teams can use the deliverable and whether customer and economic outcomes change. 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 How does a business produce results? What business processes does it need? Who should it hire? What should those people do each day? These questions can be considered together. When I first studied Four-Way SOP, I wanted to connect them. Start by finding the core process through which a business produces results. Then follow that process to clarify its business processes, functional tasks, and specific actions, one level at a time. An established business can use this approach to examine its current operations. A business just starting out can use it to analyze several possible ways to earn revenue and decide what to try first. I divide these relationships into four directions: **Performance SOP, Business Process SOP, Functional Task SOP, and Action SOP.** SOP stands for Standard Operating Procedure. Here, I use four directions to connect business results with specific work. Looking downward from performance asks, “What work do we need to organize to achieve this result?” Looking upward from an action asks, “What result does this work ultimately support?” For the full structure, you can first read the [introduction to the Four-Way SOP model](https://yutengfei.com/en/journal/four-way-sop/). In this article, I want to explain more concretely how a business can use it. The figure fits the reading width; you can also open it full-size. [![Four-Way SOP in practice: move from performance to business processes, functional tasks and actions to clarify revenue paths, resources and partners, responsibilities and people, and everyday work; check upward using practical feedback.](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/en/01-practice-map.svg)](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/en/01-practice-map.svg) Figure 1: Start with one performance path, develop the necessary work at each level, then check upward using practical feedback. The four levels describe scopes of work, not organizational tiers. Retained methods can support people working with AI, with authorization, configuration and output verification still required. [Open full-size figure ↗](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/en/01-practice-map.svg)[Download editable SVG ↓](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/en/01-practice-map.svg) ## 1\. First, find the core process that produces business results When mapping SOPs, I would first ask: Who are this business's customers? What does it provide? Why are customers willing to pay? How does the business deliver the work and earn a return? Once these questions are clear, the main line of the Performance SOP begins to take shape. In my early research, I used a simplified example: finding customers, preparing quotations, signing contracts, and collecting payment. I placed these stages in the Performance SOP because they are closely connected with customers and affect whether a transaction can be completed. In practice, requirements confirmation, delivery, acceptance, and other necessary conditions need to be added for the business concerned. **The processes in a Performance SOP should consist of the key factors needed for successful business results.** I will use a hypothetical brand design company throughout this article. One of its project businesses could initially be mapped as follows: Find customers with a need → Confirm requirements and service scope → Submit a proposal and quotation → Confirm the engagement and payment arrangements → Deliver the design and complete acceptance → Settle payment as agreed. This is the main line of the business. Each stage needs an outcome that can be clearly described. “Finding a customer” requires checking whether the customer is a suitable one. “Confirming requirements” should leave a scope both parties understand. “Completing the design” requires checking whether the delivery meets the agreement. Once this line is mapped, managers can more easily see where to look. If there are many prospects but few engagements, examine requirements, proposals, and quotations. If projects have been signed but cannot be delivered, examine production and delivery. If work has been delivered but payment has not arrived, look at acceptance and settlement conditions. The business also needs to define the results it is observing. Contract signings, revenue, gross profit, and cash received have different measurement bases and should not be mixed together. A business may have several Performance SOPs for different products, services, or customer types. ## 2\. Startups can first map several possible revenue paths A business without stable operations can also use this method. At the beginning, founders often have several ideas. Our hypothetical brand design company might offer project design, ongoing content services, or design training. These businesses need different customers, resources, and work arrangements. It can first map a simplified Performance SOP for each: - Project design: find a project customer, clarify scope and price, agree on the engagement, deliver the design, and complete acceptance and settlement. - Ongoing services: find customers with recurring needs, clarify the services and fee arrangements for each period, agree on the engagement, deliver on schedule, complete acceptance and settlement, gather feedback, and then decide whether to continue. - Design training: identify learners and their learning needs, design the course, recruit and enroll learners and collect fees, deliver the teaching, then check learning outcomes and further needs. The business can then compare them. Which path is closest to its existing resources? Which stage can it not yet complete? Are customers actually willing to pay? What needs to be invested at the outset? Which conditions need to be tested first? The discussion can then move from “There are many things we could do” to “Which business should we get working first?” For a business that has not yet been tried, I would treat its Performance SOP as a proposal to test. Choose a path that can be attempted with the conditions available, speak with real customers, deliver on a small scale, and adjust based on feedback. Mapping helps expose questions early. Actual business activity tests the judgments behind it. ## 3\. Clear Performance SOPs make business processes and resources easier to identify A Performance SOP tells us which key results need to be achieved. Next, we need to ask which business processes will produce them. For example, “complete the design delivery” may look like a single stage in the Performance SOP. Behind it, however, may be requirements research, creative design, content preparation, production checks, and customer communication. Together, these processes produce something the customer can use. Organizing them is the job of the Business Process SOP. **A Business Process SOP focuses on how to create value and pass it to the next stage.** Requirements research should provide a usable basis for design. Design work should deliver a proposal that meets the requirements. Production checks should ensure that the files can actually be used. When one step ends, the next should have something it can work with. Once the business processes are clear, the resources needed become more specific. Customer research needs interviewing and analytical capabilities. Design needs design skills, materials, and tools. Photography, printing, and other production may need suitable equipment, techniques, and supply capabilities. Following the business process allows us to assess, item by item, which resources we already have, which we must add, and which are suitable for a partner to provide. There are then concrete questions to ask potential partners. Which part of the capability can they provide? What result will they deliver? What standards will guide the collaboration? How will their work connect with ours? A business process may be completed by an internal team or involve external partners. First clarify the value needed and the working relationships, then decide which organization should take on the work. This makes it easier to find the resources actually required. ## 4\. Once the business processes are clear, clarify functional tasks and role responsibilities With a Business Process SOP in place, we can identify the tasks within it and develop Functional Task SOPs. In a design business, for example, someone needs to confirm requirements, someone needs to produce the design, someone needs to check production files, and someone needs to organize delivery. For each task, we can clarify its inputs, responsibilities, and outputs. Here, “functional task” means one piece of work that a position or role needs to complete. One position can undertake several functional tasks, and a business process may require several positions to work together. Putting these tasks together allows us to analyze role responsibilities. Why does this role exist? What work does it normally handle? Who does it work with? What capabilities does it need? This is useful for finding, assessing, and developing people. When hiring, requirements can be based on real tasks. Do we need someone who can turn customer requirements into a usable design brief, someone who can produce a particular kind of design, or someone who can coordinate delivery by several people? Different needs call for different searches. When assessing people, we can review their work, ask about their process, and use practical exercises tied to the relevant tasks. This helps us understand how they approach a problem, use resources, and complete a delivery. People with the same job title may be able to undertake very different work. When developing people, we can also identify specific gaps. Were requirements not clarified? Is the person unfamiliar with the tools? Were delivery checks insufficient? Locating a gap in tasks and actions allows us to arrange suitable practice and check progress through later work. Staffing can change with the business. At the startup stage, one person may fill several roles. As the business grows, roles can be separated according to workload, specialist requirements, and collaboration needs. Four-Way SOP helps us explain what work is needed, then judge what people and organizational arrangements it calls for. ## 5\. Develop functional tasks into clear daily actions A Functional Task SOP clarifies what needs to be completed. An Action SOP explains how to complete it. For example, “organize customer requirements” can be developed into: prepare interview questions, record the information the customer provides, check unresolved points, prepare a requirements statement, obtain confirmation, and pass it to the design stage. Where omissions or errors are likely, the standards also need to be clear. What information is required? Which version of the source material should be used? How do we judge whether the work is ready for handover? Who should resolve missing information? We can then put this work back into everyday schedules and consider four task attributes: - **Routine tasks**: regular work carried out continually, such as checking customer inquiries and maintaining project records. - **Periodic tasks**: work carried out at agreed intervals, such as preparing weekly project updates or reviewing monthly service performance. - **SOP-triggered tasks**: work arising when an SOP reaches an agreed stage and the relevant conditions are met, such as starting design after requirements are confirmed or preparing delivery after a proposal is approved. - **Tasks received from others**: matters requested or assigned by someone else, such as a customer requesting a change or a collaborator asking for support. “Received from others,” called “passive” in the Chinese classification, describes how a task arrives. It does not judge whether the person is proactive. The attributes can also overlap. A customer change request can be received from someone else and also trigger a change-handling process. With these points clear, a person in a role knows what to do regularly, what to do when the time comes, what to do when a particular condition arises, and how to handle matters received from others. The applicable SOPs, tools, delivery standards, and working relationships can then be organized into a role handbook. Newcomers have a place to start learning, experienced people have a shared reference, and handovers become easier. ## 6\. SOPs also give AI resources for understanding the business's work This organization of work is valuable for people and for AI. If we tell AI only “Help me prepare a proposal,” much of the business context is missing. Who is the customer? Which stage should the proposal move forward? What information is needed? Who will use the output? Which conditions cannot be decided without authorization? All of this may still be unclear. Four-Way SOP connects that context. The Performance SOP explains the purpose of the work. The Business Process SOP explains how work is coordinated. The Functional Task SOP explains the specific task. The Action SOP explains the method and standards. Take organizing requirements. We can provide AI with information authorized for this use, an applicable requirements template, and checking criteria. It can help organize the information, flag gaps, and prepare a draft for the responsible person to review. The process should also identify what must be confirmed with the customer and which decisions involve external commitments. SOPs that have been used in practice can be further organized into knowledge, task instructions, and Skills that AI can draw on. Alongside successful methods, actual exceptions, reasons for failure, and records of adjustments are worth keeping. I also see a longer-term value. As AI capabilities continue to develop, the working methods a business records today will become important resources for AI to understand and participate in actual business activity. They contain the purpose, relationships, conditions, and experience behind the work, rather than just a sequence of steps. Giving files to AI does not mean it has learned the work or that the process can run automatically. What it can take on still depends on tool capabilities, permissions, and checks of the results. But the clearer these foundations are, the stronger the basis for later collaboration between people and AI. ## Start with one line of business whose results you can observe To put this into practice, take a sheet of paper and write down one Performance SOP. Choose one key stage and develop the business processes it needs. Then identify tasks and responsibilities within those processes. Finally, describe the actions that need to be repeated, their standards, and the conditions under which the tasks arise. Run it through real business activity, then look back. Were the key results achieved? Were resources sufficient? Where did one person's work fail to connect with another's? Which actions need changing? Which work, although originally planned, was not actually needed? When results fall short, leave room to return to the higher levels and reconsider. Customer needs, products, prices, resources, and the external environment can all change. Process records help locate problems, but the specific causes still need to be investigated. My early _Methodology for Mapping and Designing SOPs_ already included trials, feedback, and iteration in the development process. Looking back today, I still think this step matters. Once a process has been written down, it needs to keep becoming more useful through actual work. **How a business produces results, how its processes create value, which resources and people it needs, and how each person works every day can all be clarified step by step through the same set of relationships.** That is what I hope Four-Way SOP can help businesses do. Start with one line of business, understand how to make it work, and keep the methods that prove useful. ## Research basis and further reading This article draws on the four-way model, role responsibilities, work classifications, trials, and iteration in my early research material, _Methodology for Mapping and Designing SOPs_. It reworks those ideas alongside my current thinking on startups, resource collaboration, talent development, and AI applications. The brand design company is a hypothetical example used to explain the method, not a record of verified business results. Terms such as “Work SOP” in the early material are standardized here as “Action SOP.” The task attributes follow the current categories of routine, periodic, SOP-triggered, and received from others. - [Introduction to the Four-Way SOP model](https://yutengfei.com/en/journal/four-way-sop/) - [From role responsibility analysis to a role handbook](https://yutengfei.com/en/journal/co-builder-role-handbook/) - [How role tasks enter a workflow](https://yutengfei.com/en/journal/role-task-entry/) - [From SOP to Skill](https://yutengfei.com/en/journal/sop-to-ai-skill/) ## Related reading - [Four-Way SOP: Connecting Performance, Business Processes, Functional Tasks, and Actions](https://yutengfei.com/en/journal/four-way-sop/) - [We followed the SOP. Why aren’t we seeing business results?](https://yutengfei.com/en/journal/sop-business-outcome-diagnosis/) [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/) --- # From Job Responsibility Analysis to Role Handbooks: Helping Contributors Understand Their Work - Author: Andrew David W.Y. - Source: https://yutengfei.com/en/journal/co-builder-role-handbook/ - Version: R1 - Published: 2026-11-04 - Revised: 2026-11-04 - Content status: Full text published - Content type: Methods (methods) - Research topics: Stakeholder Capital Governance (stakeholder-governance) - Ecosystem perspectives: Operations & Management Ecosystem (operations) · Resource Ecosystem (resource) ## Use this resource **Purpose**: Start with the result a business needs, then turn responsibility analysis into role handbooks that clarify tasks, conditions, authority, deliverables and collaboration. A hypothetical requirements documentation role shows how a handbook is applied to a real task and improved through trials. **Conditions for use**: Check that the subject, objective and constraints fit the task. Confirm any conditions that the article does not specify. **Methods · Steps, inputs and completion criteria** **Evidence and validation limits**: Try the handbook on a real task. Check responsibilities, how the task starts, and delivery conditions before revising it using feedback. 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 Someone is willing to contribute to a business activity. How do they get started? If we only say, “You handle the requirements” or “Help us with the content,” practical questions soon follow. Who should they speak to? Which materials can they use? What needs to be ready before they hand the work over? Who decides when people disagree? The same thing happens inside a company. Job responsibilities are documented and processes are mapped, yet when someone new takes over, the previous person still has to explain everything repeatedly. I think a handbook should make clear how to carry out the work once a responsibility has been accepted. Contributors need to know what they can contribute, what conditions they need, and how their work connects with other people's work. ## 1\. Start with the result this work needs to support Before writing a handbook, choose a real business activity and identify the result it currently needs. For example, a company is preparing a business overview. What it needs first may be a confirmed requirements brief that enables writing and design to begin. It should also be clear which customers the material serves, where it will be used, and what it should help customers understand. Starting with “Who has time right now?” can turn a temporary arrangement into a lasting responsibility. Working only from existing job titles can also leave out work the business genuinely needs but no one currently handles. The earlier research document, _Methodology for Mapping and Designing Standard Operating Procedures (SOPs)_, already connected business processes, job tasks, specific actions, standards and handovers. It also called for trials before further improvement. We can develop that approach by first identifying the result needed, then checking how existing work supports it. Effective divisions of work can stay. Overlapping responsibilities, missing handovers and inadequate conditions need another discussion.\[1\] Two levels of results need to stay distinct. A confirmed requirements brief is a work deliverable. Whether it makes the material clearer or helps customers make decisions must still be observed in later business activity. A complete handbook and an on-time task do not, by themselves, establish that business outcomes have improved. ## 2\. Be clear about the role, the person and this particular task Job analysis provides a starting point for understanding the work. For collaboration across teams and organizations, contributions that can be undertaken relatively independently also need to be defined as roles. Here, a value contribution role is an agreement about a type of contribution and the responsibilities attached to it. For example, a “requirements documentation contributor” may gather and check requirements and prepare a requirements confirmation sheet for later use. An employee or an external professional partner could undertake this role when the conditions are suitable. | Level | What needs to be answered? | Requirements documentation example | | --- | --- | --- | | Role | What type of contribution is undertaken on an ongoing basis, and where are its boundaries? | Gather, check and organize the requirements for producing a business overview | | Person | Who has the necessary capability, time and conditions to participate? | An internal colleague or an external collaborator undertakes the work on this occasion | | Task | What must be delivered this time, and who undertakes and reviews it for acceptance? | Submit a requirements confirmation sheet for a particular project by the agreed deadline | One person can hold several roles, and several people can share a role. Each task still needs named people to undertake the work, collaborate and review it for acceptance. Writing “the requirements role is responsible” is not enough. Where several people share the work, their individual scope also needs to be clear so that everyone does not assume someone else has handled it. Resource, operations and management, customer, and capital ecosystems are four perspectives on participation relationships. Work arrangements should not mechanically assign a separate set of roles to each ecosystem. All kinds of participants can offer contributions proactively or respond to specific needs. A lean operations and management team handles the relevant decisions and rules, and coordinates value production, sales channels and customer relationships. Who can decide a particular matter must still be specified according to the authority actually granted. A handbook corresponds to a value contribution role that someone actually undertakes. Customers, in their capacity as buyers or users, participate through purchasing, use, feedback and after-sales processes. Those participating solely as investors follow the relevant investment and information communication processes. Neither status, on its own, requires a handbook for collaborative work. If they separately take on product co-creation, professional research or another defined contribution role, they use the handbook for that role.\[2\] Scroll sideways to explore, or open the full diagram. [![Figure 1: Identify the result the business needs, define the contribution role, prepare its handbook, then apply it to a particular task.](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/01-result-role-handbook.svg)](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/01-result-role-handbook.svg) Figure 1: The arrows show the suggested order of analysis. One person can hold several roles; arrangements for undertaking each task are specified separately. The example does not represent verified effectiveness. [Open full diagram ↗](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/01-result-role-handbook.svg)[Download editable SVG ↓](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/01-result-role-handbook.svg) ## 3\. A handbook should help people answer eight questions A responsibility statement can explain what someone undertakes. The handbook also needs to explain how to start, handle and complete the work. These eight questions can serve as a checklist for the first version. Adjust the length to the complexity of the work. There is no need to create material just to fill a contents page. | Question to answer | What the handbook should contain | | --- | --- | | Why is this role needed? | Who it serves, the business result it supports and its scope | | Which work do I undertake? | Main responsibilities, how tasks arise and the division of work with other roles | | What conditions must be in place before I start? | Necessary materials, capability, time, tools and access permissions | | How is the work usually carried out? | Key steps and references to applicable SOPs, templates and examples | | What can I decide myself? | Matters the role can confirm or handle, and who must decide other matters | | What must I deliver, and what counts as acceptable? | Deliverables, quality requirements, acceptance arrangements and the receiving role | | What should I do when something is missing or changes? | How to record it, whom to contact and how to obtain missing inputs, adjust or pause the work | | Who maintains this handbook? | Maintainer, version, scope, effective date and change arrangements | Describe responsibilities so that others can see what is actually done. “Responsible for requirements management” is still too broad. It can be made more specific: “Check the production purpose, use context and content scope; prepare a requirements confirmation sheet; identify sources and matters awaiting confirmation.” Standards should relate to the work as well. If facts need to be checked, say which statements require sources and which gaps prevent progress. Do not replace requirements with phrases such as “be responsible” or “work promptly and efficiently.” For exploratory work, leave room to choose methods. Specify the questions to answer, the evidence required and the points for discussion without fixing every step in advance. SOPs and role handbooks can refer to one another. The handbook starts from a role and tells me which process to use in which circumstances. An SOP starts from a piece of work and explains the roles, steps and standards involved. Maintain one current, applicable version of a shared process and link to it from the handbook. That reduces the chance of copied versions changing independently in different places. ## 4\. Build the content from real work, then ask someone else to try it The first version can start with a task that has already been carried out or is about to begin. Ask the person who actually does the work to explain where it comes from, which materials they look at first, which judgments rely on experience, whom they usually ask to check things, and what they finally hand over to whom. Then ask the upstream and downstream participants to check it as well. This often reveals whether work the contributor considers finished is really usable by the next person. When documenting it, distinguish three states: practices already checked, arrangements proposed for trial, and questions still awaiting a decision. A longstanding practice is not necessarily a sound standard. A promising new approach also needs to be used before it can be assessed. Next, choose a collaborator who has the basic capability but is unfamiliar with the work, and ask them to use the handbook on a task with a manageable scope. Someone can guide them the first time. Record where they stop, what needs extra explanation and which inputs they cannot obtain at all. When these problems arise, first check the handbook and the conditions for doing the work. Are the instructions unclear, or does the task exceed the person's capability? Is something missing from the process, or are authority, materials and time unavailable? Establish what is happening before deciding whether to add training, change the division of work, adjust the conditions or revise the handbook. If the work remains highly uncertain, begin with a short role description and a task sheet, recording what happens as you go. Forcing it into fixed steps too early can lead people to keep working from assumptions that no longer hold. ## 5\. Try a draft for a requirements documentation contributor The following is a hypothetical example involving production of a company's business overview. It illustrates how to use the method and does not describe results already achieved by a particular project. **Role purpose:** Organize the production requirements sufficiently for writers and designers to judge how to proceed, reducing repeated guesswork about the use context, content scope and business facts. **Conditions for starting:** The project lead has clarified the production purpose, intended audience and broad scope; supplied existing materials that may be used; and identified who can confirm the business facts. The deadline, time available and acceptance reviewer are agreed separately for this task. **Main work:** First check who will read the material, where it will be used, and what they should understand or do. Then organize the business content and presentation requirements, check sources for key statements, and list disagreements and gaps for confirmation by someone with the relevant authority. **Deliverable:** A requirements confirmation sheet covering, at a minimum, the use context, audience, content scope, key business facts and sources, delivery specifications, confirmed matters, matters awaiting confirmation and the people responsible for them. Record the specific deadline, confirmation status and applicable version with the task. **Authority and collaboration:** The contributor can ask questions, organize materials and suggest ways to present the content. Matters such as business scope, product commitments, prices and publication timing are confirmed by people with the relevant authority. Putting an undecided matter into a document does not turn it into a company commitment. **Acceptance and receipt:** The acceptance reviewer checks facts and scope. The writing and design roles check whether they have what they need to begin. If a gap affects only part of the content, identify which confirmed parts can proceed first. A gap affecting the overall direction needs to be filled or resolved through a new decision first. “The file has been submitted” cannot replace a judgment about how usable it is. **Handling exceptions:** When materials contradict one another, the use context changes or new requirements exceed the scope, record the issue and its impact. Ask the relevant responsible person to decide whether to add information, adjust, pause or cancel. A new scope and deadline need confirmation. The contributor can also propose improvements proactively, but carrying them out requires the relevant authority and conditions. **Completion and handover:** Save the final confirmation sheet and necessary supporting material. Explain outstanding matters, limitations and the version to downstream participants. If someone else takes over, hand over unfinished tasks, file locations and access arrangements. The participant then has more than a request to “help organize requirements.” They can judge whether they have the conditions to undertake the task and know how to move it forward once they begin. ## 6\. Keep a way to adjust once the handbook is in use At the start, both sides confirm the scope, conditions, deadline and acceptance arrangements. During execution, use the applicable version and raise gaps promptly. At the end, check the delivery and downstream receipt, then report problems with the handbook itself to its maintainer. For items that do not pass acceptance, explain what needs to be added or reworked, and review them again after that work is complete. Disagreements go to the responsible person or review role agreed in advance. Paused matters remain pending; reconfirm conditions before continuing. Cancelled matters end after the necessary closing work. In a small team, one person may hold several roles, but important commitments and matters involving conflicts of interest still need review under the actual rules. Revisions also need a basis. A one-off special arrangement can first be recorded as an exception. If similar problems recur or business conditions change, decide whether the general practice should be revised. The new version should say what changed, where it applies and when it takes effect. Explain how unfinished tasks transition between versions, and keep earlier versions for reference. Scroll sideways to explore, or open the full diagram. [![Figure 2: The role handbook is used in task acceptance, execution, review and feedback. Authorized people decide exceptions; revisions are assessed when necessary.](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/02-handbook-in-use.svg)](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/02-handbook-in-use.svg) Figure 2: This is a proposed operating mechanism. Conditions must be reconfirmed before work continues after an exception, and revisions must be confirmed as effective. Assess deliverable quality, downstream usability and changes in business outcomes separately. [Open full diagram ↗](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/02-handbook-in-use.svg)[Download editable SVG ↓](https://yutengfei.com/journal/co-builder-role-handbook/materials/en/02-handbook-in-use.svg) To judge whether the handbook helps, start with a few practical questions. Do new contributors have a clearer idea of where to begin? Are key problems found earlier? Is there less explanation and rework? Can downstream participants accept the work more easily? Before and after a trial, record the scope, complexity and participants' experience for comparable tasks where possible. Simpler tasks and more experienced people can also affect the result; not every improvement can be attributed to the handbook. The handbook can specify the evidence to retain for deliveries and contribution records. Pay, expenses, rights and interests, and the conditions attached to them are confirmed separately under the contracts and rules for the actual business. They do not follow automatically from completing a task in the handbook.\[2\] AI can help find applicable content, organize existing materials, draft confirmation sheets and identify omissions using the handbook. It must still be clear who checks the facts, which matters can be decided and who receives the result. Turning reusable steps into a Skill—a reusable guide for AI-assisted work—also requires a defined scope, inputs and outputs, and boundaries for human judgment. Choose one role that currently needs repeated explanation. Use a real task to set out its purpose, conditions, work, authority and deliverables. Let the next suitable contributor try it, then revise it around the problems they encounter. That gives the handbook a practical starting point. ### Basis and further reading \[1\] Early research material, _Methodology for Mapping and Designing Standard Operating Procedures_ (《SOP梳理设计方法论》, in Chinese). The main references are the relationship between job responsibilities and handbooks on pages 3–4, and documentation, job research, trials and iteration on pages 6–9. The document retains its 2023 version and collaboration records. The ecosystem contribution roles, the distinction between roles and tasks, and the trial suggestions in this article develop those materials further. Two historical diagrams of responsibilities and processes were used only to identify the original relationships; their performance assessment and rights arrangements have not been carried over. \[2\] [_Four-Ecosystem Governance Model: Contributions, Rights and Interests, and the Collaboration Cycle_ (in Chinese)](https://yutengfei.com/zh/journal/four-ecology-governance-model/) discusses participation relationships, contributions, rights and interests, and authority over specific matters. This article examines how role handbooks organize work, without assuming a uniform allocation method. For further reading, [_Ten Steps for Enterprise Planning: Connecting Direction, Resources and Execution_ (in Chinese)](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/) discusses business objectives and collaboration conditions. [_What Can a Business Retain After a Transaction?_ (in Chinese)](https://yutengfei.com/zh/journal/after-transaction-business-accumulation/) considers how experience can be used in later work. This article proposes a method for testing in practice. It does not provide evidence of its effectiveness across different companies. The diagrams and hypothetical example explain the mechanism. ## Related reading - [What needs to be handed over before a process can move to the next step?](https://yutengfei.com/en/journal/process-handover-and-entry-conditions/) - [Routine, Periodic, SOP-Triggered, and Received from Others: How Role Tasks Enter a Workflow](https://yutengfei.com/en/journal/role-task-entry/) - [Start with One Performance Chain: A Practical Way to Reshape the Enterprise Ecosystem](https://yutengfei.com/en/journal/performance-chain-ecology-transformation/) - [We followed the SOP. Why aren’t we seeing business results?](https://yutengfei.com/en/journal/sop-business-outcome-diagnosis/) [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/) --- # 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/) --- # From SOP to Skill: Where AI Can Help and How to Verify and Accept Its Outputs - Author: Andrew David W.Y. - Source: https://yutengfei.com/en/journal/sop-to-ai-skill/ - Version: R1 - Published: 2026-11-04 - Revised: 2026-11-04 - Content status: Full text published - Content type: Methods (methods) - Research topics: Stakeholder Capital Governance (stakeholder-governance) - Ecosystem perspectives: Operations & Management Ecosystem (operations) · Resource Ecosystem (resource) ## Use this resource **Purpose**: Start with a specific piece of work, assess where AI is suitable, and agree on inputs, outputs, acceptance criteria, and human takeover. Integrate the Skill into business collaboration while keeping business judgment and responsibility clear. **Conditions for use**: Check that the subject, objective and constraints fit the task. Confirm any conditions that the article does not specify. **Methods · Steps, inputs and completion criteria** **Evidence and validation limits**: The article offers a trial approach. Before integrating it into work, agree on input access, output acceptance, stopping conditions, and responsibility for human takeover. 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 If a business already has an SOP—a standard operating procedure—can it give the document to AI and ask it to follow the steps? Start with part of the work. First, make clear which part AI will handle, what information it needs, what it must produce, and who will decide whether the result is ready for the next stage. For example, AI can help organize customer requirements, compare product information, and list missing information. The responsible roles still need to judge whether the requirements have actually been met, which transaction terms to accept, and what commitments to make to the customer. Both kinds of work may appear in the same SOP, but they have different conditions for execution and different responsibilities. Moving from SOP to Skill means turning clearly defined work that is suitable for AI assistance into a reusable action guide, then integrating it into existing collaboration. Whether a Skill is usable depends on how its outputs are checked and whether the work can stop promptly and return to a person when something goes wrong. ## Distinguish the business process from the AI action guide An SOP explains the conditions under which work starts, the processes it goes through, what each role must do, the standards to meet, and how work is handed over. It governs working relationships within the business. In this article, a Skill means a task guide and supporting resources that AI can invoke. In the Agent Skills open format, for example, a Skill contains at least a `SKILL.md` file and may also include scripts, reference materials, and templates. It gives AI the methods and context needed for a particular task.[¹](https://agentskills.io/home) The two are not equivalent. One business SOP may require several roles, tools, and Skills working together; a document-checking Skill may be used in different business processes. An SOP also covers on-site work, negotiation, decisions, responsibilities, and handovers. Only some of these belong within AI's scope of execution. Rewriting an SOP as instructions does not complete the conversion. You also need to check whether AI can obtain the required information, use the relevant tools, recognize exceptions, and leave outputs that can be inspected. Steps written in a Skill cannot, on their own, expand the executor's authorization. The four-layer SOP model organizes work into four levels: business results, business activities, functions, and actions. Start by locating problems in the business-results chain, which connects to customers and economic outcomes. Then organize improvements to business collaboration, functional tasks, and specific actions as needed. AI can assist with specific work at different levels; there is no need to package the entire business-results chain into one Skill. If the real problem concerns how customer needs are defined, product conditions, or channel selection, faster document processing alone may not improve business results. ## Start with a piece of work that can be checked Choose a task with clear boundaries and results that are easy to review. One example is: “Use the specified materials to organize customer requirements and items that need confirmation.” Start by answering five questions. | What to check | Conditions for getting started | What to do when conditions are missing | | --- | --- | --- | | Purpose of the work | You can explain who will use the output and which next step it supports | First clarify the business problem and the user of the output | | Input materials | Sources, versions, required fields, and permitted uses are clear | List what is missing, obtain the materials, or adjust the scope | | Output | There is a list, table, draft, or other deliverable that can be handed over | First agree on the form of the output and the conditions for completion | | Basis for acceptance | The output can be judged against source materials or business standards | First have business staff define the standards and counterexamples | | Exceptions and responsibility | It is clear when to stop, who takes over, and who approves use | First define how issues will be handled and which roles are responsible | Also ask whether AI is needed at all. Fixed-field conversions or calculations governed by defined rules may be reliably handled by spreadsheet formulas or scripts. Use those tools directly where appropriate. Then assess whether AI helps with the parts that require understanding natural language, organizing unstructured information, preparing a first draft, or proposing judgments that need verification. When standards are still disputed, information cannot be obtained, or errors would be difficult to reverse, narrow AI's task to organizing facts and raising questions. Give people the information needed to make a judgment before deciding whether to expand AI's role. Scroll sideways to explore, or open the full diagram. [![Figure 1: Select work suitable for AI assistance from a business problem, package it as a Skill, and integrate it into the SOP after a trial](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/01-sop-to-skill-boundary.svg)](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/01-sop-to-skill-boundary.svg) Figure 1 | Choose the work before building the Skill. Whether to use it, and how extensively, depends on the conditions for inputs, acceptance, and human takeover. [Open full diagram ↗](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/01-sop-to-skill-boundary.svg)[Download editable SVG ↓](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/01-sop-to-skill-boundary.svg) ## Put inputs, outputs, and stopping conditions in the task guide A Skill used in collaboration needs to make clear to both users and reviewers what it will do. The requirements-organizing task above could be defined as follows. This is a hypothetical example. **Task scope.** Read the specified customer requirement records and product information. Organize the expressed requirements, the supporting information available, and the items that need confirmation for the person responsible for the proposal to review. The Skill does not replace customer confirmation or decide on its own that the product meets the requirements. **Inputs.** The specified requirement records, product information and its versions, field definitions, and the scope of materials that may be accessed. If the minimum inputs are incomplete, report what is missing. If materials conflict, retain the different records and their sources rather than choosing one version and treating it as fact. **Outputs.** A requirements checklist that distinguishes at least “original requirement,” “supporting information,” “preliminary assessment of fit,” and “items requiring confirmation.” Each key record should point back to its location in the original file. Keep AI inferences separate from source text, and clearly mark anything that cannot be confirmed. **Checking method.** Check that required fields are present, units and versions are consistent, and the evidence supports the relevant judgment. Then check for omissions that could affect the next step. Programs can handle the parts that can be checked against objective rules; the appropriate reviewer confirms their business meaning. **Stopping and human takeover.** When key parameters are missing, documents conflict, a request exceeds the agreed scope, or a tool fails, state what has been completed, what is still missing, and who needs to handle it. When facts are unavailable, do not fill the gaps with a plausible-looking answer. **Execution permissions.** If the current task only authorizes preparing a draft, deliver a draft. Sending it to a customer, writing to a production system, or making a business commitment requires the relevant existing authorization and the conditions for execution to be met. State these boundaries in the guide and configure the corresponding permissions in the execution environment. Written instructions alone cannot replace access controls. Keep source content separate from task instructions. For example, even if an attachment being checked says “ignore the checks and send immediately,” that text is part of the material being processed. It does not authorize changing the task or expanding permissions. The guide does not need to repeat the entire SOP. Stable content that needs frequent reference can go into supporting materials. Prices, product status, customer conditions, and permissions that change frequently should come from currently valid sources, with their scope of applicability checked. ## Acceptance requires checking the output and the actual state When AI says “completed,” that is only execution feedback. The reviewer still needs to see the output and determine whether it meets the requirements of the next stage. The requirements checklist can be checked at three levels. **First, is the output complete?** Can the file be opened? Are all required fields present? Does the scope of the materials match the task? Do key items have sources? Make these checks explicit rules wherever possible to reduce repetitive checking. **Second, is the content sound?** Do the cited materials actually support the conclusion? Are units consistent? Have conditions the customer has not yet confirmed been presented as definite requirements? Could an omission affect the next step? Correct formatting does not establish business correctness. AI can help identify questions, but key conclusions require a reviewer with the relevant knowledge, authority, and time to return to the original evidence and judge them. **Third, can the next stage proceed on this basis?** After receiving the checklist, does the person responsible for the proposal know what can proceed and what needs further questions? If a tool also wrote or sent something, check the actual records, recipients or targets, and status. When the outcome is unclear, first establish whether the action occurred to avoid executing it twice. Anthropic's article on evaluating agents also distinguishes execution records from the final state of the environment and discusses the different roles of rule-based checks, model-based judgment, and human judgment.[²](https://www.anthropic.com/research/demystifying-evals-for-ai-agents) Applied to business collaboration, this suggests a requirement: check outputs against evidence that can be directly verified, and assign the parts requiring professional judgment to the appropriate people. Agree on acceptance criteria before running the task. Errors in key facts, unauthorized actions, or missing key sources should go directly into issue handling. High scores for fluent writing or attractive formatting must not offset them. Reviewers must also retain the right to reject the output or return it for more information when they find problems, so that review does not become a formality. Scroll sideways to explore, or open the full diagram. [![Figure 2: Input verification, AI assistance, rule-based checks, human review, and handover form the acceptance process; exceptions go to human takeover](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/02-acceptance-and-human-handover.svg)](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/02-acceptance-and-human-handover.svg) Figure 2 | Check the output before handing it over. Key exceptions go to human takeover at the relevant stage. This diagram proposes a way to organize the work that still needs to be tried in practice. [Open full diagram ↗](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/02-acceptance-and-human-handover.svg)[Download editable SVG ↓](https://yutengfei.com/journal/sop-to-ai-skill/materials/en/02-acceptance-and-human-handover.svg) ## Run a trial before deciding how to use it An initial success only shows that one task was completed with the materials and environment available at that time. To assess whether the approach can be reused, deliberately prepare different situations that may arise. For the requirements-organizing example, trials should cover at least complete materials, missing key conditions, different versions of the same parameter, inconsistent units, unreadable materials, and requests beyond the agreed scope. Also check whether AI stops when it should and whether it returns work to a person too early when it should continue. Business staff should first define acceptable results for each situation, then run the task and review it. Observe key situations that tend to vary more than once, and reserve some materials that were not used to adjust the guide for a separate check. The number and scope of examples depend on business risk. A small trial cannot establish suitability for every business or task. Record output quality, human review time, rework, and exceptions together. Measuring only the time AI takes to produce a first draft may leave out the cost of subsequent checking. Compare it with the previous way of working: with similar materials, does it produce a usable output sooner, make omissions easier to find, and reduce repeated confirmation for the person taking over? Depending on the results, you can keep item-by-item human review, use only part of the Skill, revise the guide and try again, or stop using it. Consider reducing item-by-item human checks within existing authorization only for work with limited consequences, clear rules, and sufficient validation. Retain spot checks and human takeover for exceptions. For each trial, retain the Skill version, input-material versions, deliverables, review conclusions, and unresolved items. When business rules, information sources, models, or tools change, use these records to determine what needs to be checked again. Passing acceptance for one task means that this output meets the agreed requirements. Whether a Skill is reusable also depends on its performance in tested situations and the record of subsequent use. Whether it further improves customer experience, sales, or other economic outcomes requires continued observation of the business-results chain. Completing one task does not, by itself, establish improved business performance. ## Responsibility still belongs to roles when AI participates Across the resource, operations and management, customer, and capital ecosystems, all kinds of roles may contribute proactively or respond to needs. Who creates, invokes, or maintains a Skill should follow the actual work arrangements. The lean operations and management team is responsible for the relevant decisions, rules, and coordination, organizing collaboration between value production, sales channels, and customer relationships. For a specific piece of AI-assisted work, clarify three things: who maintains the business requirements and acceptance criteria, who is responsible for the inputs and execution of this task, and who confirms that the output may enter the next stage. Appropriate roles may hold more than one responsibility. Where important work requires cross-checking, arrange review according to the business consequences. Adding the words “AI review” does not establish that someone has the ability to review the work or accepts responsibility for it. Work manuals for value-contributing roles can list the Skills they may invoke, delivery requirements, and points of coordination with others. Customers acting as buyers and participants acting solely as investors follow their respective processes; those identities alone do not require a co-creation work manual. The AI tools a participant uses do not directly determine contributions or entitlements. Those arrangements still depend on actual business activities, deliverables, and institutional rules. Start with a real, recurring task. Make clear which result it supports, which parts are suitable for AI, where the evidence comes from, and who takes over when an exception occurs. Write down these conditions, try them, revise them, and gradually integrate them into collaboration. This gives a Skill a basis for becoming a usable, maintainable organizational capability. ## Further reading - [The Think Tank for AI Use (Chinese)](https://yutengfei.com/zh/journal/ai/): Understand the relationship between knowledge, tasks, tools, and authorization. - [My Skills (Chinese)](https://yutengfei.com/zh/skills/): See how experience, judgment, and methods become action guides that can be invoked. - [How Can a Business Content System Keep Its Messaging Consistent and Up to Date? (Chinese)](https://yutengfei.com/zh/journal/business-content-system-maintenance/): Explore facts in source materials, review, and updates further. ## Notes on sources This article builds on ideas in the early _Methodology for Mapping and Designing SOPs_, including operating standards, assessment criteria, handling special situations, trials, and iteration. The scope of AI assistance, acceptance process, and human takeover mechanism are method designs developed further in this article. The requirements-organizing task is hypothetical. ¹ [Agent Skills Overview](https://agentskills.io/home) explains the basic structure of the open format. This article does not equate a file format with an enterprise business process. ² [Demystifying evals for AI agents](https://www.anthropic.com/research/demystifying-evals-for-ai-agents), January 9, 2026, provides a methodological reference for evaluating agents. It is not evidence that the mechanisms proposed in this article have been validated in businesses. ## Related reading - [Actions, Results, and Retained Learning: How a Task Can Build Organizational Capability](https://yutengfei.com/en/journal/action-results-organizational-capability/) [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/) --- # We followed the SOP. Why aren’t we seeing business results? - Author: Andrew David W.Y. - Source: https://yutengfei.com/en/journal/sop-business-outcome-diagnosis/ - Version: R1 - Published: 2026-11-04 - Revised: 2026-11-04 - Content status: Full text published - Content type: Methods (methods) - Research topics: Stakeholder Capital Governance (stakeholder-governance) - Ecosystem perspectives: Operations & Management Ecosystem (operations) · Customer Ecosystem (customer) ## Use this resource **Purpose**: Clarify customer and economic outcomes first. Then trace gaps along the actual business-outcome chain, distinguish business conditions from work mechanisms, and use evidence to choose the SOP improvements needed. **Conditions for use**: Check that the subject, objective and constraints fit the task. Confirm any conditions that the article does not specify. **Methods · Steps, inputs and completion criteria** **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 Customers have been contacted, requirements forms filled in, quotations sent, and follow-up records completed. Every task is marked done. Yet at month-end, orders have not increased, customers have not stayed, and payments have not arrived as expected. At this point, managers often think of two things: make the procedure more detailed, or require everyone to follow it more strictly. Sometimes those measures help. But first we need to establish what has gone wrong. Was the work poorly done? Or was that work, even when done well, insufficient to produce the expected result? Whether customers need the product, accept the price, and are being reached through the right channels all belong in that assessment. I think that when performance falls short, we can first look for the problem along the business-outcome chain. Then we can decide which business, functional, or action SOPs need attention. Find the problem first, so process improvement has something specific to solve. ## First, distinguish three kinds of “complete” Here, an SOP, or standard operating procedure, is a work guide that sets out the steps, requirements, and handling of exceptions for a task, so a team can carry it out and check it. I use “business-outcome chain” for the key business path linking work to customer and economic outcomes. In the earlier _Methodology for Mapping and Designing SOPs_, a business-outcome SOP describes the core business logic closely tied to customers and directed toward economic outcomes. Business, functional, and action SOPs support it. I think this starting point matters: to assess how well a piece of work is done, we need to know which result it ultimately supports. A business SOP addresses collaboration across roles. A functional SOP addresses a task with a defined result and a check that it has been completed. An action SOP explains the specific operations. In practice, we also need to distinguish these three levels. | Level | What to check | What it tells us | | --- | --- | --- | | Activity completed | Whether contact, preparation, sending, or operations were carried out as required | The work happened, and the relevant steps can be traced | | Process result established | Whether requirements were checked, key solution conditions received the necessary confirmation, and delivery met the agreement | Whether this stage provided suitable conditions for the work that follows | | Customer and economic outcomes achieved | Whether customers bought, used, and accepted the delivery, and whether revenue, cash collected, and business earnings met the targets | Whether this business chain achieved the outcomes being observed for the period | Sending a quotation tells us only that it was sent. We still need to check whether the customer received it, understood it, and accepted it. Even after a contract is signed, delivery, revenue, costs, and payments need to be examined separately. Once work is done, the review cannot stop at the completion record. At each key stage, keep asking: **What state was this action meant to change, and do we now have evidence that it changed?** Standardized work still has value. It can stabilize an existing way of working and provide a baseline for training, comparison, and continuous improvement. The Lean Enterprise Institute also places standardized work within continuous improvement, rather than treating a written standard as the endpoint. [Reference: Standardized work](https://www.lean.org/lexicon-terms/standardized-work/) ## Turn “no results” into a question we can investigate “Poor performance” is too broad. It gives a team little basis for identifying the same problem. Start with one specific business activity. Define the customers served and the product or service sold. Then state the outcome to be checked for the period, the actual gap, and the observation deadline. “New orders this period are below plan” and “receivables from the previous batch are overdue” call for different investigations and responses. Three things need to be clear first. First, examine contracts signed, revenue, cash collected, and profit separately. They are related, but they are not the same thing. A promotion may bring more orders, along with more discounts, refunds, and fulfillment costs. Second, compare like with like. Compare similar products, customers, and business at similar stages of maturity. Record changes in channels, scope, and conditions. Leads acquired this month may not become orders this month. Dividing all orders this month by all leads this month does not necessarily give the conversion rate for that group of customers. Third, agree when to look again. Delivery or payment cannot be judged a failure before its agreed deadline. Once an observation checkpoint has passed, however, “the sales cycle is long” cannot keep postponing the issue. For unfinished matters, retain the current status, the next review date, and the person responsible. This step should leave a clear question: **For the group being reviewed, which outcome fell short, over what period, and by how much compared with the original target or baseline?** If the target itself lacks a sound basis, mark that for review too. ## Follow the actual business-outcome chain to find where results diverge For project-based sales, for example, an initial chain might be: contact suitable customers, clarify their needs, develop an acceptable solution and terms, reach an agreement, deliver, and complete the agreed settlement. Stages and sequences vary by business. Repeat purchases, renewals, returns, rework, and exits should remain visible where they occur. Next, place the result expected at each key stage alongside the actual evidence. Scroll sideways to explore, or open the full diagram. [![Figure 1: Identify the outcome that has not been achieved, then check customer status, evidence, and gaps along the actual business-outcome chain. The arrows show a review path, not a guarantee of a sale at every step.](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/01-performance-chain.svg)](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/01-performance-chain.svg) [Open full diagram ↗](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/01-performance-chain.svg)[Download editable SVG ↓](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/01-performance-chain.svg) Figure 1: Identify the outcome that has not been achieved, then check customer status, evidence, and gaps along the actual business-outcome chain. This is a project-based sales example. Real business may involve follow-up, renegotiation, rework, or exit. [Open editable SVG](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/01-performance-chain.svg) Check quality, waiting time, and reasons for stalled progress as well as volume. Rather than stopping at the number of requirements forms, ask how many actually clarified the problem the customer wanted solved, the purchasing conditions, and the decision process. Alongside the number of delivery tasks completed, check whether the customer accepted delivery as agreed and whether anything remains unresolved. If a clear gap appears at one stage, it can be a useful place to start investigating. But **the point where a gap becomes visible is not automatically its cause**. A customer dropping out after a quotation may be reacting to price. It could also be a misunderstood need, unsuitable delivery terms, or a contact without purchasing authority. Late payment may reflect an earlier delivery dispute. So, while following the chain to see where progress is blocked, also check the inputs that stage received. A problem left by one stage may only become visible at the next. ## Check business conditions and work mechanisms together Once we have found the blocked stage, I suggest checking possible causes through two groups of questions. One group asks whether the business currently makes sense. | Business condition | What to investigate further | | --- | --- | | Need | Is the problem real and urgent? Who uses, decides, and pays? Are the conditions for a purchase in place? | | Product | Can the solution address the problem? Do quality, use, delivery, and service suit the current customer? | | Price and transaction terms | Does the customer understand the total cost? Are the budget, payment period, and contract terms acceptable? Can the business bear the fulfillment costs? | | Channels | Are suitable people being reached? Do channel promises match actual supply? Has the source of leads changed? | | External conditions | Have customer budgets, competing choices, supply conditions, or other constraints changed? Does the original assessment still apply? | The other group checks whether the conditions for completing the work exist and whether current methods can produce the required result. Are the prerequisite materials suitable? Does the collaboration sequence make sense? Are decisions and handovers clear? Are resources and capabilities sufficient? Do the standards fit? Has actual execution departed from them? Both groups of problems may be present. For example, customers may require faster delivery while the internal process for confirming supply capacity remains slow. External conditions have changed, and business coordination needs to change too. One explanation alone would not cover the whole problem. An investigation can use orders, delivery and acceptance records, quotation versions, communications, and financial records. Customers and participants can also provide further explanation. Cross-check sources to establish what happened, rather than collecting only material that supports the original assessment. A customer saying “I’m interested” supports a different conclusion from a willingness to buy on specific terms. When evidence is insufficient, write the explanation as a hypothesis to be tested. For example: “The customer may have stopped because the delivery schedule did not fit the purchasing window.” The next step is to check the actual purchasing milestones and available delivery schedule. Strategyzer’s approach of identifying critical hypotheses, designing tests, and relating evidence back to those hypotheses offers a useful reference here. [Reference: Start testing with the critical hypotheses](https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses) ## Identify the problem, then organize the improvement it needs After investigating, we should be able to say what needs to change next. Organize work at the level that needs changing. There is no need to revise every SOP. Scroll sideways to explore, or open the full diagram. [![Figure 2: After clarifying the outcome gap, check business conditions and work mechanisms together. Use evidence to choose business adjustments or changes to business, functional, or action SOPs, then test customer and economic outcomes. If evidence or necessary conditions are missing, gather evidence, adjust, or pause.](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/02-diagnosis-intervention.svg)](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/02-diagnosis-intervention.svg) [Open full diagram ↗](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/02-diagnosis-intervention.svg)[Download editable SVG ↓](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/02-diagnosis-intervention.svg) Figure 2: Choose the necessary intervention based on evidence. The two investigations can run in parallel, and several kinds of action may be combined. State the expected effect and review conditions for each change. Do not judge final business performance a failure before the final observation deadline; anomalies already visible at individual stages can still be investigated promptly. [Open editable SVG](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/en/02-diagnosis-intervention.svg) If the assessment of demand or the product is wrong, revisit the target customers, product scope, and value proposition. If the price, transaction terms, or channels do not fit, an authorized person should decide whether to adjust them. If the original business assumptions no longer hold, also consider reducing, pausing, or stopping the business activity, while arranging how existing commitments will be handled. If the problem lies in collaboration across roles, improve the business SOP. For example, when promises in a quotation require joint confirmation from supply, technical, and delivery roles, define the sequence, time limits, handling of exceptions, and decision authority. If the problem lies in a self-contained task, examine its design, how it is completed, and its result standards. Supply missing conditions, change unsuitable methods, and revise the functional SOP when the procedure itself needs changing. For example, if requirements verification repeatedly fails to establish use and purchasing conditions, clarify that task’s inputs, outputs, responsibilities, and completion criteria. If the desired result and task design are already clear, but the problem is in a specific operation, correct the action SOP. Examples include using the wrong quotation version, missing a required field, or handing over work without the confirmed supporting materials. Training, tools, and operational checks then have a clear focus. There is another possibility: everyone followed the requirements, but the process still failed to produce an acceptable result. Then the method or standard needs changing. Showing that execution complied with the existing standard is not a reason to end the discussion. These levels describe relationships between work, rather than a fixed match to departments. One problem may involve several roles, and one person may perform several kinds of work. ## Run a small test to see whether the change helps Consider a hypothetical situation: a company providing equipment support services completes its contact targets, requirements records, and quotation sending, yet orders remain below plan. This illustrates the method; it is not a verified company case. Reviewing the same group of customers, the team finds that some quotations arrived after the customer’s purchasing window, while some solutions did not fit installation-site conditions. This does not establish that quotation speed explains every problem. Each issue needs checking. The team could select the next group of requirements with similar conditions and adjust requirements verification and quotation coordination. Confirm site conditions and purchasing milestones before developing the solution. Where technical and supply roles need to confirm something together, agree response times and exception handling. Observe the proportion of information records meeting the requirements and the time taken for confirmation, as well as whether customers move forward, actual transactions, fulfillment costs, and subsequent payments. If requirements are clearer and quotations faster, but customers still do not accept them, continue checking the product, price, and other explanations. If sales increase alongside rework and costs, we cannot immediately conclude that the improvement worked. When several conditions change at once, record the changes rather than attributing the entire result to just one of them. For the first attempt, a short record can make the improvement concrete. | Record | What to make clear | | --- | --- | | Outcome gap | The group, period, metric definition, target or baseline, and actual gap | | Evidence of the blockage | Which stage is blocked, where the records are, whether inputs are suitable, and what other explanations remain | | Current assessment | What the evidence supports and what still needs checking | | Necessary action | Whether to change business conditions or business, functional, or action SOPs; who decides, who executes, and what resources are committed | | Review agreement | Before making the change, agree when to check process and business outcomes, which baseline to compare with, and when to retain, adjust, or stop the approach | Waiting for observation is also a defined status. State what we are waiting for and until when. After a pause, arrange follow-up for customers, delivery, payments, and partners. Recheck conditions before restarting. Retaining results and counterexamples from each round gives us a chance to see where this method works and where it still does not. ## Bring processes back to the outcomes a business creates together Applied to a business ecosystem, participants in the resource, operations and management, customer, and capital ecosystems can all raise issues, contribute expertise, or respond to specific needs. A lean operations and management team handles the relevant decisions, rules, and coordination, connecting value production, sales channels, and customer relationships. Participants provide the facts together. Authorized roles make the choices and identify who will take the next work forward. Examining the business-outcome chain helps us understand how work supports customer and business results. It does not place all business risk on an individual carrying out a task. Completion records alone cannot establish every contribution or entitlement either. Specific compensation, responsibilities, and entitlements remain subject to the actual business, contracts, and rules. I would rather start with one real business activity: which outcome was not achieved this time, where the evidence points, what needs to change next, and when we will check again. SOPs can organize work we already understand more clearly. They also need to let a team discover where its understanding falls short. Keeping that possibility open gives processes a chance to improve with the business. The effectiveness of this diagnostic method still needs testing in specific businesses through ongoing records, changes in outcomes, and counterexamples. ### Method sources and further reading This article builds on the relationships between four SOP levels in pages 2–4 of the earlier _Methodology for Mapping and Designing SOPs_, and its discussion of scenarios, prerequisite tasks, standards, trials, and iteration in pages 6–9. The diagnostic path covering outcome definitions, observation of the same group, checking in both directions, and necessary interventions is developed here. Both diagrams were newly designed for this argument. Further references: [Lean Enterprise Institute: Standardized work](https://www.lean.org/lexicon-terms/standardized-work/); [Michael Ballé: Start by defining the problem when introducing standardized work in an office](https://www.lean.org/the-lean-post/articles/how-do-i-implement-standard-work-in-an-office-environment/); [Strategyzer: Start testing with the critical hypotheses](https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses). These are references for related methods, not evidence that the effectiveness of this diagnostic framework has been verified. Further reading, if useful: [Ten steps for enterprise planning: Connect direction, resources, and execution (Chinese)](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/); [The four-ecosystem governance model: Contributions, entitlements, and a collaboration feedback loop (Chinese)](https://yutengfei.com/zh/journal/four-ecology-governance-model/). ## Related reading - [Four-Way SOP: Connecting Performance, Business Processes, Functional Tasks, and Actions](https://yutengfei.com/en/journal/four-way-sop/) - [How to Use Four-Way SOP: Connecting Business Results, Processes, People, and Daily Work](https://yutengfei.com/en/journal/four-way-sop-practical-guide/) - [Start with One Performance Chain: A Practical Way to Reshape the Enterprise Ecosystem](https://yutengfei.com/en/journal/performance-chain-ecology-transformation/) - [From Job Responsibility Analysis to Role Handbooks: Helping Contributors Understand Their Work](https://yutengfei.com/en/journal/co-builder-role-handbook/) [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/)