A signed solar proposal goes in; a fully provisioned job comes out across every core company platform—document libraries, job workbooks, CRM, customer portal, work boards, field service, accounting and more—while scheduled jobs and automations carry it through crew scheduling, compliance certificates, STC lodgement, invoicing, receipts and close-out with virtually no manual handling. The result: 5,000+ staff hours reclaimed, administrative duplication removed, and the equivalent workload of 3–4 full-time roles eliminated—real operational value from a system the entire business now runs on.
Proposal in. Job out.
Connected platforms. One automated flow.
Proposal incustomer signsA customer signs a proposal. The sales platform and installer forms feed in the same way.
Receiververify · dedupeThe receiver is private, with no open ports. Every message is verified, and repeats are ignored.
Queuenever lostIf anything fails, the job picks up where it left off. Nothing is lost.
Orchestratorbuilds the jobThe orchestrator finds the deal, then creates the job and its documents across the connected platforms in one go.
Press play to hear it, step by step.
Staff consoleSSO · audit trailStaff can look up any job across every system, with single sign-on and an audit trail.
Deal registrysource of truthEvery signed deal is recorded once. Everything after it reads from that record.
Schedulertimed jobs and automations · rebates · scheduling · compliance · stock · reports · syncTimed jobs and automations see the work through. Rebates, crew scheduling and compliance certificates.
Foundationsecrets · sandboxing · security logs · backups · infrastructure as code · test gatesUnderneath, secrets are kept in a vault and backups are verified every night. Nothing changes untested.
Once a job exists, scheduled jobs and automations carry it from the week before install to well after the crew has left. Each one does a single piece of paperwork, on a timer or on an event, and leaves a person the decisions that need a person.
Scheduling and the crews
Every weekday morning the next day's install packs are assembled into one print-ready PDF; Friday's carries the weekend and Monday. The field-service platform gets each job as a task with its stock pick list, plus a calendar entry for each crew member, refreshed through the day. Crews fill in phone-friendly safety and checklist forms, and the work board reminds them on the day.
Network and meter applications
Each morning the jobs that need a distributor's pre-installation application go to the applications team as one workbook, a sheet per distributor. On the Ausgrid portal the connection application is filled in and stopped at payment, so a person reviews it and submits. Once an install is complete, the retailer's smart-meter request goes out with the compliance certificate attached.
Compliance certificates
Each day's completed installs get their electrical compliance certificate filled from the signed job data and the installer's licence, with a serial issued once per job and reused after that. When the crew's post-install form comes in with the customer's consent, the certificate is prepared for electronic lodgement with the NSW regulator; a person lodges it from the staff console, and the issued copy is filed back to the customer's records.
Rebates and warranties
Each install's rebate job is created on the rebate platform before the crew goes out: a Sunday-night batch for the week ahead, then a daily top-up for anything added mid-week. A return visit never gets a second one. A battery certificate ledger, rebuilt every morning, gives Finance an auditable record per job, and the panel warranty upload file builds itself each month.
Invoicing and receipts
At signing, the customer's accounting contact and a deposit invoice are raised, followed by a payment-reference email and one reminder. On the install day a draft invoice is waiting for the accountant, crediting the deposit so the two add up to the contract price. Paid invoices are receipted to the customer exactly once, the proof of payment lands in the CRM, and a daily sweep lists what is overdue by age.
Close-out and after
When a job counts as done, its field-service project is closed and the deal returns to Closed Won in the CRM. The work does not stop at handover: a fleet monitor watches about 1,700 installed systems, opens a support case when one drops offline for ninety minutes, and closes it when the system recovers.
Kept reliable
Built to be left running
The business runs on this system every day, including weekends and holidays. Reliability comes from a handful of rules applied everywhere, and from refusing to call anything a check unless it can fail.
Every change through the gates
A pull request cannot merge until six required checks pass: the unit suite against the locked dependencies, lint and formatting, strict type checking on the core packages, dependency drift and a vulnerability audit, security scans over the full history and the infrastructure code, and an image check that starts every app with a read-only root. Behind them sit 9,300+ automated tests on this system alone.
Deploys pulled, never pushed
CI holds no credential that can write to production. The server pulls the release from git itself, takes a lock, checks out cleanly so deleted files cannot linger, proves the app imports, restarts its services and writes a deploy record. The health endpoint reports the commit that is running, and a deploy never arms a new schedule: that is a deliberate, separate step.
Safe to run twice
Every automation that writes keeps a ledger: a sent-once log for customer emails, one serial per certificate, one open support case per system, a request id on every job-editor save. That is what makes catch-up safe. A timer that missed its run while the server was down runs on boot, and finds the work it already did.
Loud when it fails, and on quiet days too
Any automation that fails posts its name and log tail to the team's alert channel. The fifteen-minute mirror sync alerts only on a second failure in a row, so an upstream blip heals itself while a real outage still raises the alarm within about half an hour. The morning digest always sends, an "all quiet" email included, because silence would be ambiguous.
A trail for every decision
Every automation run is recorded with its start, finish and result, and so is each decision inside it: a job selected, skipped, held or failed, with a reason code and the sentence the automation printed. "Why wasn't this application submitted?" has an answer backed by evidence, and a daily watchdog lists what is overdue.
Evidence kept off the server
Each business-critical store is snapshotted every night, each one attempted on its own so a single locked file cannot stop the rest, and the copies leave the server. Security events go off-box within seconds, to a log store the servers themselves cannot alter or delete. A weekly clean-up deletes stale files that carry personal data.
What is changing now
Moving to Postgres, then into containers
The system grew up on SQLite stores on a single server. Both of those are changing, one step at a time, with evidence before anything depends on the new side.
In progress: the database move. Every store now writes to SQLite and to Postgres, while SQLite is still the one that is read. A job compares the two copies every night, and a verifier runs the same reads on both, so any drift shows up the morning after it happens. The soak has started, and the switch of reads is a script, rehearsed both ways on the sandbox. Reads move only after a clean run of nights, with SQLite kept as the copy for a few working days before it is retired. The method is in Shadow writes: proving a database move, the plan in Moving 30 SQLite databases to Postgres, and the latest progress in Every store on two databases. Two things it turned up have posts of their own: a job slowed by a third and rehearsing the read switch.
Planned: the move into containers. Once Postgres is the only database, the services and scheduled jobs move off the single server into containers, with a staging environment that runs the whole system on dry run and every image proven there before it is promoted. Some of its gates already run on every change: each pull request builds the image, starts every app with a read-only root and scans it for vulnerabilities and secrets. The rules the image is built to are in Building a container image I'd trust in production and Docker Best Practices; where the whole move stood in October is in Containerising JAS: where it stands.
Built on the same system
Two tools built on it
Web Console
The staff side of the system: look up any job across every platform, run reports and live actions behind a confirm, correct a job with an audit trail, and read the automation catalogue.
The mobile app sales consultants use on site. One submit creates the inspection, a quote per system option and the PDF in the CRM, and raises a service job when a site visit is needed.