Replacing a field-service system without retraining the crew

The first job was an audit: every screen, label, field order and status of the old system captured in a document the build treats as the authority. Where the audit and the developer's taste disagree, the audit wins. Labels such as Tasks for jobs and Locations for sites are settings rather than code, and status text is read from a table, so a raw database value is never shown. New abilities (a sales pipeline, estimating, a portal) arrive as additions to familiar flows, not replacements for them.

Every table carries row-level security with office, manager, admin and technician roles; a technician cannot read sales records at all. Money is stored ex-GST and every total is computed by database triggers, so a browser can never send a number the database will believe. Changes to business records are logged to an audit table with who and when, records are archived rather than deleted, and a sales lead cannot move to the next stage until the fields that stage requires are filled in, with the database naming what is missing.

A read-only importer pulled clients, sites, contacts, tasks, quotes with their lines and timesheets from the old system's API, riding out its rate limits and page-size limits. A dry run measured the load before anything was written: The new platform's total calculation matched the old system's on all of about 2,850 quotes, 2,638 of them exactly and the rest within a dollar of rounding. Staff can also scan the old system from Settings at any time, see what is new, changed or gone, and import the difference with one click, so the two can run side by side during the move.

Technicians get an installable app with today's jobs, the job card, photos, notes and a clock on and off that records location. Clock events, notes and photos go into an outbox on the phone and sync when the signal returns, and tap targets are sized for one-handed use on a 375-pixel screen. Office staff install a separate office app, so neither group wades through the other's menus.

The crew already coordinated over group chats, so the platform has a messenger of its own: one conversation per job with the people booked on it and the office, a general chat per client, and direct messages. A photo sent into a job chat lands in that job's documents, and a message can be filed straight into the job notes.

The estimating assistant described in our separate case study is part of the platform: past proposals become a searchable library, and a plain-English brief becomes a draft in which the model names the parts and code sets every price. All model calls go through one layer that switches between providers, logs each run with its cost and enforces per-user and daily limits.

Checklists, safe-work method statements and service reports are signed on the phone and produce PDFs; a refrigerant log supports the licensing record that air-conditioning work requires; site surveys run offline; and a design studio places equipment, pipe and cable runs on a satellite map or floor plan. Each client gets one link to a portal showing their jobs, quotes (with online acceptance), reports, certificates and designs awaiting approval, and a way to report a fault.