Job intake
Requests from the website, phone, email and recurring contracts, captured with the address, the asset, the problem and the access details.
Solution
Dispatch, routing, mobile job capture and invoicing for businesses whose work happens at the customer address rather than in an office.

Overview
Field service management covers everything between a customer asking for work and the money arriving: scheduling the visit, getting the right technician there with the right parts, capturing what was done, and billing it.
The hard parts are the constraints. Skills, certifications, territory, vehicle stock, travel time and appointment windows all bound who can take a job, and a scheduler that ignores them produces a board that dispatch overrides by hand every morning.
We build systems where the constraints are modelled, the mobile app works without signal, and the paperwork from a visit becomes an invoice without rekeying.
Dispatchers and mobile crews coordinating work orders, equipment, parts and customer visits.
Scheduling has to respect skills, travel, parts and promised windows. A field application must show the last successful sync and distinguish pending changes from accepted work. Completion evidence belongs to the work order and equipment record.
Modules
Requests from the website, phone, email and recurring contracts, captured with the address, the asset, the problem and the access details.
A board showing technicians, jobs and travel, with constraint checks on skills, certification, territory and appointment windows, and drag to reassign with conflict warnings.
Sequenced routes with travel estimates, so a day is built from realistic drive times rather than equal length slots.
The technician view: today route, job details, history for the address, checklists, photos, parts used, signature capture and time on site, all working offline and syncing on reconnect.
Equipment recorded per address with model, serial, install date and every visit against it, so the third call on a unit is informed.
Stock by vehicle and warehouse, consumption recorded at the job, with replenishment triggers.
Priced from your rate card and parts catalogue, produced from the visit record, sent and paid without a second data entry step.
Recurring visit plans with entitlements, automatic scheduling of the next visit, and renewal tracking.
Booking confirmations, day before reminders, on the way notifications and post visit summaries, sent automatically with suppression rules.
Architecture
A typical implementation flow, with explicit responsibilities at each boundary.
Create the work order and reserve a qualified technician, slot and required stock.
Capture labor, photos, parts and exceptions with a bounded offline queue.
Review completion, update service history and hand approved charges to accounting.
Security and controls
Restrict property access instructions and customer data to assigned workers. Define device revocation and local-cache expiry. Audit changes to completion and invoicing states.
We select the final stack after reviewing your existing systems and operating requirements.
Security and IP practicesFit
FAQ
The app keeps working. Job data, photos and signatures are written to local storage with client generated identifiers, queued, and synced on reconnect. The technician sees what is still pending.
Yes. Routes are sequenced with travel estimates between addresses, and the board warns when a booking cannot be reached in the window.
They are modelled as constraints on the technician record with expiry dates. A job requiring a certification cannot be assigned to someone whose certification has lapsed.
Yes, against real availability, with the same constraint checks the dispatcher sees. The alternative, a request form that a person then reschedules, is also supported where you prefer a human step.
Yes. Stock is held per vehicle and warehouse, consumption is recorded at the job, and replenishment triggers when a line falls below its threshold.
No, and it should not. It integrates, sending invoices and reading payment status, so accounting stays the financial record.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.