Field service management software: the technician drives back a second time and nobody pays for that trip

The owner of a woodworking machinery manufacturer, fifty four employees and eleven million in revenue, showed me the service department whiteboard on a Tuesday morning. Fourteen lines written in marker pen, a customer name, a town, sometimes the machine model. Next to it, a plastic box holding last week's job sheets, carbon copy paper, some of them still waiting to be invoiced. Nine technicians were already on the road. One of them was driving back to the same customer for the third time, for the same fault, because the first time he did not know which control board was fitted and the second time he brought the spare part for the previous version.

If you recognise that scene, this article gives you the real cost of running service the way you run it today, the single number that tells you whether field service management software will give you margin back or only a tidier archive, why the installed base is the project and the app on the technician's phone is only the tip, how to handle spare parts that travel in vans, how to find out which service contracts you are selling below cost, the real price ranges between the service module of the ERP you already own, a subscription product and a custom system, and the threshold in euros beyond which the maths changes.

I have been writing software since 1999 and I have seen plenty of companies that sell something and then have to service it: machinery builders whose technician drives to Romania with two cases of spare parts, contractors with thirty vans and a warehouse nobody can account for any more, refrigeration companies with maintenance contracts signed ten years ago and never read again, IT service firms with support included in the fee and nobody who knows what it actually costs. I also built and sold a software product used by many companies, and from the selling side I learned something that applies here too: service is not a cost centre to squeeze, it is the place where it is decided whether the customer will buy from you again in seven years.

What I learned, and what nobody says during the demo, is this: the number that decides is not how many jobs you do, it is how many of them are followed by a second visit for the same fault on the same machine within thirty days. Every second visit is a full trip, with the travel, the hours and often the part, and the customer almost never pays for it. If your second visit rate is high, good software halves it and pays for itself. If it is already low, what you are buying is order, not margin, and it should be bought with a different budget.

What field service management software is, and what it is not

Field service management software holds together four things that in most small and medium companies live separately today: what you have installed at your customers, what has happened to each of those installations, who goes out to work on them and when, and which part of all that turns into an invoice. On the market you find it under different names, and the confusion suits the sellers: job management, field service management, service management, after sales management, technical ticketing, technician apps. These overlap only in part and cost very different amounts.

The distinction that really matters, before you watch any demo, is between a system that starts from the job and a system that starts from the machine. The first is a diary with job sheets attached: it knows who went where, how many hours they worked and what they wrote. The second knows what is installed at the customer, in which configuration, with which modifications made over the years, and hangs the jobs off that machine. They cost roughly the same. The first tidies up your administration, the second removes your second visits. Almost every company buys the first and believes it has bought the second.

Servicing customers or maintaining your own plant: two different products

This is where the confusion usually happens, and it is expensive because you end up buying the tool for somebody else's problem. If you need to keep the plant and machinery inside your own factory running, your subject is maintenance: periodic plans, downtime, spare parts in stock, and I covered it at length in maintenance management software. If instead you need to service what you have sold, sitting in somebody else's building, your subject is a different one: the journey, the serial number whose configuration you do not know, the part you do not have with you, the warranty that may have expired, the invoice that may need writing.

The practical difference comes down to three points. The first is distance: in internal maintenance the technician is a hundred metres from the spare part, in field service he is a hundred and twenty kilometres away and if he gets it wrong he has to come back. The second is money: an internal job is purely a cost, an external job can be revenue, or a warranty cost, or consumption of a contract, and knowing which of the three changes your profit and loss. The third is the customer: when the technician arrives, it is your company arriving, and it is the only moment when somebody physically touches whether the product you sold is worth what they paid.

A third kind of thing is sold under the same names, namely the ticketing system for software or telephone support, the one with the queue, the priorities and the first response time. It has its place, and it is the right part for those who support products you cannot touch. But if your technicians travel, a ticketing system on its own is not enough: it knows nothing about the journey, the van or the serial number.

The three families of companies that look for it, and look for different things

Those who build and service what they sold. Machinery builders, plant builders, production line builders, equipment manufacturers. A few hundred or a few thousand installations, each one different because almost every machine is a project, their own spare parts, highly specialised technicians, trips abroad. Here the value is entirely in the installed base: knowing what is really in that building is worth more than any route optimisation. It is the family with the highest second visit rate, and therefore the biggest return.

