The Complaint That Wasn’t About the Lock

When an entry fails, the phone call usually names the lock. It is the newest piece of equipment on the door, the one with a battery and a keypad, and the one most people understand least. That makes it an easy suspect, not necessarily the cause. A door entry complaint troubleshooting process starts by resisting that first explanation.

Whoever answers the phone needs a short, repeatable way to sort the report before a technician is booked. The script below moves from the door to the person to the hardware, in that order. It does not replace model documentation or an installer’s judgment. It keeps a routine building problem from becoming a lock replacement.

Three branches, in order

Treat every complaint as belonging to one of three branches. The order is deliberate: it ranks the branches by how often they explain the report and how cheaply they can be checked.

• Door or frame. The door has to close, latch and align before the lock can do its job. Swollen timber, a changed closer, dropped hinges, a shifted strike plate, a new weather seal, or a frame that moves when the door is pulled can produce a report that sounds electrical. The lock may be the messenger.
• Habit or expectation. People describe what they expected, not what happened. A credential may work at a different entrance, a user may press the wrong part of the reader, a door may be held open, or a new resident may have a credential for a different door. Reports also arrive after staffing changes, when someone assumes access was transferred and it was not.
• Hardware. The lock itself is last, not because it never fails, but because it should be reached with the first two branches already ruled out. A hardware report is stronger when the caller can say the door closes freely, the credential worked last week, and nothing on the door changed.

Branching is not a diagnosis. It is a sorting decision that gives the next person the right starting point.

Why the order matters

A dispatcher who jumps straight to hardware spends the first visit on the wrong object. A replacement lock can be fitted to a door that still binds at the top corner, and the complaint returns as soon as the door settles into the same bad geometry. The second call is now more expensive because the first repair was logged as done. The building also loses confidence: the lock was changed, so the fault must be something else.

Starting with the door also protects the supplier conversation. If an installer reports a fault and the supplier asks what was checked, “the door closes and the old credential worked” is useful information. “The customer says it does not work” is not. The branch becomes the shared language between the person on the phone, the installer and the supplier’s documentation.

Complaints often cluster in a building’s first year, while doors settle and users form habits. Our notes on first-year lock maintenance explain why that early period deserves a closer look. The order is an operational default, not a claim that doors cause most faults; clear hardware evidence should always move the call to branch three.

The questions that sort the branch

Three questions do most of the work. Ask them in plain language and write down the answers, because the value comes from the pattern across calls, not from any single response.

1. “Does the door close on its own weight?” Ask the caller to let go of the door and watch it, without forcing it. If it rubs, stops short, swings open or needs a lift to latch, the door or frame has earned the first branch. Ask whether anything changed: a closer adjusted, a new seal fitted, painting, furniture moved or a hinge replaced.
2. “Has this credential worked on this door before?” A credential that never worked points to enrollment, user setup or the wrong door. A credential that worked yesterday points to a change: a removed user, a new credential, a different entry method or a power source. After staff changes, check the access record before assuming a hardware fault; our guide to staff offboarding and access revocation shows why a clean removal process matters.
3. “Did anything change on the door recently?” This catches the invisible cause. A new tenant, a maintenance visit, a closer adjustment, a delivery or a cleaning crew can change how a door behaves. The answer does not prove a cause, but it tells the next person where to look.

These are general door-entry questions, not model-specific diagnostics. They sort the report; they do not replace the installation manual or the supplier’s documentation.

Power as a false alarm

Power deserves its own branch because it can imitate hardware so well. A lock that does nothing at the door looks like a failed lock, but the cause may be the energy source. The details are model-specific, which is exactly why a generic answer is dangerous.

CaremLock documentation gives three different examples. The DS-series deadbolt is documented with a mechanical key override and a 6V supply using four AA batteries. The DDA2 is documented with dual power (2x4AA) and anti-reverse charging. The A20 can run on a 12V 23A battery or a 5V power bank. Those arrangements are not interchangeable, and nobody should assume that the battery arrangement for one model belongs in another. Ask for the current documentation for the exact model before advising a replacement.

A flat battery can present as a hardware fault, but power is not a diagnosis by itself. On a DS-series unit, the documented mechanical key override gives the building a way to enter while the cause is established. That is a fallback, not a fix, and it should sit inside the building’s key control. For doors where power loss has to be planned for, the power outage entry plan covers the operational side. Keeping the model sheet with the door file also means the power question can be resolved before a hardware visit is booked.

Keeping the record

Complaints become useful only when they leave a record. A notebook at the front desk is better than memory; a shared spreadsheet is better still. The fields should be small enough that a busy person will actually fill them.

Three months of notes will not explain every incident, but they will show which door keeps attracting the same branch. If one entrance produces repeated door-or-frame reports, the building has a door problem, not a lock problem. If one user group produces repeated habit reports, the handover needs work. If one model produces hardware reports while other models on the same site do not, the model documentation and installation record are the next stop. That is pattern reading, not a promise of a root-cause answer.