Services specification

Four channels, specified.

Each channel below is written the way we write a scope: what it is, what you actually receive, how it gets delivered, where it fits in the flow, and what it explicitly does not include. Most engagements begin with one channel and add the next only after the first is in production.

CH 01Operations centralizationone system of record CH 02Quote-to-cash automationestimate → payment CH 03Talk-to-your-data interfacesanswers with sources CH 04Data-integrity engineeringthe foundation layer

CH 01

Operations centralization

What it is. We consolidate the places your operation currently keeps its truth — spreadsheets, shared drives, message threads, a scheduling tool, a folder of photos — into one system of record where every job, customer, quote and document has a single identity and a single history.

The work is mostly unglamorous: deciding what a “job” is, reconciling three different spellings of the same customer, and choosing which of your existing tools stays and which becomes a read-only archive. That modelling is the product. The interface on top is comparatively easy, and it is worthless if the model underneath is wrong.

What you actually get

A single database of your operation, hosted on your own account, with a documented schema.
A web application your team uses on desktop and phone — job list, job detail, customers, documents, status.
A migration of your existing records into it, with a reconciliation report showing exactly what was merged, what was ambiguous, and what we could not resolve.
Role-based access, so the office sees what the office needs and the crew sees the job in front of them.
A written runbook: how it is deployed, how to add a user, how to restore from backup, who to call.

How it is delivered

Flow mapping session — we walk one real job end to end with the people who touch it.
Data model drafted and reviewed with you in plain language before a line of code is written.
Trial migration on a copy of your records; you review the reconciliation report and correct our assumptions.
Build, with a working version in front of your team early rather than a reveal at the end.
Cutover on a date you pick, with the old tools kept read-only for a defined period rather than deleted.
Handover: source, schema, credentials, runbook, and a walkthrough with whoever will own it.

Where it fits

This is the substrate the other three channels sit on. If your records are scattered, automation just moves errors around faster and a natural-language interface answers confidently from the wrong table. When an operation comes to us with several problems at once, this is almost always the first phase.

Inputs: Exports from current tools, a sample of real jobs, access to the people who run the flowRead-only access first; write access only when you are ready.
Outputs: One database + one web application + documented schema + reconciliation report + runbook
Interfaces: Browser (desktop and mobile). Optional read connections to accounting and scheduling tools you are keeping.
Data boundary: Single-tenant. Your cloud account, your keys, your backups. No pooled storage, no training on your records.
Handover: Source code, schema, infrastructure config and runbook, transferred at phase end regardless of what happens next.
Not included: Replacing your accounting package, hardware procurement, or ongoing data entry on your behalf.

CH 02

Quote-to-cash automation

What it is. The five transitions in Fig. 01 — estimate, approval, schedule, invoice, settlement — connected into one flow, so a number entered once is never retyped and every step forward leaves a record behind it.

The value is rarely in any single automated step. It is in closing the seams: the approval that never made it to scheduling, the change order agreed by text and never priced, the completed job that sat two weeks before anyone invoiced it. Those seams are where margin quietly disappears, and they are visible the moment the flow is one flow.

What you actually get

Estimates built from your own rate and materials data, in your format, with your terms.
A customer-facing approval step that records who approved what, when, and at which price — and locks that scope.
Scheduling that cannot run ahead of an approval, and that carries the approved scope to the crew.
Invoices generated from the approved scope and any recorded change orders, pushed to your accounting system rather than typed into it.
Payment matched back to the job, so “what is still owed on this job” is a query rather than an investigation.
An event log covering every transition, exportable, with the source of each value attached.

How it is delivered

We trace your current flow and write down every handoff, including the ones that only happen verbally.
Gates are agreed explicitly: which steps a machine may complete, and which require a person to press the button.
Integrations are built one at a time and verified against real records before the next one starts.
The flow runs in parallel with your current process on live jobs until you trust the output.
Cutover, then a period of watching the event log together to catch the cases nobody remembered to mention.

Where it fits

This is the channel that pays for itself first, which is why it is our niche wedge. It assumes a usable system of record — either the one from CH 01, or an existing setup that is already coherent enough to build on. We will tell you honestly which of those you have.

Outward actions are gated by default. An invoice is drafted automatically and released by a person. You can widen that later, per action, once you have watched it behave — but the default direction is conservative, and we will not quietly reverse it.

Inputs: Pricing model, terms, current estimate and invoice formats, accounting system accessPlus a handful of real closed jobs to test against.
Outputs: Connected flow across the five stages + event log + gate configuration + reconciliation between jobs and payments
Interfaces: Accounting (QuickBooks, Xero or similar), e-signature or in-app approval, email and SMS delivery, card or ACH payment links
Data boundary: Credentials to third-party systems are yours, stored in your secret manager, revocable by you without our involvement.
Handover: Flow definitions, integration code, gate configuration and runbook.
Not included: Acting as your merchant of record, collections or dunning as a service, or bookkeeping.

CH 03

Talk-to-your-data interfaces

