Field-service software is bought in a demo and lived in for a decade, and demos are built to sell. This is the checklist we would hand a friend walking into one: vendor-neutral, including questions where our own answer today is a stage on a roadmap rather than a shipped feature. It is meant to be useful even if you never buy from us.
Every question follows the same pattern: turn a claim into something you can verify in the room, on your own numbers, before you sign.
Price you can compute yourself
A posted price is one you can compute for your shop tonight without talking to sales. If the pricing page says contact us, the price is whatever the rep thinks you will pay, and next year's price is whatever the renewal rep thinks you will tolerate.
Run the per-seat math at the size you plan to be, not the size you are. A per-seat product priced for your five people gets renegotiated by hire number eight, which means the vendor collects a tax on your growth. Per-company pricing avoids that particular tax, but read what sits outside the flat number (extra locations, metered usage, implementation), because those can be honest line items or a second price hiding behind the first. Either way, make the vendor put the whole model in writing.
- Can I compute my total monthly bill for ten people from your public pricing page alone?
- What did your last price increase look like, and how did existing customers find out?
- Which behaviors are metered, at what posted rates, and where do I see usage before the invoice arrives?
The export you run yourself
Every vendor says you own your data. In the demo, make them prove it: ask to run a full export yourself, from the settings screen, while you watch: customers, jobs, invoices, notes, photos. Note the format, note whether the export contains attachments or just rows, and note whether it took a support ticket. An export that requires the vendor's help is an export the vendor controls, and you will need it most on the day the relationship is worst.
Then ask the uncomfortable version: what does leaving look like. How long does the account stay readable after you cancel, what does the export cost on the way out, and can they name the process a departed customer actually followed. A vendor with a good answer will not flinch at the question.
The demo shows you what joining looks like; make it also show you what leaving looks like.
The phone, the roadmap, and the fine print
Ask whether the phone system is included or an add-on, because the answer decides your intake. If calls live in a separate product, every booking starts with re-typing, and the integration doing the gluing is the first thing that breaks on a busy morning.
Ask whether the vendor publishes a roadmap and a changelog. A public roadmap is a vendor betting its credibility on its plans; a private one is a rep saying it is coming about whatever you ask for. Then ask about implementation: what it costs, who owns the data migration, and what the plan is for the weeks your team runs two systems in parallel, because there will be such weeks.
The checklist, in one place
- Compute the real monthly bill from public pricing, at next year's headcount, usage included.
- Per-company or per-seat, in writing, and what hire number eight does to the bill.
- Run the export yourself in the demo. Check that it carries attachments, not just rows.
- Get the exit terms in writing: how long the data stays readable after cancellation, and what the final export costs.
- Phone included or bolted on, and if bolted on, where a booked call gets typed twice.
- A public roadmap and changelog, or a rep saying it is coming.
- Implementation cost, migration ownership, and the parallel-run plan, in the proposal itself.
For symmetry: we publish our price and our roadmap, but we are a waitlist-stage product still finishing the core loop, and some of what this checklist demands we are still building. Ask us these questions too, and hold every vendor, us included, to the checklist rather than the demo.