Response When a Wrong Key Cut Is Discovered After the Customer Leaves

Purpose

A duplicate or code-cut key that does not work is usually treated as a nuisance recut, and most of the time that is exactly what it is. The exposure this procedure exists to control is the sharper case underneath it: the key was not cut wrong in the sense of missing the mark, it was cut correctly to the wrong job's bitting, because two tickets crossed in the queue. That failure hands a stranger a working key to a real lock, and the customer who complains is often the one who noticed least, since their own key not working is the visible symptom while the actual exposure sits on someone else's door who has not called in yet.

This applies mainly to counter and walk-in cutting, duplicates from a sample key or codes cut without the actual cylinder present to test against, because that is the shop's own testing gap: the on-the-spot turn test that closes out a rekey on site does not exist for a key cut from a sample or a code, so a mismatch is not caught until the customer gets home.

Scope

Covers discovery, after the customer has left, that a cut key does not work as intended, whether by a data or bitting error or by a crossed job. Does not cover on-site testing during a rekey or installation, owned by the Rekey and Lock Change SOP's own test step. Does not cover restricted-blank custody and the periodic count, owned by the Key Blank and Key Control Inventory SOP. Does not cover a customer disputing they ordered a key at all, which is an identity and authority matter.

Roles and responsibilities

Procedure

Step 1: Freeze the original artifacts before doing anything else. Pull the original job ticket, and ask the customer to bring back or photograph the non-working key. Acceptance: ticket located with job number, code or sample source, and cutter identified, within the same call. Wrong looks like re-cutting from memory of "probably the same code" without the ticket in hand. Stop rule: if the ticket cannot be located, do not re-cut blind; schedule an in-person visit to re-derive the bitting from a working key the customer holds or from the lock itself, because guessing a second time compounds the first error.

Step 2: Determine which failure shape this is before choosing a response, because they are not the same problem. Shape A: the key was cut to the wrong depths for the intended lock, a data or reading error, and it will not work anywhere real. Shape B: the key was cut correctly, just to a different job's bitting, a queue mixup. Acceptance: measure the returned key's actual bitting and compare it against both what the ticket ordered and every other job worked at that station in the same period. Wrong looks like assuming Shape A, the harmless read, without running that second comparison; skipping it is the likeliest real failure in this whole procedure, because Shape A is the comfortable assumption and Shape B is the one that matters. Stop rule: any match, even partial, between the measured bitting and another open ticket routes immediately to step 4, not to the routine recut in step 3.

Step 3: Correct Shape A with a re-verified source, not the same ticket note. Re-read the bitting from a working key the customer still holds, or re-pull the code from the authoritative record rather than the same note that may have been misread the first time. Test the new cut independently against that source. Acceptance: new key's measured bitting checked against a re-verified source, delivered the same business day at no charge, logged against the original job number. Wrong looks like recutting from the same flawed ticket note, which reproduces the identical error. Stop rule: if the source cannot be independently re-verified, no working key available, code illegible, lock inaccessible, schedule an on-site pinning-read visit rather than guessing a third time.

Step 4: Freeze both tickets the moment Shape B is suspected, and name the second hazard route in its own clause. Nothing further is delivered or activated on either job until this resolves. Separately: if the miscut key was already delivered and fits a lock in active use, an unauthorized key now exists in a stranger's hands, which is a live compromise of that other address, not an inconvenience for the customer who complained. Treat that address exactly as a key-compromise event even though its occupant has not called in. Acceptance: both job files compared field by field, address, keyway, code, technician, date and time, and a written call on whether contamination is confirmed. Wrong looks like waiting for the second customer to notice, who may never notice a key that works exists somewhere. Stop rule: confirmed or plausible and unresolved by the end of the same business day means the other customer gets a proactive courtesy call and a no-charge rekey offer in that same conversation, whether or not they asked for one; a customer is never told a stranger may have a key without also being offered the fix.

Step 5: Recut, redeliver to a verified customer, and close the loop on the original miscut key. The correcting key is tested against the re-verified source, delivered only after checking the recipient against the original job's authority record, not assumed because "it's the same person who complained." The wrong key already in the first customer's hands is recovered and destroyed, logged by serial or description, or, if it cannot be recovered, that gets its own line as an open exposure escalated to the lead. Acceptance: recovery-and-destruction logged, or non-recovery logged with the specific reason. Wrong looks like closing the ticket once a correct key is delivered while the original miscut is still unaccounted for. Stop rule: an unrecovered Shape B key against a real cylinder stays on the exception list, closed only when recovered or when that cylinder is rekeyed.

Step 6: Name the root cause before closing, because Shape B implies a process gap, not a one-time slip. Check whether two tickets were being worked at one machine without clearing between jobs, whether a sample key returned to the wrong customer's tray, or whether a code was read off the wrong line on a shared card. Acceptance: a stated cause on the ticket, not "cutter error" alone. Wrong looks like closing without identifying what actually happened. Stop rule: no identifiable cause means the bench's queue handling is flagged for the lead's review before the next high-volume day, rather than filed as an isolated mistake.

The record this produces

Original ticket, the discovery report, the measured-bitting comparison from step 2, the shape determination, the recut's independent verification, the recovery or non-recovery log, any cross-customer notification with its date, and the named root cause. Readers later: the office running the next busy day, the lead reviewing a pattern, and the customer on the other end of a proactive courtesy call who needs the shop's account to be complete.

Worked pass: two tickets on a busy duplicate day

Two customers order duplicates from a sample key back to back on a similar keyway, tickets 4471 and 4472. The next morning, customer 4471 calls: neither new key opens her front door.

The office's first instinct is Shape A, a straightforward recut, and a walk-in is scheduled without running step 2's comparison against other open tickets. This is the step that fails. The bench technician assigned to the recut, following this procedure rather than the office's shortcut plan, measures the returned key's bitting before cutting anything new, per step 2's requirement, and finds it does not match ticket 4471's sample at all, but matches ticket 4472 closely. Step 2's stop rule fires and the routine recut in step 3 is halted before it starts.

Step 4: both tickets are pulled, addresses compared, different buildings, no shared tenancy, confirming genuine cross-contamination rather than coincidence. The cause traces to sample keys placed on a shared tray during a busy stretch: both customers' sample keys were duplicated from the same clamped source without swapping between the two tickets, so 4471 received two keys cut to 4472's lock, and 4472's duplicates were cut to 4471's. Customer 4472 has not called in and does not know.

Step 4's stop rule: customer 4472 gets a proactive call the same business day, told plainly that a mixup means two keys cut for someone else may fit their door, and offered a no-charge rekey in that call. They accept, scheduled for the next morning.

Step 5: customer 4471's two wrong keys are recovered on the spot, she still has them, destroyed and logged. New duplicates are cut from her own original key, which she still carries, and delivered the same visit. Customer 4472's door is rekeyed the next morning at no charge, closing the exposure regardless of whether the two wrong keys are ever separately located. Step 6: root cause named as untagged sample keys on a shared tray during a multi-job stretch; the fix, name tags on every sample key during any day with more than one duplicate order in queue, goes on the bench's process notes.

References

• Key Blank and Key Control Inventory SOP (owns restricted-blank custody and periodic count discipline this procedure mirrors for sample-key handling)
• Rekey and Lock Change SOP (owns the on-site test-before-delivery step this procedure's gap sits outside of)
• Identity and Authority Verification Before Any Work SOP (owns the recipient check referenced in step 5)
• ALOA Security Professionals Association guidance on key identification and customer notification practice