What it is. An assistant that sits on your own operational data and answers questions in plain language — which jobs from last quarter came in under estimate, and by how much — and returns the answer together with the query it ran and the rows it read.

The citation is the point. An answer you cannot check is a rumour with good grammar. We build these so that every response can be expanded into its evidence, and so that a question the system cannot answer accurately returns “I cannot answer that from this data” rather than a fluent guess.

What you actually get

A question box — in your system, in a browser, or in the chat tool your team already uses.
Answers with the underlying query and source rows attached, one click away.
Read-only access by construction, so a question can never modify a record.
Permission scoping, so an answer only ever draws on data the person asking is allowed to see.
A set of evaluated example questions we tested against known-correct answers, so you can see where it is reliable and where it is not.
An explicit refusal path for questions outside the data, instead of invention.

How it is delivered

You give us the twenty questions you actually ask, including the ones currently answered by guessing.
We establish the correct answer for each by hand, from your data. That set becomes the test.
The interface is built and measured against that set, not against a demo script.
Failure cases are handled deliberately: refuse, ask a clarifying question, or route to a person.
Rollout to a small group first, with the question log reviewed together before wider release.

Where it fits

Last, usually. This is the channel people ask for first because it is the one that demos well, and the one most likely to disappoint when the data underneath is not modelled. If your records are already clean, it can be a fast standalone win — and if they are not, we will say so rather than sell you a convincing demonstration.

Inputs: A modelled dataset, your real question list, and a person who can confirm correct answers
Outputs: Question interface + citation view + evaluation set with recorded results + refusal behaviour
Interfaces: Browser, or an assistant surface your team already uses. Optional scheduled digests by email.
Data boundary: Read-only credentials. Model calls carry the minimum data required for the question; we agree in writing what may leave your system and what may not.
Handover: Interface code, prompt and query definitions, evaluation set and results.
Not included: Fine-tuning a model on your data, or a general-purpose chatbot for customers.

CH 04

Data-integrity engineering

What it is. The layer underneath the other three, sold on its own when a business already has systems but cannot trust them. Isolation, provenance, reversibility and failure behaviour, designed on purpose and enforced by code rather than by everyone remembering.

Most operational data problems are not caused by a lack of tooling. They are caused by a silent default: a missing price that became a zero, an integration that failed at 2 a.m. and swallowed the error, a nightly job that has written nothing for three weeks while reporting success. This channel finds those and closes them.

What you actually get

An audit of where your data comes from, who or what can write it, and what happens when each of those paths fails.
Provenance on automated writes — source, actor, timestamp, and the input that produced the value.
Approval gates on every outward action, configured per action rather than all-or-nothing.
Loud failure: alerting that fires on a broken write instead of a swallowed exception, routed somewhere a human actually looks.
Backup and restore that has been rehearsed, not merely configured — a restore nobody has run is not a restore.
A short written statement of the guarantees your system now makes, in language you can hand a customer who asks.

How it is delivered

Inventory every write path and every external dependency, including the ones nobody documented.
Rank by blast radius: what breaks quietly, and what breaks expensively.
Close the silent failures first — the ones producing wrong numbers with no signal.
Add provenance and gates to the paths that touch money or customers.
Rehearse the restore, in a copy, end to end, and write down what it actually took.

Where it fits

Included as a matter of course inside CH 01 and CH 02 — it is not an upsell on our own builds. It is sold standalone when you have inherited a stack you are not sure you can trust, or when a customer, insurer or partner has started asking questions you cannot currently answer.

Inputs: Access to current systems and integrations, plus whoever knows the historyRead-only is enough for the audit stage.
Outputs: Write-path inventory + ranked findings + implemented guards + rehearsed restore + written guarantees statement
Interfaces: Your existing databases, integrations, schedulers and alerting destination.
Data boundary: We work inside your accounts. Nothing is copied to ours; findings are recorded without reproducing your data.
Handover: The inventory, the findings, the guard code, and the restore procedure with its rehearsal notes.
Not included: A formal security certification, penetration testing, or regulatory compliance sign-off. We will tell you when you need a specialist.

§ 05

Which channel first

If the truth is scattered: Start at CH 01. Every other channel gets cheaper and more reliable once there is one system of record, and more expensive if there is not.
If records are fine but slow: Start at CH 02. The flow exists, it is just running on people carrying paper between stages, and that is the shortest path to money recovered.
If you cannot get answers: Start at CH 03 only if the data is already modelled. Otherwise CH 01 first, then this — in that order, or the answers will be confidently wrong.
If you inherited a stack: Start at CH 04. Find out what your systems actually guarantee before building anything else on top of them.
If none of the above: Book the call anyway and describe the problem. If the right answer is an off-the-shelf product or no project at all, that is what you will hear.

Next step

Bring the flow that costs you the most.

A discovery call is a working session, not a pitch. We walk your flow, name the seams, and tell you which channel we would start with and roughly what it would take.

Book a discovery call → How engagements are priced