Facility-maintenance companies coordinate a lot of moving parts: requests from many clients and sites, technicians spread across a city, parts and materials, deadlines written into contracts, and invoices that depend on what was actually done. Many of them run all of this on phone calls, WhatsApp groups and spreadsheets until the volume makes that impossible.
I designed, built and run NeonTask, a field-service platform for facility-maintenance companies that is in daily production use with multiple service companies. Work orders from many clients come in, get dispatched to technicians, and are tracked through to invoice and payment. This post covers what this kind of software needs to do, from that experience.
The core flow
Everything revolves around the work order:
- Intake. A request arrives: from a client portal, an email, a phone call logged by a dispatcher, or a scheduled preventive task.
- Triage. It is categorized, prioritized and linked to a client, a site and, if relevant, an asset.
- Dispatch. It is assigned to a technician or team, with a scheduled time.
- Execution. The technician travels, checks in, does the work, records notes, photos and parts used, and checks out.
- Review and closure. A supervisor reviews and closes the job, and the client is informed.
- Billing. The completed work feeds invoicing, receivables and reporting.
If any step happens outside the system, the data breaks down. The goal of the software is to make each step easier in the system than outside it.
Intake: getting requests in cleanly
Requests arrive in different ways, and the software has to accept all of them without making dispatchers retype information:
- A form or portal for clients, with site, category, description and photos.
- Quick entry for dispatchers taking phone calls.
- Recurring schedules for preventive maintenance.
Each work order needs a clear status from the start, and a unique reference that everyone, including the client, can use.
Dispatch: the dispatcher's view
Dispatchers need to see the whole operation at a glance. In NeonTask, the Next.js web app gives dispatchers and admins intake, queues, a list, a map and a schedule. Each view answers a different question:
- Queues: what needs attention now, by priority and age.
- List: everything, filterable by client, site, status, technician and date.
- Map: where jobs and sites are, to group nearby work.
- Schedule: who is doing what, when, and where the gaps are.
Assigning a job should take seconds, and reassigning when a technician is delayed should be just as quick.
The technician app
Technicians are in basements, on rooftops and in traffic. Their app has to be simple and dependable:
- Today's jobs, in order, with addresses and directions.
- Job details: site contact, access notes, history at that site.
- Check-in and check-out, so time on site is recorded.
- Notes and photos, before and after.
- Parts and materials used.
NeonTask's technician app is built in React Native for iOS and Android with exactly these jobs, check-ins, notes and photos. Connectivity on site is often poor, so the app should keep working and sync when the signal returns. I wrote about that in building apps that keep working on unreliable connections.
Keeping clients informed
Facility managers on the client side want to know what is happening without calling the dispatcher. Status updates when a job is scheduled, started and completed, with the technician's notes and photos attached, answer most of their questions before they are asked. A client view of open and closed work orders, scoped strictly to that client's own sites, reduces calls further. Every update the client receives should come from data the technician already recorded, so nobody has to write a separate report by hand.
SLAs and accountability
Maintenance contracts often define response and resolution times. The system should:
- Attach the right SLA to each work order based on client, site and priority.
- Show how much time is left and highlight jobs at risk.
- Record timestamps for each status change automatically.
This turns arguments about "you were late" into facts, which protects both the company and the client relationship.
Parts and materials
Parts are where money leaks. Track what was used on each job, from which stock, and whether it is billable to the client. Even a simple parts list per job, without full inventory management, improves invoicing accuracy a lot. Full stock tracking can come later if the business needs it.
From completed job to invoice
The work order history is the basis for billing: labour, parts, call-out charges and contract terms. NeonTask covers receivables, payables and reports, so the company can see what it is owed and what it owes without rebuilding everything in a separate spreadsheet. Even if the accounting itself happens in another system, the operational data should flow there cleanly through exports or an integration.
Reports
Useful reports for a maintenance company:
- Work orders by client, site, category and status.
- SLA performance by client and period.
- Technician workload and time on site.
- Revenue and outstanding receivables by client.
- Repeat issues at the same site or asset.
Clients increasingly ask for these reports too, so being able to produce them quickly is a commercial advantage.
Architecture choices that matter
A few decisions from NeonTask that I would make again:
- One API for every app. A .NET Core API serves the web app and the technician app for clients, sites, work orders, SLAs, technicians, parts and finance. See API design for a mobile backend.
- Each client company on its own deployment. Data separation is simple and strong, and each company can be updated on its own schedule. I compare this approach in multi-tenant or per-client deployments.
- Dockerized services and CI/CD. Every change is built and shipped by a pipeline, which keeps deployments to several companies routine. See a CI/CD pipeline for a small team.
Off-the-shelf or custom?
There are field-service products on the market, and for a company with a standard workflow they can be a good start. Companies usually look at custom software when their contracts, SLA rules, reporting requirements or billing models do not fit, when they need Arabic and English, or when they want to own their data and platform.
Rolling it out
Software is only half the work. A rollout that sticks usually:
- Starts with one team or one client's sites.
- Trains dispatchers and technicians on real jobs.
- Stops the parallel spreadsheet on a fixed date.
- Collects feedback weekly in the first month and fixes the friction quickly.
Technicians adopt the app when it saves them phone calls and paperwork. Make that true from day one.
Common mistakes
- A technician app with too many fields to fill.
- Dispatch views that do not show the map and the schedule together.
- No timestamps, so SLA performance cannot be proven.
- Parts recorded on paper, then lost.
- Building every report before the core flow works.
If you run a maintenance or field-service company and your operation has outgrown phone calls and spreadsheets, see the NeonTask case study and get in touch. A demo is available on request.