Your technician in the field loses two jobs a day: the phone app you (haven't) given him

“Where are you? Which part are you missing?”: the phone call that costs you two jobs a day

There’s a soundtrack in companies that send technicians out — service, maintenance, installations, plants. It’s the office phone ringing constantly. “Where are you now?” “How long until the next one?” “Which spare part do you need, so I can prepare it?” “Did this morning’s customer sign?” “How long did you work, I need to invoice?”. Every question is a phone call, every phone call is an interruption, and every interruption is time the technician isn’t spending on the thing you pay him for: doing the job.

The tally is steeper than it looks. Between dead time, wrong trips because a piece of information was missing, spare parts not loaded because nobody knew they were needed, and jobs that slip because the office doesn’t have the picture, a technician easily loses one or two jobs a day. On a team of five people, that’s five to ten jobs lost every day — that is, revenue you don’t make, not for lack of work, but for lack of organization.

This article is for anyone who has technicians in the field and still coordinates them with phone calls, WhatsApp, paper job sheets and PDFs by email. Let’s see what a field technician app actually has to do — and what it must not do — because so many field service software products are so complicated that technicians hate them and go back to the sheet. We’ll look at the app in four taps, the data that vanishes today, the queue the office needs to see, the offline knot, and above all ROI measured where it counts: in extra jobs, not in “we’ve digitized”.

What the app has to do in four taps

Let’s start from the technician’s side, because if the app doesn’t work for him, it simply doesn’t work. And the golden rule is: a technician, with gloves on, in the rain, with dirty hands, has to be able to do everything in a few taps. If an operation requires navigating menus, filling long forms, picking from endless lists, the technician doesn’t do it: he goes back to calling the office, and the ringing phone is back.

Here’s what the app has to do, and in how many taps:

• See the next job (1 tap): where, who, what, with the address that opens the navigator immediately. No more “where do I have to go?”.
• Open the job in progress (1 tap): the customer card, the history, what was done the other times, the contract. All there, without calling.
• Record what he did (a few taps): the type of job, the spare parts used (chosen from a short, relevant list, not from a catalog of 8,000 codes), the hours. Buttons, not keyboard.
• Close with photo and signature (2 taps): he takes the photo of the work done, has the customer sign on the screen, closes. The job is documented and ready for the invoice, without a piece of paper.

And there’s a practical rule: everything that can be decided in the office, is decided in the office, not in the field. The technician shouldn’t choose the contract type, apply the price list, decide the priority: those things arrive already set on the job. What’s left for him is only what he has to do there physically — see, do, record, close. Every decision you move from the office to the field is a decision taken worse (in a rush, without context) and one more tap that slows things down. The less the technician has to think, the faster he is and the more the data is right.

Four moments, a few taps each. Notice what’s missing: everything else. The fields the office needs but the technician doesn’t, you pre-fill or you ask later; you show the technician only what he needs at that moment, in that place. It’s the same principle as internal apps that remove friction instead of adding it: make trivial what is done a hundred times, and hide the rest. A technician app with thirty fields to fill on every job is an app technicians sabotage within a week.

The data that vanishes today (and that you need in order to invoice)

Here’s the hidden cost nobody puts in the account: today, every job produces data that vanishes. The technician used three spare parts, it took him two hours, he took a photo with his phone that stays on his phone, he had a sheet signed that he may lose in the van. Then in the evening, or on Monday, he tries to reconstruct from memory what he did during the week, for the office that has to invoice. He forgets some things. The “small” spare parts he doesn’t write down. The hours he rounds by eye. The result: you invoice less than you did, because part of the work wasn’t recorded at the moment it happened.

An app changes this at the root, because it captures the data when it happens, not from memory afterwards. The spare part used, you mark it on the spot (and it deducts from the van warehouse). The hours start when you open the job. The photo and the signature stay attached to the job, not scattered across five phones. When the office goes to invoice, it has everything: what was done, with which spare parts, how many hours, with the proof (photo + signature) in case of a dispute. It isn’t “digitization”: it’s stopping giving work away because you didn’t record it.

A brutal way to understand how much you’re losing: take ten jobs closed last month and compare what was invoiced with what the technician remembers actually doing. Almost always a spare part that wasn’t marked turns up, half an hour that wasn’t counted, an extra visit forgotten. Multiply by all the jobs in the year: that’s the revenue you give away not because you work for free, but because you don’t record at the right moment.

And there’s more: that data, accumulated, becomes valuable information. Which jobs repeat on the same customer (a signal of an underlying problem). Which spare parts you consume most (for the warehouse). Which technicians are faster on certain jobs. What it really costs to serve a certain contract. Today all of this vanishes; with an app it becomes the basis for deciding better.

A typical case: six technicians, less phone, full invoices

A typical profile, architectural, no names. Plant service company, six technicians out. The office spent the mornings on the phone: assigning, figuring out where they were, knowing what had been closed. The technicians in the evening reconstructed hours and spare parts from memory for the office. Result: jobs lost to disorganization, and “light” invoices because hours and parts weren’t all marked.

What was done. First they watched a technician’s real round for a couple of days: where he lost time, which information he was missing, what made him call the office. Then an app with the job cycle in four taps — next job, customer card, recording, close with photo and signature — working offline. And in the office, the job queue that you can see.

After: the “where are you / what’s missing” phone calls almost gone, because the information is in the app. Each technician recovered time for one extra job on full days. And the invoices went back to “full”, because hours and spare parts are recorded on the spot, not from memory. With the usual honesty: the first two weeks a couple of technicians turned their nose up (“I was faster with the sheet”), then they stopped having to fill anything in in the evening and they never went back.

Why a PDF by email isn’t an app

A myth needs to be taken apart here, because it’s the shortcut many try before they give up: “let’s make a nice PDF of the job sheet, the technician fills it in on the phone and sends it back”. It looks like the cheap solution. It isn’t, and it’s important to understand why.

A PDF is a document, not an application. Filling in a PDF on a phone is a nightmare (anyone who’s tried it knows), it doesn’t connect to anything, it doesn’t update the warehouse, it doesn’t show the office where the technician is, it doesn’t have the customer history, it doesn’t work offline in a serious way. It’s paper in a different outfit: the technician does the same work as before, the office receives a file that someone still has to retype, and the data stays isolated.

The difference between a document and an app is all here: the document records, the app connects. The app makes the technician talk to the office in real time, to the warehouse, to the gestionale. When the technician closes a job, the office sees it immediately, the spare part is deducted, the invoice is ready. A PDF does none of this: it only moves the paper sheet onto the screen, plus the inconvenience of filling it in with a thumb. If you’re evaluating the “digital form” path, know that it’s the same path that leads technicians to hate it and go back to the real sheet — the paper one, which at least you fill in fast.

The office: the job queue you can see

Half the value of a field service app sits on the other side: in the office. Today whoever coordinates the technicians works in the dark: they don’t know where they are, how far along they are, what’s closed and what isn’t, whether a customer needs a callback. They reconstruct everything with phone calls. With an app, the office has a job queue you can see: a screen where, at a glance, they know what’s scheduled, what’s in progress, what’s closed, what’s late, what still needs invoicing.

What changes, in practice:

• Planning stops being a whiteboard and a fit-by-memory. You see who’s free, who’s near an urgent customer, where it makes sense to send whom.
• Urgencies are handled without scrambling everything: a call comes in, the office sees which technician is closest and available, and assigns him the job — which appears on his phone, without a phone call.
• Customers can be informed: “the technician arrives in an hour”, automatically, instead of leaving them waiting half a day.
• Delay is visible earlier: if a job is overrunning, the office notices and reorganizes, instead of discovering it when the customer calls angry.

This queue you can see is the twin, for the field, of the order queue for people who work in the office: the same principle — stop keeping the status in your head and in phone calls, and put it on a shared screen where whoever coordinates sees everything.

There’s a less obvious but important effect: the queue you can see also changes the relationship with the customer. Today, when a customer calls to know “when are you coming?”, the office can’t answer precisely and promises at random, generating more calls when the promise slips. With the queue in front of them, the office gives a real answer — “we’re with you tomorrow morning” — and can even notify automatically. Fewer inbound calls, calmer customers, and the feeling, for the customer, of dealing with an organized company instead of a switchboard guessing.

The mistakes that make technicians hate apps

There are precise mistakes that turn a technician app into a hated, abandoned object. Knowing them also helps you recognise a vendor who has never set foot in a van.

• Too many mandatory fields. If to close a job the technician has to fill in fifteen fields, he doesn’t close while he’s at the customer: he does it in the evening, from memory, and the data goes back to being inaccurate. On site you ask only for the essential.
• No offline. Killer number one: it dies exactly where you need it, and after two times the technician abandons it.
• Endless lists. Making someone choose a spare part from a catalog of eight thousand codes, in the street, is torture. The list has to be short and relevant — the spare parts that technician actually uses, the ones on his van.
• No feedback. The technician closes, he doesn’t know if it went through, the sync is opaque: at the first doubt he starts calling the office again “to be safe”. The app has to say clearly what’s saved and what’s queued.
• Designed in the office, tested in the office. An app designed looking only at the office’s needs, without having technicians try it in the field, is already disconnected from reality at birth. The real test is a real technician, in a real van, in a real basement.

What the technician sees vs what the office sees

As with every internal app, there isn’t a single screen: the technician and the office look at different things. The technician’s screen is essential and mobile — the next job, the one in progress, the few buttons to record and close — optimized to be used standing up, with one hand, maybe in the rain. The office screen is for coordination — the queue of all jobs, who is where, what’s late, what still needs invoicing — made for a person sitting at a monitor who has to have the picture and reorganize on the fly.

Same information underneath, two views for two jobs. The classic mistake is giving the technician the office screen (too much stuff, unusable in the street) or the office the technician’s (too little, they don’t see the picture). You need both, each thought for the person who uses it.

Offline and coverage: the technician is where there’s no signal

A technical detail that isn’t a detail: technicians work exactly where there’s no signal. Basements, sheds, garages, industrial zones, the countryside. A field service app that only works with a perfect connection is an app that dies exactly at the moment you need it — and the technician, after twice losing the work he did because “there was no signal”, abandons it forever.

That’s why a serious technician app has to work offline: the technician opens the job, records everything, takes the photos, gets the signature — all locally, on the phone, even without a connection. When he’s back in coverage, the app syncs on its own with the office and the warehouse, without him having to think about it. It’s one of those things that, if missing, you don’t notice in the demo (in the office there’s wifi) and it destroys the project in the field. When you evaluate a vendor, the right question is: “what happens if the technician closes a job in a basement with no signal?”. If the answer isn’t “it works anyway and syncs later”, you have a problem.

Integration with warehouse and gestionale

A technician app that lives in isolation is only half a solution. The full value arrives when it connects to two things: the warehouse and the gestionale.

With the warehouse: when the technician uses a spare part, it deducts — from the van warehouse and from the central one. So you always know what’s on every vehicle, you notice when a spare part is running out, and you stop discovering the part is missing when the technician is already at the customer. It’s tightly linked to stock misalignment across warehouses and to the operations I cover in the guide to internal apps: every technician’s van is, to all intents and purposes, a warehouse in motion, and if you don’t track it you have a hole in your stock.

With the gestionale: when the job is closed, the data (hours, spare parts, proof of execution) is ready to become an invoice, without anyone retyping anything. This closes the loop that loses money today: the work done in the field becomes revenue in the office, automatically and in full, instead of passing through a reconstruction from memory that forgets pieces.

ROI is measured in jobs, not in “digitization”

Here’s the point that makes the difference between a project that’s worth it and one that’s only an expense: the return on a field service app isn’t measured in “we’ve digitized”, it’s measured in extra jobs per day. It’s a concrete number, and it’s worth looking at.

If a technician today loses one or two jobs a day between dead time, wrong trips, phone calls and missing spare parts, a well-made app gives him a good part of them back — not with magic, but by removing the causes: he has the information on the phone (no empty trip), the office coordinates him without calling him (no interruptions), the right spare parts are loaded (no return to base), closing is immediate (no evenings filling forms). Even half an extra job a day, per technician, on a team of five people, for 220 days, is hundreds of extra jobs a year — that is, additional revenue with the same technicians and the same vehicles.

Add to that the recovered revenue (the spare parts and hours you don’t record today and therefore don’t invoice) and the avoided costs (fewer returns to base, fewer errors, less office time on the phone). The count, done honestly, almost always says the app pays for itself in months. But the number to keep an eye on is that one: extra jobs. If a vendor only talks to you about “digital transformation” and doesn’t help you estimate the extra jobs, they’re selling you a word, not a return.

A simple way to build the business case before you spend: estimate the jobs lost per day per technician (ask them, they’re honest), multiply by the average value of a job and by the working days; add the revenue you don’t record today and the office time spent coordinating by phone. That figure is the ceiling of the return: even recovering part of it, the comparison with the cost of the app is almost always in favor of the app. And it’s the same method as the diary of a day — measure before, so after 90 days you know whether it actually worked, with numbers and not with impressions.

When you DON’T need a dedicated app

For honesty: not everyone needs a dedicated app. If you have a single technician, few jobs a day and you know them by heart, a shared calendar and an orderly group can be enough — and that’s perfectly fine. If your jobs are all identical and extremely simple, with very little to record, the app adds little. And if your gestionale already has a service module that technicians actually use in the field, you don’t need anything else.

The dedicated app makes sense when the numbers count: more technicians, many jobs, spare parts and hours to track in order to invoice, coordination that today eats the office’s mornings. Below a certain threshold, the cost of the app doesn’t pay itself back in jobs gained, and an honest vendor tells you so. The question to ask yourself is always the same: how many jobs am I losing and how much revenue am I not recording? If the numbers are small, keep the calendar; if they’re large, the app pays for itself fast.

Not only service: where it applies

It’s worth being clear that “technicians in the field” isn’t only classic technical service. It’s anyone who sends people out to do trackable work: plant maintenance, installations, site surveys, deliveries with assembly, industrial cleaning, checks and commissioning, meter readings, building work, green care, inspections. If you have people who go to a customer, do something and have to record it and invoice it, the problem is the same — and so is the solution: an app in four taps, offline, with the queue in the office. The details change (the fields, the spare parts, the types of job), not the principle.

The proof that protects you: photo and signature

A value people underestimate until they need it: photo and signature collected on the spot are your proof. The customer who a month later says “it wasn’t done” or “the technician never came” runs into the photo of the work and the signature of whoever accepted the job, with date and time. Without that proof, it’s your word against theirs, and often you pay — a free return visit, a discount, an argument. With the proof attached to the job, the dispute closes in thirty seconds. It isn’t bureaucracy: it’s protection of your work and your collection, and it’s worth even more when the customers are large and the contracts are serious.

Where you start

If we decided to start, you don’t begin by buying a “field gestionale” with a thousand functions. You begin from the basic job cycle — assignment, execution, close with photo and signature — and you make it work well, on all technicians, maybe starting from a pilot team. A cycle that runs creates trust; from there you add warehouse, integration with the gestionale, customer notifications, history.

The first step you can take yourself: follow a technician for a day, or have him tell you his round in detail. Where does he lose time? Which information is he missing that makes him call? How many times does he go back to base or drive empty? That diary of a day is worth more than any field service software brochure, because it tells you exactly what the app has to solve — and it gives you the baseline to measure, afterwards, the jobs gained.

It’s for you if / it isn’t for you if

It’s for you if: you have technicians in the field coordinated with phone calls, WhatsApp and sheets; you lose jobs to dead time, wrong trips and missing spare parts; you invoice less than you do because hours and spare parts aren’t recorded; the office never knows where the technicians are and how far along the work is.

It isn’t for you if: you have a single technician and low volume (a shared calendar can be enough); your jobs are all identical and extremely simple (little to track); you’re looking for a “field gestionale” full of functions more than a tool the technician uses in four taps — because that’s exactly the software technicians abandon.

Frequently asked questions

The technicians aren’t “tech people”, will they manage to use it? If the app is made well, yes — precisely because it’s made for them. Four taps, big buttons, nothing to type with a thumb, it works with gloves. Technicians don’t refuse technology: they refuse uncomfortable tools. An app that lets them finish earlier and close the day without homework in the evening, they adopt fast.

Does it work without a connection? It has to. Technicians work where there’s no signal. The app has to let you do everything offline and sync on its own when the line comes back. It’s the function you don’t see in the demo and that decides success in the field: ask for it explicitly.

Do we need to buy new phones? Almost never. A good field service app runs on the phones the technicians already have. The investment is in the app and in its hook to warehouse and gestionale, not in the hardware.

How long to get started? You start from a flow — the job cycle (assignment, execution, close with photo and signature) — and you bring it home in a few weeks, maybe with a pilot team. Then you add warehouse, gestionale integration, customer notifications. Better a cycle that works on everyone than ten functions halfway.

And ROI, can you really measure it? Yes, and it’s the right thing to ask. Baseline: how many jobs per day per technician today, how much revenue “lost” in unrecorded hours and spare parts, how much time the office spends on the phone. After 90 days you compare. If it doesn’t improve those numbers, the app is badly made, however pretty it is.

Do the data and the system stay mine? Yes. Jobs, customer history, photos, code and integrations stay your property, no lock-in. The job history is a company asset: it has to be yours.

Can we know where the technicians are? Technically yes, but it has to be done with judgment and transparency: it’s there to send the job to the closest technician and to inform the customer, not to control people. The useful question isn’t “where are they now”, it’s “who is free and close to this urgency”. A respectful use works; a Big Brother use only generates resistance.

What if I already have a gestionale with a service module? Sometimes that’s enough, if the module is actually usable in the field. But many gestionale service modules are designed for the office and unusable on a phone in the street — and that’s why technicians bypass them. If yours they actually use, great; if it’s there but nobody touches it in the field, the problem is the mobile UX, not the lack of functions.

How long until the technicians adopt it? If it’s made for them, fast: the classic two weeks of running-in, then they don’t go back because they finish earlier and close the day without homework in the evening. If after a month they still bypass it, it isn’t the technicians’ fault: it’s the signal that the app has too much friction and needs to be simplified.

In one line

If your technicians lose one or two jobs a day between phone calls, empty trips and missing spare parts, and you invoice less than you do because hours and spare parts vanish, you don’t need to “digitize”: you need a field technician app that does everything in four taps, works offline, gives the office the job queue you can see, and connects to warehouse and gestionale. The return is measured in extra jobs per day and in recovered revenue — not in slides on digital transformation.

If you want to estimate how many jobs you’re losing and what the right app would look like for your technicians, look at the projects I’ve built or drop me a couple of lines: we start from your technicians’ real round, not from a catalog software.