Those who install and maintain systems for others. Electrical and plumbing contractors, air conditioning and refrigeration companies, fire safety, lifts, automatic doors, security systems. Many installations, many of them small, periodic maintenance contracts with statutory deadlines, mandatory inspections, technicians who are less specialised but more numerous. Here the value is in scheduling and deadlines: the periodic visit that never happens, the certificate that does not exist when the inspector arrives, the contract that has renewed silently for six years without anybody recalculating the price.

Those who sell products that need on site service. Dealers of agricultural machinery, earth moving equipment, catering equipment, medical devices, printing systems. The product belongs to somebody else, the service is yours, the warranty is honoured by the manufacturer and has to be claimed back from them. Here a cost item appears that the other two families do not have: warranty recovery from the supplier, which without a system is lost in ninety per cent of cases because claiming it by hand costs more than it pays back.

The three families buy products with the same name and use different parts of them. Before watching any demo, decide which one you are in, even though companies often sit in two. Most of what follows applies to all three; where it changes, I say so.

The real cost of running service on paper job sheets

This is the calculation almost nobody does in full, because none of these items has a line in the accounts: technicians are a payroll cost that looks necessary, spare parts disappear into stock differences, unbilled hours simply do not exist anywhere. I take the company from the whiteboard as my reference: eleven million in revenue, fifty four employees, one thousand nine hundred machines still installed and alive, fourteen people in service split between nine field technicians, two in the workshop and three in the office, four thousand one hundred site visits a year plus around two thousand seven hundred jobs solved by phone or remotely, and one million four hundred thousand euros of spare parts sold. It is a common size among the people who write to me, and the numbers scale reasonably well on the number of visits.

The second visits you never invoice

This is the biggest item and the most invisible, because a second visit is not called that in any system: it is called a job, exactly like the first one. Out of four thousand one hundred visits, a second visit rate of twenty two per cent means nine hundred trips repeated for a fault already seen. Some of them are unavoidable and honest: the part had to be ordered, the fault was hiding under another fault. But two thirds, in my experience, come from three causes a system solves: the technician did not know what he would find, did not have the right part with him, or could not read what had been done six months earlier.

The full cost of a visit is not the technician's hourly rate. It is the round trip, which in Italy is almost always between one and a half and three hours, the hours on site, the van, the return to the workshop, and the fact that on that day the technician did not go to another customer who was paying. Between one hundred and eighty and two hundred and sixty euros, and I am being conservative. Six hundred trips nobody pays for, at two hundred and ten euros, make one hundred and twenty six thousand euros a year. That is not a theoretical saving: it is money leaving the bank account and generating no invoice.

Spare parts fitted and never invoiced

The part leaves the warehouse, goes into the van, is fitted at the customer, and then the corresponding line has to appear on a job sheet, reach administration and be invoiced or deducted from a contract. Somewhere along that chain, when the job sheet is paper, something always gets lost. The technician who fitted the part at seven on a Friday evening writes "replaced sensor" without the code. The part taken from a colleague's van is not booked out anywhere. The board fitted as a test and then left in place.

You see the size of it at stocktaking, and it is the difference between what the system says and what is on the shelf. On one million four hundred thousand euros of spare parts moved, a loss between three and five per cent is normal in companies with no field tracking, and it is worth up to seventy thousand euros a year. It is almost never theft: it is paper. A spare parts store has its own rules, different from those of a production warehouse, and I described them in warehouse management software: here it is enough to know that until the vans are real stock locations, those numbers will never add up.

The hours that never become an invoice line

A paper job sheet travels a long road: it stays in the van for a few days, reaches the office, gets interpreted by whoever does the invoicing, sometimes goes back for a question. In companies that measure the time between job and invoice, the median sits between twelve and thirty days, and a share between five and ten per cent never arrives at all because the sheet was lost, because the customer disputed it and nobody felt like arguing over a hundred and twenty euros, because the technician wrote three hours but did not write what for.

