Automation Build
Build a workflow your team can run.
I turn an approved workflow design into a working automation, with clear access rules, human review, and a plan for exceptions.
The facts
- Fixed quote
- scoped before work starts
- 4–6 weeks
- usually, after prerequisites
- 1 workflow
- up to three systems, one environment
- 14 days
- defect correction after handoff
The base scope covers one approved workflow with bounded, human-reviewed output. Testing, documentation, and training are included. Usage costs and ongoing operation are separate.
Use this when
- A workflow design is approved and you need it built in your environment.
- The system has to read from and write to real marketing systems, such as your CRM, marketing automation, or analytics, under defined access and permissions.
- Exceptions need a route, not a dropped record.
- Your team needs to own the result after handoff, with documentation written for the owner.
You leave with
A working automation in your environment, access and permission rules, acceptance tests, documentation and training, an operating guide written for the owner, and 14 days of defect correction.
Don't have a complete specification yet? That's normal. The Workflow Design Sprint is where we decide whether the work should be automated, what the system may read and write, what a person still owns, how exceptions move, and what a builder must prove before launch. The person reviewing during testing and after handoff needs enough context to recognize what is wrong and enough authority to act on it. A review screen alone is not a working control.
What a build produces
Input in, reviewed output out, and a place for everything else.
Input · as received
High-priority and client-related email content, client deliverables, client meetings notes with action items, and outstanding tasks by client. Paired with it - key industry and tool news and updates for broader context.
Read from up to three systems the client already licenses.
Output · reviewed by a person
A weekly email that assesses client health, opportunities & insights, and challenges and blockers. Kick off your week with actionable next steps that will help you build your business.
Approved by the named owner. Nothing ships without this step.
Exception · routed, not dropped
When a workflow that gathers and collates any of the input or output doesn't run - an alert goes out immediately to an engineer for assessment. If the model is uncertain about key takeaways - it will admit uncertainty rather than inventing results.
Unmatched, low-support, or failed items go to a named reviewer with the original attached.
Before we start
Four things that have to be true first.
An approved workflow design
A specification with access rules, review points, exception route, and acceptance criteria. From a Sprint, your team, or another builder. I review existing work before reusing it.
Systems with supported interfaces
Up to three systems your team already licenses, each with a documented way in. Custom connectors are scoped separately.
A named owner with time to review
Someone who will check output during testing, sign off at acceptance, and run the workflow after handoff.
One production environment, access granted
Procurement, security review, and account provisioning happen before the clock starts. Delays here move the schedule, not the scope.
What's included
The base scope, and what moves it.
The base scope is one bounded, well-prepared workflow, built properly. I won't squeeze a larger job into it by removing review or testing.
In the floor
Scoped separately
In the floor
- One approved workflow, up to three systems
- Access rules, human review step, and exception routing as specified
- Agreed test plan, run with your owner
- Operating guide and acceptance checklist
- Training for the people who run it
- 14-day defect correction window after accepted handoff
Scoped separately
- Additional use cases or workflows
- Custom connectors for systems without a supported interface
- Data migration or cleanup
- Heightened assurance, audit, or compliance needs
- Model and platform usage costs, paid by you
- Ongoing operation, monitoring, and new features
Milestones
Four milestones. Three payments.
Milestone 1
Kickoff
What I do
Confirm the specification, access, and test plan. Set up the environment.
What you do
Grant access. Name the owner. Supply sample inputs for testing.
40% billed at kickoff
Milestone 2
Working build
What I do
Build the workflow, the review step, and the exception route. Run it on sample inputs and share results weekly.
What you do
Look at weekly outputs. Flag anything that reads wrong. About an hour a week.
No payment at this milestone
Milestone 3
Staging ready
What I do
Staging build ready for your acceptance testing against the agreed criteria. Fix what the tests find.
What you do
Owner runs the acceptance checklist on real-shaped inputs. Sign off, or send back with specifics.
40% when staging is ready for acceptance
Milestone 4
Accepted handoff
What I do
Move to production. Deliver the operating guide. Train the people who run it. 14-day defect window begins.
What you do
Attend training. Run the workflow. Report defects within 14 days.
20% at accepted handoff
After handoff
You run it. I fix what I broke.
The operating guide is written for the owner, not for me. If they can't run it from the guide, the guide isn't finished.
Operating guide
What to check, how often, what "wrong" looks like, and who to call. Kept with the workflow, not in my inbox.
14-day defect window
Anything that doesn't meet the accepted criteria gets fixed at no charge for 14 days after handoff.
Not a defect
A new feature, a changed requirement, or a system you connected afterward. Those are a new scope, quoted separately.
Running costs
Model and platform usage is billed to your accounts. I'll estimate it from testing volume before handoff. Ongoing operation can be covered under Advisory or a separate agreement.
Related builds
Systems I've built and run.
In their words
“When Allison builds a workflow, she will really 'dot her i's and cross her t's'. By thinking about edge cases and performing rigorous QA, she builds solutions that stand the test of time.”
Excerpts from 2025-2026 company award submissions
Before you book
Common questions.
Can you build from a specification we already have?
Yes. I review it first for access rules, review points, exceptions, and acceptance criteria. If those are there, we start. If not, a short Sprint fills the gaps. You won't be asked to repeat work without a reason.
Will the model ever make something up?
It can. I won't promise otherwise. The build is designed so unsupported output is detected, constrained to what the review step allows, and routed to a person. The acceptance tests check that routing works.
What happens after the 14 days?
You own and run it. If you want a standing second opinion or help with changes, Advisory covers that. New features are quoted as new scope.
Do we own the code and configuration?
Yes. Everything runs in your accounts and is documented for your owner. Nothing depends on me staying involved.
Bring the specification, or the workflow that needs one. We'll work out whether it's ready to build.
Free introductory conversation. No preparation required.
