We followed the SOP. Why aren’t we seeing business results?

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.

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

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.

Open full diagram ↗Download editable 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

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.

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

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.

Open full diagram ↗Download editable 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

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.

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; Michael Ballé: Start by defining the problem when introducing standardized work in an office; Strategyzer: Start testing with the 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); The four-ecosystem governance model: Contributions, entitlements, and a collaboration feedback loop (Chinese).