Most software disasters in small service businesses start the same way: buying the platform before writing down what it needs to do.
TL;DR Write the requirements first. Test the field experience before the office one. All-in-one is right for most businesses under twenty staff. Migrate clean data or the new system inherits the old mess.
Write requirements before you look at anything
Two hours of writing saves a year of regret.
Answer these, honestly, from how you actually work
- How many jobs a week, and how many are same-day?
- How many people need to see the schedule?
- Do technicians work in areas with poor signal? This one is decisive.
- Do you invoice from site or from the office?
- Do you need parts and stock tracking, genuinely?
- Recurring contracts or one-off jobs, or both?
- What must it connect to? Accounting, payments, phone system.
- What are you doing on paper today that you want to keep doing on paper?
Mark each as must-have or nice-to-have. Vendors sell to nice-to-haves. You need the must-haves to work.
The categories
| Category | What it covers | Who it suits |
|---|---|---|
| Field service management | Scheduling, dispatch, job records, mobile app, invoicing | Most trades. The default |
| General CRM | Contacts, pipeline, marketing | Sales-heavy, quote-heavy businesses |
| All-in-one marketing platform | CRM plus email, SMS, funnels, automation | Businesses where marketing is the bottleneck |
| Accounting-first | Invoicing and books with light job features | Very small operations |
Most service businesses need field service management as the core, with everything else attached to it.
All-in-one or best-in-breed
Under roughly twenty staff: all-in-one, nearly always.
Why
- One system to learn, one to administer.
- Data lives in one place, so reporting works without integration work.
- One vendor to chase when something breaks.
- Integration maintenance is a job nobody at your size has time for.
Best-in-breed makes sense when
- One function is genuinely specialised and central to your business.
- You have somebody responsible for the systems.
- The all-in-one option is materially worse at the thing you do most.
The honest trade-off: all-in-one is worse at everything and better overall, at small scale.
Test the field experience first
This is where implementations fail, and it is almost always tested last.
Trial checklist, done by an actual technician on an actual job
- Does it work with no signal? Offline mode that genuinely queues and syncs, not a spinner.
- How many taps to complete a job? Count them. Over about fifteen and it will not get used properly.
- Photo upload. Fast, and does it compress sensibly on mobile data?
- Can they see the customer history without leaving the job screen?
- Battery drain over a full day.
- Does it work with cold hands and gloves? Not a joke. Small touch targets fail in real conditions.
If the technicians hate it, the data will be wrong, and everything downstream depends on that data.
Integration bridges
For the connections the platform does not offer natively.
Tools like Zapier or Make connect systems without code. Useful and genuinely powerful.
Caveats worth knowing before you build on them
- They break silently. Build a failure notification, or you will find out from a customer.
- They cost more at volume than the plan you sign up on.
- They add latency. Fine for a follow-up email, not for anything time-critical.
- Every bridge is a thing to maintain, indefinitely.
Rule: prefer a native integration even if it is slightly worse. Fewer moving parts wins over years.
Data cleanliness
Migrating bad data into good software produces bad software.
Before you migrate
- Deduplicate. Same customer under three spellings and two phone numbers.
- Standardise phone formats. This breaks SMS and click-to-call otherwise.
- Delete the genuinely dead. Contacts with no activity in five years and no service history.
- Fill the fields you will filter on. Acquisition source, customer type, service type. Retrofitting these later is painful.
- Decide what not to bring. History from a system you barely used is clutter.
Set the rules for the new system on day one. Required fields, naming conventions, who can create records. Systems degrade from the first week if nobody sets standards.
Evaluating vendors
Ask these
- What does export look like? Get a straight answer. Difficulty leaving is a real cost.
- What does it cost at double our current size? Per-user pricing scales unpleasantly.
- What is included versus an add-on? Especially SMS, payments and reporting.
- Where is support based and what are the hours? If your emergency is at 6am, their 9-to-5 support in another timezone matters.
- How often does the mobile app get updated?
Talk to a business your size in your trade. Vendor reference customers are chosen for a reason. Find your own through a trade group.
Migration
Run parallel for two to four weeks. Painful, and cheaper than a failed cutover.
Sequence
- Configure and test with a small dataset.
- Train the office team.
- Train the field team, on site, with real jobs.
- Migrate the data.
- Run both systems briefly.
- Cut over, with the old system readable for a year.
Pick a quiet period. Migrating during peak season is a decision people regret specifically and loudly.
Write your must-have list this week, before you book a single demo. Every bad software purchase in this industry traces back to skipping that document.
Need a pro to choose it? [BOOK A CALL]