The instinct when credentials start failing is to blame the batch. It is usually the least likely explanation, and replacing a batch that was never faulty leaves the property with the same problem and less money.
- Isolate before you diagnose
- Test with a known-good credential
- Check what changed
- Report specifically
- When it is genuinely the batch
Isolate before you diagnose
Four questions, in order. Does it fail at every reader or one? For every guest or some? With every credential from the batch or a few? At every time of day, or when it is busy?
The answers narrow it immediately. One reader means a reader problem. Some guests means a presentation or fit problem. A few credentials means a batch question. Only at peak means a throughput or procedure problem, not a technical one at all.
- One reader, all credentials
- Reader, mounting or placement — not the credential
- All readers, some credentials
- A batch question worth escalating with the range number
- All readers, some guests
- Presentation, fit or where the credential sits on the wrist
- Only at peak
- Throughput or procedure, not technology
Test with a known-good credential
Keep one credential from the approved sample set that is known to work, stored separately. When something fails, presenting the known-good credential at the same reader separates a reader fault from a credential fault in about ten seconds.
Properties without one spend hours arguing about which it is. It costs nothing to set aside at the point of approval.
One credential from the approved set, stored separately and never issued. It is the fastest diagnostic tool in a credential programme and the cheapest.
Check what changed
Credential problems rarely appear spontaneously. Something changed: a reader was replaced, a lock system was updated, a new batch arrived, a wing was refurbished, or staff issuing credentials changed at the start of a season.
Asking what changed in the last month resolves a large proportion of cases before any technical investigation begins.
Report specifically
A report saying credentials are failing is unactionable. A report naming the reader, the range number of the credentials, the proportion failing, whether they were wet, and what a known-good credential does at the same reader is actionable immediately.
This is where counted, range-labelled supply pays for itself: a problem traced to a range is contained, while the same problem in an unlabelled delivery is a question about everything.
When it is genuinely the batch
It happens, and the response is the same either way: quarantine the affected range rather than the whole stock, keep examples rather than discarding them, and record what the known-good credential did at the same reader.
That gives a supplier something to work with and gives the property a contained problem rather than a general loss of confidence in its own stock.
Compatibility is confirmed against the property’s lock system, credential technology and encoding requirements before production. We do not claim universal compatibility.
Questions this raises
01How do we tell a reader fault from a credential fault?+
Present a known-good credential at the same reader. If it works, the problem is the credential; if it fails, the problem is the reader. Keeping one credential from the approved set aside makes this a ten-second test.
02Credentials started failing this week. Where do we look?+
At what changed — a replaced reader, a system update, a new batch, a refurbished wing, or new seasonal staff issuing credentials differently. That question resolves a large share of cases before any technical work.
03What should a fault report contain?+
The reader, the range number of the affected credentials, the proportion failing, whether they were wet, and what a known-good credential does at the same reader. Anything less is not actionable.