One to three workflows, all the way into operation.
A fixed-scope sprint. Options are tested on approved examples of your real work before anything is installed, a named person reviews whatever needs judgment, and the whole thing is documented so your team owns it at handoff. If the evaluation does not clear the bar, the sprint ends with a written stop decision instead of a system nobody trusts.
A sprint needs something specific to aim at.
Fixed scope only works when the scope is knowable on day one. Most sprints that go wrong were sold against a workflow nobody could describe.
If you cannot describe it, we are not ready to price it.
Scope one if
- You can name the workflow, and someone can describe it end to end without hand-waving.
- It repeats often enough that operating it differently is worth the change.
- Approved examples of the real work exist and can be used for evaluation.
- Someone on your side will own the result after handoff and has the time to take it on.
- You want it running in your environment, not living in a consultant's account.
Do not scope one if
- Nobody can describe the workflow. If the current process is undocumented and contested, the sprint spends its budget on discovery and delivers a map.
- The goal is a demo for a board meeting. A demo is faster and cheaper to make than a system that survives a Tuesday.
- You need the answer to be yes. The gate is real, and a sprint that fails evaluation ends with a written recommendation, not an installation.
- The work is one-off or rare. Automating something that happens twice a year costs more than it returns.
If the workflow is still fuzzy, a one-day workshop will surface it faster than a scoping exercise will. The method behind the sprint is written up under AI implementation and how we work.
How the sprint runs.
Six moves, in order. The fourth one is the gate, and it is the reason the other five are worth paying for.
Fix the scope before anything starts
One to three workflows, named. What is in, what is out, what counts as done, and who signs off. Scope and price are agreed before work begins, so the sprint cannot quietly grow.
Map the work as it is actually done
Systems, data, handoffs, volumes, and the exceptions people absorb without telling anyone. The map is written down, because the sprint is scoped against it.
Evaluate options on your real examples
Candidate approaches are tested on approved examples of your own work, against a bar agreed in advance. Clean sample data proves nothing, so it is not used.
Pass the gate, or stop
If the evaluation clears the bar, the build proceeds. If it does not, the sprint ends with a written recommendation and nothing installed. That is a result, and it is cheaper than the alternative.
Build it, and build the review path with it
The system and its human review path are designed together. Wherever output reaches a customer, a record, or a decision, a named person reviews it, and that path exists on day one rather than being bolted on later.
Test in your environment, then hand it over
The workflow runs where it will live, on your access and your data boundaries, until it holds. Documentation, access notes, and a named internal owner are deliverables, not follow-ups.
The gate is the product.
Before the build starts, we agree what good enough means for this workflow: which examples it has to handle, how often it may be wrong, what kind of wrong is tolerable, and who decides. Then candidate approaches are run against that bar on approved examples of your own work.
If they clear it, the build is a known quantity from that point on. If they do not, you get the evaluation record and a recommendation, and you have spent a sprint instead of a year finding out. Most of the value of a fixed scope is that both endings are priced in advance.
A demo on clean sample data is not evidence.
What you own at handoff.
Including the row nobody puts on a proposal: what you get if the answer turns out to be no.
| Deliverable | What it is | Who owns it after |
|---|---|---|
| Workflows in operation | One to three workflows running in your environment, tested on approved examples of the real work. | Your named internal owner. |
| The review path | A defined human checkpoint for anything that needs judgment, with escalation and what to do when it is wrong. | The team and the reviewer named in it. |
| Documentation and access notes | How it is built, where it runs, what it touches, how to change it, and how to turn it off. | Your team, in your own systems. |
| The evaluation record | What was tested, against what bar, what passed, and what was rejected and why. | You. It is the evidence behind the next decision. |
| A stop decision, if it comes to that | A written recommendation explaining what failed the bar and what would have to change first. | You, to take into the next budget conversation. |
Boundaries.
- Outcomes
No outcome is guaranteed. The sprint guarantees an evaluation against an agreed bar and an honest answer about what it found, which sometimes is that the work should not be automated yet.
- Scope and price
Scope and price are agreed before work begins. Anything that turns up mid-sprint and is genuinely out of scope gets written down and priced separately rather than absorbed quietly.
- Your data
Data handling, access, and boundaries are agreed before any real records are shared. Evaluation runs on approved examples.
- Accountability
Soxoa builds and documents. Decisions about what may be automated, and sign-off on legal, security, privacy, and compliance questions, stay with your own responsible people.
- Vendors
Soxoa does not resell software. If the right answer is a tool you already own, that is the recommendation.
Questions people ask before they scope one.
What counts as one workflow?
A repeating path through the work with a clear trigger, a clear finish, and a person who can say whether the output is right. If it takes three meetings to agree where it starts and stops, it is probably two workflows and we will scope it that way.
What actually happens if the evaluation fails?
The sprint ends at the gate. You get a written recommendation covering what was tested, what the bar was, what fell short, and what would have to change before it is worth trying again. Nothing gets installed to justify the engagement.
Who reviews the output once it is live?
A named person on your side, on a review path designed during the build rather than added afterwards. Where a mistake would reach a customer, a record, or a decision, there is a human checkpoint by design.
Does this run in our environment or yours?
Yours. The point is a system your team owns and can change. Access and data handling are agreed before anything real is shared, and the handoff includes the documentation needed to run it without Soxoa.
Can you work alongside our own engineers?
Yes, and it usually makes the handoff better. If your team is building, Soxoa can take the evaluation, the review path, and the documentation and leave the build with them.
How is this different from the workshop?
The workshop is one day and proves your team can do this, on one workflow, with the build running on approved examples. The sprint takes one to three workflows all the way into operation in your environment, with evaluation, a review path, documentation, and handoff.
What does it cost?
Scope and price are agreed before work begins. The scope conversation comes first, because the price follows from what is in it.
Where this sheet sits in the set.
Each engagement stands on its own and each one bears on the next. Start where your organization actually is, not where the ladder starts.
- S-01AI Readiness Assessment
“Where are we, honestly?”
Fifteen questions, five dimensions, one recommended next step.
- S-02Live Build Workshop
“Can my team actually do this?”
One day. One working automation, built live on your own work.
- S-03AI Build Sprint
“Get the important one into production.”
A fixed-scope sprint that takes one to three workflows into operation.
You are on this sheet
- S-04Fractional Chief AI Officer
“Who owns AI here, month after month?”
A named, accountable AI lead on a monthly engagement.
Name the workflow. We will scope it.
Thirty minutes with John. Describe the workflow you want running properly, and you will get a straight answer about whether it can be scoped, what the evaluation bar would have to be, and whether a sprint is the right sheet at all.