Create a customer spreadsheet
It may bridge the first transactions, but ownership, audit and recovery become dependent on the people maintaining it.
D/04You won the customer.
You won the customer.
Now keep the promise.
A major account brings revenue, credibility and the possibility of further growth. It can also introduce volumes, integrations and service commitments the current operation was never designed to carry.
One customer has changed the operating requirement.
Large customers rarely buy only the core product or service. They bring ordering formats, data exchanges, approvals, reporting, service levels, security expectations and exceptions shaped by their own operation.
The commercial pressure is immediate: agree now, solve it before go-live. Teams compensate with manual uploads, dedicated coordinators and one-off logic hidden inside existing systems.
That may protect the launch. It also risks creating an account that grows revenue while absorbing margin and management attention. The strategic question is which requirement is truly customer-specific and which reveals a capability the wider market will soon expect.
The same event can create exposure or advantage.
The fear
The business wins revenue it cannot deliver profitably.
Manual work becomes embedded in the service, errors threaten the relationship and every contract renewal depends on the people who remember the workaround.
The ambition
A demanding customer funds a reusable advantage.
The immediate commitment is met, while the underlying capability becomes something the business can operate efficiently and offer to the next customer.
How the constraint shows up.
01
The contract includes an integration, portal or reporting requirement not supported today.
02
Go-live depends on people moving data between the customer's systems and yours.
03
The account needs service levels the operation cannot currently evidence.
04
Commercial teams have agreed an exception without a costed operating model.
05
The proposed solution creates customer-specific logic in several systems.
06
A dedicated team is being assembled to compensate for the missing capability.
A one-off workaround can become a permanent cost of sale.
01
02
Customise the core platform
This keeps work in one place only if the change is supportable and does not make every future upgrade harder.
03
Build a separate portal or integration
A bounded capability may be right when it can protect the core systems and serve more than one customer over time.
Separate the account exception from the market capability.
The contract creates the deadline. It should not make the architecture decision by itself.
Q/01
Which requirement is unique to this customer's operation, and which is likely to recur?
Q/02
What volume, failure and recovery conditions must the solution withstand?
Q/03
How will the business prove the service level it has promised?
Q/04
Can the new capability be isolated from the core platform and reused safely?
The right answer may be to change the process, configure a product, integrate what you already have, modernise one part or build an owned capability. ORBN helps make that decision before it helps deliver it.
Own the promise made in your name.
A customer may define the interface or evidence it needs. Your business still needs control of how that promise is fulfilled, monitored and recovered when something fails.
OWN / 01
The rules that translate the customer's requirement into operational work.
OWN / 02
The evidence needed to prove service and investigate failure.
OWN / 03
A reusable boundary that prevents one customer's logic spreading through the estate.
Continue the decision.
Service
Systems integration
Connect customer, ERP, WMS, ecommerce and EDI flows with visible exceptions and recovery.
ServiceCustom software development
Build a bounded portal or operational capability when the requirement cannot be configured safely.
ProofIntegration inside the operation
See how Crowbond replaced exports and re-entry with a route-planning capability connected to its order system.
What else changed?
What changed?Keep the promise
Keep the promise
without creating a permanent exception.
Tell us what the customer requires, when it must work and what your current systems cannot do. We will help separate the immediate fix from the capability worth keeping.