Prove it · Suggestions with a reason and a switch
A renewal proposed before it lapses, a reprice that shows its reasoning, a past-due invoice that gets a nudge — every one a suggestion a person approves, with a reason attached and a switch to shut it off.
What it is
Automation in Thermal is a closed loop, not a black box: the system senses something on a real record — a renewal date approaching, a job that needs scheduling, an invoice going past due — proposes an action, and waits for a person to approve it before anything changes. Every proposal carries a plain-language reason for why it was made.
This is the plan for how that loop runs across the platform, module by module. The oversight mechanism below — reason strings and a kill switch — is real and live in Thermal today. The specific suggestions it will make on agreements, preventive maintenance, and invoicing are what's on the roadmap, named below rather than hidden behind vague promises.
Every proposal here is meant to move the same numbers a shop already tracks — the field service metrics and field service KPIs on the operations dashboards — not a separate scorecard only the automation layer can read.
Every proposal this page describes reads from and writes to the same agreement, work order, and invoice records the rest of the platform runs on — a suggestion never lives in a separate automation layer disconnected from the job.
One account. Every site under it.
The address, and the branch that covers it.
The unit a suggestion is about.
Renewals and repricing start here.
You are hereSchedule suggestions land here.
Past-due nudges point here.
The loop starts on the service agreement — a renewal or reprice that's due — and the resulting work lands on preventive maintenance or invoicing. Nothing on this page is a live, unsupervised layer.
| Module | Trigger | Proposed action | Reason | Status |
|---|---|---|---|---|
| AG‑2258 | Renewal inside 90 days | Reprice +4.2% | Margin 22% → 17% over term | Needs approval |
| AG‑2231 | Renewal inside 60 days | Reopen renewal | Escalation never applied last term | Over $10k cap |
| PM‑route | Weekly build | Re-route day 3 | Two stops share a drive corridor | Draft |
| INV‑4401 | Invoice 30 days past due | Send reminder | Balance outstanding 34 days | Draft |
| AG‑2240 | Renewal inside 45 days | Reprice +3.0% | Unit age + margin trend | Approved |
Four specific things Thermal is building toward — all on the roadmap today, named here instead of left vague. Nothing on this page is a live, unsupervised agentic layer.
A drafted reprice ahead of a renewal date — based on the equipment's age and the agreement's margin — waiting for a person to approve before the price changes. Today, renewal dates and margin are visible on the agreement; the reprice is still a manual call.
A suggested price adjustment shown with the reasoning behind it — the equipment age, the margin trend, the comparable job — before anything on the customer's price ever changes without a person signing off.
A drafted first pass at a maintenance day's assignments, weighing certification, drive time, and current load — a starting point a dispatcher reviews and adjusts, not a schedule that publishes itself. The surface it would feed is preventive maintenance.
A suggested reminder for a past-due invoice, held for a person to approve before it goes to the customer — not an automatic collections message a customer gets without anyone at the shop seeing it first. See the current flow on the invoicing page.
Turning an inbound call into a structured job — customer, site, and a first pass at the problem — without an office admin re-typing the whole conversation, is on the roadmap and deferred past this phase.
This isn't a disclaimer at the bottom of the page — it's the mechanism every proposal above is required to run through, live in Thermal today.
Nothing the system proposes, applies, or holds back arrives without a plain-language reason attached — including why something was held back instead of applied (a proposal that would exceed a set dollar cap says so, not just "declined").
One switch turns every proposal off across the whole account. Each module has its own dial on top of that — turning a module off stops it from proposing anything at all, evaluated fresh every time, never a setting that's cached stale.
Every module in Thermal that proposes anything sits on the same three-position dial — set per module, not one blanket switch for the whole account.
The module proposes nothing and takes no action. Where sensing has no cost or side effect, it keeps a record that it saw the signal — but surfaces nothing and suggests nothing.
The module proposes an action and routes it to the right person to approve, decline, or let expire. Nothing changes on the record until a person says yes.
Everything Suggest does, plus: the action applies on its own within configured bounds — a dollar cap, a rate limit, an allowed scope, and quiet hours — all still carrying a reason string.
The dial is per module, not per suggestion — bounds like dollar caps and rate limits apply per action type underneath it. As the named capabilities above move off the roadmap, this is the framework they ship inside, not a separate promise layered on afterward.
Three boundaries that are the whole point of the design.
No ungated auto actor exists. Off and Suggest never apply anything without approval, and even Auto only applies within bounds configured for that module. The framework is documented on the security page alongside how it's enforced.
A plain-language reason is required on every proposal — including why one was held back instead of applied. There is no suggestion that arrives without a stated reason, and no "our system decided" hand-waving anywhere in the loop.
The records a suggestion reads and writes are your records. Your data remains yours. Migration covers how records get in — and what it looks like if they ever go out.
If a capability isn't on this page, assume it isn't built. We'd rather lose a deal on a missing feature than win one on a sentence that turns out to be aspirational.
The loop reads the records that signal something's due and, once a person approves, writes back to them.
The ones that come up when a shop has been burned by software that acts on its own.
The named capabilities on this page — suggested renewals, smart repricing, PM-schedule suggestions, and AR nudges — are on the roadmap, not live for customers today. The oversight mechanism behind them — reason strings and a kill switch — is real and already runs in Thermal.
Only if a module is explicitly set to Auto, and only within bounds configured for that module — a dollar cap, a rate limit, an allowed scope, and quiet hours. Off and Suggest never apply anything without a person's approval.
Yes — one switch turns every proposal off across the whole account, and each module has its own switch on top of that. Turning a module off stops it from proposing anything, evaluated fresh every time.
Yes — a plain-language reason is required on every proposal, including when something is held back instead of applied. There's no suggestion that arrives without a stated reason.
Not yet — voice intake is on the roadmap and deferred past this phase. Today, a call gets logged and dispatched the way it does now.
Ask us what's live today and what's still on the roadmap — we'll give you the same straight answer that's on this page, and show you the dial.