On a billable capacity of around one thousand four hundred technician days a year, losing seven per cent of what is billable is worth up to sixty thousand euros. On top of that comes an effect nobody measures but everybody knows: an invoice arriving forty five days after the job is disputed far more often than one arriving the next day, because the customer no longer remembers what happened, and neither does the technician.

Service contracts sold below cost

This is the item that hurts most when you find it, because it concerns the customers you consider your best. The maintenance or service contract is written once, with a price set by looking at the customer's turnover rather than at the hours it will consume, and then it renews. Years pass, the machine ages, jobs increase, the fee stays where it was. Nobody ever compares, contract by contract, the hours and parts consumed against what has been invoiced, because doing that needs data that does not exist in a comparable form.

When that comparison is made for the first time, the result is almost always the same: between fifteen and twenty five per cent of contracts are loss making, and one or two are badly so. On a contract portfolio typical for this size, that is up to fifty five thousand euros a year of burnt margin. It does not mean cancelling those contracts: it means renegotiating them with numbers in hand, or realising that the machine needs replacing, which is a sale.

The office that reconstructs the history

Three people in the service office, and a large part of their day is not organising: it is reconstructing. Which machine does this customer have. Who went there last time. What did they do. Is the part under warranty. Where did the job sheet end up. In my experience it takes between thirty and forty five per cent of the time of the people in the service office, so a little more than two people out of three, and it is worth up to forty five thousand euros a year of full cost.

The total, for an eleven million euro manufacturer with four thousand one hundred visits a year, sits between forty five thousand and three hundred and fifty thousand euros a year, and no company hits the maximum on all five items. The range is wide because the real variable is not how many visits you make: it is how many of those visits happen because the information was not where it was needed. Do the sum with your own numbers, roughly, on a single sheet. If your total is under twenty five thousand euros a year, this is not your most urgent problem, and further down I say what probably is.

The second visit rate: the number that decides

If I had to keep one number from this whole article, I would keep this one: out of a hundred jobs closed in the last twelve months, how many required a second visit for the same fault, on the same machine, within thirty days. I call it the second visit rate. It decides everything, because it is the only number that directly measures what it costs you that information does not travel with the technician, and that is exactly what a good system works on.

The reason this number matters more than the number of jobs, the average job duration or the satisfaction your customers declare is that it cannot be gamed and does not depend on how you work. The number of jobs grows if you grow, and says nothing. Average job duration improves if technicians rush, which is the opposite of what you want. Satisfaction is measured with a survey answered by whoever feels like it. The second visit rate, on the other hand, is a fact: either that technician went back, or he did not.

How to measure it, in one day

You need three pieces of information, and the good news is that at least two are almost always there. The first is the list of jobs from the last two years with customer and date: it exists, because jobs become invoices. The second is the reference to the machine, that is the serial number, and this is where the problem starts, because in many companies a job is linked to the customer and not to the machine. If the customer has one machine, you can infer the serial number; if they have four, you cannot. The third is a description of the fault, and it is usually free text written by different people.

If the data is in a database, the measurement is a query. This is the shape I use on SQL Server. The table names in your system will be different, the substance will not:

-- Second visit rate: jobs followed by another visit on the same machine
-- within thirty days, excluding planned maintenance
WITH visits AS (
    SELECT j.JobId,
           j.SerialNumber,
           j.JobDate,
           j.JobType,
           j.HoursWorked
    FROM Job j
    WHERE j.JobDate >= DATEADD(MONTH, -12, CAST(GETDATE() AS date))
      AND j.JobType <> 'PLANNED'
      AND j.SerialNumber IS NOT NULL
),
with_return AS (
    SELECT v.*,
           CASE WHEN EXISTS (
                    SELECT 1
                    FROM Job n
                    WHERE n.SerialNumber = v.SerialNumber
                      AND n.JobType <> 'PLANNED'
                      AND n.JobDate > v.JobDate
                      AND n.JobDate <= DATEADD(DAY, 30, v.JobDate))
                THEN 1 ELSE 0 END AS SecondVisit
    FROM visits v
)
SELECT COUNT(*) AS TotalJobs,
       SUM(SecondVisit) AS WithSecondVisit,
       SUM(SecondVisit) * 100.0 / NULLIF(COUNT(*), 0) AS SecondVisitRatePercent,
       SUM(CASE WHEN SecondVisit = 1 THEN HoursWorked ELSE 0 END) AS HoursToRedo
