A QMS process flow shows how requirements become accepted outputs and how evidence feeds back into later decisions. It should explain more than the forward movement of work. Changes, rejected inputs and recurring problems need defined routes too, because those conditions often expose gaps between otherwise well-run activities.
The QMS guide explains the system surrounding the flow. This article uses a fictional service assignment to make the handovers and decisions visible. It is a practical example rather than a universal ISO process sequence.
Begin with the commitment
A customer requests an assessment report. The service provider clarifies the intended output, required inputs, review needs and delivery conditions. It checks whether suitable capability and capacity are available before accepting the assignment.
The output of this stage is an understandable commitment, not merely an entered order. If the scope remains ambiguous, an authorised person needs to clarify or limit it. Starting work on incompatible assumptions can create rework that later checks cannot easily remove.
Record important decisions in the existing engagement or order information. A separate form is useful only where it adds necessary control or evidence.
Accept inputs and plan delivery
The project owner checks whether required customer information is sufficiently complete and suitable for the planned work. Missing information follows a clarification route. If provisional work is authorised, preserve the assumption and its limits so others do not mistake it for a settled fact.
Planning then assigns competent people, resources and suitable review arrangements. It identifies dependencies and the information each recipient needs. Where external expertise contributes, specify the expected output and acceptance evidence.
The process inputs and outputs guide explains this boundary. Handover is dependable when the recipient can recognise whether the input is usable and what to do when it is not.
Perform the work and control changes
Staff perform the assignment using current requirements and relevant methods. They preserve important observations and decisions proportionately. If information changes, the project owner evaluates the effect on completed and planned work.
Suppose the customer revises an instruction after analysis begins. The organisation identifies affected files, obtains competent input and agrees any revised commitment. The change route should communicate the result to everyone relying on the earlier information.
A flowchart that shows only perform work and send report omits this important loop. The actual process needs a controlled way to return to clarification or planning without losing the history of the decision.
Verify the result and authorise release
Before issue, the relevant reviewer evaluates the report against suitable acceptance criteria within their competence and authority. Material comments are resolved or escalated. The record identifies the output and revision to which the decision applies.
An unacceptable result returns to the appropriate work stage for correction. A release decision should not be inferred solely from a completed task status if the acceptance evidence remains outstanding.
The organisation communicates the accepted output and any relevant limitations to the customer. Delivery evidence should correspond to the actual output rather than an earlier draft that happened to pass review.
Describe the complete flow clearly
| Stage | Output or decision | Exception route |
|---|---|---|
| Understand request | Accepted scope and conditions | Clarify or decline unsuitable work |
| Review inputs | Ready inputs or authorised assumptions | Obtain missing or corrected information |
| Plan | Competent assignment and resources | Escalate capability or capacity constraints |
| Perform | Work using current information | Assess changed requirements |
| Verify and release | Accepted output and authority | Correct, investigate or obtain a decision |
| Learn | Evidence-based improvement choice | Review recurring or unresolved issues |
Keep an overview at this level readable. Detailed methods can sit below it. Use the QMS framework guide to connect the flow with wider governance, resources and evaluation.
Feed experience back into the system
Customer feedback, internal checks and later use can reveal problems not identified before release. The organisation assesses affected work, responds appropriately and examines recurring mechanisms where justified.
If incomplete inputs repeatedly cause report corrections, the response may change input acceptance rather than add another final review. Evaluate later cases to see whether the revised arrangement addresses the mechanism and remains workable.
The learning loop can also begin with an opportunity. A simpler handover might reduce uncertainty in an already acceptable process. Test the change and retain evidence supporting the adoption decision.
Test the flow against actual work
Select a completed assignment and ask each participant which information they received, what they decided and what they passed on. Compare the account with records. Include a changed instruction or rejected input rather than demonstrate only the smoothest case.
Look for waiting points, duplicate decisions and missing authority. A delay may arise because two teams each expect the other to accept a departure, not because either team needs to work faster.
Update the description where actual practice is useful but undocumented, and improve controls where practice creates exposure. A QMS flow is valuable when it helps people understand and manage those connections. Drawing the sequence is a starting point; evidence from real cases establishes whether the arrangement works.