Vendor onboarding often accumulates across finance, operations, legal, and risk teams. A process distributed across inboxes can become difficult to operate as volume and requirements grow, but there is no universal vendor count at which it fails.
The difference between a checklist and a process is that a process answers three additional questions: who does each step, what happens when a step stalls, and how you know the whole system is working. This guide covers how to design for all three.
Start With Vendor Types, Not Documents
The most common design mistake is building one onboarding flow for every vendor. A software subscription and an electrician working on your roof do not carry the same risk, and asking both for the same paperwork produces two bad outcomes: low-risk vendors are annoyed by requirements that do not apply to them, and high-risk vendors slip through with less scrutiny than they deserve.
Segment your vendor base first. A typical mid-market segmentation:
- On-site trades and contractors: full insurance requirements, licenses where the work is regulated, signed contract, W-9 (for construction specifically, see OnComply)
- Professional services: professional liability coverage, W-9, signed agreement
- Suppliers and product vendors: W-9, ACH authorization, basic terms
- 1099 independent contractors: W-9 before first payment, IC agreement, license verification where applicable
Each segment maps to a requirement package. In OnComply these are onboarding groups: every vendor joins a group, and the group defines exactly what they must provide. However you implement it, the principle is the same. Requirements should be assigned by vendor type, not negotiated vendor by vendor.
Define the Stages Explicitly
A complete onboarding process has six stages:
- Intake. The vendor enters your system with a name, a contact, and a vendor type. Nothing else should be required to create the record.
- Requirement assignment. The vendor type determines the document package. This should be automatic, not a judgment call made per vendor.
- Collection. The vendor receives a request and submits documents. This stage produces the most delay, so design it for the vendor's convenience, not yours.
- Validation. Each document is checked against your rules: coverage limits on the COI, a complete and signed W-9, an active license. Received is not the same as accepted.
- Approval. Someone with authority confirms the vendor is cleared, or grants a documented exception.
- Activation. The vendor becomes available for work orders and payment in your operational systems.
Write these stages down. The exercise sounds bureaucratic, but every onboarding failure you have had maps to a stage that was skipped or owned by no one.
Assign an Owner to Every Stage
Stalled onboarding is almost never caused by a missing form. It is caused by a missing owner. The vendor submitted a COI two weeks ago; nobody was responsible for reviewing it; the project start date arrived anyway.
For each stage, name a role (not a person) that owns it. Collection can be owned by the system itself if you automate reminders. Validation and approval need a named human role, with a backup. If you cannot name an owner for a stage, that stage is where your process will break.
Set Time Targets and Escalation Rules
Decide what good looks like before you measure anything. Set targets from project lead time, reviewer capacity, vendor type, and consequence of delay. Then define reminder and escalation points that support those targets. Measure actual completion time and adjust from evidence rather than copying generic day counts.
Connect the Paperwork to Work and Payment Decisions
Collection should feed explicit decisions. Whether an insurance issue blocks work, or missing tax information triggers backup withholding or a lawful payment hold, depends on the contract, policy, law, and risk. Keep work and payment decisions separate so each can follow the correct rule.
This is the can-work/can-pay model. It converts compliance from a report someone reads into a control your operational systems enforce. If your onboarding process ends at "documents received" rather than at an eligibility status other systems can check, the last and most important step is missing.
Automate the Chasing
Follow-up is a good automation candidate when messages, timing, exceptions, and escalation are defined. Reminders, renewal requests before expiration, and status updates can run automatically, while humans handle judgment, exceptions, and approvals.
Measure Three Numbers
Three useful measures of an onboarding process are:
- Median time from invitation to activation. Rising time means the process is stalling; find the stage.
- Completion rate. The share of invited vendors who finish. Investigate the stage and reason when it changes.
- Compliance rate of active vendors. The share of activated vendors whose documents are all currently valid. This measures whether onboarding quality survives past day one.
End at a Decision, Not a Folder of PDFs
Design the process deliberately: segment vendors into types, define the stages, give every stage an owner, set time targets with escalation, and end at a documented operational decision rather than a folder of PDFs. Reassess capacity and controls as volume and risk change.