Out-of-Tolerance Calibration SOP
An out-of-tolerance calibration SOP for Insatech: assessing how far and which way an instrument drifted, determining what it affected, notifying the customer before touching it, then correcting and recalibrating.
How it works
Replace the lanes with your actual calibration-failure roles
This chart uses Calibration Lab, QA / Documentation, Customer Account, Field Service and ServiceDesk. If your organization routes urgent customer notifications through a different role than the account manager, or handles corrective action entirely in-lab with no field dispatch, collapse or rename the lanes to match — the handoffs are where a step quietly gets assumed done by someone who assumed someone else did it.
Set your own significance threshold on the impact decision
"Impact assessed as significant?" needs a stated basis, for example a deviation percentage past a set margin, or any instrument tied to safety, custody transfer or product release, not just a judgment call made differently by whoever is on the case that day. Write the actual threshold into the row's comment field.
Do not move the notification gate
"Notify customer of out-of-tolerance finding and impact assessment" sits downstream of the impact decision and upstream of corrective action on purpose. If you adapt this chart, keep corrective action after notification, not before it — the entire point of this SOP is that the customer hears about a bad reading before Insatech quietly fixes it.
Set People and Workload on every row before you rely on the BI panel
The workload panel can only total hours for rows that carry them. Fill in People and Workload for each step as you adapt the chart, using realistic effort hours rather than elapsed time, so a case with a failed recheck actually shows up as more hours than one that passed first time.
Decide what a recalibration failure escalates to
"Recalibration passes acceptance criteria?" loops a Fail back into corrective action, but a second failure on the same instrument is usually a signal to stop repeating the repair and move to replacement. Add a row or a comment stating at what point the loop should stop and the instrument gets swapped instead of readjusted again.
Frequently asked questions
What triggers this SOP?
It starts at "Calibration fails acceptance criteria (as-found out of tolerance)", the point where the as-found step of the parent Instrument Calibration & Documentation SOP finds a reading outside acceptance criteria. That SOP's happy path, within tolerance, certificate issued, stops there; this SOP is the formalized failure branch that runs instead.
Why does the customer get notified before the instrument is touched?
Because the customer's own process or product decisions may have relied on this instrument's readings since its last good calibration. "Notify customer of out-of-tolerance finding and impact assessment" sits between the impact assessment and corrective action deliberately, so the customer hears about a possible bad reading from Insatech directly, rather than finding out after the fact that a fix and a fresh certificate quietly papered over it.
What happens if the fix doesn't hold on recalibration?
The "Recalibration passes acceptance criteria?" decision has a Fail branch that routes straight back to "Determine corrective action: adjust, repair or replace the instrument" rather than assuming a single repair attempt is enough. In practice a second failure on the same instrument is usually the point to move from repair to replacement, which is why the how-to guidance recommends stating that escalation point explicitly.
How is this different from the routine Instrument Calibration & Documentation SOP?
The parent SOP covers the full as-found-to-certificate flow, including the happy path where the instrument passes. This SOP starts one step later, at the point where it doesn't, and does not repeat the parent's as-found or as-left steps. It exists specifically for the unhappy branch: assessing deviation and impact, gating on customer notification, correcting the instrument, and documenting the corrective action as its own auditable record.
Who decides whether the impact is significant?
In this chart, QA / Documentation owns the "Impact assessed as significant?" decision, using the instrument's calibration history and the customer's records for the affected period. Significant impact routes to an urgent, account-manager-led notification; minor impact still gets notified, just through the standard channel — the decision changes urgency, not whether the customer is told.