{
  "path": "insights/find-operational-bottlenecks",
  "title": "How to Find Operational Bottlenecks in Your Business",
  "description": "Follow a real piece of work, distinguish waiting from effort and choose a contained improvement with clear ownership and a practical measure.",
  "heading": "Something could work better. Start here.",
  "intro": "Find operational bottlenecks by following one recurring task from request to completion. Separate work from waiting, check whether the delay repeats, then test one change with a named owner and a measure tied to the original problem.",
  "kind": "article",
  "category": "Operations",
  "date": "2026-10-01",
  "modified": "2026-10-02",
  "readingTime": "6 min read",
  "sections": [
    {
      "heading": "1. Choose a journey with a clear finish",
      "paragraphs": [
        "Pick one recurring piece of work: responding to an enquiry, preparing an order, approving a purchase or producing a monthly report. Start small enough that you can follow it from beginning to end. “Improve operations” is too broad to observe.",
        "Find a recent example and ask each person involved to show what happened. Record the actual steps, tools and handovers. A process document describes the intended route; a real example shows where people use messages, memory or a second spreadsheet to keep work moving. Treat those workarounds as information, not a reason to blame the team."
      ]
    },
    {
      "heading": "2. Separate work time from waiting time",
      "paragraphs": [
        "For each step, note when the item arrived, when someone could act and when it moved on. If exact times are unavailable, use a rough range and label it clearly. The aim is to locate a pattern worth investigating, not manufacture a precise productivity score.",
        "Ask what the item was waiting for: missing information, approval, capacity, a customer response or an update in another system. An hour spent entering data calls for a different response from a request sitting untouched because nobody knows who owns it."
      ],
      "bullets": [
        "Where does work wait without a visible owner?",
        "Which information gets entered or checked more than once?",
        "Where do people return work because something is missing?",
        "Which exceptions require help from the same person every time?"
      ]
    },
    {
      "heading": "3. Check whether the pattern repeats",
      "paragraphs": [
        "One difficult order can draw attention to a rare event. Review several examples, including an ordinary case and one that went smoothly. Ask what differed. Consider the volume of work, staff availability and unusual customer requirements before concluding that a step is the bottleneck.",
        "Keep a simple observation log with the step, the delay or rework, the apparent cause and the evidence you still need. Distinguish what you saw from what someone suspects. “Approval arrived two days later” is an observation; “the approval tool is the cause” is a hypothesis to check."
      ]
    },
    {
      "heading": "4. Choose a contained change",
      "paragraphs": [
        "Compare the candidate improvements using four questions: how often does this happen, what does it prevent, how confident are we about the cause and how disruptive would a change be? Avoid a complicated scoring model if a short discussion and clear examples will establish the first priority.",
        "The intervention might be a named owner, a shared status view, a better request form or a connection between existing tools. Do not automate an unclear approval rule and expect the ambiguity to disappear. Make the decision rule understandable first, then assess what technology could support it."
      ]
    },
    {
      "heading": "5. Observe the change in everyday use",
      "paragraphs": [
        "Choose a measure connected to the original problem: time waiting for approval, requests returned for missing information or records requiring duplicate entry. Note the starting position and the conditions under which you observed it. Agree who will check the measure after the change.",
        "Also look downstream. Making intake faster is not useful if it creates an unmanageable queue for delivery. Ask the people doing the work whether the change made the next action clearer and which new exceptions appeared.",
        "Your first useful output can be a one-page account of the workflow, the observed friction, the proposed change and its owner. That is enough to begin a focused engineering conversation, even when you started with only a sense that the business could run better."
      ]
    },
    {
      "heading": "Make the next review part of the change",
      "paragraphs": [
        "Give the review a date, an owner and a small set of observations to repeat. Include the people who do the work, because a change that looks efficient in a report can create extra explanation or exceptions on the ground.",
        "If the evidence is mixed, keep the change small and continue learning. A useful operational improvement makes the next decision clearer; it does not need a dramatic claim to be worthwhile."
      ]
    },
    {
      "heading": "Worked example: enquiries waiting for the next action",
      "paragraphs": [
        "Imagine a property business where enquiries arrive through a website, calls and messages. The team believes it needs a new CRM. Before choosing software, follow a small sample of recent enquiries from arrival to the agreed next action. This is an illustrative investigation, not a finding about a particular business.",
        "For each enquiry, note the stated need, the information missing, who took responsibility and whether the next step was a property comparison, a viewing or a later follow-up. Check why any enquiry stopped moving. Missing customer preferences, unclear ownership and unavailable properties require different responses; a single label such as ‘poor leads’ hides those differences.",
        "A useful first change might be a short intake prompt and a named owner for every enquiry. Trial it in the current tools before replacing them. Check whether fewer enquiries wait without an agreed action, and ask the team whether the new prompt creates unnecessary work. If visibility remains difficult across channels, that evidence can support a scoped integration or system change."
      ]
    },
    {
      "heading": "A simple observation log you can reuse",
      "paragraphs": [
        "Use one row per example in a document or spreadsheet. Avoid collecting names and private customer details when a reference number will do. The log is useful because it keeps observations separate from proposed solutions."
      ],
      "bullets": [
        "Task and finish: what should happen, and what would count as complete?",
        "Observed route: which people and tools handled the example?",
        "Delay or rework: where did progress stop, and what evidence shows it?",
        "Possible cause: what explanation still needs checking?",
        "Next test: what small change will we try, who owns it and when will we review it?"
      ]
    }
  ],
  "sources": [
    {
      "label": "GOV.UK Service Manual: how discovery works",
      "url": "https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works",
      "description": "A primary guide to understanding the problem, users and constraints before building; its public-service context differs from a commercial engagement."
    }
  ],
  "related": [
    "services/forward-deployed-engineering",
    "how-we-work",
    "insights/custom-software-or-existing-tools"
  ],
  "canonicalUrl": "https://aykaai.in/insights/find-operational-bottlenecks"
}