Locksmith Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a locksmith build turn into a second system nobody enters jobs into?

The scope failure that shows up most often is treating the project as a replacement when it should be a layer. Your shop already runs Housecall Pro or ServiceTitan. Payroll depends on it, your accountant reads it, and your techs have been tapping the same three buttons for years. Then a new platform arrives with a live dispatch board and a phone agent, and nobody ever wrote down which of the two systems is the truth.

This bites locksmiths harder than most trades because your job mix is wide. A residential rekey, a car lockout, a commercial master key install and a safe opening all invoice differently, and the moment one of those cannot be written back into the incumbent, someone starts keying it in by hand. Within weeks half your jobs exist in one system and half in both.

The fix is a decision made in week one and written into the statement of work: name the system of record, and require that every job the new build creates lands in it through the application programming interface, not through a person. Then test the awkward cases early. If the incumbent cannot accept a job type, a multi-site commercial account or a deposit on a safe job, you want that discovered in week two while the plan can change, not in month five when the office is already retyping. Ask your developer to demonstrate a full round trip on your worst job type before any of the pretty screens get built.

What goes wrong when you migrate six years of customer and job history?

Locksmith history does not migrate cleanly because the thing you actually sell against is the property, and almost no field service database models it. Your record says Marcy Ortega, one phone number, one billing address. In reality she manages nine buildings, and the rekey cycle that is worth real money next year belongs to the buildings, not to Marcy. Migrate her as one customer row and the nine sites disappear.

The second problem is that your most valuable data is sitting in free text. Key codes, bitting, master key chart references, safe combinations, key blank numbers and vehicle details have been typed into note fields by a dozen different people over six years, in a dozen different formats. A migration that copies notes across preserves the characters and destroys the usefulness, because you still cannot ask which accounts are on a five year rekey cycle.

Do three things. Model the site or property as a first class record with its own history, separate from the billing customer. Run structured extraction over the note fields to pull codes, chart references and vehicle details into typed columns, with a human reviewing anything the extraction is unsure about, because a wrong bitting is worse than no bitting. Then reconcile on value, not on row count. Counting that 41,000 records moved proves nothing. Pick your fifty largest accounts and confirm their sites, balances and key records by hand before cutover.

Treat the key data as the security asset it is. Codes and combinations need role based access, an audit log that records reads as well as writes, and a rule that a phone agent transcript never contains a combination. If a developer treats that as a later phase, that tells you what you need to know.

Why do integrations with Housecall Pro and ServiceTitan break after launch?

They rarely break on day one. They break in week six, quietly, and you find out when a customer calls about a job that was never invoiced. Three causes account for most of it. Rate limits, because a nightly sync that was comfortable at 40 jobs a day starts getting throttled at 90 and drops the tail. Field drift, because someone in your office adds a new job type or a new price book entry in the incumbent's own interface and nothing in the new system knows the name. And token expiry, because refresh handling was written for the happy path.

There is a fourth that catches locksmiths specifically. The read surface of these products is generally more workable than the write surface, so a build reads jobs and customers fine and struggles to push back the things you care about, such as a job with a deposit, a multi-technician assignment or a line item that maps to no existing service.

The fix is unglamorous and it is the difference between a system that survives and one that does not. Writes go through an outbox with retry and idempotency keys, so a repeated attempt cannot create a duplicate job. A nightly reconciliation compares both sides and puts every difference into a queue a human clears, rather than into a log file nobody reads. Failures alert a named person, not a channel. And you keep a contract test that fails loudly the day a field mapping stops matching. Ask any developer what happens when the incumbent returns an error on a job write at 2am, and listen for whether the answer involves a person.

What happens when on-call rotation and service area rules are not covered?

This is the gap that turns a working phone agent into a liability. The agent answers at 1am, sounds excellent, and books a lockout 55 minutes outside your area for a price band that does not cover the drive. Or it books an automotive job to the truck that carries safe tooling. Or it wakes a tech who swapped out of the rotation on Thursday in a WhatsApp thread the system never saw.

