Field service tool with post-calculation and purchasing control

Work and material consumption on site were not registered in a structured way, which meant invoicing and purchasing happened on estimates. We set up a field service tool with existing SaaS platforms, connected by API to the software that was already there. Employees register every completed step of a project on site, those registrations are turned into a post-calculation per project, and consumption is made available on an annual basis as management information for purchasing.

With work away from the office, the truth about a project sits with the people carrying it out. What exactly was done, how long it took and what was consumed happens on site and not at the office. If that is not recorded at the moment itself, after a few days it only exists as a memory. That was precisely the case here.

That affects two processes at once, and they are exactly the two where the money passes. Invoicing starts from what people think they delivered instead of from what was actually delivered. Purchasing orders on gut feeling, because actual consumption does not exist as a figure anywhere. Both problems have the same cause, and therefore the same solution.

Each link solves part of the problem, and only together do they change how the company invoices and orders.

The platforms used are not named in this document. We explain the technical choices and connections in a conversation.

Invoicing starts from work actually delivered, so an invoice is defensible when a customer asks about it. The project is transparent afterwards, so it becomes visible what an assignment actually cost instead of what it should have cost. And purchasing gets annual consumption as a figure in hand, which means orders match actual consumption more closely and cash flow improves.

It shows up in every organisation where people work outside the office, where time and materials are consumed on location and where administration afterwards has to reconstruct what happened. A company repairing floors, an installer, a technical service or an agency sending crews and materials to a location: the same three breaking points every time.

We do not start with software. Every trajectory starts with a screening: interviews on site with the people who do the work, a mapping of the process as it really runs today, and a prioritisation of what should be tackled first. Only then do we determine what gets built, how big it gets and in which order it is rolled out. The most expensive mistake in this kind of project is building a tool around a process nobody has properly mapped out.

That order also determines the budget. After the screening you know what needs to be built and what it costs, instead of having to decide up front about something that is not yet sharp.