Who Owns Vendor Onboarding When It Spans Teams
Vendor onboarding rarely fails inside a single team. It fails in the gaps between procurement, legal, finance, security, and the business unit that requested the vendor, where each function assumes the next one has the file.
The usual symptom is a vendor record that sits at 'pending' for weeks while no one can say why. Procurement finished its part, legal has the contract but is waiting on a signal, and the requesting team assumes everything is moving. Nothing is broken inside any one function. The process simply has no owner between the stages.
Assigning vendor onboarding ownership across teams comes down to two separate decisions: who is accountable for each stage, and who is accountable for the whole. Treat them as different roles. Mixing them is how onboarding ends up owned by everyone, and therefore by no one.
Step one: define the stages. Keep the list short and base it on what must be true before the next piece of work can start. A workable set for most operations teams:
- Intake: the request is logged, the business need is stated, and the requester is named.
- Review: risk, security, legal, and payment or tax documents are checked against your own requirements.
- Setup: the vendor is created in your systems, payment details are verified, and access is provisioned.
- Activation: the first order or engagement begins, and the requester confirms the vendor is usable.
- Close-out: the record is complete and a review date is set.
Your stages may differ. What matters is that each one has an entry condition and an exit condition that someone can check without asking around.
Step two: name one accountable owner per stage. Accountable means a single role, not a department, that can say whether the stage is complete. Other teams contribute, but one role signs off. A reasonable starting point:
- Intake: the requesting business unit owns the completeness of the request.
- Review: procurement owns completion of the stage, while legal, security, and finance each own their individual check.
- Setup: finance or accounts payable owns vendor creation and payment verification.
- Activation: the requester owns confirmation that the vendor can actually deliver.
- Close-out: procurement or vendor management owns the final record.
Adjust this to your organization. The test is whether, for any stage, a colleague can name the one role that decides it is done.
Step three: appoint a process steward. Stage owners cover their own segment. Someone also has to watch the seams. The steward does not do other teams' work; the steward owns elapsed time, the handoffs, and escalation. In a smaller company this is often an operations lead. In a larger one it may be a vendor management function. The steward needs authority to request status from any stage owner and to escalate when a stage stalls, and that authority should be written down rather than assumed.
Step four: make every handoff traceable. A handoff is where work goes dormant, so each one needs a record. Keep it minimal:
- What is being handed over, and which stage it leaves and enters.
- Who sent it and who the named receiver is.
- The date the receiver accepted it, not just the date it was sent.
- Open items the receiver inherits.
Acceptance is the important field. A handoff that has been sent but not accepted is still the sender's responsibility. That one rule removes most of the ambiguity about where a stalled record is sitting.
Step five: measure age in stage. Set a target duration for each stage and report on time in the current stage, not only total elapsed time. A record that has spent nine days in review looks very different from one that has spent nine days across five stages. When a record passes its stage target, the steward contacts the stage owner. When it passes a second threshold, it goes to a named escalation contact. Choose both thresholds from your own cycle times; there is no universal number worth borrowing.
Several failure modes show up repeatedly when ownership is unclear:
- The shared inbox as owner. A mailbox is a location, not an accountable role. Requests sent there can sit unread with no one at fault.
- Ownership by committee. If three teams must all approve and none is designated to close the stage, each waits for the others.
- The vanishing requester. The business unit submits the intake and disengages. Later questions about scope or contacts have no one to answer them.
- Unowned exceptions. Urgent requests skip stages, and no one records what was skipped or who accepted the risk.
Each of these has the same fix: a named role, a recorded acceptance, and a steward who can see the whole path.
To roll this out, start with the vendors currently stuck in onboarding. Map each one to a stage and assign a stage owner on the spot. That exercise alone shows which handoffs have no named receiver. Then write the stage definitions, publish the owner list where requesters can see it, and review the first month of handoff records to adjust stage boundaries and targets.
The model reduces to four rules: one accountable owner per stage, one steward for the whole process, one record per handoff, and one clock per stage. None of it requires new software; a shared tracker with these fields is enough to begin. The goal is simple. When a vendor record stalls, the question 'who has it right now?' has exactly one answer.