The approach
We build up to the line and stop.
Most AI work in a mid sized company starts with a tool and goes looking for a use case. We start with a decision somebody is accountable for and time the work sitting in front of it.
The idea
Every decision has a line in it
Above the line is assembly: reading the invitation, checking history, pulling margin, confirming capacity, writing the summary. It is repeatable, timeable, and mostly retrieval. Below the line is the call itself, which takes minutes and depends on judgment somebody is paid for.
We automate everything above the line and nothing below it. The person who owns the outcome still makes the call, only now it arrives prepared, with the evidence attached, instead of after forty minutes of digging.
The note written at the line, what the decider needs in front of them, is the build specification. Everything the system produces exists to satisfy that note and nothing more.
- Read the invitation, plans and addenda12
- Check our history with this general contractor7
- Check backlog and crew availability6
- Look up margin on the last three like it9
- Check bonding capacity and prequal status5
39 minutes of assembly. Two minutes of judgment.
Principles
Four things you can hold us to
01
You get a number before you get a proposal
Everyone else scopes from a conversation. We scope from timed steps your own people supplied, and we publish the arithmetic so you can argue with it.
02
The judgment stays with the person accountable for it
The method has a named stopping point. We automate the gathering, checking and summarizing, and the call stays with whoever owns the outcome.
03
It runs in your accounts, so nothing turns off when we leave
Workflows live in your environment, on your credentials. You own them. That is a property of how we build, not a promise about behavior.
04
You will not spend the first meeting explaining your industry
We have run B2B marketing across manufacturing, distribution, construction and logistics. We know how a contractor pursues work.
Scoring
How we decide what is buildable
Each decision is scored one to five on six dimensions, weighted so the hard constraints outrank the soft ones. Any score of one or two gets a written reason, because those reasons become the fix first and do not build lists.
- Data reachability
- A hard constraint. If the data lives in heads and inboxes, no build talks past it.
- Output acceptance
- Would the decider use it, or re-gather it anyway? This quietly kills systems that already work.
- Trigger clarity
- A clean event or schedule beats something that starts when someone happens to notice.
- Variability
- Same shape every time is buildable. Every instance different is not.
- Owner pull
- A named owner who raised it themselves and will make time.
- Error tolerance
- Mistakes that surface fast and cheap are safer to automate than invisible ones.
| Dimension | Why it matters |
|---|---|
| Data reachability | A hard constraint. If the data lives in heads and inboxes, no build talks past it. |
| Output acceptance | Would the decider use it, or re-gather it anyway? This quietly kills systems that already work. |
| Trigger clarity | A clean event or schedule beats something that starts when someone happens to notice. |
| Variability | Same shape every time is buildable. Every instance different is not. |
| Owner pull | A named owner who raised it themselves and will make time. |
| Error tolerance | Mistakes that surface fast and cheap are safer to automate than invisible ones. |
What you get back
Every decision lands in one of four boxes
High cost, feasible
Build first
Two or three at most. These go into the sprint proposal with what a working version looks like.
High cost, blocked
Fix first
The value is real and something is in the way, usually data or ownership. We name the fix, not a build.
Low cost, feasible
Batch or skip
Group several into one sprint or leave them. Never sold on their own.
Low cost, blocked
Do not build
Named in the report with the reason in full sentences. This list is why the rest is believed.
The most common failure in this kind of work is mapping twelve things and recommending nine. Recommending everything is recommending nothing. So the report names a few things and rules out the rest, with the reason for each.
Questions
Before you ask
What is the decision line?
Every recurring decision has preparation above it and a judgment call below it. Above the line is assembly: pulling history, checking systems, confirming capacity, writing the summary. Below the line is the call itself, which usually takes minutes. We automate everything above the line and nothing below it.
Why not automate the decision itself?
Because somebody is accountable for the outcome and a system cannot hold that. We make the call cheap to make, well evidenced and fast, and the person who owns the result still makes it. If a decision genuinely has no judgment in it, it was a lookup rather than a decision and it did not need us.
How do you decide what is worth building?
Each decision is scored one to five on six dimensions, weighted so the hard constraints outrank the soft ones. Data reachability and output acceptance can sink a case on their own. Any score of one or two gets a written reason, and those reasons become the fix first and do not build lists.
What does the do not build list actually do?
It gets drafted before the recommendations, so every build we propose has to survive it. Mapping twelve things and recommending nine is the most common failure in this kind of work, because recommending everything is recommending nothing. The list is why the rest of the report is believed.
Do you need our systems before you can score anything?
No. The scoring comes out of interviews and timed walkthroughs, not out of an integration. We do ask where the data lives and whether anybody can already export it, because data reachability is a hard constraint and a decision blocked on it goes on the fix first list rather than the build list.
Talk to us
Bring one decision. We will map it in twenty minutes.
No deck, no discovery process, no proposal to review. Tell us one thing your team decides most weeks and we will walk it backwards on a call until we find where the time is. If there is nothing there we will tell you and we can both get on with our day.