Companies servicing air conditioning, medical devices, industrial scales, large-format printers or construction equipment share surprisingly similar problems. Eight technicians in the field, a dispatcher with a paper schedule, service reports being re-typed from pen into the ERP on Friday afternoon. A mobile app for field technicians (FSM — Field Service Management) fixes most of that mess, but not every company needs it at this point.
When we talk to owners of such companies we usually hear two extreme opinions. One: "it won't work here, my guys don't want a phone at work". The other: "I need an app like Uber for technicians". Both are usually off the mark. The truth sits in the middle and depends heavily on how many jobs a day you have, how many people are in the field, and how long the cycle from job to invoice lasts.
This piece is not about "every service company needs an app". It's about the point where not having one starts to cost more than having one.
What happens without FSM
A typical day at a 12-person HVAC service company near Kraków looks like this. In the morning the dispatcher prints today's schedule from Excel — six technicians, five visits each. Jobs come in from several channels: phone, email, a retail chain's complaint portal, a form on the website. Everything lands in one spreadsheet.
Technicians get printouts. On site they fill in a service report (paper, carbon copy, one copy for the customer). The customer signs. That evening or the next morning the technician hands the stack of reports to the office. In the office someone re-types the data: into the ERP (Comarch Optima, enova365, whatever), into a technician profitability spreadsheet, into the customer's equipment register. The invoice gets issued on Friday from the paperwork collected all week.
The problems this generates are always the same:
- The invoice goes out 5–10 days after the visit. The customer no longer remembers what it was about. A "that wasn't in the contract" dispute becomes easy.
- Paper gets lost. Statistically 3–5% of reports go missing every month. There's no way to invoice them.
- Nobody actually knows how long a visit takes. The technician writes "2 hours" after the fact, because that looks right. Real duration is unknown.
- Repeat visits. The technician forgot to order parts because the part list is on the report that arrived at the office a week later. In the meantime the customer calls back saying it's still broken.
- The dispatcher has no real-time view of where anyone is. The customer calls "where is the technician?" and the answer is "let me call Chris and I'll get back to you".
Each of these has a real annual cost. In aggregate, in a company that size, we've seen 60–80 thousand PLN (roughly EUR 15–19k) of "lost revenue" per year — un-invoiced visits, repeats with no basis for an extra invoice, back-office hours spent on re-typing.
What FSM actually changes — a real example
At one of our clients — a 12-person HVAC service company near Kraków (6 field technicians, 2 back-office, the owner, 3 installation staff) — we rolled out a simple FSM app integrated with their Comarch Optima. Not enterprise. An Android app for technicians, a lightweight dispatcher panel in the browser, integration with the ERP over a REST API.
Here's what changed in the first three months:
- Time from visit to invoice dropped from 5–10 days to same day. The technician signs the report on a tablet at the customer's site, the report goes into the system, the invoice is generated from a template. The sales rep just approves it.
- Repeat visits dropped from ~15% to ~4%. Because the "missing parts" list from the first visit lands in the warehouse the same day, not a week later.
- The dispatcher got back ~10 hours per week. Stopped re-typing paper. Started actually planning.
- We discovered one technician was averaging 40% longer visits than the others. Not because he was slow — he was getting the harder customers. The schedule got rebalanced and his time stopped being burned on driving.
- "Lost" reports disappeared. A report can't get lost if it doesn't exist on paper.
Total: about 90k PLN of annual bottom-line difference against a ~45k PLN one-off implementation and ~1200 PLN/month running cost. Paid back within year one.
This is not a fairy tale — it's simply the effect of paper disappearing and data appearing in the system at the moment the work is done, rather than a week later.
When FSM doesn't pay off yet
Anti-hype: not every company needs this. Signs it's still too early:
- Below 3 field technicians and ≤10 visits a day. A whiteboard in the office and a WhatsApp group genuinely cover it. The tool won't pay back even in three years.
- Jobs are big and rare — installations that take three days. FSM shines with lots of short visits. With a handful of big projects per month you're better off fixing the process inside the ERP.
- The team is older and genuinely scared of a tablet. That doesn't mean don't do it — it means plan 2–3 months for acclimation and pick an app with screens you can actually operate one-fingered wearing a glove.
- The ERP is in a state where everything has to be re-typed manually anyway. Then FSM just shifts the problem. First clean up the customer equipment register and the customer master data in the ERP.
SaaS, custom software or low-code — how to choose
Three schools. Each makes sense in a different situation.
Off-the-shelf SaaS (ServiceMax, mHelpDesk, Fieldcode, Polish MobileNET, Fielda, a few others). Upside: live in 2–4 weeks, per-user monthly billing. Downside: you have to adapt to their workflow. Integration with your ERP usually exists, but in the "50%" version — wrong fields, different formats, invoice pushed as a CSV at midnight anyway. Reasonable if you have a standard service process (visit, report, invoice) and can live with the customer equipment register existing in two places.
Custom software (this is what we do at SilverData). Upside: the app looks exactly like your process, not like an American startup's idea of it. ERP integration is native — one system, one customer and equipment register, the invoice is issued in your ERP at the same moment. Downside: 35–70k PLN upfront, 6–12 weeks. Makes sense from ~5 field technicians upwards and for a non-standard process (e.g. a legally regulated service with mandatory specific handover protocols).
Low-code (Power Apps, AppSheet, low-code on Airtable). The middle path. You can assemble an MVP in a few weeks, integrate the ERP via API, at lower cost than custom. Downside: the functional ceiling arrives quickly, and licences at 10+ users stop being cheap. A good option for a first attempt — pilot with one crew, validate assumptions, then decide: off-the-shelf, custom, or stay on low-code.
Where to start — the first 30 days
Before you pick a tool, do three things. This works in every service company we know.
- Measure the current process. Take the last 20 visits. Check: days from job to visit, days from visit to invoice, how many required a second trip and why. Without a baseline, you can never prove FSM did anything.
- Clean up the customer equipment register. This is the foundation. Every serviced device (AC unit, printer, scale) has to have one ID in your ERP. Not "AC on the ground floor" — a specific model, serial number, installation date. Without this, even the best app won't give you a service history.
- Pick one crew for the pilot. Not everyone at once. Two technicians, one dispatcher, two weeks. See what actually doesn't work before you pour it across the whole company.
Only then talk to a vendor — whether that's an off-the-shelf SaaS or a company like ours. The conversation goes differently when you enter it with numbers instead of "we'd like some kind of app".
If you'd like to estimate whether FSM will pay off in your company (and how fast), the first call is free, takes half an hour, and doesn't come with a salesperson attached.
FSM doesn't turn chaos into order. FSM turns ordered chaos into a measurable process. Step one is to clean up the equipment and customer register, only then the app.