The integration workstream inside an outsourcing deal

Integration belongs in the commercial schedule

The agreement should state which interfaces are provided within the price, which are chargeable, the standards and transport methods supported, the environments made available for testing, and the timescales for building each one. Providers with a mature integration layer connect quickly; those building bespoke connections need longer and often want payment for it. Neither position is a problem once it is known, but discovering it after signature compresses the implementation plan.

The message types people forget

Orders out and stock levels back are the pair everyone specifies. What gets missed is the rest: purchase order and advance despatch information inbound, receipt confirmations, stock adjustments with reason codes, cancellations and amendments to orders already sent, returns notifications, despatch confirmations carrying tracking references, and item master updates. Each omission becomes a manual workaround that quietly consumes someone's day for the life of the agreement.

Master data ownership and who repairs it

Item records, dimensions, weights, packaging configurations, hazard classifications and customer delivery constraints have to exist in both systems and agree. Decide which system is the source, how updates propagate, what the provider does when it receives a record it cannot use, and who corrects the underlying error. A provider quietly fixing bad data at the site keeps the operation running while ensuring the client never learns its records are wrong.

Change requests after go-live

Requirements change: new sales channels, new carriers, new customer formats, new reporting. Agree the mechanism now — how a change is requested, how it is estimated, the rate card that applies, the lead time and how a disputed estimate is resolved. Clients who negotiate integration change rates alongside the operating rates get better terms than those who ask once the relationship is established and switching is expensive.

Testing and an agreed definition of done

Interfaces should be tested against realistic volumes and against the awkward cases: an order cancelled after despatch, an item with no dimensions, a partial receipt, a duplicate message. Agree what evidence constitutes a passed test, who signs it off and what happens when a defect appears after go-live. Testing only the straightforward path is what produces a first week spent handling exceptions manually.

Frequently asked questions

Who owns the operational data held in the provider's system?

Commercially it should be the client, and the agreement should say so, along with rights to extract it in a usable format during the term and at the end. Without an extraction right, a client can find its own transaction history accessible only through a portal it is about to lose.

Is a standard interface always preferable to a bespoke one?

Usually. Standard connections are quicker to build, cheaper to maintain and better tested. Bespoke work is justified where a genuine business requirement has no standard equivalent, not where it merely reproduces a habit from a previous system.

How much integration is needed before a modest operation can start?

Less than most assume for launch, and more than most assume for stability. Orders out and stock back can support an early start, but adjustments, returns and receipt confirmations are what stop the two systems drifting apart within weeks.