Software that sends the nearest tech, and keeps every keycode behind a named role.

Locksmith software is the system a locksmith firm uses to run the work in one place instead of phone calls, paper job cards, and memory. It covers taking the call, sending a technician, recording the work and the parts used, holding the key and master key records for each site, and raising the invoice, so the next person to touch that customer can see what was done and when.

It is the firm's locked notebook of key information, kept in software instead of a book or spreadsheet. For each site it holds the keycodes, which are the numbers that let a correctly cut key be reproduced, the master key charts, and the list of keys issued. Only the roles you name can open it, and the audit log, which is simply the written record of who opened what and when, keeps every view. If a code is ever questioned, the log answers who saw it.

The call is logged once with the address, the lock type, and how urgent it is. The dispatcher sees where each van is and who is free, then assigns the nearest available technician with the right skill for that job, whether that is a car lockout, a residential entry, or a commercial door. The customer gets an arrival window instead of a guess, and when a job runs long or a second emergency lands, the board is reshuffled and the technician is told at once, not left working from an old plan.

Each system is recorded once, as one structured record: the levels of the system, from the master key down to the individual doors it opens, which keys have been cut, who holds each key, and which keys have been returned or reported lost. When a property manager asks what was rekeyed on the last visit, or which keys open a floor, the answer comes from that record instead of from scattered notes and a technician's memory.

Only the roles you name. A dispatcher might see that a site has a key record without seeing the codes inside it. A senior technician on that site's work can open the record for the job in hand. Everyone else sees nothing. The enforcement is in the software, not in a promise: access is checked on the server, where it cannot be talked around, and every view, change, and key issued is written to the audit log with the person and the time.

The record is updated the moment you hear about it: the key is marked lost, the holder list changes, and the system can show every door and site that key could open, so you and the customer can decide what needs rekeying. When a technician leaves, their access to the register ends with their account, and the log still shows what they viewed while they worked for you. That is the difference between a controlled system and a spreadsheet that left on a laptop.

Before entry work starts, the technician records how the caller's right to the property was checked: the identification shown, the person who authorised the work, and photographs where the job needs them. That record sits on the job card with the work done and the parts fitted. If the job is questioned weeks later, by the customer, a property manager, or an insurer, the check can be shown instead of reconstructed from memory.

Blanks, cylinders, locks, and hardware are tracked as stock: received, issued to each van, and used on a job. When a technician fits a cylinder, it comes off that van's count and onto the job card, so the job cost is a record, not a guess. Common sizes carry a reorder level, and the alert appears before the van runs out mid-call, not during the call.

They sit on one schedule. Commercial contracts hold their visit dates, key audits, and renewal dates beside the emergency call list, so a dispatcher sees the planned visit before sending the only free technician across town. When an emergency genuinely takes the technician, the visit is moved deliberately and the customer is told, instead of being silently missed and discovered at renewal.

Yes, and that is where the margin is protected. The technician prices the rekey, the hardware swap, or the lockout from the firm's own price list on the job, shows the customer the figure before the work starts, and takes a card payment before leaving. The quote the customer accepted is kept on the job record, so the figure quoted and the figure invoiced are the same figure, with no argument about what was said on the phone.

Field service products that locksmiths run are usually priced per user per month. ProHelper, the platform we checked first-hand while writing this page, lists locksmith plans from $35 per user per month with a 30-day free trial and no credit card required; confirm current pricing on the vendor site before you budget, because plan names and what each plan includes change. Price the dispatch board and route features separately, as products often place them on higher plans.

First phases start at $10000 for a bounded audit, proof of concept, or small first release. A full first release is a larger engagement: our build vs buy guide for locksmith firms puts a first release covering dispatch, GPS tracking, dynamic pricing, a technician mobile app, and on-site payment at $80K to $140K over 10 to 14 weeks. The key register and master key records are scoped on the call, because their access rules and history decide the shape. Read the full breakdown in our guide to building locksmith management software.

Buy a product when your work is the standard shape: emergency calls, booked rekeys, quoting at the door, and card payment are well served by maintained field service products. Own custom software when the product keeps forcing workarounds: your key register and master key records need access rules no product offers, your pricing rules are yours and the product cannot hold them, you run enough technicians that dispatch and pricing break the product's model, or commercial accounts need records the product will not keep. If the rules of the operation are still changing every week, wait and settle them first.

It should be designed to. Locksmith work happens in parking garages, basements, and stairwells where the signal drops. The app should hold the job, the site record the technician is allowed to see, and the photos on the phone, then send everything when the signal returns, with a clear state for what is saved, what is waiting, and what failed. That behaviour belongs in the first release, not on a later list.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start. Send a test lockout to the board. Open a key record with the wrong role and confirm it stays shut. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

We need one person who owns the workflow, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.