What Should a Process Definition Document Include?

A process definition document, usually called a PDD, is meant to be the single written account of how a process actually works. In practice, most PDDs are either too thin to be useful (a list of step names with no detail) or too bloated to be read (forty pages nobody opens after the sign-off meeting). The difference between a good PDD and a bad one is not length. It is whether each section contains the specific information someone would need to run the process, change it, or automate part of it.

Take a claims processing team as the example running through this article. A claim comes in, gets triaged, gets assessed, sometimes gets sent for additional evidence, and eventually gets approved, partially approved, or declined. That sounds simple as a sentence. A proper PDD has to make it simple as a document too, without losing the details that make claims processing genuinely complicated: multiple entry channels, several decision points with real judgment involved, and rework loops when information is missing.

Purpose and scope

This section states what the process is for and, just as importantly, what it is not for. For claims processing, the purpose might be to assess and settle claims submitted through any channel within the service standard the business has committed to. The scope should name the boundary conditions: does this PDD cover only standard claims, or does it also include disputed claims that get escalated to a review panel? Does it cover claims from all product lines, or just one? Teams routinely skip this section or write one throwaway line, and then spend the next several pages describing a process that quietly drifts across boundaries nobody agreed to.

Roles and ownership

List every role that touches the process, not just the ones with the most steps. In claims processing this typically includes the intake team, the assessor, a senior assessor or team lead for escalations, sometimes an external verifier, and a policy or underwriting contact who answers coverage questions. For each role, note what decisions they are authorized to make on their own and what has to go up a level. This is the section most likely to be incomplete because the people writing the PDD only interview the assessors and forget that intake staff make judgment calls too, deciding what counts as a complete submission before a claim ever reaches an assessor's desk.

Step-by-step narrative

This is the core of the document: what happens, in order, from trigger to outcome. Good step narratives describe the input required to start the step, who performs it, what they actually do (not just a verb like "review"), and what output moves the case forward. For claims processing, a step description that says "assessor reviews claim" is close to useless. A step description that says "assessor checks the claim against policy coverage terms, confirms supporting documents match the incident description, and either approves, requests further evidence, or flags for senior review" tells a reader something they can act on.

Decisions and branches

Every place the process forks needs a documented rule, even an approximate one, and a rough sense of how often each branch is taken. For claims, the biggest fork is usually the evidence-sufficiency decision: does the assessor have what they need, or not. If the PDD does not record this decision and its rough frequency, nobody downstream can judge how much of the caseload is affected by delays waiting on additional documents, which is often the single biggest driver of cycle time in claims work.

Exceptions and rework

Exceptions are the paths that fall outside the normal pattern: a claim tied to a fraud investigation, a policy dispute, a claimant who cannot be reached. Rework is different: it is the normal process looping back on itself, such as a claim bounced back to intake because a form was incomplete. Both belong in the PDD, and both are commonly left out because they are less satisfying to document than the happy path. A PDD that omits rework loops will understate cycle time and confuse anyone trying to estimate capacity, since the same claim may pass through the assessment step more than once.

Assumptions and open questions

No PDD is complete on first draft, and pretending otherwise creates false confidence. This section lists what the document assumes to be true (for example, that all claims arrive through one of three known channels) and what remains unresolved (for example, whether a newly acquired product line follows the same assessment rule). Naming assumptions explicitly is what allows a reader to challenge them later without having to re-interview the whole team.

Metrics and current performance

Wherever real numbers exist, such as typical cycle time, volume by channel, or the proportion of claims requiring additional evidence, they belong in the PDD as observed figures, clearly labeled as estimates where they are estimates. This section is what turns a PDD from a description into something that can support a business case, because it gives a baseline that any proposed change can be measured against.

Future state and change log

If the PDD also documents a proposed future state, that section should be kept visibly separate from the as-is description, with a short change log stating exactly what is different and why. Blending as-is and to-be into one narrative is one of the most common ways a PDD becomes untrustworthy, because a reader can no longer tell which parts describe reality and which parts describe a hope.

1. Purpose and scope
   - What triggers the process, what it is meant to achieve, explicit boundaries
2. Roles and ownership
   - Every role touching the process, decision authority per role
3. Step-by-step narrative
   - Trigger, actor, action, output for each step
4. Decisions and branches
   - The rule for each fork, rough frequency of each branch
5. Exceptions
   - Non-standard paths, who handles them, how often they occur
6. Rework loops
   - Where work returns to a prior step, and the typical cause
7. Assumptions and open questions
   - What is taken as true, what is still unresolved
8. Metrics and current performance
   - Cycle time, volume, and any other observed figures, labeled as estimates where relevant
9. Future state and change log (if applicable)
   - Kept clearly separate from the as-is description

Where Processfix fits

Processfix supports this kind of documentation work by turning a mapped process, whether built from a plain-language description or extracted from an existing SOP, into an editable swimlane model that can be exported as a PDD in Word, PDF, or Markdown. It helps structure the sections above and keep as-is and to-be states clearly separated, but it does not verify system integrations or technical feasibility. Any estimates of cycle time or volume come from the process model and the assumptions a user provides, not from live operational data.