Field Service Report Software: When the Spreadsheet Template Stops Being Enough

Most teams start with a report template in Excel or Word. Most should move to an off-the-shelf tool. Some, the ones whose report is tied to shipping, freight and approvals, need something built. Here is how to tell, with a California example we put in production in a day.

Oct 16, 2026

A workshop shipping bench with a crated machine part, a label printer, and one glowing record printing two sheets, one to a clipboard and one into the crate

Field service report software lets a technician record a visit or a repair (customer, equipment, fault, work done, parts, sign-off) and turns it into a report for the customer and a record for the office. Most teams start with a template in Excel or Word. Most of them should move to an off-the-shelf field service tool, which handles dispatch, reports and invoicing well for a monthly fee. A smaller group shouldn't. These are the teams whose report is tied to things those tools don't model: shipping machines between their own sites, freight calculations, authorizations that must exist before anything leaves the building. For them the spreadsheet grows until it becomes the system. Below: what a report needs, how to tell which group you are in, and a California example we replaced in a day.


What a field service report should contain

  • Customer and site, with contact details that come from a customer record, not retyped each time.
  • Equipment: model and serial number.
  • The reported fault and the diagnosis, which are not the same thing.
  • Work performed, parts and materials used, time on site.
  • Follow-up actions and their owner.
  • Sign-off from the technician and, where the contract requires it, the customer.

If parts or machines are shipped, add what went in the box, how it was shipped, and the tracking number, linked to the same record.

Keep Excel, buy, or build?

Keep the template while one or two people write a handful of reports a week and nothing downstream depends on them.

Buy an off-the-shelf tool when your process is the common one: schedule a visit, do the job, write the report, invoice. Field service platforms do that with mobile apps, signatures and accounting integrations, for far less than anything custom. This is the right answer for most service businesses.

Build when the report is the middle of a process the tools don't cover, and you can see the signs:

  • your team copies a form tab in a shared workbook for every job;
  • the same record has to print two different documents, for different readers;
  • rules exist on paper but nothing enforces them ("never ship without a tracking number");
  • someone works out weights, volumes or freight classes by hand every time;
  • the workbook has quirks only one person understands.

A real example: one workbook, two documents, a day to production

A California company that sells, installs and repairs industrial manufacturing equipment ran its shipping from one shared Excel workbook. Every shipment started as a copy of a form tab. A technician or office manager filled in the customer, the machine, the fault, the repair and what went in the box, then printed two documents from two ranges of the same sheet.

The workbook had grown by hand for years. Two unrelated tables shared rows by accident of layout. Phone numbers sat in the same columns as shipping items. Codes were prefixed with an underscore to stop Excel reformatting them. Nothing was enforced: a package could be marked shipped without a tracking number, a request could go out without written authorization, and freight figures were worked out against a printed lookup table every time.

What we built:

  • The workbook as the specification. Its structure told us what one shipping request is. Its quirks told us what the import had to survive, so every column is read by its header and every block is checked before it is trusted.
  • Two flows, because small packages and freight are shaped differently. Freight moves between the company's own sites in both directions, and the billing term follows from the route instead of being typed. Each crate has its own dimensions and weight, and the carrier figures calculate live as the crate table fills in.
  • One record, two documents: the internal service report, and the packing slip that goes in the box, with no diagnosis or pricing on it.
  • Stages that enforce the rules. A request cannot ship without a tracking number or close without an arrival date.
  • The team's existing Microsoft sign-in, and a Slack message when a request is submitted.

Results: staging was up the day after we received the workbook, production followed that evening, and the team's iteration requests have shipped the same evening they were asked for. The full write-up is in the case study.

What it costs

Our prices are published. A first useful slice covering one process, like this one, is $5,000 to $18,000. A complete business application with several processes and integrations is $18,000 to $45,000. Running it, with hosting, monitoring and a monthly allocation of changes, starts around $470 per month. You own the code.

If an off-the-shelf field service tool covers your process, buy it. We will tell you so on the call.

Related: the shipping platform case study, custom manufacturing software, and low-code, no-code or custom?

Read next: is QuickBooks Desktop going away?, ERP implementation failure.