How to Create a Process Definition Document

A vendor onboarding PDD is easy to get wrong in one of two directions. Some end up as a bloated narrative that reads like a company history and tells the reader almost nothing they can act on. Others end up as a bare list of steps with no context, which is really just an SOP wearing a different label. A good PDD sits between the two: structured enough that a process owner or a reviewer can find exactly what they need, and detailed enough that it explains not just what happens but why, and what would need to be true for a proposed change to work.

Know who is going to read it before you start writing

A PDD for vendor onboarding might be read by a procurement lead deciding where to focus a process improvement effort, a finance stakeholder checking that risk and compliance steps are properly represented, or a new team member trying to understand how the function operates before joining a project. Each of these readers needs the same underlying facts but cares about different parts of the document. Deciding this upfront shapes how much detail to put where, and stops you from writing a document that only makes sense to the person who wrote it.

Gather the input before you draft anything

Writing the PDD is the easy part once you have real input. The harder part is gathering it, and for vendor onboarding that usually means talking to procurement, legal, and finance separately, because each team sees a different slice of the process and none of them has the full picture on their own. Ask each team to walk you through a recent onboarding case, note the decisions and handoffs the way you would for any undocumented process, and pay particular attention to where the process stalls, since vendor onboarding delays are often caused by one team waiting on a document or approval from another.

Write each part deliberately, not as one long narrative

The roles section should name each actor and what they are accountable for, such as procurement collecting vendor documentation, legal reviewing contract terms, and finance setting up payment details. The process steps section should follow the actual sequence of the work, not an idealized version of it, and should reference the diagram rather than duplicating it in prose. The decisions and exceptions section deserves particular attention for vendor onboarding, since this is where most of the real variability lives: what happens if the vendor's documentation is incomplete, what happens if legal flags a contract clause, what happens if the vendor is based in a jurisdiction that requires extra due diligence. Each of these should be written as a distinct, findable entry rather than folded into a paragraph about the general flow.

Keep assumptions visible instead of burying them

Every PDD rests on assumptions, and vendor onboarding is full of them: an assumption about how many vendors require enhanced due diligence, an assumption about how quickly legal typically turns around a contract review, an assumption about how often a vendor's initial documentation is rejected and needs to be resubmitted. Write these down explicitly in their own section rather than letting them sit silently behind the numbers elsewhere in the document. A reader who disagrees with an assumption should be able to find it and challenge it directly, rather than having to reverse-engineer it from a metric that looks off.

Include metrics that mean something to the reader

A metrics section for vendor onboarding is useful when it includes things like typical cycle time from request to approval, the proportion of cases that require rework such as resubmitted documentation, and where in the process time tends to accumulate. It is not useful when it lists numbers without explaining where they came from or how confident you are in them. If a figure is an estimate based on limited data or a handful of interviews, say so plainly rather than presenting it with false precision.

Get it reviewed before it becomes the reference document

A PDD that has not been reviewed by the teams it describes is a draft, not a definition. Circulate it to procurement, legal, and finance, ask each to check their own section against how the work actually happens today, and be prepared for at least one correction, since vendor onboarding tends to change quietly over time as new compliance requirements or system changes are introduced without anyone updating the documentation. Once the process owner has reviewed and approved it, note the date and version, since a PDD that nobody dates tends to be trusted long after it has gone stale.

Where Processfix fits

Once a vendor onboarding process is modeled as an editable swimlane map in Processfix, with roles, steps, decisions, and exceptions confirmed, the tool can export that structure as a PDD in Word, PDF, or Markdown. It carries across the roles, process steps, decisions and exceptions, and any metrics generated by the simulation, such as estimated cycle time and where bottlenecks tend to occur, giving you a working first draft rather than a blank document.

That export still needs the review step described above. Processfix models and estimates based on the process you and your team have described and approved, it does not verify against your actual procurement or legal systems, and it does not confirm that any assumption you enter reflects current reality. The document it produces is a strong starting point for the write-up, not a substitute for the interviews and sign-off that make a PDD trustworthy.