Process Description: Template, Example and Structure

Anyone looking for a process description template usually has a concrete problem: a workflow has to be written down because an audit is coming up, a colleague is retiring, or a quote went out with the wrong prices for the third time this quarter. The question is not whether to document, but in what form - and what belongs in the document so that somebody still opens it a year from now.

This guide gives you the template as a copyable structure, a filled-in example from a machine builder, and the answer to when a table suffices and when you need a flowchart.

What a process description is - and where it sits

A process description documents a bounded business process from trigger to result: what sets it in motion, which steps follow in what order, who is responsible for each one, which systems and documents are involved, what comes out at the end. It is the document at middle altitude: more concrete than the overview of all processes, coarser than the instructions for a single hand movement.

That places it between three documents it gets confused with. The process map shows on one page which processes exist at all and how they connect; it describes no individual workflow. The standard operating procedure is the binding, controlled QM document with purpose, scope and approval - in content often a process description with formalities around it, and the three-level model of process, procedure and work step explained there applies here too. The work instruction describes a single step down to the click path and machine setting.

The rule of thumb: the process description says that costing follows the technical clarification, and who does it. The work instruction says which fields you fill in the costing tool.

So they are good for more than certification: a stand-in finishes a job someone else started, a new employee understands the approval routes, and you see where a workflow keeps snagging.

The template: how a process description is built

There is no standardized outline, but one structure has proven itself across industries. Copy it into Word, your wiki or your document control system - the format is secondary, the fields are not.

Process description: <process name>
Process no. / version / date / approved by

1. Process owner
   Role (not a name) responsible for the workflow, its metrics and its upkeep

2. Purpose and objective
   Why the process exists, what it is meant to ensure (1-2 sentences)

3. Trigger
   Which event starts the process

4. Input
   What has to be in place before the process can start (documents, data, approvals)

5. Workflow
   No. | Step | Responsible (role) | System / tool | Result of the step
   ... including decision points

6. Output
   What exists at the end, in which system, in what state

7. Interfaces
   Which processes / departments feed in or take over

8. Metrics
   How you measure whether the process works (2-3 figures are enough)

9. Special cases and exceptions
   What happens when things run differently from the normal case

10. Related documents
    Work instructions, templates, checklists, policies with document numbers

Some fields deserve a further sentence.

Process owner is always a role, never a person. "Head of Sales" stays; "Mr. Wendt" moves on at some point. The owner need not run the process himself, but decides when it changes.

Trigger and input get lumped together, but they are two things. The trigger is an event: an enquiry arrives, a month ends, an employee resigns. The input is what the process works on: the enquiry itself, customer master data, the specification. Missing input means the process cannot start - the most common cause of delay in daily work.

Workflow is the centerpiece. Every step gets a role and a result, not just an activity. "Cost the quote" is an activity; "costing sheet with contribution margin exists" is a checkable result. Where a decision falls, give it its own row with the possible outcomes.

Metrics are no controlling luxury. Two or three figures show whether the process still runs as described. Without one, nobody notices that quoting now takes 18 days instead of 10.

Special cases are the section missing from most templates and worth the most in practice. More on that below.

The turtle diagram as a supplement

Anyone running ISO 9001 knows the turtle diagram: the body is the process, and legs, head and tail answer six questions - with what (equipment, systems), with whom (roles, competencies), how (methods), how much (metrics), what goes in and what comes out. It summarizes the process description on one page rather than replacing it: framework conditions and interfaces yes, sequence of steps no. Excellent for audits and management discussions, useless as a working aid for whoever covers an absence.

Example: quoting at a machine builder with 80 employees

A builder of special-purpose machinery, 80 employees, two sales engineers, inside sales with three, design with eight. Quotes run from 20,000 to 600,000 euros. Filled in, the process description for quoting reads like this:

Process owner: Head of Sales.

Purpose and objective: Customer enquiries are answered within ten working days with a technically reviewed and commercially approved quote. Target: a win rate of at least 30 percent on quotes above 100,000 euros.

Trigger: An enquiry arrives - by email, through the contact form, by phone or at a trade fair.

Input: Enquiry with a named contact, the customer's specification or sketch, customer master data in the CRM, current costing policy.

Workflow:

Output: Approved quote as a PDF with the customer, opportunity in the CRM at status "quoted", costing sheet archived.

Interfaces: Design (step 3), purchasing (step 4), management (step 7), order processing (takes over if the order is won).

Metrics: Lead time from enquiry to dispatch (target 10 working days), win rate by quote class, deviation between quoted costing and post-calculation.

Special cases: Framework customers with an agreed price list skip steps 4 and 5; inside sales writes the quote directly. Spare parts and service enquiries below 5,000 euros run through the service process. For urgent trade fair enquiries the sales engineer issues an indicative quote without step 4, marked non-binding. A missing specification is requested in step 1, and the ten-day clock starts only when it arrives.

Related documents: Costing policy KR-03, authority matrix FM-01, quote template in the ERP, work instruction AA-VT-07 "Creating a quote in the ERP".

