From the Job Card to the Invoice: What a Field Service App Has to Capture in Version One

Start at the invoice and work backwards

Most feature lists for a technician app are written by looking at the day forwards. The technician arrives, opens the job, does the work, closes the job. That version reads well and still produces an app that the office cannot bill from, because the office needs facts the technician never had a field to record.

The faster way to scope version one is to sit with whoever raises invoices and ask a single question: for the last twenty jobs, what did you have to chase before the invoice went out.

The answers are always concrete. Hours that did not match the schedule. A part fitted but never written down. A visit that turned out to be under a maintenance agreement after the invoice was already drafted. A photo that lived in a chat thread.

That list is the specification. It is also short, which is the point, because a first version that covers it can ship in weeks rather than quarters, and everything else has a second version to go to.

The four records that decide the bill

Across HVAC, facility maintenance and inspection work, the same four records carry the invoice. Everything else in a field service app is either navigation around them or reporting on top of them.

Notice what is not on that list. Route optimisation, a customer portal, van stock across the whole fleet, quoting, dashboards. All of them are reasonable, none of them changes whether an invoice can leave the building this week.

Coverage is where HVAC work breaks generic tools

In HVAC the maintenance agreement is the business model, not a discount scheme. It says how many visits a site gets a year, which units are included, what happens to parts, and what a callback inside the guarantee period costs the company rather than the customer.

Every one of those clauses turns into a decision on a Tuesday morning about whether an engineer is doing paid work or covered work.

Generic tools model a customer, a job and an invoice. They rarely model an agreement that sits above all three and quietly changes the answer. They almost never model the unit itself as the record that carries its own history, serial number, refrigerant charge, warranty dates and every visit it has ever had.

That gap is why service companies end up running a spreadsheet next to the platform, and it is the same gap we describe on the page about custom HVAC software development.

For a first version you do not need the full contract engine. You need the app to answer one question on arrival, in one line, with the entitlement behind it: is this visit covered, and by what.

Time is the number people argue about

Labour is usually the biggest line on the invoice and the only one recorded from memory. That is why a timer sounds trivial and turns out not to be.

On TimeFix, the work timer had to keep counting when the technician locked the screen, and keep counting when a call was placed from inside the app.

That requirement was not in the original assumptions. It appeared once real technicians used the app on real jobs, because that is how they work: screen off in a plant room, phone to the ear with the office, hands on the unit.

Two things follow for anyone scoping a first version. Requirements like this only surface in the real environment, so plan for your own crew to use the app on live jobs while it is still being built. And treat time as a record with a start, a stop and a reason for every gap, not as a number typed at the end of the day.

Captured means written to the phone first

A basement plant room, a rooftop unit, a site with one bar of signal. The invoice trail cannot depend on connectivity at the moment the work happens, so every one of the four records is written to the device first and syncs when the phone comes back.

This is where the word offline needs a definition before it goes into a scope document, because it means three different things and the price depends on which one you mean. We wrote the long version in what offline mode in a mobile app actually means, and the delivery side of it sits on the offline first app development page.

One practical warning from live use. When the app does not yet handle a case, technicians work around it, and the workaround is usually the notepad on their own phone. Those notes never reach the office, so the data in the system and the data on the job quietly drift apart. Whatever version one leaves out, it has to be something the crew can leave out too.

Where the record lands

The invoice is raised somewhere already: an accounting system, an ERP, a service platform, sometimes a spreadsheet that has run the company for a decade. Version one does not have to replace it.

It has to reach it, in a format the office can post without retyping, and it has to be clear which side holds the truth for customers, sites and units. That decision usually moves the schedule more than any screen in the app, so it is worth settling before the design starts.

The three routes in, and what each one costs in weeks, are laid out in our guide to mobile app integration with existing systems. If the question in front of you is still whether to build at all, that argument is in build or buy field service software.

What waits until version two

Cutting scope is easier when the cut has a reason attached. These are the parts we most often move out of a first release for service companies, and why they survive the wait.

• Dispatch and route optimisation. The office already assigns work in a way that reflects skills, certificates and customer relationships. Automating that judgement is a project of its own, and a wrong assignment is more expensive than a longer drive.
• Customer portal. Useful, visible, and dependent on the record being trustworthy first. Publish a service history to customers before the history is complete and you generate calls rather than remove them.
• Van stock across the fleet. Accurate inventory needs discipline at the depot as well as in the app. Start with parts used on the job, which is what the invoice needs, and add stock levels once that data proves reliable.
• Quoting from the field. Prices, margins and approval rules pull in a second set of stakeholders. Capture the finding and the recommendation in version one, and let the office turn it into a quote.
• Dashboards and reporting. Three months of clean records make useful reports. Three months of guesses make convincing looking charts of nothing.

The same principle applied to a product rather than an operation is in our piece on what to build, what to do by hand and what to postpone.

Measure your own operation for one week

Before anyone quotes you, this costs a week and nothing else. Take your own jobs, not an industry average.

• Count the calls. How many invoices this week needed a phone call or a message to a technician before they could be raised.
• Time the gap. Days between job completed and invoice sent, per job, and the worst case rather than the average.
• Count the retyping. How many lines somebody keyed in from a paper card, a photo or a chat message into the system that holds your money.
• Count the disputes. Jobs where a customer questioned hours, parts or whether the work was covered, and how long each one took to settle.

Those four numbers are what a build has to move. They also make the conversation with any supplier concrete, and they are what we start from in an app discovery workshop before a scope and a fixed number exist.

What this shape of project asks of you

A technician app plus a backend and a simple office view is a real project, not a weekend build, and the parts that slip are rarely technical. The two causes we see most often are store and service accounts not being ready, and no single person on the client side who can decide when two departments disagree.

The commercial side is easier when the scope is written down properly. We work on a fixed price basis, with the scope agreed before the start and current ranges on our pricing page.

The drivers behind a quote for this exact shape of product are broken down on field service app development cost, and how the weeks are actually spent is in the mobile app development timeline.

We build these as one Flutter codebase for iOS and Android with the backend and the web view your office needs, from Krakow, as a team of nearshore Flutter developers working on European hours. The delivery detail for this vertical sits on the field service app development page.

Related guides