Observable condition
The announcement goes out on the company chat: a new contract has been signed. There is genuine celebration. Within an hour, a different kind of message starts. Procurement asks how much stock to order and by when. Finance asks for the customer's registration documents, VAT number and credit application. Operations asks who will run the account and whether the team has capacity. Someone asks whether the agreed prices have been loaded. The account manager is copied on all of it.
Over the next fortnight, people work late to set things up. Stock is ordered urgently at a worse price. A temporary person is brought in. The first delivery goes out, but the invoice is delayed because the customer account was not ready in the accounting system. Everyone agrees it was a good win. Few people would describe the start as smooth.
An illustrative example: a KwaZulu-Natal cleaning and hygiene services company wins a contract for twelve new sites with a retail group. Sales had been working on the bid for four months. Operations learned the details the week the contract was signed, and had to recruit, train and equip staff, order consumables and set up site schedules with a start date three weeks away.
Realisation
The scramble is usually explained as the natural cost of growth: new work brings new effort. But much of the scramble is not caused by the work itself. It is caused by the fact that the rest of the business did not know the work was coming, and that the steps needed to set up a new customer are not defined as a single, owned process.
In most businesses the information that would have prevented the scramble already existed. The opportunity was in the pipeline for months. Its likely value, products, start date and probability were known to sales. That information simply never reached the people who would have to deliver, buy, staff and bill for it. Modern CRM platforms are built to forecast likely revenue from the pipeline; Microsoft's Dynamics 365 Sales documentation, for example, describes predicting how much revenue a sales team will generate in a given timeframe. The question is whether anyone outside sales ever sees that forecast in a form they can plan from.
Realisation prompt: when did your operations, procurement and finance teams first hear about your last significant win, and when could they have heard?
Identification
This is a forward-visibility and customer-setup orchestration problem. The visible symptom is a rush of activity across several departments after a win. The common assumption is that success simply creates pressure. The structural cause is twofold: pipeline information does not flow to the functions that must prepare for it, and the many steps needed to make a new customer operational are not designed as one coordinated process.
The Pattern The Cost of Delayed Handoffs After a Deal Is Won deals with information lost between sales and delivery at the moment of signature. This Pattern looks earlier and wider: the months before signature when other departments could have been preparing, and the parallel setup work across finance, procurement, people and systems.
Diagnosis
- Pipeline visible only to sales. Probability, timing and scale of likely wins sit in the CRM or in a sales manager's head. Procurement, operations and finance plan from history, not from what is coming.
- No defined setup sequence. Creating the customer account, completing credit checks, loading contract prices, setting up delivery points, ordering stock and assigning people are separate tasks owned by separate teams, triggered by emails.
- Customer data created several times. The same customer is captured in the CRM, the accounting system, the operations scheduler and the delivery tool, each with slightly different details. IBM's description of master data management names this problem: different departments keep separate records of the same customer, with conflicting information.
- Contract terms not structured. Pricing, service levels and special commitments are in the signed document, not in fields that downstream systems can use.
- Capacity is not modelled. Nobody can answer, before signature, whether the business can deliver the work with current people and stock.
The general argument that broken handoffs are systems problems is made in the Insight Broken Handoffs Are Systems Problems.
Commercial impact
The commercial value at stake is margin, cash flow, customer experience, risk and scalability.
Margin suffers when stock is bought urgently, staff are hired or contracted in a hurry, and overtime absorbs the setup. Cash flow is delayed when billing cannot start because the customer account, prices or purchase order details are not ready. Customer experience is at risk at the most sensitive point in the relationship, when the customer is watching to see whether the decision to appoint you was right. Risk rises because rushed setup creates errors in pricing, credit limits and compliance documents that can take months to surface. Scalability is limited because the business can only absorb a certain number of scrambles at once, which can make leaders cautious about pursuing larger contracts.
Common misidentification
Asking sales to "give operations a heads-up" is the usual fix. It helps in the short term but depends on memory and goodwill. When the sales team is busy, the heads-up is late or forgotten.
Another misidentification is to treat the scramble as an operations capacity problem and add permanent headcount. That may be needed, but if the cause is late visibility, extra people still arrive late to the same surprise.
Possibility
In a better state, the pipeline is shared in a planning form. Opportunities above a defined size, or past a defined stage, are visible to operations, procurement and finance with their likely start date and requirements. Those teams can say early whether the work is deliverable and what lead times apply. When the deal closes, a single customer-setup process starts automatically, with each step owned and tracked: account creation, credit, pricing, delivery points, stock, people and system access. The customer record is created once and shared, rather than recaptured by each team.
For the hygiene services company, that might mean operations reviewing any bid above a set number of sites at proposal stage, with recruitment and consumables plans drafted before signature and triggered on award.
Intervention
- Reconstruct the last three significant wins. List every task that happened in the month after signature, who did it and when they first heard about the deal.
- Define the setup sequence. Turn the list into one ordered checklist with an owner for each step and the information each step needs.
- Share the pipeline. Agree a threshold for when opportunities become visible to other functions and give those teams a read-only planning view.
- Capture contract terms as data. Record prices, service levels and commitments in structured fields that downstream systems can use.
- Create the customer once. Decide the system of record for customer details and connect the others to it.
- Trigger on close. Make the won status start the setup workflow automatically. The Insight How to Design a Handoff That Cannot Depend on Memory covers the design principles.
Diagnostic questions
- How far ahead do your operations and procurement teams see likely new business?
- Is there a single, owned checklist for setting up a new customer?
- How many systems is a new customer's information typed into?
- How long after a win does the first invoice go out, and what delays it?
- Have you ever hesitated to bid for larger work because of the setup it would cause?
Bottom line
Winning a customer creates an internal scramble when the business learns about its own success too late and has no defined way of absorbing it. The information needed to prepare is usually already in the pipeline. Sharing it early, defining customer setup as one owned process and creating the customer record once turns a scramble into a routine, and makes growth something the business can plan for rather than survive.
Sources and further reading
- Welcome to Dynamics 365 Sales (last verified 10 October 2026)
- What is Master Data Management? - IBM (last verified 10 October 2026)
Related Mellorca reading
- When Client Onboarding Becomes a Growth Constraint
- Why Does Hiring Someone Create So Much Internal Admin?
- The Hidden Cost of Repetitive Customer Questions