Every one of those is a comped job and a bad conversation, and each one happens because the rules that live in your dispatcher's head were treated as configuration to add later. Service area is the classic example: a radius on a map is not your service area, drive time is, and a river or a toll bridge makes the two wildly different.

Cover it explicitly in the first release. Service area as drive time from the on-call tech's start point, not a circle. On-call rotation as dated records with a named escalation if the first tech does not accept inside a set number of minutes. Job types tied to required equipment, so an automotive key programming job cannot route to a truck without the gear. Price bands per job type per zone, with the agent quoting a band rather than a number.

Then give the agent permission to decline. A booking it should not take becomes a captured callback with the caller's number and job type, and that declined list is the most useful report the system will produce in year one, because it tells you exactly where the demand you are turning away actually sits.

Should you build custom or configure what you already own?

If you run one or two trucks, do not build. Housecall Pro is a good product and at that size the scheduling, invoicing, price book and automated reminders it gives you are more than you are currently using. In most shops we have looked at, features that are already paid for have never been switched on: per job type pricing, online booking, the automated review request, the recurring commercial reminder. Turning those on costs a weekend and no capital.

The honest middle option deserves naming too. A human answering service, briefed with a one page script, your real service area and a price sheet, with instructions to send you a text on anything commercial, will close a good part of the after-hours gap for a fraction of a build. It is worse than a proper agent. It is available on Monday.

Build when the pain is measurable in hours and missed jobs rather than in frustration. Multiple crews with dispatch on a whiteboard. Thousands of past customers nobody has contacted. Commercial estimates going out and never being chased. Several acquired shops running on different tools. And even then, keep the incumbent as the system of record and build the phone agent, the follow up engine and the dispatch logic against it. Replace the customer relationship management (CRM) tool only when it physically cannot hold what you need, not because it looks dated.

How do hidden costs get into the quote?

The build number is usually the honest part. What gets left out is what the thing costs to run. A voice agent consumes telephony minutes, speech recognition and model calls on every single call, including the wrong numbers and the hang ups, and that bill scales with your busy season rather than sitting flat. Ask for the run cost per thousand calls and ask what it looks like if volume triples in a storm week.

Four more that get omitted routinely. Migration reconciliation, which is days of somebody comparing accounts by hand and is a line item, not a script. Parallel running, where both systems are live and your office does more work for a few weeks, not less. On-call developer support through the first month, because the failures that matter happen at 2am. And number porting, which is administratively slow and sits on the critical path.

Then the trade specific one. If you run automotive, residential, commercial and safe work, you have four sets of dispatch and pricing rules, not one, and a quote that prices a single rule set is either optimistic or is planning to charge you for the other three as change requests. Ask for the price of the second and third trade in writing at the start, along with the consent line, retention policy and audio storage that call recording obliges you to run.

What separates a locksmith build that works from one that fails?

Four things, and none of them is technology choice. The first is that somebody on the development side rode along on a truck before writing code. A team that has watched a tech open a car at 11pm and seen how the dispatcher actually decides who goes where builds different software from a team that read a requirements document.

The second is that the phone agent was tested on genuinely bad audio before anyone signed. Your callers are outdoors, stressed and often inside concrete. A demo recorded in a quiet office proves nothing about the only conditions that matter.

The third is sequencing. Ship the after-hours agent first, on its own, and measure one number weekly: after-hours calls answered and booked. If that number moves, everything after it is easier to fund and easier to argue for internally. Builds that try to launch dispatch, quoting, follow up and invoicing together tend to arrive months late with nothing yet proven.

The fourth is ownership, settled in writing before kickoff. You hold the source code, the customer and key data, the phone number and the trained voice agent, and you can hire anyone else to continue the work. Ask a candidate directly what happens to all of it the day you walk away, and agree the kill criteria in the same conversation. If after-hours bookings have not moved by a defined number after eight weeks live, what changes. A team willing to write that down with you is a team that expects the thing to work.