FROM with_return;

If the serial number is not there, use the customer instead and accept a slight overestimate: a customer who calls you back within thirty days about a fault is almost always calling about the same thing. If you have the fault type coded, add it to the condition and you will get the exact number. On two years of jobs the query takes a few seconds with an index on serial number and date. Run it in the evening, or on a copy.

Then do the second pass, and that is the one that tells the truth: group the same measure by machine and sort by number of visits. You will almost always find that twenty per cent of installed machines generate between fifty five and seventy per cent of the visits. Those machines are the scope of the first release, and they are also a sales list: some of those installations do not need better service, they need replacing, and a system that tells you so with numbers helps you sell.

And there is a third calculation, the most convincing one when you have to explain the project to a partner: take twenty second visits at random from the last six months and, for each one, ask the technician who went why he had to go back. Not in a meeting, one by one, in the workshop. The answers group into four or five causes, and usually two of those causes account for more than half the cases. Those two are the specification for your project, written by your technicians instead of by the software salesperson.

Three warnings, because the measure is easy to distort without meaning to. Exclude planned maintenance, otherwise you count as a second visit the periodic service that happens to fall twenty days later. Exclude jobs on new machines in the first ninety days after commissioning, because returns there are normal and say nothing about your process. And count second visits even when you did invoice them: the fact that the customer paid does not mean they did not cost you, only that they have not complained yet.

The four thresholds, and what you can do at each one

Under ten per cent: diagnosis works. Your technicians arrive knowing what they will find and with the right part, and it is almost always because they are few, good and know the installations by heart. It is an excellent result and also a risk: that knowledge lives in three people's heads, and when one of them retires the rate explodes. Here software will not bring you margin straight away, it will bring continuity, and the right spend is a module of your ERP, not a project.

From ten to twenty per cent: the part is missing, not the skill. This is the most common band. The fault is correctly diagnosed but the part is not in the van, or it was there and the system did not know. The recovery comes from two things only: van stock managed properly and a history of parts fitted per serial number, which tells you which parts fail on which model and therefore what must always travel. It is also the band where the return shows up fastest, usually within six months.

Over twenty per cent: you do not know what is installed. The technician discovers the configuration of the machine when he is standing in front of it. It happens almost always to companies that build to order and have made modifications over the years without recording them anywhere. Here the installed base is worth more than any technician app, and it is the only case where I recommend spending on the data before spending on the software. The return is the highest of all, but the project is also the longest.

Never measured: you do not know. This is the most common case, and it is not a failing: nobody asks for that number, neither your accountant nor the person selling you the software, who would rather talk about how good the scheduling board looks. It is also the best case, because measuring costs one day and tells you, before you spend a euro, whether you have a thirty thousand or a three hundred thousand euro a year problem.

The installed base is the project, the app is the tip

Demos always show the app: the technician opening his phone, signing with a finger, taking a photograph. That is the easy part and the cheap part. The part that decides whether the project works is another one, and nobody talks about it: knowing what you have installed at your customers, machine by machine. Without that, the app is an electronic notepad, and it will give you more legible job sheets and nothing else.

The eight pieces of information in the table above are the minimum. Look at them one by one and ask yourself where they live in your company today: the answer is almost always "on the project drawing", "in Stefano's head", "in the files in the archive", "on the sales rep's phone". It is not sloppiness, it is the natural result of twenty years in which nobody had a place to put them. You can run the test this morning: take three serial numbers at random sold between five and ten years ago and try to answer those eight questions in ten minutes without phoning anyone. If you cannot, you have just found the cause of your second visits.

How to build it without stopping the company

The typical reaction, once you understand that you need the installed base, is to imagine a six month project to survey one thousand nine hundred machines. That is the best way never to do it. The method that works is the opposite, and it rests on three rules.

First: do not survey everything, survey what calls you. Twenty per cent of machines generate the majority of visits, and those machines survey themselves within a few months, because technicians go there. The rest you will survey when and if it matters, and for many it never will because the customer has already scrapped them without telling you.

