Locksmith Scheduling and Dispatch Software: A 2026 Evaluation Framework

Locksmith Scheduling and Dispatch Software: A 2026 Evaluation Framework

Almost every scheduling product you will demo was designed for a salon, a dental office, or a barber shop. Someone picks a service, picks a 30-minute slot, and shows up at a fixed address that never changes. Then a vendor bolts on a map view, adds the word "field service" to the homepage, and sells it to you.

Your business does not work like that. Your appointment has a variable location, a variable duration, a drive time between it and the last job, a service radius beyond which it stops being profitable, and a caller who is standing in a parking lot at 9:40 PM asking how soon someone can get there. A 2:00 PM slot on a salon calendar is a 2:00 PM slot. A 2:00 PM lockout in a town forty minutes away is a decision about the whole rest of your day.

As of July 2026 there are more products chasing this market than ever, and the marketing language between them has converged to the point of uselessness. Every vendor says "smart scheduling," "real-time dispatch," and "seamless integrations." None of that tells you whether the software can do the one thing you need it to do on a Tuesday afternoon with three trucks out and a fourth call coming in.

This is not a list of vendors. This is the evaluation framework: the specific capabilities to test, the questions to ask in a demo, and the answers that should end the conversation. Run every product you consider through it, including the one you already pay for.

First, decide which category you are actually shopping for

Before you evaluate anything, get honest about which of three different things you are buying. Vendors blur this deliberately, because "scheduling" sells and "platform" scares people with the price.

A scheduling tool owns the calendar. It holds appointments, sends reminders, and often gives customers a booking link. It does not decide who goes where, and it usually does not know anything about your trucks.

A dispatch tool owns assignment and movement. It knows which tech is where, routes jobs, and tracks status from assigned to en route to complete. It usually assumes the job already exists, and it is not where a customer books.

A full field-service platform tries to own the whole job lifecycle: the call, the quote, the booking, the dispatch, the invoice, the payment, and the review request. It costs more and takes longer to set up, and if it is weak in one area you are stuck with the weak area.

	Scheduling tool	Dispatch tool	Full field-service platform
What it covers	Calendar, booking link, reminders, basic customer records	Tech assignment, routing, job status, live location	Call handling, quoting, booking, dispatch, invoicing, payments, reviews
Who it fits	One truck or two, mostly scheduled work, owner books everything personally	Shops with three or more trucks where assignment is the daily bottleneck	Shops where phone volume, quoting, and dispatch all compete for the same person
What it misses	No nearest-tech logic, no drive time, no live job status	No customer-facing booking, no quoting, often no price book	Depth in any one module, and setup effort is real
Typical failure	Board looks organized while techs drive across town for no reason	Great board that nobody answering the phone can see	Paying for six modules and only using three
What to test hardest	Drive time and duration modeling	Assignment logic and status accuracy	Whether the modules genuinely share one data set

Most locksmith shops that think they need scheduling software actually need dispatch logic, and most shops that think they need dispatch actually have a phone problem feeding a scheduling problem. Read the table above and pick your row before you take a single demo. If you want the broader category overview first, our page on locksmith management software lays out how the pieces relate.

Test 1: Does the calendar model a mobile job or a chair?

This is the single fastest way to disqualify a product. In the demo, ask the rep to book a job for you live, and give them a real one:

"Book a 2019 Honda Accord all-keys-lost at an address twenty-two miles from my shop, starting at 2:00 PM."

Then watch what the software does with three things.

Duration. Does it let you set a duration per service type, and can that duration be a range rather than a fixed number? An all-keys-lost push-to-start job is not the same length as cutting a spare. If every job on the board defaults to one hour because the product came from the salon world, your board is fiction by 11:00 AM.

Drive time. Does the system add travel to the job, or does it treat 2:00 PM to 3:00 PM as the whole commitment? A product that models drive time will show you a block before and after the appointment. A product that does not will happily let you book a 3:15 PM job across town after a 2:00 PM job that ends at 3:00 PM, and then act surprised when you are late.

Service radius. Can you define how far you will travel, and does the system flag or price a job that falls outside it? Mobile work has a profitability boundary. Software that treats every address as equally reachable is going to put unprofitable jobs on your calendar and let you find out later.

If the answer to all three is no, you are looking at a booking widget with a map on it. That is not necessarily useless, but price it accordingly. Our breakdown of scheduling built for mobile service work covers what these fields should look like when they exist.

Test 2: Nearest tech, or round robin?

Ask the rep directly: "When a new job comes in, how does the system decide which tech gets it?"

