Skip to content

Supplier onboarding to exit

Perspective: enterprise buyer managing a supplier. For supplier-side bid preparation, pricing and delivery monitoring, use Commercial delivery. The two perspectives have different accountable owners even when they refer to the same contract.

Trigger

A technology supplier or SaaS product is being considered.

Intended outcome

A contracted supplier with assurance, monitored performance and a tested way out.

Workflow steps and gates

Step Accountable role Activity Handover Gate
1 IT Procurement Specialist runs the selection with the right requirements in the tender tender, evaluation and recommendation Security, privacy, exit and continuity requirements in the tender, not added after
2 Third-Party Risk Manager assesses and tiers the supplier risk risk assessment and tier Critical suppliers have a tested exit or substitution plan
3 Security Architect sets the control requirements the supplier must meet supplier control requirements Requirements traced to threats, not copied from a questionnaire
4 Contract Manager extracts obligations into a tracked register contract and obligation register Obligations on both sides tracked with owners
5 Vendor Manager manages performance and the relationship after signature scorecards and governance cadence Renewal started early enough for a real alternative to exist
6 Service Level Manager aligns supplier commitments with what was promised internally aligned SLAs and OLAs No internal commitment exceeding what the supply chain can deliver
7 Business Continuity Manager proves the organisation survives the supplier failing exercised continuity and exit plan Exit tested, not described

Running this workflow: operator and implementer boundary

In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.

For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.

How to use this workflow

A practical prompt pattern is:

Apply the supplier-onboarding workflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.

Operational interpretation

The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.