A return is a poor diagnostic method. It delays access restoration, consumes stock and can leave the actual cause unresolved. A better channel process turns recurring symptoms into a sequence: confirm fit, identify configuration, isolate the operating boundary and then decide whether a part or complete device needs replacement.
Prevent the predictable cases
| Failure pattern | Preventive control | Support evidence |
|---|---|---|
| Latch binding or motor strain | Confirm backset, door thickness, mortise and alignment on a representative door. | Installation photos and lock-handling test. |
| Battery or power issue | Specify approved battery type, replacement procedure and emergency power fallback. | Battery condition and voltage check. |
| Credential problem | Define enrollment, deletion, administrator ownership and fallback credential. | Exact credential action and account state. |
| App or gateway offline | Confirm network owner, gateway placement and offline operation. | Firmware, network state and reproduction steps. |
| Incorrect replacement part | Maintain a model and revision-specific spare record. | Serial or batch and fitted configuration. |
Use samples as a support rehearsal
Sample approval should cover the support path, not only unlocking. Test installation, credential creation and removal, normal locking, low-power behaviour, manual or emergency fallback, user handover and the support record that would be available if the unit failed later. The result is both a product decision and an installation instruction.
Fit comes first. Use the door-fit checklist on a representative door and keep the photos with the sample record; the TD-M1-B page shows the model-specific details worth capturing.
Set the response sequence
- Keep access safe through the approved fallback.
- Collect the unit and site identity before reset or replacement.
- Run the mechanical, power, credential and network checks relevant to the symptom.
- Escalate with evidence when the first-line boundary is closed.
- Record the disposition and update training or installation guidance if the pattern recurs.
| Symptom | First checks | Escalate when |
|---|---|---|
| Will not unlock | Credential type, account or gateway state, event log, fallback result. | Fallback works but the credential route is still failing after account checks. |
| Door will not close or latch | Alignment, strike, latch travel; stop changing app configuration. | Mechanical load is clear and motor strain persists. |
| Battery drains quickly | Cell chemistry, batch, measured voltage, opening duty, temperature, radio signal, firmware. | Approved cells and measured load still show abnormal drain. |
| App or gateway offline | Network owner, gateway placement, firmware, reproduction steps. | Network is confirmed healthy and the device still fails to reconnect. |
| Wrong spare fitted | Serial or batch, fitted configuration, revision record. | Spare record and fitted unit do not match. |
Keep access safe, then diagnose
A door that cannot be opened is an access problem first and a product problem second. Agree the fallback in advance: which mechanical key, emergency power route or alternative credential is approved, who holds it, and who may use it. Restore safe access, then capture the evidence. Resetting a lock to get a resident through the door often removes the log, the account state and the firmware record that would have identified the cause.
Train installers on the causes you can prevent
Many repeat cases start at installation, so the cheapest control is a short, repeatable installer routine. Cover these points on a representative door before volume rollout:
| Topic | What the installer must do | Evidence kept |
|---|---|---|
| Door and frame check | Measure thickness and backset, check mortise, handing and strike alignment before mounting. | Photos of outside, inside, edge and strike. |
| Latch travel | Operate the latch by hand through its full travel before fitting the electronics. | Pass or fail note on the installation sheet. |
| Battery | Fit the approved cell type, confirm polarity and record the replacement procedure. | Cell type and installation date. |
| Credentials | Enrol, delete and test each credential type, and name the administrator. | Administrator and fallback credential recorded. |
| Connectivity | Place the gateway, pair the lock and confirm offline behaviour. | Firmware and network state recorded. |
| Handover | Show the resident or property team the fallback opening method and support contact. | Signed handover note. |
Match spares and replacements to the installed range
An incorrect replacement part turns one visit into two. Keep a spare record by model and revision, tie it to the serial or batch on the installed unit and name who approves a replacement. When a revision changes, update the spare list and the installer routine at the same time, and check that the replacement is compatible with the firmware already deployed. The replacement decision should also state whether the returned unit comes back for analysis, because a unit that is scrapped on site cannot contribute to a root-cause review.
Turn recurring cases into controls
Classify each case by the first reproducible condition and record whether it was solved by installation, configuration, training, replacement or a supplier change. A repeated symptom should produce a controlled change to the fit guide, commissioning step or supplier sample, rather than a new untracked workaround. Keep the model, revision and destination in every case record.
Track the stages between intake, first reply, evidence request, reproduction, replacement and closure. If one stage repeats, change the guide or ownership. For the quality evidence behind these records see how smart lock quality affects after-sales cost, and for the commercial side see OEM access control: purchase price vs TCO.
Frequently asked questions
Why is a return a poor way to diagnose a smart lock?
It delays access restoration, consumes stock and can leave the real cause, such as fit, power, credential or network, unresolved. Diagnosing first avoids repeat visits.
What are the most common preventable causes?
Latch binding or motor strain from poor fit, battery or power issues, credential administration problems, an offline app or gateway and incorrect replacement parts.
What should be collected before reset or replacement?
The unit and site identity: model, serial or batch, firmware, site configuration and the observed symptom, so the evidence is not lost.
How should samples be tested to reduce later returns?
Test installation, credential creation and removal, normal locking, low-power behaviour, manual or emergency fallback and handover, and keep the resulting record available to support.
Can I promise a percentage reduction in returns?
Not without measured data from a defined cohort. State the controls in place instead: representative-door testing, configuration records, intake evidence, trained installers, spares scope and an escalation route.
When should a case be escalated to the supplier?
When the first-line mechanical, power, credential and network checks are closed and the symptom persists, escalate with the model, revision, batch, destination and reproduction evidence.
Turn the guide into a project brief
Share the selected model, site conditions, interfaces and destination market so the next review stays within a written scope.
Request a project reviewEditorial review: Updated 25 October 2026 for search intent, scope and project usefulness.