There are three answers, and only one of them is a real dispatch feature.

Round robin or manual means the software rotates through your techs or waits for you to drag the job onto someone. This is fine for one or two trucks. It is a daily tax on three or more, because the tax is paid in fuel and windshield time.

Skill-based means the system knows which tech can do which work. That matters more in this trade than in most, because programming a 2022 European push-to-start is not the same skill as rekeying a deadbolt, and sending the wrong truck means sending a second truck.

Location-based nearest-tech means the system knows where the trucks actually are right now and offers the closest qualified one. This requires live location, which requires the techs to have the app running, which requires you to enforce that. If the vendor promises nearest-tech assignment but has no live tech location, ask what "nearest" is measured from. Usually the answer is "their home address" or "the last job they were assigned," which is not the same thing at all.

The honest test question: "If my tech finishes early three miles from a new call, will the system know that before I do?" Systems with real GPS tracking on the dispatch board will say yes and show you. Systems without it will change the subject to route optimization.

Test 3: Emergency insertion into an already-booked board

Every locksmith evaluation should include this scenario, verbatim:

"It is 3:10 PM. My board is full through 6:00 PM. A lockout comes in eleven minutes away and the caller will pay the emergency rate. Show me what happens."

What you are testing is whether the product has any concept of priority. Most scheduling tools do not. They will let you create the appointment and drop it on top of an existing one, and the conflict is your problem to sort out mentally.

Good behavior looks like this: the system identifies which currently assigned techs are closest, shows you what each one is in the middle of, shows you what pushes if you insert the emergency, and lets you commit the change so that every downstream customer and tech sees the new times. Great behavior adds the notification automatically, so the 4:00 PM customer learns they are now 4:45 PM without you making a phone call while you are already dispatching an emergency.

This is where the difference between a calendar and a dispatch system becomes obvious. A calendar records that you double-booked. A dispatch system makes the tradeoff visible before you commit to it.

Test 4: The two-truck shop and the six-truck shop are different products

Vendors will tell you their product "scales." Push on it, because the failure modes are opposite at each end.

At two trucks, your problem is not assignment, it is coverage and visibility. You know where both trucks are because one of them is you. What kills you is the phone ringing while you are under a steering column, and the calendar living somewhere your helper cannot reach. A heavy dispatch product with role permissions, territories, and a configuration wizard will be abandoned inside a month because the setup cost exceeds the problem. What a two-truck shop needs is a shared board that is trivially reachable and something answering the phone. We wrote about this economics specifically for mobile locksmith operations.

At six trucks, your problem inverts. Now assignment is the bottleneck, tech accountability matters, and a single dispatcher becomes a single point of failure. You need territories or zones, you need per-tech skill flags, you need job status you can trust without calling the tech to ask, and you need to be able to see yesterday's board to settle a dispute about who was where.

Ask every vendor: "Show me your product configured for two trucks, then show me six." If they show you the same screen twice, one of those two shops is going to have a bad time. If they cannot show you six trucks at all, you have learned their real ceiling.

Test 5: What happens when a job runs long

Jobs run long. A ten-minute lockout becomes a broken key extraction. A key programming job becomes a dead battery and a jump start. This is normal, and it is where most scheduling software silently stops being accurate.

The question to ask: "My tech is 40 minutes past the scheduled end of a job. What does the system do on its own?"

The weak answer is "the tech can update the status in the app." That is not a system behavior, that is a hope. Techs with their hands inside a door panel do not update apps.

Better answers, in increasing order of usefulness:

• The board visually flags the overrun so the dispatcher sees it without hunting.
• Downstream jobs for that tech are automatically shown as at-risk.
• The customer whose slot is now in jeopardy gets a proactive message with a revised window.
• The system suggests a reassignment for the at-risk job to another qualified tech.

You will rarely find all four. Find out which ones exist, because the gap between them is a real amount of phone calls you will be making by hand every week.

Test 6: Does the customer ever get an automatic ETA?

An enormous share of "where is my tech" phone calls exist because nobody told the customer anything after the booking. Every one of those calls costs you a live interruption during your busiest hours.

Test it: "When my tech marks en route, what does the customer receive, and can I change the wording?"

Look for a text message that fires on the en-route status change, includes a realistic arrival window rather than a bare "on the way," and ideally includes the tech's name. Look for whether it fires automatically on status change or requires the dispatcher to press a button, because a button that must be pressed during a busy afternoon does not get pressed.

