Field service software categories have converged to the point where the marketing is nearly interchangeable. Scheduling, dispatch, routing, mobile app, invoicing, customer portal. Every vendor has the list. The lists do not distinguish the products.
The real differences sit one layer below, in mechanics that rarely appear on a pricing page. These twelve questions are designed to surface them. Ask them of every vendor you are considering — including us.
On travel and feasibility
1. What position do you compute travel time from?
The single most revealing question. Listen for whether the answer is a place or a place at a time.
Weak answers: from the depot, from the technician's home address, from a stored distance between two addresses. All of these are wrong by mid-morning, because where a truck will be at 2:00 p.m. is determined by the day's schedule, not by where it started.
Strong answer: from the location of the preceding job, at the hour that job is expected to end.
2. Does travel time vary by time of day?
The same twelve miles is a different drive at 7:00 a.m. and 4:30 p.m. A system storing one duration per address pair is wrong at both ends of the day, and the error compounds across a shift.
3. When is feasibility checked — before the slot is offered, or after it is booked?
This is the category distinction. A system that validates after booking tells you about problems. A system that checks before offering prevents them. Both may be described as "drive-time aware."
Ask to see the moment of truth: show me the availability screen, and show me a time that does not get offered because the drive does not fit.
4. What happens when a job overruns?
Every day breaks somewhere. Ask what the system does at 11:40 when the 10:00 is still running. Does it flag the downstream jobs that are now at risk? Suggest a reassignment? Or does it simply display a schedule that is no longer true?
On the data underneath
5. Can service duration vary by service type?
If every appointment is a uniform block, every downstream calculation is built on a guess. Ask whether durations can be set per service, whether they can differ by technician skill level, and whether the system learns from actual completion times.
6. What exactly is stored per job?
Ask for the event-level detail: dispatched, arrived, work started, work complete, departed. Without those timestamps you cannot compute productive utilization or real travel, which means you cannot measure whether the software helped.
7. Can I get my data out?
Ask specifically: full export, including job-level timestamps, in a documented format, without a support ticket. The answer tells you how the vendor thinks about the relationship.
On people and permissions
8. What can each role see?
You will eventually have employed technicians, possibly subcontract crews, office staff and field managers. Ask what each role sees by default and what is configurable. Specifically: can a crew see the jobs assigned to them without seeing your full customer list or your pricing?
9. How does the mobile experience behave with no signal?
Residential service means basements, rural roads and dead zones. Ask what happens when a technician completes a job offline, and when the data reconciles.
On the commercial reality
10. How does pricing scale — and with what?
Per user, per technician, per job, per truck? A model that charges per seat punishes you for giving office staff access; one that charges per job punishes growth. Neither is wrong, but model it against your next two years, not today.
11. What does implementation actually require from us?
The honest version of this answer includes your effort, not just theirs. Service durations have to come from somewhere. Territories have to be defined. Someone has to clean the customer list. A vendor who says "we handle everything" is either doing a shallow setup or has not thought about it.
12. Can I run a week of my own historical jobs through it?
The best evaluation test there is. Take a real week you have already completed, schedule it in the candidate system, and compare: how many jobs did it place, how much travel did it plan, and how does that compare to what actually happened?
A vendor confident in their engine will say yes. This single test is worth more than three demos.
Applying this to us. CrewLink is built around the answer to question 3 — feasibility checked before a slot is offered, with travel computed from where the truck will actually be. That is a deliberate design choice, not a claim of exclusivity: several established platforms offer forms of travel-aware availability. Ask us questions 1 through 12 the same way you ask everyone else, and ask for the historical-week test.
Two traps worth naming
The suite trap. Consolidating quoting, scheduling, invoicing and payments into one vendor is genuinely valuable. It is also how companies end up with a scheduling layer nobody would have chosen on its own. If scheduling is your actual constraint, evaluate it on its own merits and then decide what integration you need — rather than accepting whichever scheduler came attached.
The demo trap. Demos run on data built to make the product look good: tidy territories, uniform durations, no emergencies. Your Tuesday does not look like that. Insist on your own data, or at minimum bring three genuinely awkward scenarios — the job at the edge of the territory, the emergency that displaces a booked afternoon, the customer who will only accept a narrow morning window.
Before you evaluate anything
Decide what you are trying to fix, in numbers. If you cannot state the problem as a measurement, no software will prove it solved it.
Most companies looking at scheduling software have one of three problems: crews are productive far less of the shift than they are booked; the day does not survive contact with reality; or nobody can see what capacity actually exists. Those look similar from the inside and want different answers.
Measure productive utilization and travel share for two weeks first. Then go shopping. The evaluation will be faster, the demos will be sharper, and you will know within a month of implementation whether it worked.
What to take away
- Feature lists have converged; the differences live in mechanics that are not on the pricing page.
- The highest-signal question is what position travel is computed from — a place, or a place at a time.
- Ask whether feasibility is checked before a slot is offered or after it is booked. Both get described as "drive-time aware."
- Insist on running a real week of your own historical jobs through any candidate system.
- Do not inherit a scheduler because it came attached to a suite you bought for other reasons.
- Measure your baseline before evaluating, or you will not be able to tell whether the purchase worked.
Common questions
What should I look for in field service scheduling software?
Look past the feature list at four mechanics: what position travel time is computed from, whether feasibility is checked before a slot is offered or after it is booked, whether service durations can vary by service type, and what the permission model allows you to scope by role. Those four determine whether the schedule holds together.
What is the difference between FSM software and scheduling software?
Field service management suites cover the whole job lifecycle — quoting, scheduling, invoicing, payments, customer records. Scheduling-focused tools concentrate on building the board. Many companies run a suite and find the scheduling layer is the weakest part of it, which is the usual reason for looking at a dedicated approach.
How long should a field service software evaluation take?
Long enough to run your own data through it. A demo on vendor sample data proves nothing about your territory, service durations or job mix. Ask to schedule a real week of your own historical jobs and compare the result against what actually happened.