// Posted 2026-08-11

How to Scope a 14-Day AI Sprint Before You Sign the Check

Founders keep asking what fits inside a 14-day AI sprint. The answer is one function, one queue, three data sources, one live output the team already reads.

Translucent indigo 14-day calendar grid tilted in space with amber milestone markers, pink scoping arcs, and blue dependency beams tracing between workflow nodes on a dark backdrop

It is Tuesday, 11:14 AM. Your COO forwards an SOW for an AI sprint. Fourteen calendar days. Low to mid five figures. One function running end to end on day 15. Her note reads five words: "is this a real thing." She has three quotes in the same thread. One agency proposes a six-month discovery. One consultant proposes a Zapier retainer at $4K a month. The third quote is the 14-day sprint.

She has good instincts. Six-month discovery kills the budget before anything ships. Zapier retainers stall the day the automation hits a decision the workflow builder cannot express. The 14-day sprint sounds fast enough to be either serious or fake. The difference sits inside the scope, and the founders who get it right hold three rules going in.

Rule one: one function, not one task and not one department

A task is a step. A function is a queue that never stops. Drafting a follow-up email is a task. Owning the inbound demo queue so every request gets contacted inside 20 minutes is a function. Summarizing a Gong call is a task. Producing the case-study backlog from closed-won through published landing page is a function.

Ninety percent of failed AI sprints scope a task. The team ships a Gong-to-Notion summarizer and calls it done. The queue upstream still drifts because no agent owns the routing, the interview ask, the legal review, or the publish step. The founder writes a check for a demo that never becomes a function on the org chart.

A function is scoped by the queue it owns and the output it ships. Case-study production owns nominations through published stories. Renewal ops owns the 90-day-out list through the negotiated contract. Support triage owns the ticket queue through routed and pre-drafted replies. If the scope reads "drafts emails" or "summarizes calls," the sprint is a task and it will not pay back. If the scope reads "clears the queue and posts the output the team already reads on a cadence," it is a function.

Scoping the wrong altitude is the single most common founder mistake. The tell in the SOW is the deliverable list. A task sprint ships a prompt library and a Zap. A function sprint ships an owner for a queue, a live output on a cadence, and a Slack channel where the humans handle the exceptions.

Rule two: three data sources max on day one

Every stuck function in a Series B company touches seven to twelve systems. Case-study production reads Notion, Salesforce, Gong, NPS, G2, Slack, Figma, and WordPress. Renewal ops reads Salesforce, Gainsight, Zendesk, product usage, invoice history, and the CSM's Notion. The temptation is to wire all of them in week one.

Do not. The sprint scopes three data sources on day one and adds the rest on the following cycle. Pick the two systems that hold the queue and the one system that holds the trigger. For case-study production that is Salesforce closed-won, Gong transcripts, and Notion pipeline. For renewal ops that is Salesforce opportunity data, product usage from Amplitude or Mixpanel, and the CSM's Gainsight notes. Everything else waits.

Three sources is the number where a 14-day build finishes with room to test the exception loop. Five sources doubles the auth debugging, the schema mapping, and the failure surface. The teams that scope five on day one ship on day 22 and burn the founder's confidence in the process. The teams that scope three ship on day 14 and add the fourth source in the next cycle at a fraction of the cost.

The disciplined version of this reads like a 14-day process. Day one to three: pick the queue, wire the three sources, define the exception rules. Day four to eight: build the routing, drafting, and publishing steps. Day nine to twelve: run the queue on real data with the humans watching. Day thirteen and fourteen: publish the first outputs, hand the exception Slack channel to the function owner, and set the monitoring dashboard.

Rule three: one live output the team already reads

The output is the proof. If the agent does not ship a thing the team already looks at, the sprint dies inside a month. Founders confuse "the agent is running" with "the team trusts the output." The two are different problems, and the first one is trivial next to the second.

Pick a surface the team already opens. For case-study production it is the demand-gen Notion board and the published landing page. For renewal ops it is the weekly renewal Slack channel and the Gainsight health dashboard. For support triage it is the Zendesk queue view the CX lead opens at 8 AM. The agent posts into the surface the team reads on its normal cadence. Nobody has to learn a new tool. Nobody has to open a new dashboard. The output shows up where the work already lives.

Three translucent indigo system panels feeding amber data flows into a central pink hexagonal decision node ringed by blue SLA gauges on a dark backdrop

The four questions the SOW has to answer

Before the founder signs, the scope has to answer four questions in one page. If the SOW hedges on any one of them, the sprint is not ready. Send it back and ask for the redline.

What queue does the agent own on day 15. Name the queue by the system and the count. Salesforce closed-won at 47 rows a quarter. Zendesk tickets past first-response SLA at 340 open. Renewal opportunities inside 90 days at 47. The queue count anchors the payback math and forces the vendor to commit to a boundary.

What three data sources connect on day one. Name them by product and the specific object read. Salesforce Opportunity, Gong Call, Notion Database ID. Not "the sales stack" and not "the CRM." A scope that lists categories instead of objects has not been scoped.

What output ships on day 15 and where. Name the surface the team already reads and the cadence. A Slack post at 8 AM weekdays in #cs-renewals. A row appended to the demand-gen Notion database inside 24 hours of closed-won. A pre-drafted Zendesk reply attached to the top 40 tickets by 6 AM. If the deliverable is a "dashboard the team will get access to," the sprint is a demo and the team will stop opening it by week three.

What exception routes to a human and how. Every function has 5 to 15 percent of cases the agent should not resolve alone. Name the exception rule and the Slack channel it pages. The exception loop is where the trust gets built in weeks three and four. Sprints that skip this step ship a black box the team stops trusting the first time an edge case slips.

The unit economics of scoping right versus scoping wide

A scoped-right sprint runs low to mid five figures and ships an owned function on day 15. A senior manager loaded at $190K to $260K a year takes four to nine months to reach the same steady state. On a stuck queue defending or recovering ARR at the $1M to $5M range a year, the payback math on the sprint lands inside a single quarter. The copilot version covers why seat-level tools do not close a function gap even at $38K a month.

A scoped-wide sprint ships an unfinished pilot on day 22, burns 40 to 60 percent of the budget on auth and schema debugging across five sources, and hands the founder a Slack channel that pages nobody. The next quote lands from a different vendor promising a six-month rebuild. That is the loop the founders who read this piece are trying to break, and the fix is a one-page scope that holds the line at three sources and one function.

What the SOW looks like when it is ready

Picture the same Tuesday morning, one week later. Your COO forwards the redlined SOW back. The scope reads: agent owns the renewal opportunity queue inside 90 days, reads Salesforce Opportunity, Amplitude product usage, and Gainsight notes on day one. Ships a Monday 8 AM brief in #cs-renewals naming every account inside 90 days, health score, product usage trend, last CSM note, and a proposed play. Exception rule pages the CSM Slack DM on any account with a $180K+ ACV showing a red health score inside 60 days.

Day fifteen the brief posts at 7:58 AM. The VP CS reads it before the Monday standup and the CSMs work the list. The exceptions land in Slack DMs on the four accounts that need a human call. The agent runs the queue Tuesday through Friday and posts the next brief the following Monday. The queue has an owner. The output has a surface. The exception loop has a human.

That is what a 14-day sprint looks like when the scope is right. One function, three data sources, one live output the team already reads, one exception loop that pages a human. If your SOW answers those four questions and the vendor holds the line at three sources on day one, sign the check. If the SOW hedges on any of the four, send it back and ask for the redline. You can scope one with us in a 30-minute call.

// Related notes