Then ask the harder version: "What does the customer get if the ETA slips?" This is where nearly everything falls down. Sending an initial ETA and then going silent when it moves is worse than sending nothing, because you have now made a promise you visibly broke.

Test 7: Can the person answering the phone see the board?

This is the failure that quietly wastes the most money, and it is the one almost nobody tests in a demo.

You buy a good calendar. You configure it. Your techs use it. And then a call comes in at 7:20 PM, the person or service answering your phone has no access to that calendar, and the only thing they can do is take a message and promise a callback. You now own a beautiful scheduling system that does not prevent a single callback, because the booking decision happens on the phone and the phone is not connected to the board.

Every layer of your business that talks to customers has to be able to read and write the schedule. Ask the vendor:

• Can a non-technical answering user see today's availability without seeing everything else?
• Is there an API or webhook that lets an outside answering layer create an appointment directly?
• If an appointment is created by that outside layer, does it appear on the dispatch board immediately, with the same conflict checking as an internally created one?

If the answer to the second question is no, your scheduling system is an island, and your phone will keep generating callbacks no matter how good the calendar is. This is exactly why a modern ai receptionist for locksmith services is evaluated together with the calendar rather than separately: the answering layer and the schedule are one workflow, and splitting them across two disconnected products reintroduces the callback you were trying to eliminate.

Test 8: Double-booking prevention that actually blocks

"Does it prevent double-booking?" gets a yes from everyone. Make them prove which kind of yes it is.

There are three levels:

1. Visual only. Overlapping jobs look different on the board. Nothing stops you.
2. Warning. The system tells you there is a conflict and lets you continue.
3. Hard block with override. The system refuses the booking through the customer-facing and API paths, and only an authorized user can force it.

Level 3 is what you want, specifically on the paths you do not control. You can train yourself not to double-book. You cannot train a customer using a booking link at midnight, and you cannot train an external system creating appointments over an API. The conflict check has to live in the server, not in the interface.

Ask this: "If two customers open my booking link at the same second and both pick the 3:00 PM slot, what happens?" A product with real server-side conflict checking will describe a lock or a rejection. A product without one will say "that has never come up."

Test 9: Reschedule and cancellation, from the customer's side

Reschedules are more common than cancellations and far more valuable, because a reschedule keeps the revenue. Yet many products treat rescheduling as cancel-then-rebook, which loses the job history, loses the quote, and frequently loses the customer.

Test the full path:

• Can the customer reschedule themselves from the confirmation message, or do they have to reach a human?
• Does a reschedule preserve the original quote, vehicle information, and notes, or does it create a fresh empty appointment?
• Does the tech's app reflect the change without them refreshing or being called?
• Is there a cancellation reason captured, and can you report on it later?
• Does the freed slot become visible to the booking path immediately?

That last one matters more than it sounds. A 2:00 PM cancellation on a busy Saturday is a slot you can sell again in the next twenty minutes if the system releases it. If the slot only frees up after a manual cleanup, you sold nothing.

Test 10: The integration question, or how you find out it is an island

Save this for last, and ask it plainly: "Does this product have a documented public API and outbound webhooks, and can I see the docs right now?"

The reaction tells you more than the answer. Vendors with a real API will send you a link during the call. Vendors without one will describe a roadmap.

Here is why it decides the purchase. Your schedule does not live alone. It needs to connect to at least three other things:

Whatever answers your phone, so bookings happen live instead of becoming callbacks. Whatever quotes your work, so the price the customer heard on the phone is attached to the job the tech sees. Whatever takes money, so a deposit on an all-keys-lost job is tied to the appointment rather than tracked in someone's texts.

If those connections do not exist, you get the classic four-system shuffle: the call happens in one place, the quote is written on paper, the job is typed into the calendar by hand, and the payment link is sent from a phone. Every handoff is a place to lose a job. The specifics of wiring a calendar to call handling and payments are covered in our guide to integrations, APIs, and webhooks between an answering layer and your calendar.

A useful follow-up: "When an appointment is created, updated, or canceled, can you send a webhook to a URL I control?" Outbound webhooks are how you keep a second system honest without polling it. A product with inbound API but no outbound events forces every other tool you own to guess.

How to run this evaluation in one week

You do not need a two-month procurement process. You need five focused sessions.

Day 1. Write down your real numbers: trucks, average daily jobs, share of same-day and emergency work, average ticket, and how many calls per week currently end in a callback. Every decision below is scored against those numbers, not against a feature list.

Day 2 and 3. Demo two or three products. Bring the same three scenarios to each one: the twenty-two-mile all-keys-lost, the 3:10 PM emergency insertion, and the job that runs 40 minutes long. Do not let the rep drive the demo with their own happy path.

