Supplier onboarding: from procurement approval to IT operations

Imagine a newly appointed application-support provider. The contract is signed and procurement registration is complete. Then the service desk tries to raise a request and discovers that its staff are missing from the supplier’s authorised contact list.

Supplier onboarding establishes a new relationship through information gathering, checks and agreed working arrangements. Administrative approval covers only part of that preparation. The handover after appointment should leave the receiving team ready to work directly with the provider.

Confirm who takes over the supplier relationship

Assign a named operational owner for IT supplier management, with authority to coordinate internal teams and pursue unresolved supplier issues. Ask that person to accept responsibility explicitly, rather than assuming the contract signatory will handle it.

Agree where their responsibilities begin and end. Procurement might retain commercial matters, while the service owner oversees delivery and the service desk handles support requests. Identify who provides cover when the owner is unavailable, and record these arrangements as part of the handover.

Make the supplier record usable

Assemble an accessible record identifying the provider, the application or service it supports, the internal owner, the contract reference and the agreed support route. Connect it to the application’s service information so that someone investigating a fault can identify the relevant provider.

Link to controlled source documents instead of distributing copies that could fall out of date. Keep approved operational instructions accessible to the people using them, with a reference to the commercial agreement for questions requiring further detail.

For the application-support provider, ask a receiving team member to find the supplier record and the instructions for requesting support. If they need the buyer to forward an email, the information has yet to become a usable team resource.

Agree how the teams will work together

Turn the contact list into working instructions. Confirm which internal staff are authorised to raise requests, which supplier team receives them and who follows up when work stalls.

Specify the information needed to start a request, such as the application name, customer reference, symptoms and business impact. Agree where updates will be recorded and which internal team communicates with affected users. These instructions should reflect the agreed service arrangements.

Keep the supplier’s request reference alongside the internal ticket. The service owner then has a traceable record for pursuing an unresolved issue, while colleagues can follow progress without access to an individual employee’s inbox.

Check that the support route works

Arrange a non-disruptive check with the supplier before accepting the handover. Have an authorised service desk contact submit an agreed test request through the intended channel, clearly identified as an onboarding check rather than a production incident or emergency.

Confirm that the supplier recognises the customer and supported application, accepts the contact as authorised and returns a usable acknowledgement or reference. Check that the receiving team can retrieve the response.

Keep the evidence with the onboarding actions. A rejection because the contact is unknown identifies a specific setup task to resolve and retest.

A successful check confirms a usable contact route, not the supplier’s ability to restore a failed service.

Decide what must be finished before handover

Separate operational blockers from tasks that can remain open. An inability to raise support requests should block acceptance of that arrangement. An unsent invitation for the first routine check-in can remain open if someone owns it and a deadline is recorded.

For the example provider, a compact handover entry could read:

• Action: establish the service desk’s support-request route.
• Owner: service desk lead, coordinating with the supplier.
• Completion evidence: an authorised test request acknowledged with a retained reference.
• Status: blocked until confirmed.

The receiving owner should record the acceptance decision, its supporting evidence and any remaining actions. For each open action, record whether it blocks acceptance and why.

At the first operational check-in, confirm that deferred actions have closed and revise any instructions that proved unclear. The operational team should now be able to deal directly with the supplier, involving procurement in the commercial responsibilities it retains.