Second: the survey is done by the technician while he is there, not by a clerk in the archive. The first time a technician opens a job on a machine that has not been surveyed, the system asks him for four fields, not forty: model, serial number, year, and a photograph of the nameplate. Four fields take two minutes, forty fields never get filled in. The rest enriches itself, job after job, because every part fitted and every modification made becomes the history of that machine.

Third: start from what you already have. The delivery notes of the last ten years have customer, date and often the serial number. Production orders have the configuration. The two archives cross referenced, even roughly, give you the first version of the installed base in a week of work rather than six months. It will be dirty, and that is fine: a dirty installed base that technicians correct is infinitely more useful than a perfect one that does not exist yet.

One thing to decide early, because changing it later is expensive: who owns the machine in your system. It sounds obvious, it is not. Machines get resold, customers merge, a plant closes and the line moves. If you attach the job history to the customer rather than to the serial number, the day that machine changes hands you lose ten years of history. Attach it to the serial number, and keep ownership as a fact that changes over time.

Spare parts: the warehouse that travels in the vans

In a service business the warehouse is not a place: it is one place plus nine vans, and the nine vans often hold more value than the place. Until those vans are real stock locations in the system, with movements in and out, everything else is approximation: you do not know what you have, you do not know what to invoice, and the year end stocktake produces a difference that gets written off and forgotten.

The practical rule is simple to state and hard to apply: every van is a stock location, every part loaded is a transfer, every part fitted is an issue linked to a serial number. The hard part is not technical, it is habit: the technician taking a part off the shelf at seven in the morning with nobody watching needs a way to record it that costs him ten seconds, not two minutes. If it costs two minutes he will not do it, and you will have paid money to get the same wrong numbers as before, with more effort.

Ten seconds means one thing only: scanning a barcode or a QR code with the phone he already has in his hand, and confirming. Everything else, which location it leaves, which van it enters, who took it, the system knows by itself. Labels cost little and can be printed in house, and they are the part of the project with the best ratio between cost and result, by a distance.

The second decision is what has to be on each van, and here the system only helps you if you have history per serial number. With two years of parts fitted per model, you know which ten codes account for seventy per cent of the replacements on that model, and you know that the technician going out to that family of machines must carry them. Without that history, van stock is decided by the workshop manager's experience, which is a good criterion for as long as that person is there.

Then there is the subject nobody enjoys tackling: parts fitted under warranty and recoverable from the supplier, for those who resell other people's products. Every manufacturer has its own procedure, its own deadlines and its own form, and claiming by hand costs more than it recovers, so it does not get done. If the digital job sheet collects from the start the fields the manufacturer asks for, the claim becomes an export instead of a job, and that line of income starts existing again. In the companies where I have seen it done, it is worth between fifteen and forty thousand euros a year that used to be left on the table.

Contracts and response times: where margin leaks unnoticed

The service contract is the most profitable product you can sell and also the one that can lose you the most money, and the difference between the two cases is one piece of data almost nobody has: how many hours and how many parts that contract consumed in the last year, compared with what you invoiced.

To have it, the system has to do three things from day one. The first is to link every job to a contract, not just to a customer: the same customer can have three machines, one under warranty, one under contract and one on call, and if the technician does not know that while he is there, he will bill it wrongly one way or the other. The second is to deduct from the contract what the contract actually covers, which is often not a pot of hours but something subtler: two planned visits a year, labour included and parts excluded, travel included within fifty kilometres. The third is to show, contract by contract, the real margin.

The first time that list is sorted by margin, the same thing happens in every company: two or three lines at the bottom with a minus sign, and they are almost always long standing customers whose price nobody ever dared to touch. It is not a disaster and it is also an opportunity: with the numbers in hand, that conversation becomes possible. "In the last year we made eleven visits to this machine, the contract covers four, and the fee has not moved since 2019." Three honest options come out of that: update the fee, reduce the cover, or propose replacing the machine, which for you is a sale and for the customer is the end of the breakdowns. Without the numbers, none of those three conversations ever starts.