That fits on a page and a half and answers the questions daily work throws up: who approves at 180,000 euros, why the spare parts quote runs elsewhere, what happens when no drawing arrives.

Table or flowchart - which one when?

The two do not compete, they answer different questions. The table carries detail: roles, systems, results, deadlines. The flowchart shows logic: sequence, branches, loops.

For the quoting process above the table suffices: eight steps, two decisions, no loop. For complaint handling, with its loops between root cause analysis and the customer, a diagram earns its place. Pragmatic standard: table always, flowchart only where the table gets unreadable. Five symbols will do - start, step, decision, connector, end. Full BPMN impresses the consultant, not the colleague who has to get a quote out on Friday afternoon.

Common mistakes in process descriptions

Target state instead of actual state. The description shows the workflow as management wants it, not as it runs. On paper purchasing sources the bought-in parts; in reality the sales engineer calls the supplier himself because it is faster. A document that misses the practice goes unused, and when something goes wrong nobody knows what applies. Capture the practice first, decide whether it should stay that way, then document. How to do that, and what robust process documentation needs overall, is in the guide.

No special cases. The normal case rarely needs describing; everybody knows it. The description is needed at the exceptions: framework customer, rush enquiry, missing specification. Drop that section and you document what works anyway, leaving open what causes trouble.

No owner, or a name instead of a role. Without an owner nobody is responsible when the workflow changes. With a name, the document is wrong at the next staffing change.

Activities without a result. "Cost it", "check it", "align on it" - what exists afterwards? A step with no named result can be neither verified nor handed over. Click paths belong in the work instruction: they go stale with the next ERP update.

Only the manager was asked. Management knows the process in outline. The special cases sit with the inside sales team that has caught urgent trade fair enquiries for years. Skip the people doing the work and you get a description without the places where it snags.

Upkeep: why the description ages after approval

Most process descriptions are written once and then untouched for three years. The ERP is replaced, the approval threshold rises to 200,000 euros, purchasing reorganizes supplier enquiries - and the document still describes approval day. The problem is a missing trigger: changes get implemented in the team, but the route back into the document has neither a date nor an owner.

Three things help. A review date in the header with the owner named as responsible - a review may take five minutes and end with "no changes", but it happens. Change triggers: every system migration, every new responsibility, every new approval threshold sets off a review. And short, regular conversations with the people doing the work, because the fastest indicator of a stale document is the gap between description and practice.

That gathering work is where wissa.ai comes in. An AI interviews the employees who run the process, 15 to 20 minutes per person, by chat or voice, no workshop. If inside sales names the colleague in production planning as the one who costs the job, that colleague is invited next; the system works from one knowledge holder to the next. Out comes the process description with a source reference per statement: each step records who described it, and when the sales engineer tells it differently from purchasing, the contradiction is flagged instead of smoothed over. After every interview the description updates with a diff against the previous version, so upkeep becomes a side effect of the conversations. Editing and approval stay with the process owner.

If you would rather not assemble your process descriptions from twelve conversations yourself: wissa.ai delivers the raw draft from the interviews, traceable to the individual statement, GDPR-compliant with EU hosting and voluntary participation. The first three interviews are free; after that, 12 interview credits cost 149 euros. Register for free

Conclusion

A usable process description has ten fields, fits on one and a half to three pages, and describes the workflow as it runs - owner as a role, a result per step, and the special cases where daily work gets stuck. Table as the standard format, flowchart as the supplement for branched workflows, turtle as the summary for the audit. Copying the template takes five minutes. The real work is listening to the people who run the process, plus an upkeep mechanism that stops the document aging from the day of approval.

FAQ

What is the difference between a process description and a standard operating procedure?

In content they are often the same: a workflow with steps, roles and systems. The standard operating procedure is the QM term and brings formalities - purpose, scope, document number, approval, change history. A process description can exist without certification, for example as a wiki page for whoever covers an absence. If you have both, use the process description as the core of the SOP, not as a parallel document.

Is there a process description template for Word?

The structure in this article transfers straight into Word: header block with process name, number, version and approval, then the ten sections, the workflow as a five-column table. More important than the file format: the document sits where the people doing the work find it, and carries a version and an owner.

How long should a process description be?

One and a half to three pages. Longer usually means two processes have been mixed, or click-by-click instructions belonging in a work instruction crept in. More than twelve steps is a hint to split the workflow or combine sub-steps.

Who writes the process description?

The process owner is accountable; the content comes from the people doing the work. A proven division: the employees who run the process daily supply workflow and special cases, by conversation or AI interview; somebody with an overview structures it; the owner approves. Write it alone at your desk and you document the target state.

What is a turtle diagram and do I need one?

The turtle diagram summarizes a process on one page: input, output, resources, people involved, methods and metrics arranged around it. It is widespread in ISO 9001 environments and useful for audits and management discussions. As a working aid it does not replace the process description, because it shows no sequence of steps. Without a QM system you can skip it.