How to run a vendor onboarding before the first batch

Onboarding is where the contract becomes operations

A signed contract describes obligations. Onboarding is the short interval where those obligations turn into named people, granted access, and delivered documents. It is unglamorous work, and it is where most of the avoidable friction in a project is either prevented or created.

Five parts, in the order they should happen: roles, artifacts, access, controls, cadence. Each one is a checklist rather than a meeting, and each prevents a specific failure.

Roles: one named person on each side

A project with a shared inbox and no named owner loses days to questions nobody is accountable for answering. One check is specific to this moment: the people named in onboarding should be the people who ran the pilot, because if a different delivery team appears after the contract, the pilot tested a team that will not do the work.

• A single point of contact on each side, with the authority to make ordinary decisions without calling another meeting.
• A named quality owner on the producer side who is not the person doing the production. If the same person produces and approves, the approval carries no information.
• A named approver on your side who can accept or reject within the acceptance window. Acceptance that waits on a committee is a schedule risk you created yourself.
• An escalation ladder with time expectations at each rung: who to contact first, who next, and how long before the next rung is expected to respond.
• A rule that decisions arrive in writing, because a decision that exists only in a call is a decision that will be remembered two ways.

Artifacts: hand over the operating documents

Everything the producer needs in order to make a decision without you should be in this handover, and so should everything you need in order to check their work.

• The annotation guideline at its final version, with a version number and a date, plus any language-specific addenda.
• The label taxonomy with boundary definitions, so the cases between two labels have a stated answer rather than an argument.
• The reference examples and the acceptance criteria, including what fraction will be inspected and how the sample is drawn.
• The delivery specification with one validated example file, so format questions are settled by comparison rather than by discussion.
• The change log, naming who may approve a change and stating that changes are versioned like everything else.
• The reporting format for status and quality, agreed now rather than improvised in the first week of production.

Access: the minimum, logged, with an exit plan

Access is the part of onboarding with a security consequence and a project consequence at the same time.

• Scope access to the material in this project rather than to the whole storage location. Convenience here is how a later project inherits a permission nobody remembers granting.
• Named accounts for every person who touches the material. Shared logins make an access log worthless and an incident investigation impossible.
• If audio is involved, listening access is a named and logged permission, separate from access to transcripts or metadata.
• A stated transfer method: encrypted, with a manifest, and a reconciliation step at each end of the transfer.
• A rule on local copies on annotator machines, either prohibited or audited, since a local cache is where material escapes an otherwise controlled pipeline.
• An offboarding plan written at onboarding: what gets revoked, what gets deleted, and what document proves the deletion happened. Writing it at the start is what makes it available at the end.

Controls: configure once, rely on later

The legal side of data handling belongs in the processing schedule. Onboarding is where you verify that operations match it, and where you set the controls that matter only on a bad day.

• Confidentiality obligations that reach the producer's annotators as individuals, not only the company that employs them.
• An approved-tool list for the project, with a step requiring approval before any new tool touches the material. Most leaks in annotation work come from an unapproved tool rather than from a malicious act.
• A device and screen policy for remote annotators, stated plainly enough that someone could check it.
• Incident notification with a stated window and a named recipient on your side, tested once with a harmless drill rather than discovered during a real event.
• Retention and deletion rules for the producer side, aligned with the schedule, with the deletion verification method named in the agreement.

Cadence: what gets reviewed, and when the first batch lands

The last part is the operating rhythm, which should be set before the first batch rather than after it. Onboarding is complete when three things exist: an accepted first batch, a reconciled record of what was sent and received, and an offboarding plan. If the project ends early, the third is the one that turns out to have mattered.

• A standing check-in with a fixed agenda: progress against the current milestone, open questions, quality sampling results, and risks. A meeting without an agenda becomes a status narration.
• A quality sampling report delivered with each batch, in the agreed format, so acceptance review starts from evidence rather than from the files alone.
• A first-batch review scheduled in advance, with the acceptance window blocked on your calendar. That window is the deadline deciding whether acceptance happens by decision or by default.
• A higher sampling rate for the first two batches, with the reduction to steady state decided in advance. Deciding it in advance makes the reduction a plan; deciding it later makes it a drift.