The same applies to response times. Many contracts contain a promise, twenty four or forty eight hours, written years ago without knowing whether it was sustainable. A system that measures the time between call and arrival tells you two things: how often you actually meet it, which is usually less than you think, and what meeting it costs you, because every promise of a fast response is a technician you have to keep free. If you find that you meet it seventy per cent of the time, you have two honest choices, organise yourself to get to ninety or rewrite the promise. What you can no longer do is not know, because the customer knows.

Companies that also work on projects have one more problem, namely deciding when the project ends and service begins, and it is not an accounting nicety: those are hours that somebody has to book somewhere. The criterion that works is the date of accepted commissioning, and I set out the rest of the rules in job costing software.

The technician app: why it fails and how to get it adopted

This is the number one reason these projects fail, and it is not resistance to change: it is that the app does not work where technicians work. Technicians work in basements, in steel clad sheds, inside cold rooms, in electrical substations, on rural sites, in factories that deliberately block the signal. An app that needs a connection to save a job sheet, in those places, loses two hours of work.

It only has to happen twice. The technician who has lost a job sheet twice will never open that app with confidence again: he will keep writing on paper and copying it up at the end of the week from memory, and you will have achieved the worst of both worlds. The chart above is not a theoretical simulation: it is what you see comparing companies that chose a tool that works without coverage with companies that never thought about it because the office had good signal.

Working without a connection means something precise, and at selection time it has to be verified with a test rather than with a question to the salesperson: the technician must be able to open the job, see the machine record and its history, record hours, parts, notes and photographs, get the customer's signature and close, all with the phone in flight mode. When he gets back into coverage, the system synchronises by itself. If the supplier's answer contains the word "partially", you already have your answer.

The second reason for failure is the number of fields. Whoever designs the digital job sheet is almost always whoever does the invoicing, and they would like to know everything. The result is a screen with thirty mandatory fields that the technician fills in at seven in the evening, tired, wearing gloves, in front of a customer waiting to sign. The rule I use is strict: the standard job sheet has to be closable in under ninety seconds with the phone in one hand. Anything that does not fit into ninety seconds must be optional or pre filled by the system.

The third reason is that nobody explained to the technicians what it is for. If the only message is "from now on record your hours on the phone", the message that arrives is "from now on you are being monitored", and the reaction is predictable. The right message is different and it also happens to be true: you arrive at the customer already knowing what is fitted and what your colleagues did on the three previous visits, the part you need shows up in your van or in Marco's twenty kilometres away, and you no longer have to copy anything up on Saturday morning. In companies where that conversation was handled well, and ideally led by the workshop manager rather than by management, adoption reaches eighty per cent in six months. Where it was not, people argue about it for two years.

One small thing that is worth more than many features: the customer's signature on the phone, with the job sheet emailed automatically before the technician drives out of the gate. It removes ninety per cent of later disputes, because the document arrives while the customer still remembers what was done, and it makes the invoice much harder to argue with.

What it costs: ERP module, subscription product or custom system

The figures below are what I see on the Italian market for a company of the reference size, fourteen people in service and one thousand nine hundred installed machines. They are there to tell you which order of magnitude you are in before you ask for quotes, not to replace them.

The service module of the ERP you already own. Between six thousand and twenty five thousand euros of setup plus a fee between one hundred and twenty and five hundred euros a month. The advantage is large and underrated: customers, items, spare parts and invoices are already there, so there is no integration to build, and integration is the item that blows budgets. The limitation is that almost all these modules start from the job rather than from the machine, and the technician app, where there is one, is often a web page that does nothing without a connection. It is the right choice if your second visit rate is under ten per cent and what you mainly want is administrative order.

A subscription field service product. Between twenty five and sixty euros per technician per month, so for fourteen people between four thousand two hundred and ten thousand euros a year, plus a setup between twelve thousand and forty five thousand euros. Watch that second figure, because that is where the real project hides: loading the installed base, defining job types, integrating the ERP for customers, items and invoices. These products are mature, the app often works without coverage, and if your work resembles what they were designed for they give you in three months what a custom project gives you in nine.

A custom system. It starts at forty thousand euros for the base that actually matters: installed base per serial number, technician app that works without a connection, job sheet with hours and parts, van stock, contracts with consumption deducted, and integration with the ERP for customers and invoices. It reaches one hundred and sixty thousand with assisted scheduling, a customer portal, machine telemetry, supplier warranty claims and margin reporting per contract. Annual maintenance runs between fifteen and twenty per cent, and it is not optional. It makes sense when your product is so particular that no standard system can represent it, or when service is part of your competitive advantage rather than an accessory.

