A major foodservice customer rarely creates trouble by ordering a little more of everything. They bring their own prices, product ranges, cut-off times, delivery windows, substitutions, documents and reporting. The deal changes the shape of the operation before the first order reaches the warehouse.
That is why a business can have enough warehouse capacity, enough vehicles and a stable ERP, yet still struggle to serve the customer profitably.
The constraint often sits in the exceptions. Experienced people keep orders moving by fixing customer codes, checking two versions of stock, chasing a missing file or remembering a rule that no system records. A large new account multiplies those moments and gives the team less time to rescue them.
The useful systems question is not simply "can we handle the volume?" It is "can we see and recover the awkward work before the customer feels it?"
The extra volume is not the dangerous part
Volume is relatively easy to discuss. The forecast contains cases, orders, drops and invoices. Systems can be tested with larger files and the warehouse can model a busier day.
Variation is harder.
One customer may need a different product code on every document. Another accepts substitutes but only from an approved list. A national account may have hundreds of delivery points with separate windows and contacts. A credit hold, late price change or short-dated product can take a familiar order down a completely different path.
Those details matter because they join commercial promises to operational systems. If the contract says the customer receives an acknowledgement in five minutes, somebody needs to know what the acknowledgement means. Has the file arrived? Has the order passed credit and product checks? Has the warehouse accepted it? What happens when one of those steps fails?
An average-volume test will not answer that. It may show that the system processed 1,000 records while hiding the 20 that now need somebody to intervene before the cut-off.
Find the work people quietly rescue
Most operational businesses already have a form of exception handling. It just may not look like a system.
A customer-service colleague keeps a spreadsheet of missing orders. Someone in the warehouse knows that one account's code needs changing before import. Finance compares two reports each morning because rejected invoices are hard to trace. A manager approves a substitution in a message and hopes the reason can be reconstructed later.
That knowledge is valuable, but it creates a hidden capacity limit. The new customer does not need to overwhelm the whole operation. It only needs to multiply one manual check beyond what the person who owns it can absorb.
Ask the team about the last awkward day. What did they have to chase, rekey or repair? Which failure became visible only when the customer called? Which decision depended on a remembered rule?
This is discovery in useful, plain English. The aim is to understand where the operation already compensates for weak connections and missing visibility. The GOV.UK Service Manual describes discovery as understanding the problem, users, constraints and value before committing to a solution. In this setting, the people rescuing the work usually know where the first useful change belongs.
Visibility matters more than another dashboard
The answer is rarely a large "customer readiness system". It may be one focused piece of software or one better connection between systems.
An incoming-order service could validate customer codes, prices and required fields before an order reaches fulfilment. An exception queue could show what failed, why it failed, who owns it and how long remains before the service promise is missed. A reconciliation service could compare the order, warehouse response and invoice so missing or duplicate work appears before month end.
The important change is shared visibility. Operations should not need to search several systems to work out whether an order exists. Customer service should not have to ask the warehouse for a status the system already knows. A manager should be able to see whether exceptions are increasing faster than the team can clear them.
Useful logging supports the same goal. NCSC guidance describes logs as evidence that helps a team establish what happened, understand its impact and respond. For a new customer launch, that means being able to follow an order across the handoffs and find the point where it stopped.
The software does not remove every human decision. Credit, safety, material cost and customer commitments may still need judgement. It should put the information and reason in one place so the person making that decision can act before the deadline passes.
Protect the win with the smallest useful change
The first release should protect the promise most likely to fail.
That could be reliable order acknowledgement, visible substitutions, delivery evidence or a daily reconciliation that shows every accepted order has reached the warehouse. Choose the one outcome that matters to the customer and exposes the weakest handoff inside the business.
Build or integrate only what that outcome needs. Use representative customer data. Include the awkward exception, not only the happy path. Give the team a fallback and a clear owner during the first live weeks.
This is where ORBN can help. The client brings the contract, the operational knowledge and the people who understand the exceptions. We can trace the promise through the existing systems, identify where people are holding it together and build the smallest defensible change before the account goes live.
If a major win has created a systems deadline, book a readiness conversation. Bring the customer promise and one awkward order. That is usually enough to find the first place software can protect service, margin and the relationship.