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.

Use this template

What the Out-of-Tolerance calibration SOP process is

Insatech's Instrument Calibration & Documentation SOP has a happy path: as-found reading within tolerance, no adjustment needed, certificate issued. This SOP is what runs on the branch where that isn't true. The moment "Calibration fails acceptance criteria (as-found out of tolerance)" fires, the case leaves the routine calibration flow and enters a track with its own gates, because a reading that failed acceptance criteria isn't just a data point to correct, it's evidence that the instrument may have been reporting wrong numbers for some period before anyone noticed. "Assess deviation: magnitude and direction of drift" and "Determine impact: which process or product decisions relied on this instrument since its last good calibration" exist as two separate, named rows rather than one combined note because they answer two different questions: how far out is it, and what did that distance actually cost the customer. A 0.3% drift on a non-critical level indicator and a 4% drift on a custody-transfer flow meter both fail the same acceptance criteria, but they do not carry the same consequence, and the chart is built to make that distinction visible rather than leaving it to whoever happens to be reviewing the case.

The "Impact assessed as significant?" decision doesn't decide whether the customer gets told; it decides how urgently. Either branch, "Escalate to account manager for urgent customer notification" or "Prepare standard out-of-tolerance notification", converges on the same row: "Notify customer of out-of-tolerance finding and impact assessment". That convergence is deliberate. Insatech's calibration certificates are what a customer's own quality system leans on, and if their process or product decisions were made on a reading this instrument later turns out to have gotten wrong, they need to hear that from Insatech before Insatech starts fixing the instrument, not after it's already been adjusted, recalibrated and quietly re-certified as if nothing happened. That's the hard gate this SOP is built around, and it's why "Determine corrective action: adjust, repair or replace the instrument" sits downstream of notification on the chart, never upstream of it.

The last two lanes close the loop the parent SOP opened. "Recalibration passes acceptance criteria?" is a real branch with a real fallback: a Fail routes back into "Determine corrective action: adjust, repair or replace the instrument" rather than assuming the first fix worked, because a repair that doesn't hold on recheck is exactly the failure mode a customer running on Insatech's certificate can't afford to inherit. "Document corrective action and impact assessment" then records both halves together on the case file, what was done to the instrument and what it may have affected while it was wrong, so an auditor reading the file later sees the full story, not just a repair note. Every row carries a named owner and hours through the built-in People and Workload columns, so the workload BI panel can separate Daniel Cole's calibration-lab hours on the deviation and recheck from Sophie Lund's customer-notification hours on the same case.

What this flowchart covers

In this template

  • The deviation and impact chain from "Calibration fails acceptance criteria (as-found out of tolerance)" through "Assess deviation: magnitude and direction of drift" to "Determine impact: which process or product decisions relied on this instrument since its last good calibration"
  • The severity branch at "Impact assessed as significant?", which routes to "Escalate to account manager for urgent customer notification" or "Prepare standard out-of-tolerance notification" before both paths converge on the hard gate: "Notify customer of out-of-tolerance finding and impact assessment"
  • Corrective action across the Field Service and ServiceDesk lanes: "Determine corrective action: adjust, repair or replace the instrument", "Schedule technician and arrange spares or replacement unit", and "Adjust, repair or replace the instrument"
  • The recalibration checkpoint at "Recalibration passes acceptance criteria?", which either proceeds to closeout or loops back to "Determine corrective action: adjust, repair or replace the instrument" when a fix doesn't hold
  • Closeout and traceability: "Document corrective action and impact assessment" and "Share corrective action report with customer", the record that closes the case the parent Instrument Calibration & Documentation SOP opened when the as-found reading first failed
  • Named owners and hours on every row via the People and Workload columns, so the workload BI panel can show, for one case, Daniel Cole's calibration-lab hours against Sophie Lund's customer-notification hours and Thomas Reid and Nadia Kessler's hands-on repair time

When to use this template

  • An as-found calibration reading comes back outside tolerance under the parent Instrument Calibration & Documentation SOP and you need a defined next step instead of an ad hoc phone call
  • You need to show an auditor, or the customer themselves, that a deviation was assessed for impact before the instrument was touched, not fixed first and explained later
  • A drifted instrument may have influenced customer batch releases, process setpoints or product decisions since its last good calibration, and you need a record of who determined that and when
  • You're onboarding a new calibration technician or QA reviewer and need a reference for exactly when the customer must be notified relative to when corrective action starts
  • A repair or adjustment doesn't hold on recalibration and you need a defined path back into corrective action instead of an informal second attempt nobody logs

How it works

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Where this process fits

In most operations this process follows Instrument Calibration & Documentation SOP.

Comes before

  • Instrument Calibration & Documentation SOP — Insatech's core calibration SOP: verify traceable reference equipment, record as-found readings before adjustment and as-left readings after, then issue a certificate an auditor can follow end to end.
  • Preventive Maintenance & Calibration Planning SOP — A preventive maintenance and calibration planning SOP for instruments under a service agreement: criticality assessment, interval determination, scheduled maintenance, drift-trend analysis and evidence-based interval adjustment.

Part of

QueryChart features for this process

Use this template

More in SOP templates

Browse all SOP templates

Out-of-tolerance calibration (deviation assessment to closeout): Deviation & Impact Assessment → Customer Notification → Corrective Action → Recalibration → Documentation & Closeout
Out-of-Tolerance Calibration SOP