Schedule of Services
Four lines of work, scoped and priced separately. For each one: what it actually is, what you receive at the end, how it is delivered, and the conditions under which it is the wrong thing to buy.
Consolidation of record
Turning the four-tools-and-a-group-chat arrangement into one system of record your team works inside — including the unglamorous part, which is the migration and the cut-over.
What it is. Most operations under about fifty people run on an accumulation: a quoting spreadsheet someone built in 2019, a scheduling tool bought for one crew, a customer list in an inbox, and a group chat where the real decisions happen. None of it is wrong on its own. The failure is between them — the same fact exists in four places, three of them stale, and nobody can tell you which is current without asking a person.
Consolidation is the work of deciding which system owns which fact, moving the history into it, wiring the rest to read from it rather than duplicate it, and retiring what is left. It is mostly not an AI project. It is the prerequisite that makes an AI project honest, because a model pointed at four contradictory sources will confidently average them.
What you receive
- A written system-of-record map — every operational fact your business depends on, which system owns it, who writes it, and what reads it downstream.
- One consolidated operational store, single-tenant, in an account you own, with your historical data migrated and reconciled against the originals row by row.
- Integrations replacing the re-keying — the tools you keep read from the store instead of holding their own drifting copy.
- A cut-over plan and a rollback plan, both rehearsed on a copy before the day it matters.
- Working documentation written for your team, not for us: how the system is laid out, how to add a user, what to do when something looks wrong.
How it is delivered
Where it fits. This is the right first engagement when your honest answer to “how many open jobs do you have right now” involves opening more than one application. It is the wrong first engagement if one system already holds the truth and the problem is that nobody can get answers out of it — that is § 2.3.
Quote-to-cash automation
Estimate, approval, schedule, invoice, paid — one path, one record, an audit entry at every hand-off. The part of the operation where a dropped step is immediately money.
What it is. Quote-to-cash is the sequence that turns work into revenue. In most field-service and trades operations it is also the sequence with the most manual hand-offs: the estimate is built in one place, approved verbally, entered into scheduling by hand, completed on a phone, and invoiced days later from memory by whoever gets to it. Every hand-off is a place where a job can quietly stop moving, and the loss is invisible because nothing errors — it just sits.
The build makes the sequence a single record that moves through states, with the transitions automated where they are safe and gated where they are consequential. Sending an estimate to a customer, charging a card, or posting an invoice to your accounting system are outward, hard-to-reverse actions; those stay behind an explicit human confirmation that names the system being written to. Everything upstream of that is automatic.
What you receive
- One job record carrying estimate, approval, schedule, completion evidence, invoice and payment status — with the state transitions defined rather than implied.
- Automated hand-offs: approval creates the scheduled work; completion drafts the invoice against what was actually approved and actually done.
- An append-only audit trail — every state change with its timestamp, its source, and the credential or person that caused it. A disputed line becomes a lookup.
- Accounting-system posting into the books you already keep, with a reconciliation check that flags anything that didn’t land instead of failing silently.
- An exception queue — the jobs that stalled, the invoices unsent, the approvals unanswered, surfaced as a short daily list rather than discovered at month-end.
How it is delivered
Where it fits. This is the fastest engagement to justify, because the cost of the current arrangement is measurable in your own records: unsent invoices, average days from completion to bill, jobs approved but never scheduled. We measure those in the Survey from your data, before quoting the build — not from an industry benchmark.
Talk-to-your-data interfaces
Ask your own business a question in plain language and get an answer assembled from your own records, carrying the rows it was built from — or a straight admission that the data isn’t there.
What it is. A language-model interface sitting on top of your operational data, scoped to your business, that answers questions like which jobs from last quarter went over their estimate, and by how much without anyone building a report first. The value is not the chat box; the value is removing the two-day delay between a question and an answer, which is what currently stops most operators from asking.
The part that matters is the refusal. A general-purpose model asked a question it cannot ground will produce a fluent, specific, wrong answer. That is not a bug to be prompted away — it is what the technology does. So retrieval is gated: the interface queries your records, and if the query comes back empty or ambiguous, it reports that instead of composing. Every answer carries the underlying rows, so a number you doubt takes one click to check rather than an act of faith.
Where the engagement suits it, this can be built against a model account you own, with your credentials on your infrastructure — so the interface is yours, and continues to be yours if we never speak again.
What you receive
- A question interface over your own data — web, or inside a tool your team already has open all day.
- Cited answers. Every figure links to the records that produced it, with the query that was run shown on request.
- An explicit no-answer path. Out of scope, no matching records, or an ambiguous question returns a plain statement of that, never a guess.
- Read-only by default. Any ability to write is added deliberately, scoped narrowly, and logged to the audit trail.
- A question log you own — what the team actually asks, which is the most useful roadmap for what to build next.
How it is delivered
Where it fits. Best when your data is already consolidated, or consolidated enough in one domain to be worth asking about. On top of four contradictory sources it will faithfully report contradictions — which is at least honest, but § 2.1 is the better use of the money.
Data-integrity engineering
Isolation, provenance, auditability and reversibility, built as the foundation the other three stand on — and available on its own when a system you already own needs it retrofitted.
What it is. The set of guarantees that determine whether a system can be trusted with a decision. They are invisible when present and catastrophic when absent, which is why they are usually the first thing cut. Every other line on this schedule is built on them; this line exists for the case where you already have software and want the foundation brought up to standard rather than replaced.
Typical work: separating a multi-tenant store into per-client isolation; adding an append-only audit trail to writes that currently leave no trace; putting provenance on model-generated output that is being read as fact; finding the paths where a failed lookup silently becomes a zero and turning them into refusals; and putting an explicit gate in front of every outward, irreversible action — the messages sent, the cards charged, the records pushed into someone else’s system.
What you receive
- An integrity review of the existing system — written, specific, and ordered by what would hurt most, not by what is easiest to fix.
- Tenant isolation implemented at the infrastructure layer rather than enforced by a query filter that one missing clause defeats.
- Audit trails on consequential writes: what changed, when, from which source, under which credential.
- Provenance on generated output, and a refusal path for the case where nothing grounds the answer.
- Confirmation gates on irreversible actions, each one naming the external system being written to — so approving a draft is never mistaken for approving a send.
- Restore rehearsal. A backup nobody has restored from is a hypothesis. We run the restore, on a copy, and fix what the rehearsal breaks.
Where it fits. Any system that is about to be given more authority than it currently has — more automation, more users, more money moving through it. The cheapest moment to do this is before that authority is granted.
Not on this schedule
A short list is more useful than a long one. These are declined, and named here so you don’t spend a call finding out.
- Strategy decks without a build. If the deliverable is a document about what could be done, this is the wrong firm.
- Marketing sites, brand work and ad buying. Adjacent, and done better by people who do only that.
- A general chatbot bolted onto your website. Ungrounded, unaccountable, and it will invent your pricing to a stranger.
- Staffing and placement. We build systems; we do not supply people to operate them for you.
- Anything requiring your production credentials to live with us permanently. Access is scoped, least-privilege, and revocable by you at any moment.
- Engagements where the data cannot be isolated. If the architecture forces your records to share a home with another company’s, we will say so and decline.
What it is built with
Boring, well-understood infrastructure, in accounts you own. Novelty in the substrate is a liability when the thing on top has to run your billing.