Process inputs are the information, materials, conditions or other resources used by work. Outputs are the products, services, information or decisions it produces. Defining them usefully requires more than naming items: the organisation needs to understand what makes them suitable and who depends on them.
The process management guide explains these relationships across the QMS. A clear input-output description helps establish boundaries, controls and handovers without requiring every relationship to use a separate specification document.
Describe the purpose of the input
Ask why the process needs each input and what decision or activity it enables. A customer specification supports planning only if the relevant requirement is understandable and applicable to the case.
Inputs can be intangible. An authorisation, operating condition or confirmed competence can matter as much as a physical component. Avoid a list that captures materials while ignoring the information needed to use them correctly.
Separate essential entry conditions from information that can legitimately arrive later. Requiring everything at the start may create unnecessary delay, while allowing a critical gap can move uncertainty into a more consequential stage.
Define suitability, not presence alone
A file can exist while being incomplete, obsolete or inconsistent with another requirement. Identify how the process recognises whether an input can be used and what happens when it cannot.
For a fictional service visit, an address may be present but insufficient if access restrictions or required equipment are unknown. The team should determine which information is needed before committing resources.
The control can be proportionate. A routine input may need a simple completeness check, while complex work may require technical review or customer clarification. Do not assume one approval method fits every consequence.
Define the output through the recipient’s need
An output marked complete internally may be unusable by the next activity. Ask what the recipient needs to accept or use it without unnecessary rework or guesswork.
A maintenance report might need findings and follow-up information for the customer and planning team. Closing the technician’s job in a system does not necessarily provide those outputs.
| Process relationship | Input question | Output question |
|---|---|---|
| Order review | Are requirements clear and feasible? | Is the accepted commitment usable for planning? |
| Purchasing | Is the required supply defined? | Does the order communicate suitable conditions? |
| Inspection | Are criteria and item identity available? | Are results usable for the release decision? |
| Improvement | Is the problem supported by evidence? | Is the change and its evaluation understandable? |
These are original examples, not an exhaustive ISO input-output list.
Agree handover responsibility
Identify who supplies the input, who receives it and who resolves uncertainty. A process can fail when both parties assume the other has checked suitability.
Define what happens to incomplete or rejected information. If the receiving team silently repairs every gap, upstream performance may look favourable while the overall route accumulates delay and rework.
The interaction matrix article explains a way to make significant dependencies visible. The matrix remains a tool; actual acceptance and action arrangements need to operate.
Preserve identity and relevant context
Inputs and outputs often need a case, version, period or other reference to remain interpretable. A test result detached from the item and criteria may not support release. An approval detached from the changed requirement may be ambiguous.
When information moves between systems, check whether context survives. A spreadsheet export can retain values while losing approval status, filters or relationships needed for interpretation.
Avoid unnecessary duplication. Controlled references can preserve the link without copying the same requirement into multiple independent sources, provided users can access what they need.
Use evidence to improve the relationship
Track meaningful problems such as returned information, clarification delays or downstream rework where they support decisions. Counting outputs alone can reward quantity while hiding usability.
Review both sides of an interface. A supplier may report complete submission while the recipient repeatedly finds missing detail. Agree definitions before interpreting performance differences.
The process owner article explains why someone needs a practical route to coordinate these issues across functions rather than assign isolated corrective tasks indefinitely.
Review changes to inputs and outputs
A new service, system or customer commitment can alter what a process needs and produces. Evaluate affected controls, responsibilities and evidence before assuming the old relationship remains suitable.
Test the description against real work and relevant exceptions. Users should be able to explain why an input is accepted, how an adverse condition is handled and what makes the output useful to its recipient.
Clear inputs and outputs connect process boundaries to actual decisions. Their value lies in suitable information and reliable handovers, with evidence that the next activity can proceed as intended rather than merely receive something labelled complete.
When an output is rejected at a handover, record enough information to understand why and who resolves it. Otherwise repeated repair by the receiving team can remain invisible, leaving the supplying process with a misleading view of its own completeness.