The system a field service business runs on.
The business ran its operation on a Google Apps Script application built around spreadsheets. It worked, until the business outgrew it. Operi replaced it with a single system covering the whole operation — inquiry, quote, project, schedule, field execution, invoice and payment — plus a separate pipeline for public-sector bids.
The spreadsheet had become the system.
This is the ordinary path. A spreadsheet solves one problem, then another gets added, then a script automates part of it — and eventually an entire operation depends on something nobody designed. The business vocabulary was sound. The statuses, the lifecycles, the idea of who was allowed to do what: all of that had been learned the hard way and was worth keeping.
What could not be kept was the architecture. A field service operation has real complexity underneath it — recurring agreements, crews and equipment, property access restrictions, drive time between jobs, deposits that land before the invoice they pay, sales tax that varies by jurisdiction, and a public-sector bid process running alongside all of it. None of that fits a grid of cells.
One system, covering the work from first inquiry to final payment.
Customers, properties and access facts
Customer and property records with duplicate detection, fast prefix search, and an approval workflow where a lower-privilege user proposes a change and a reviewer accepts or rejects it field by field.
Property access details — gate codes, site notes, restrictions — are stored as structured facts rather than free text, so the field app can surface exactly what a crew needs on arrival.
Quoting and estimating
Quote requests become quotes, and every sent quote is immutable. A change raises a new version that supersedes the old one, snapshotting the customer, property, scope, measurement, line items, staffing plan, tax configuration and expiry at the moment it was sent.
Selling price and internal cost are tracked separately on every line — neither derives from the other. Branded PDF quote documents are generated in the browser, and follow-ups are raised automatically two days after a send is recorded.
Property measurement
Map-based area and perimeter measurement with exclusion zones, versioned so an estimate can always be traced back to the measurement it was priced from.
Built on Google Maps Platform, with measurements stored as first-class records rather than notes.
Scheduling and routing
Weekly board, day panel, month view, timeline and a separate mobile schedule. Unscheduled work is first-class rather than missing, so nothing falls through a gap between screens.
Route order is stored explicitly, never inferred from start times. Drive times come from the Google Routes API rather than straight-line guesses, and every estimate records whether it came from the provider, a person, or a default — unknown legs stay unknown instead of being filled in.
Field execution
A mobile-first flow: today's work, navigate, arrive, site briefing, before photos, work, after photos, complete. Crews see only the jobs assigned to them.
The site briefing is assembled field by field — site contact, access, critical restrictions, scope, equipment — deliberately not the entire customer record. Access scoping is enforced twice: once in the application and again independently at the database layer.
Invoicing, payments and job costing
Invoices, payments, payment applications, reversals, expenses, per-job labour settlement, bank import and reconciliation, and sales tax by jurisdiction frozen onto the document.
All money is handled as integer cents. Payments and their applications are separate records, so a deposit taken in one month can part-pay an invoice raised later — and the system can move money backwards through corrections and reversals when reality requires it.
Government bid pipeline
A parallel lifecycle for public-sector opportunities: solicitations, bid/no-bid decisions with recorded reasons, submission and award dates, and conversion of a won opportunity into a contract with milestones.
Requirements like bonding and insurance are tracked as yes / no / unknown rather than a checkbox, because 'not stated in the solicitation' is different from 'not required'. A no-bid is a decision that can be reopened, not a deletion.
Operational visibility
A 'needs attention' engine surfaces what is actually wrong across sales, scheduling, operations, finance, employees and compliance, grouped by urgency. Nineteen report datasets are exportable to CSV and XLSX.
Reports state whether a figure is a total or a sample — a small detail that stops a partial number being read as a complete one.
The old system stayed running the whole time.
A business cannot stop operating while its software is replaced. The existing Apps Script platform was kept live until the replacement had been proven against real work, and the cutover to real business records was treated as an explicit step with its own checklist — at which point all seeding and development tooling was switched off, because the database now held real customers.
Existing customers were brought across through a guided import that parses the spreadsheet in the browser and walks through mapping, review and a summary before anything is written. The file is never uploaded anywhere.
A meaningful share of the work after launch came from watching the system meet reality: a won job that reached nobody, a crew opening a job that did not say where to go, an invoice raised from a quote that had lost track of which project it paid for. Those are the defects that only appear when real people use software to do real work, and they were treated as the point of the exercise rather than an embarrassment.
Built to be maintained.
Two decisions are worth calling out because they shape everything else. Business time is pinned to a single zone rather than read from whatever device someone happens to be holding, so a job scheduled for Tuesday is on Tuesday for everyone. And every integration that has not been switched on is an honest gap rather than a hidden failure — the system records that a quote was sent by a person, instead of quietly pretending to have emailed it.
In pilot, on real records — and honest about what is not finished.
The system is running as a client pilot against real business data. Several capabilities are built and deliberately switched off rather than half-delivered — a customer portal, public quote acceptance and online payments among them. They are complete code waiting on decisions, and the interface says so plainly rather than showing a button that does nothing.
No efficiency or financial outcomes are claimed here. The prior system was never instrumented, so there is no honest baseline to measure against, and inventing a percentage would be worth less than saying that. What can be shown is the scope of the system, the decisions behind it, and the fact that a field service business runs its day on it.
Is your operation running on a spreadsheet nobody designed?
That is usually where this work starts. Bring the problem and Operi will tell you honestly whether software is the answer.