The short answer
A CRM for service technicians is judged on a phone, in a driveway, with one bar of signal and cold hands, and almost nothing about that situation shows up in a sales demo. The office evaluates dispatch boards, reporting and invoicing. The technician evaluates whether the form survives a lift ride. Those are different products being judged by different people, and the person with the budget only ever sees one of them.
That gap is not a theory. It is the top-rated comment on a 143-upvote r/HVAC thread about a major platform's mobile release, from a technician who has used several systems:
"I'm fully convinced that none of these service trackers actually give a shit about the mobile, technician-end experience. I've used several, and the mobile apps are always hot garbage. They only focus on the desktop experience because the office people are who buy them."
Seventy-five technicians upvoted that. If you are searching for a CRM for service technicians, the useful question is not which platform has the longest feature list. It is which one survives contact with the field, and how you would find that out before signing a multi-year contract.
Why the demo cannot tell you
Every vendor guide in this category publishes the same five features: scheduling and dispatch, mobile access with offline mode, work order management, customer service history, and route optimisation. That list is accurate and completely useless for prediction, because every serious product ticks all five. The differences that decide adoption sit one level below the checkbox.
Take the second item. "Mobile access with offline mode" appears in essentially every buyer's guide for field service software as a single bullet, usually phrased as keeping staff productive regardless of connectivity. It reads like a binary. It is not.
Watch out
Offline mode is a spectrum, and the vendor's own documentation is where the spectrum is written down. Microsoft publishes a page titled "Best practices and limitations for the offline profile" for Dynamics 365 Field Service. It states that Field Mapping is not supported offline, that inventory validation does not run without connectivity, that access to SharePoint documents is not supported, that knowledge articles may download but cannot be viewed offline, and that the Export to PDF option is not available while the app is offline.
It goes further. Some tables, including Purchase Order, Agreements, return to vendor and return merchandise authorization, cannot be used offline at all, and Microsoft warns that adding them to the offline profile may produce errors for users. The offline profile supports a maximum of 15 linked tables including downstream relationships. Power Automate flows only run when the device has a network connection or on the next sync, so any business logic built that way simply does not fire in a basement.
None of that is a criticism of Microsoft. It is the opposite: Microsoft is one of the few vendors that documents its limits in public, in detail, and even advises administrators to configure offline capability even if they believe their technicians always have a reliable connection. The problem is that most of the market does not publish an equivalent page, and a demo answers "does it work offline?" with a yes.
There is a subtler trap in the same document. Tables using the "Related rows only" filter inherit the parent table's filter, so if work orders are restricted to Scheduled status, related accounts and contacts are limited to records linked to those work orders. Microsoft explicitly warns that this cascading behaviour "can unintentionally restrict data visible to technicians." That is how a technician ends up on site unable to see a customer record that definitely exists, concludes the app is broken, and stops trusting it.
The failure modes technicians actually report
Feature comparisons are written from the office. Here is what the field says, drawn from three public threads where technicians and their supervisors describe daily use of the market-leading platform.
Forms that erase themselves. One technician, at 23 upvotes: the app "erases a form I'm working on at least once a day, just restarts itself whenever it wants." A field supervisor described worse: "My guys will do the summary and other forms and they just disappear. I used it two weeks ago and when I went into the history the whole job was missing and when the office did find the job my summary, photos and everything else was missing."
Jobs that cannot be closed where the work is. Another technician listed the pattern precisely: "Buffering time as you add in information, inability to close/dispatch in bad service areas, when it wipes my page clear and refreshes." This is the offline gap showing through in the exact place it matters.
Re-authentication at the worst possible moment. At 12 upvotes: the app "always seems to want me to enter my username and password at the worst possible time, and that always requires a password reset at the worst time." A password reset in a crawlspace is a job that gets written on the back of an invoice and typed in later, or not at all.
Photos that do not survive. Two separate complaints, years apart. Zooming into photos crashes the app, "and has been like that for years." And from a ten-year user: "some pictures are compressed and you can't make out any of the information." For anything warranty-related or dispute-related, an unreadable photo is the same as no photo.
Batteries that do not last a shift. "The battery in the iPad would be dead long before my shift was over." Nobody tests this in a one-hour demo on a fully charged device sitting on a conference table.
Small frictions multiplied by every job. The same ten-year user: not being able to pause a job without calling someone to turn off notifications so it can be re-dispatched and closed "adds several minutes to each day." Several minutes, times every technician, times every working day, for the life of the contract.
By the numbers
Two of these threads end the same way. After a major mobile redesign, one technician wrote: "I instantly went back to the old one and told them I refuse until it actually functions." Another reported that complaints were loud enough that the vendor reverted. When your workforce can roll back your software rollout, adoption was never really yours to mandate.
The adoption paradox: mandatory fields punish your best technicians
This is the part that no feature matrix models, and it is where most implementations quietly fail.
The instinct when data quality is poor is to make fields required. The technician with a decade on one platform described exactly where that leads:
"It's basically just a micromanagement tool that makes life difficult for people who are already well organized but can be easily worked around by anyone who isn't and doesn't want to be."
Read that twice, because it inverts the usual assumption. Mandatory fields do not catch the careless technician. That person types a full stop in the notes box and moves on. They catch the conscientious one, who reads the question, tries to answer it honestly, and loses ten minutes discovering the question does not apply to the job in front of them.
The same technician gave the concrete version: "There's nothing worse than having to fill out a 40 point furnace questionnaire before you can leave the hydronic fan coil job you just sold a replacement on when you're slammed."
And the reductio, from another thread: a company configured an arrival checklist that appeared when a technician tapped "arrive" on site. One of the mandatory questions was "did you click 'arrive' when you arrived at the job?" It took years to get removed.
Every required field is a tax levied on every job by every technician forever. Before you add one, work out the arithmetic: a field that costs 15 seconds, across 8 calls a day, 6 technicians and 5 days, is 60 minutes a week. Ask what you will do with the resulting data that is worth an hour of field labour every week. Most required fields cannot answer that. The same friction logic applies in the office, which we covered in detail in getting a sales team to actually use the CRM.
The backfire nobody warns you about
Here is the finding that surprised us most. On the thread asking technicians their single biggest problem with the platform, the top comment by a wide margin, at 52 upvotes, was not about software at all:
"Mine and my coworkers problem was seeing how much you are making the company and not getting paid dick."
The system worked exactly as designed. It attributed revenue to jobs, jobs to technicians, and surfaced it on the technician's own screen. Then the technicians did the division.
This is a real and underdiscussed consequence of putting revenue visibility in a field app, and it cuts both ways. If your compensation structure is defensible, transparency is an asset and your best technicians will use it to argue for more work, not less. If it is not defensible, the software you bought to increase accountability will function as a payroll grievance engine, and the resentment will attach itself to the tool.
Decide which situation you are in before rollout, not after. If you are moving to revenue-visible dispatching, pair it with a compensation conversation in the same month. Doing it in the wrong order is how a technically successful implementation becomes a retention problem.
Most of the failures above come from buying a general product and bending your field process to fit it. We build custom CRM systems around how your crew actually works, including what happens when the signal drops. If you have already tried two platforms and your technicians are still using paper, that is worth a conversation.
The seven field tests
Run these with a technician holding the device, on the actual phone or tablet you plan to deploy, before you sign anything. Not the owner. Not the office manager. The person who will open it eight times a day.
| # | Test | How to run it | Fail signal |
|---|---|---|---|
| 1 | Offline write | Put the device in airplane mode. Create a job update, attach a photo, capture a signature, save. Restore signal. | Anything that will not save, or does not sync back cleanly |
| 2 | Taps to close | Count every tap from opening a job to closing it with notes, parts and signature. | No published number, or a count you would not want repeated 8 times daily |
| 3 | Crash recovery | Fill a long form halfway. Force-quit the app. Reopen. | Draft is gone |
| 4 | Photo fidelity | Take a photo of a rating plate or serial number. Reopen and zoom to full resolution. | Compression makes it unreadable, or zooming crashes the app |
| 5 | Session length | Ask how often a technician must re-enter credentials, and what happens with no signal. | Daily re-auth, or any re-auth that requires connectivity |
| 6 | Battery draw | Run one real shift on the target device with GPS and the app active. | Flat before the shift ends |
| 7 | Required-field count | Count mandatory fields per job type and multiply by your daily call volume. | Any field nobody can name a decision for |
Then ask one question in writing: "Please send your published documentation of what the mobile app cannot do offline." A vendor with a real offline architecture has this page. A vendor without one will send a marketing sheet. That single email sorts the category faster than any comparison table.
What good looks like
Strip away the vendor language and the technicians in these threads are consistently asking for four things, which one operator in r/CRM summarised almost as a specification: does it connect customer records directly to jobs and work orders, can technicians access and update from their phone on site, does it handle recurring customers without manual re-entry, and does it give the office real-time visibility into job status.
Notice what is not on that list. No AI. No analytics suite. No route optimisation. Those are real features with real value, but they are office value, and they are what gets demoed because they are what the buyer responds to.
Tip
A useful sanity check before you shortlist: if the vendor's own website markets the mobile app primarily to owners rather than to technicians, the mobile app is a compliance instrument, not a tool. Products built for technicians say so in their own copy, because the people who built them knew who had to open it.
Two more signals worth weighing. First, training length is a proxy for interface quality. A user with a UX background wrote that being told training would run 14 hours over one week "felt like a huge red flag," adding that buttons rendered as grey text on white with no underline gave no indication they were clickable. Software that needs a fortnight of instruction has moved its complexity onto your payroll.
Second, watch what happens when a company outgrows the office side. One operator described running a franchise-mandated platform with no usable lead view for a three-person office, and building a CRM in a Google Sheet alongside it, manually entering every lead every day. Wherever you find a shadow spreadsheet, you have found a gap the platform does not cover. That is worth mapping before you buy, not after, and it is the same seam we examined in CRM vs field service software.
When paper is still the right answer
It is worth saying plainly, because no vendor will. On the thread about the redesigned mobile app, one technician replied: "Wow super tech much....I'm out here with carbon copy paper book." Another added that "the original app was a downgrade from paper tickets so the trend continues."
These are not luddites making a point. Carbon paper has properties software struggles to match. It never loses a form to a sync error, never asks for a password, never runs out of battery, works at any signal level, and takes zero training. For a two or three technician operation, that is a genuinely competitive product.
Software wins when you cannot answer basic questions without physically locating a book: which jobs from last week are unbilled, which customers are overdue for maintenance, which technician's callback rate is climbing. That threshold usually arrives somewhere between three and six technicians. Below it, buying a platform to look professional is a cost with no return. Our wider comparison of CRM options for field service and blue collar businesses covers where each tier makes sense.
A rollout sequence that does not stall
If you have chosen a platform, the order of operations matters more than the platform.
- Pilot with your most sceptical technician, not your most enthusiastic one. The enthusiast will make a broken product look fine. The sceptic will find the failure modes in week one, while you can still walk away.
- Ship with the minimum required fields, then add. Starting permissive and tightening is recoverable. Starting with a 40 point checklist and loosening it means your technicians have already decided what the tool is.
- Fix the top three field complaints before adding any office feature. Reporting can wait. Adoption cannot be retrofitted once the crew has routed around the app.
- Handle the compensation conversation in the same month as revenue visibility. Not the month after.
- Measure the close. Track the median time from last task on site to job closed in the system. If it is not falling by week six, the rollout is failing regardless of what the dashboard says.
The bottom line
The phrase "CRM for service technicians" contains the whole problem. The CRM is bought for the business and used by the technicians, and the two audiences judge it on almost disjoint criteria. Vendors optimise for the buyer because the buyer signs, which is rational for them and expensive for you.
You can correct for it cheaply. Put the app in a technician's hands before you sign, run the seven tests, and ask for the offline limitations documentation in writing. If a vendor will not do a field trial on a real device with a real technician on a real route, you have learned what you needed to know without spending anything.
Sources
- Microsoft Learn, "Best practices and limitations for the offline profile," Dynamics 365 Field Service documentation.
- r/HVAC, "New ServiceTitan app is a downgrade…" (143 upvotes, 49 comments), technician commentary on mobile experience, battery, estimate speed and rollback.
- r/HVAC, "What's your biggest problem with Service Titan?" (77 comments), technician and field supervisor reports of form loss, offline close failures, re-authentication, photo compression and compensation visibility.
- r/ServiceTitanFAQ, "What does ServiceTitan still not get right?", operator reports on training length, interface affordances, permissions and shadow spreadsheets.
- r/CRM, "Anyone here using CRM tools specifically for field service businesses?", operator-stated evaluation criteria for field service CRM selection.