The threshold. Under eighteen thousand euros a year of total service software spend, fees and amortisation included, the product almost always wins: custom does not pay for itself, and the time it takes you costs you twice. The break even between the two paths falls between year four and year five, as in the chart, which means the right question is not "which costs less" but "in five years will this still be an accessory function or will it be how my company stands out". It is the same reasoning that applies to any choice between packaged and bespoke software, and I set out all the criteria in business management software, off the shelf or custom.

Two items that almost never appear in quotes and that should be budgeted from the start. The first is the technicians' phones or tablets, which have to be rugged and last until evening: between two hundred and six hundred euros each, replaced every three years. The second is internal time, that is your own people following the project, loading data, testing, teaching colleagues: between twenty and forty person days in the first year, and if nobody in the company can put those in, the project is not ready to start, whatever you buy.

Where to start: the first release in ninety days

The first release does not have to be complete, it has to be useful to somebody within three months. This is the order I use, and every step before the software costs little and is worth a lot.

Week one: measure. Run the second visit query, look at which machines generate most of the visits, and talk to twenty technicians or about twenty jobs, one at a time. By the end of the week you must have a number and two main causes. With those two things in hand, every conversation that follows, including the ones with suppliers, becomes concrete.

Weeks two and three: the first version of the installed base. Cross reference delivery notes and production orders from the last ten years, keep the machines that had at least one job in the last three, and accept that it will be dirty. For the reference manufacturer that is about six hundred machines out of one thousand nine hundred, and it is the right list: the rest will be added by the field.

Week four: decide how you invoice, in writing. Which jobs are chargeable, what each type of contract covers, how travel and expenses are treated, who decides whether a job is under warranty. It sounds like administration, it is the part that determines half the fields of the job sheet, and if you do not write it beforehand you will write it inside the software, which is the most expensive place to write it.

From month two: the first release to the technicians. Three things only: the machine record with its history, a job sheet with hours and parts that works without a connection, signature and email to the customer. No automatic scheduling, no customer portal, no telemetry. Start with two or three volunteer technicians, not with everybody: those who go first become those who teach the others, and the project stops being a management initiative.

Month three: vans and contracts. Labels and codes on spare parts, every van a stock location, and the first list of contracts with their real margin. That list is also the first result you can take to a partner or a board, and it is usually the moment when the project stops being an expense and becomes something to extend.

One last piece of advice on what not to do first. Automatic route scheduling, the feature that promises to optimise journeys, is the one that sells best and is needed last: without a reliable installed base and without job durations measured in the field, it optimises wrong data and produces schedules that technicians unpick the same day. It comes later, and when it comes it works.

If the number says this is not your problem

It can happen, and it is worth saying because almost nobody says it. If your second visit rate is under ten per cent, if job sheets arrive within three days and if the spare parts stocktake adds up, field service management software will not give you margin back: it will give you order, continuity when people change, and numbers to make decisions with. Those things are worth having, but they are worth the price of a module, not of a project.

In that case the bottleneck is almost always somewhere else, and in companies like yours it is one of these three: quotes that take three weeks instead of two days, production data that does not tell you what a job really cost, or the fact that customers have to phone somebody for anything at all. Those are three different problems with three different solutions, and spending on service to solve them would be like buying a new van because the warehouse is untidy.

And there is one case where software is not the answer even when the numbers are bad: when second visits come from a problem with the product. If one family of machines has three times the visits of the others, no management system will save you, it will only tell you precisely what that defect is costing. Which, incidentally, is already an excellent reason to measure: service is the only place in the company where the real quality of what you design and build becomes visible, and most manufacturers never look at that data.

If you have read this far you probably have a scene like the whiteboard in mind, and a fairly precise idea of which of the five cost items applies to you. Measure your second visit rate before watching any demo: it is one day of work, it costs nothing, and it tells you whether you are buying margin or just order. From there on the decisions are much simpler, and you make them yourself instead of letting the most convincing quote make them for you.