Day 4. Ask each vendor for API documentation and a sandbox. Give it to whoever handles your technical work for an hour. An hour is enough to tell whether an API is real.

Day 5. Score them on the ten tests above, weighted for your shop. A two-truck operation should weight tests 6, 7, and 10 heaviest. A six-truck operation should weight 2, 3, 4, and 5.

Then price it against the alternative. Software that costs a few hundred dollars a month is cheap if it converts one additional job a week and expensive if it converts none. If you want a concrete anchor for what an integrated answering-plus-scheduling layer costs, our pricing page lists the plans in full rather than hiding them behind a form, and the automotive locksmith software overview shows what is bundled into each.

The bottom line

The scheduling and dispatch products aimed at locksmiths mostly fail in the same two places: they model a fixed-location appointment instead of a mobile job, and they sit on an island that whoever answers the phone cannot reach.

Test for those two things first. Make a vendor book a real all-keys-lost twenty-two miles out and show you the drive time. Make them insert an emergency into a full board. Then ask for the API docs on the call. Three questions, and most products will separate themselves before you have finished the demo.

Everything else on the list matters, but it matters second. A perfect calendar that your phone cannot write into is a filing cabinet. A dispatch board that does not know where the trucks are is a spreadsheet with colors. Buy the one that closes the loop from a ringing phone to a truck in motion, and be skeptical of anything that only handles the middle of that loop.

Frequently asked questions

What is the difference between locksmith scheduling software and dispatch software?

Scheduling software owns the calendar while dispatch software owns assignment and movement. A scheduling tool holds appointments, sends reminders, and often provides a customer booking link, but it usually does not decide which technician goes where or track them once they leave. A dispatch tool assigns jobs to the nearest qualified tech, routes them, and tracks status from assigned through complete, but it typically has no customer-facing booking and no price book. Shops with three or more trucks usually need both.

What should I test first when evaluating locksmith scheduling software?

Test whether the calendar models a mobile job rather than a fixed chair appointment. In the demo, make the vendor book a real scenario such as an all-keys-lost job twenty-two miles from your shop, then check whether the system accounts for drive time before and after the appointment, allows a per-service duration rather than a default slot, and flags addresses outside your service radius. A product that fails all three is a booking widget with a map, not dispatch software.

Can locksmith dispatch software assign jobs to the nearest technician?

Some can, but only if the system knows where your trucks actually are right now. Ask the vendor what nearest is measured from, because many products calculate distance from a tech home address or their last assigned job rather than live location, which produces the wrong answer whenever a tech finishes early or gets rerouted. Real nearest-tech assignment requires live GPS on the dispatch board plus skill flags so the closest tech is also qualified for the work.

Does my scheduling software need an API?

Yes, if you want phone calls to turn into booked jobs instead of callbacks. The most common expensive failure is a well-configured calendar that whoever answers your phone cannot read or write, so every after-hours call still ends in a message and a promise to call back. Ask each vendor for public API documentation and outbound webhooks during the demo, and treat a roadmap answer as a no. Details on wiring a calendar to call handling and payments are at https://www.thekeybot.com/blog/ai-receptionist-integrations-crm-calendar-stripe.

How much does locksmith scheduling and dispatch software cost?

TheKeyBot bundles answering, quoting, scheduling, and dispatch into flat monthly plans: Core is $500 per month for 500 AI minutes with 45 cents per minute overage, Pro is $750 per month for 1,000 minutes at 40 cents overage, and Elite is $1,200 per month for 2,500 minutes at 35 cents overage. Standalone scheduling tools are cheaper but leave the phone, the quote, and the payment on separate systems. Full plan details are at https://www.thekeybot.com/pricing.

Is a full field-service platform worth it for a two-truck locksmith shop?

It depends on whether your bottleneck is assignment or coverage. At two trucks you usually know where both are because one of them is you, so a heavy dispatch product with territories and permissions gets abandoned once setup effort exceeds the problem it solves. What a two-truck shop actually needs is a shared board that is trivially reachable and something reliably answering the phone while both trucks are on jobs. Weight the answering and integration tests heaviest at that size.

Sources

1. U.S. Bureau of Labor Statistics - occupational and employment data for locksmiths and related security service trades: https://www.bls.gov/
2. Associated Locksmiths of America - industry standards, training, and professional practice resources: https://www.aloa.org/
3. Google Local Services Ads - guidance on responsiveness, lead handling, and provider ranking: https://support.google.com/localservices