Most pitches for AI consulting have the same gap. They show you the before and after but skip everything in between. You don't know what day 3 looks like, what breaks on day 13, or what the owner actually has to do. That gap is why most buyers hesitate. They're not sure what they're paying for.
This post is the literal 30-day calendar from a real engagement. Day 1 is the first call. Day 30 is the first automation running in production. I run 5 businesses on a $600/month AI stack, and the process I follow with clients mirrors what I used to build those systems for myself. Concrete specifics so you know what you're buying.
Two phases: the Audit (days 1-5, $2,500) and the Sprint (days 6-30, from $5,000). You can stop after the Audit. Most clients don't.
Five to seven questions, in order. What does a good week look like versus a bad week? Where does the owner personally spend time they wish they didn't? What's the one bottleneck that, if removed, would change the whole trajectory? What tools are already in use? What's been tried before that didn't work and why? Who on the team touches each workflow? What's off-limits (a vendor relationship, a process the owner is attached to, a compliance constraint)?
Red flags that surface: "we tried that with a vendor" usually means the vendor sold a tool and didn't build a system. "My team is not technical" is not a red flag; I handle all technical work. "We already have Zapier" usually means one or two automations covering five percent of what's possible. "We need AI for everything" is a red flag. Clients who can't name a specific pain point rarely have the process clarity needed to build anything reliable.
Two to three hours watching how the team actually works, not how they say they work. Screen share or in-person if local. I follow the path of one inbound lead or one order from first contact to close or fulfillment. Counting clicks, tracking where data gets manually re-entered, noting every "we do that in a spreadsheet" moment. The owner has usually stopped seeing the leaks.
Every tool category that's relevant gets scored against the client's specific workflows. Twelve to fifteen categories depending on the business: CRM, email automation, voice agents, document processing, scheduling, inventory, payment, customer support, reporting, outreach, content, and data storage. For each category I document: what they have now, what it can actually do (not what the vendor claims), what it costs, and what it can't connect to. This map tells me where the integration gaps are before I touch any code.
Top five automation candidates, each with a dollar estimate. I calculate the estimate two ways: time cost (hours per week times loaded hourly rate) and revenue cost (leads or deals lost because of slow response or dropped handoffs). For most $2M-$8M businesses, the top leak is worth $3,000 to $8,000 per month in either labor or lost revenue. The second leak is usually half that. The list is prioritized by ROI-per-hour-of-build-time, not by what sounds impressive. Some of the best leaks are boring: a 45-minute-per-day manual report that a 4-hour automation fixes permanently.
The report covers: workflow map of the current state, five prioritized leaks with dollar estimates and build complexity ratings, recommended stack for each leak (specific tools, not generic categories), and a decision tree: which leak to build first, whether to Sprint or self-serve, and what the Sprint would include. The 60-minute walkthrough is where we pick the leak together. The recommendation is specific. If leak number one has a hard blocker, I tell you that in the walkthrough, not after you've paid for a Sprint.
Sprint starts after the leak is selected and the scope is agreed. The scope document is one page: what gets built, what success looks like, what's out of scope, and what access I need from the client's side. No ambiguity.
Lock the three-tool stack for the chosen leak. Voice agent: Synthflow for the voice layer, ElevenLabs for natural voice, n8n to orchestrate CRM write and callback booking. Document processing: Claude API for extraction, n8n for routing, Notion or Airtable as the data store. Follow-up sequence: Make.com for trigger logic, Claude API for drafts, Gmail or Outlook via their APIs for send. The sandbox runs against test data first. No production access until the sandbox passes 50 test cases without an undocumented error.
What breaks in the first 30 minutes: rate limits on a vendor API that the documentation didn't mention. An authentication token that expires every 24 hours instead of the stated 90 days. Edge-case inputs the sandbox didn't cover (a customer who leaves a voicemail in a language the voice agent wasn't configured for). A CRM field that has three different naming conventions depending on which team member entered the data. The first production test exists to surface this stuff before it becomes an incident.
Written while the build is fresh. The doc covers: what the system does and what it doesn't do. How to tell if it's working (the daily health check takes two minutes). How to tell if it's broken (what the alert looks like and what to do when it fires). What to do when a vendor changes something. Who has access to what and how to revoke it. This doc is written for the person on the team who will actually manage the system, not for a developer. If that person can't follow it, I rewrite it.
Three common gotchas in this phase. Rate limits: most APIs have generous-sounding limits that break under real volume. A voice agent handling 100 to 200 inbound calls a day (the volume on my OD Granite stone distribution business) needs different error-handling than one handling 20. I add retry logic and a dead-letter queue so nothing gets silently dropped. Auth tokens: any token that expires needs a refresh workflow built in before production. Data quality: real data has nulls, inconsistent formats, and entries that don't fit the schema. The automation handles these gracefully rather than crashing or silently misclassifying.
Around days 17 and 18 the handoff doc gets finalized. Every automation has one owner on the client side. That person reads the doc and asks questions. The questions are the diagnostic. I keep rewriting until the owner can describe what the system does, how to check if it's working, and what to do if it stops, without me in the room.
The automation runs for 48 hours in production with the owner watching, not intervening. Every incident gets logged. Every question gets written down rather than answered immediately. The goal is to find everything that prompts a "wait, what does this do?" reaction before I'm not on the call anymore. The pause test is where most of the real handoff happens, not in a formal training session.
Three alert types. Silent failure: the automation ran but produced a wrong result, flagged by a confidence-score threshold. Hard failure: stopped running entirely, Telegram message to the owner within two minutes. Performance drift: running but slower than baseline, weekly digest report. Thresholds are calibrated to the client's tolerance. Too many alerts and the owner ignores them. Too few and a failure runs for days undetected.
Every API key, OAuth token, and service account gets documented: what it is, what it has access to, when it expires, and who owns it. Service accounts get minimum necessary permissions, not admin access. Anything I used during the build that the production system doesn't need gets revoked. The client gets a one-page access register they can use to audit the system without calling me.
A 10 to 15 minute screen recording showing exactly how to check system health, how to read the logs, and how to handle the two or three most common issues. Stored in Notion or Google Drive, not in my personal account. The video is for the team members who weren't in the daily standups during the build, so the system survives turnover.
Day 30 is the first full production day with no active engagement. The automation runs. I'm available on Slack for questions but not monitoring it myself. What gets reported in the first 24 hours: total volume processed, error rate, any alerts that fired and what caused them, and the first side-by-side comparison against the pre-Sprint baseline.
The baseline comparison is the most important output of the day 30 report. Not "the system is running" but "here's what changed." For a follow-up automation: quote response time before was 2.4 days average, after is 11 hours average. For an inbound voice agent: missed call rate before was 34 percent after hours, after is 0 percent. For a bookkeeping automation: hours per month on reconciliation before was 14, after is 2 (with a 20-minute weekly review). The numbers come from actual measurement, not projection. If the metric didn't move, I say that in the report.
Want to see what that bookkeeping automation looks like after 9 months in production? I logged the whole thing in the bookkeeper replacement case study, including the months it drifted and what fixed it.
This is the part most consultants don't talk about, because by day 30 they're gone. I stay in contact for 30 days post-handoff and hear about what happens next. Three things come up consistently.
The system that drifted quietly. A voice agent handling 40 calls a day in week one was handling 12 by week 8. Not because it broke. The owner changed the greeting script without updating the intent classification prompt, and the agent started routing calls to voicemail "to be safe." Fix was 20 minutes. The cost of not catching it for 6 weeks was real leads that didn't get qualified. This is why failure alerting in days 21-23 matters more than most clients expect at the time.
The owner who shipped a new product line. A follow-up automation built for a 3-product catalog gets confused when a 4th product appears with different pricing and lead time. The automation starts sending technically correct but contextually wrong follow-ups. Fix: update the product knowledge base and retrain one classification prompt. Twenty minutes. The owner didn't know to do it because the handoff doc covered the original 3 products. I now add a "what changes when your business changes" section to every handoff doc.
The vendor who changed an API. Happened twice in 12 months across clients. A vendor pushed a breaking change with two weeks notice to a developer inbox nobody checked. The automation broke silently on a Saturday morning. The alert fired within two minutes because of day 21 setup. Fix took a few hours. The argument for strong API stability guarantees and for listing vendor support contacts in the handoff doc.
If you want to go broader than one business type, the NYC operator breakdown covers what works across five different business models in this market and what's quietly illegal here that vendors don't tell you about.
12 questions, 30 minutes. Tells you whether you're ready to build now, a few weeks out, or have foundational gaps first. Free checklist here.
I map your operations, rank your top five leaks with dollar estimates, and hand you a 20-page report with a specific recommendation. No fit, no fee. Book a 30-min call to start.
One automation built end-to-end, tested, documented, and handed off. Includes 30 days of post-handoff support. For operators who've done the audit and know what they want built. Sprint details on the services page.
Multiple automations working together across sales, ops, and customer behavior. One daily briefing. Full documentation and 90 days of monitoring after launch. Full Install details here.
Want to know what your top automation opportunity is worth?
Book a 30-min callA Sprint is scoped to one specific leak. You pay once, we build one system, I hand it off and leave. A retainer assumes you need ongoing access to someone's time rather than a delivered result. I don't do retainers. If you need a second Sprint after handoff, we book a fresh one. The Sprint model creates the right incentive: I get paid for shipping something that works, not for showing up on a monthly basis.
That's exactly what the audit is for. Day 4 of the audit builds the leak-rank, a prioritized list of five candidates with dollar estimates. We pick the top candidate together before any Sprint begins. If during the Sprint we discover the scoped leak has a hard blocker (a vendor API that doesn't exist, a data quality problem that takes months to clean), we re-scope to the next-ranked candidate. Scope changes happen before build starts, not after.
Fully remote. Discovery, workflow shadow, and daily standups happen on Zoom. For operators with a physical location (warehouse, showroom, retail floor), one optional in-person visit during the audit is useful but not required. I'm based in Brooklyn and cover all of NYC metro for in-person if needed. Most engagements run 100 percent remote. For context on how this works for NYC-based businesses specifically, see AI consulting in Brooklyn NYC.
You own everything. The code runs on your API keys and your infrastructure. I'm available for 30 days of follow-up support included in every Sprint, typically a check-in at day 15 and day 30 post-handoff. After that, if something breaks or you want to build the next automation, we book a fresh engagement. No monthly retainer, no dependency on me to keep the lights on. See the Fractional AI Officer services page for what ongoing work looks like.
Every Sprint includes 30 days of post-handoff support: two check-in calls and async Slack access for questions. After 30 days, ongoing support is available as a fresh Sprint or a targeted fix engagement. The goal is that your team can operate the system without me. If they can't after 30 days, that's a documentation failure on my end, not a reason to charge you a retainer.
Before any build starts, we agree on one measurable baseline and one measurable target. Examples: inbound lead response time from 4 hours to under 10 minutes. Quote follow-up rate from 30 percent to 90 percent within 48 hours. Hours per week on manual data entry from 12 to under 2. The day 30 report compares pre-Sprint baseline to post-Sprint measurement. If the needle didn't move, I don't count it as a success regardless of whether the system is technically running. The voice agent 90-day log shows what this looks like across a full production cycle, including the months it underperformed and what changed.