Your techs are on rooftops, in crawlspaces, wearing gloves. Every login friction point is a job update that never happens. Here is how we designed the Ansdale tech app around that, and where a PIN is the wrong answer.
We asked techs in three markets what they hated most about the software their shops made them use. The most common answer was not a missing feature. It was the login.
Why passwords fail specifically in field work
Not because techs are careless with them, because the environment defeats every recovery path a password system depends on.
A password reset email assumes you can read email on the device you are locked out of, in daylight, with signal. On a roof in July, on a phone screen you cannot see, in a basement with no bars, that assumption fails. Fingerprint sensors want a clean dry finger, which is the opposite of a working one. Face unlock struggles with safety glasses and a respirator. And typing anything with a capital letter and a symbol through nitrile gloves takes several attempts.
What follows is predictable and it is not a discipline problem. The tech stops updating jobs during the day and does it all from the truck at 5pm from memory, or the office rings them for a status they could have tapped in themselves. The data arrives late and thinner than it should be, and the dispatcher spends the afternoon guessing.
What a PIN actually solves
A four-digit PIN is memorised in one shift, works with gloves on, needs no data connection to recall, and survives a phone change in about ten seconds. It removes the friction at the exact moment the tech is deciding whether updating the job is worth the hassle.
The point is not that a PIN is more secure than a password, on its own, it plainly is not. The point is that a credential nobody can use in the field produces no security at all, because the workaround is worse: shared logins taped inside a van door, one account for the whole crew, or the app abandoned entirely.
The part people skip: a PIN is not a password
Four digits is ten thousand combinations. That is fine as a device-bound unlock and completely unacceptable as a credential someone can try from anywhere on the internet. The distinction is what makes it safe or not.
A PIN only belongs on an already-enrolled device, tied to a tech account with a real scope limit; their jobs, not the whole tenant. It needs attempt limits so it cannot be brute-forced, and it needs to be revocable centrally the moment someone leaves or loses a phone. A PIN that unlocks a session on a device you enrolled is a reasonable design. A PIN as the sole authentication for a general login is not, and any vendor offering that should be asked hard questions.
| Method | Gloves | No signal | New phone | Safe alone? |
|---|---|---|---|---|
| Password | Poor | Reset needs email | Reset needed | Yes |
| Fingerprint | Fails when dirty or wet | Works | Re-enrol | Yes |
| PIN on an enrolled device | Works | Works | Seconds | Only with device binding and attempt limits |
What this changes day to day
Job status that reflects reality rather than a reconstruction at the end of the shift. Photos taken at the property instead of forgotten. Notes written while the detail is fresh. None of that is a feature you can put on a comparison table; it is what happens when the barrier between the tech and the record is two seconds instead of two minutes.
Office side, it means “en route” and “waiting on a part” mean something, because someone actually tapped them.
Leave a Reply