How Slack promises become undocumented scope: the 4-step evidence trail from "sure, we can do that" to a missed go-live

TL;DR: A Slack promise becomes undocumented scope in four steps: the ask arrives informally, one engineer says yes, nothing updates the SOW, tracker or CRM, and the work reaches the critical path weeks later. The go-live is missed because there was never a record to compare against, not because anyone hid a change. PMI's 2018 Pulse found that 52% of projects experienced scope creep or uncontrolled changes. Capture the commitment as account state at step 2, with the source attached. Spendesk did, and runs 3 weeks shorter from kickoff to go-live on average.

The go-live that slips by three weeks rarely has a villain. Somebody asked for something in a shared Slack channel, an engineer typed "sure, we can do that", and the ask went into the build without going into a document. Four months later the customer quotes that message back at a go-live review.

This is the most common way scope creep enters an implementation, and the least visible. PMI's 2018 Pulse of the Profession found that 52% of projects experienced scope creep or uncontrolled changes to scope, and lists poor communication as a cause of failure for 29% of failed projects. The word doing the work is "uncontrolled". A Slack yes is usually a fine decision. It just skipped every control you set up.

This article follows one commitment through the four steps that turn it into undocumented scope, and shows where the evidence gets lost. It's written for the forward deployed engineer, the role closest to the channel. A forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer. For the wider picture, start with our guide to scope creep in implementations.

Step 1: the ask arrives in Slack, on a call, or in a reply

The first step is an ask that arrives with no ceremony, in whatever channel the customer already has open. It sounds like "can you just add" or "while we're in there, can we also".

Where does an implementation commitment actually get made?

Almost never in a change request form. Commitments get made on the kickoff call, in the shared Slack Connect channel, and in the hallway when you're on site. FDE Academy, a training organization for the role, says "verbal scope changes in a hallway conversation or a quick Slack message are where silent scope creep does the most damage".

The evidence at this step is the message itself, or a recording if the call had one. It gets lost because a form has a reviewer and a channel only has readers.

The ask is often a reversal, not an addition

The dangerous asks undo an earlier decision. An FDE at an early-stage insurance-claims platform: "some clients will try to go the complete opposite way without telling you, with minimum notice." A reversal costs more than an addition, because built work has to be unbuilt, and it arrives phrased like a small tweak.

Step 2: an individual says yes

One person, usually the engineer in the channel, accepts the ask with nobody else in the loop.

Why "sure" costs less than opening the SOW

Typing yes takes twenty seconds. Doing it properly means leaving the build, opening the SOW, checking the ask against the scope baseline, drafting a change request, and finding your way back into the code. Gloria Mark's research at UC Irvine, reported by Fast Company in 2008, found that after an interruption it takes an average of 23 minutes and 15 seconds to get back to the task.

So the yes is rational in the moment. Larson and Larson's 2009 PMI paper names the mechanism: some change requests "are or appear to be small, so again, project teams act on them instead of following a formal change management process". Small is a judgment made by the person being interrupted, without the baseline open.

Why a Slack yes feels revocable to you and binding to the customer

You and the customer read the same message and see two different documents. Research by Vanessa Bohns and Roseanna Sommers, reported by the Cornell Chronicle in February 2026, found participants experienced written consent as "significantly more binding and less revocable than oral consent, even when forms explicitly stated signers could withdraw". To you, "sure, we can do that" is a conversational reply, hedged by everything said before it. To the customer, it is text with a name and a timestamp, and once pasted into a go-live review it reads like a contract.

For your side, that message becomes one needle in a channel that will hold thousands more by go-live. An FDE at a pre-seed AI startup: "I really don't want to be searching Slack for the last conversation five minutes before the meeting." Spendesk's engineers had the same problem until call prep was cut from 45 minutes to 5.

Step 3: nothing updates the SOW, tracker or CRM

A record should have been created here and wasn't. The SOW still describes the original baseline, the tracker has no ticket, and the CRM shows what sales promised before signature.

The re-entry work nobody does

Writing the ask into three systems is data entry, the work people rank lowest. Slack's own Workforce Index from June 2024, a survey of 10,045 desk workers, found respondents spend about a third of their workday on activities they consider low-value, with paperwork and data entry among the top items. An FDE at a robotics-AI vendor: "I don't want to babysit another system." That is the context tax on implementation teams, paid one unrecorded yes at a time.

The promise now lives in one head

Once nothing is written, the engineer who said yes is the only place the promise exists. Panopto's 2018 study found that 42 percent of institutional knowledge is unique to the individual. Hand the account to a second engineer and the promise leaves with the first.

The baseline stops describing the account

By the third unrecorded yes, the SOW is a snapshot of a project that no longer exists. An FDE at an early-stage insurance-claims platform: "Sales is saying one thing, marketing another, and I'm implementing a third. It's broken telephone with outdated documentation." How the baseline should evolve is covered in turning the scope baseline into account state.

Step 4: the work lands on the critical path and the go-live date moves

The fourth step is the only one anyone sees. The unrecorded asks have absorbed build time for weeks, and the original date arrives before the work does.

What the missed go-live looks like from the FDE side

Jira barely moves, because the work being done has no tickets. Status updates say "on track" against a plan that stopped describing the project at step 3. An FDE at a robotics-AI vendor: "We've had times where we couldn't deliver on that specific timeline. If that could have been surfaced before, we could have managed the customer's expectations." The signal existed at step 2, often ten weeks earlier. Then, at the review, the customer pastes that message. You have a "yes" with no agreed date, price or acceptance criteria, and the customer has a screenshot.

There was never a record to compare against

The slip is a comparison failure. Nobody compared the build to a baseline because there wasn't one to open. You can't detect scope creep without a baseline, and you can't reset expectations without a list of what you've committed to. Both need a single source of truth for the implementation that most teams don't have.

How do teams track verbal commitments to customers today?

Most teams keep them in Slack search and a spreadsheet, and the two are never connected.

• Spreadsheets + Slack (the real incumbent). Where the Slack yes ends up: In the channel. The sheet updates if someone remembers. What it misses: No link between message and row. Effort to keep current: High, on the engineer who said yes.
• Meeting recorder (Gong, Granola, Fireflies). Where the Slack yes ends up: The call version of the promise. What it misses: The Slack and email versions (meeting notes are not account state). Effort to keep current: Low to capture, unquantified to reconcile.
• PSA or tracker (Rocketlane, Jira, Linear, Asana). Where the Slack yes ends up: As a task, once a human creates it. What it misses: Every commitment made before the ticket exists. Effort to keep current: Varies by team.
• CRM notes (HubSpot, Salesforce). Where the Slack yes ends up: Sales-era scope, rarely updated after signature (the CRM handoff gap). What it misses: Everything promised after the handoff. Effort to keep current: Usually neglected post-sale.
• Home-built context file (Obsidian, Claude Code, a Postgres store). Where the Slack yes ends up: Wherever one engineer pastes it. What it misses: Anything said to a colleague. Hard to share. Effort to keep current: High, one person's discipline.
• Tandem account brain. Where the Slack yes ends up: In account state, with the Slack, call or email source attached. What it misses: Off-channel asks nobody writes down (see what stays manual). Effort to keep current: Low once sources are connected and playbooks configured.

Where the account brain fits in the trail

Tandem is the AI workspace for implementation and deployment teams. Its account brain is built from Slack, email, CRM, tickets and calls, and holds account state: what was promised, decided, and at risk, with the source attached. Risk detection shows red, amber, green with the evidence: scope drift, silence, slipping commitments.

In this trail, the Slack yes becomes a promise in account state at step 2, and the scope drift signal fires at step 3 when that promise has no matching SOW line or ticket. Tandem agents draft the SOW addendum or the CRM update, a human approves it before anything is sent, and the record carries a visible marker with the source message attached. The go-live conversation moves forward a step, while the date can still move.

What stays manual

Tandem does not decide whether the answer is yes.

The judgment calls

Deciding whether to accept the ask is yours, and so is pricing it and approving the change. Telling the customer the date moved is still a conversation you have to have yourself. FDE Academy's discipline still applies: "say yes to the business need immediately", decide the implementation separately, then write a brief summary the same day. A hallway ask on site reaches any system, Tandem included, only through that summary.

The setup and the boundaries

Tandem needs your playbooks configured first, including what counts as a commitment on your team. It pairs with a PSA or tracker rather than replacing resourcing and invoicing, so the ticket still lives in Jira or Rocketlane. Every agent action is drafted for a human to approve, and the log shows who approved it and from which source.

Get the promise into account state at step 2

The record has to be created while the evidence still exists. Spendesk's Head of Customer Success and Account Management describes the other side: "An engineer picks up any account and knows in five minutes what was promised and what's at risk. Nobody maintains anything." The calendar outcome was 3 weeks shorter from kickoff to go-live on average.

If your last slipped go-live traced back to a message nobody wrote down, see Tandem flag scope drift on one of your live implementations, and bring the account with the longest Slack channel. When the yes does need pricing, how change orders work in Rocketlane, Kantata and Certinia covers that side, and the FDE page covers how Tandem fits the role.

FAQs

What is undocumented scope in a software implementation?

Undocumented scope is work the team has committed to deliver that appears in no SOW, change order, ticket or CRM record. It usually enters through a Slack message or a call, accepted by one person, and shows up as a go-live slip nobody can explain against the plan.

How do I track verbal commitments to customers without becoming the person who says no?

Separate the yes to the business need from the decision about the implementation, and write the ask down the same day. A written summary lets you price and date the work later. Teams that capture commitments as account state tend to say yes more often, because they can see what the yes costs.

Does Tandem replace our PSA or Jira for scope changes?

No. Tandem pairs with your PSA or tracker rather than replacing resourcing, ticketing and invoicing. The account brain holds the commitment with its source, risk detection flags it when no SOW line or ticket matches, and a Tandem agent drafts the addendum or CRM update for a human to approve.

Key terms

Scope creep: Uncontrolled growth in a project's scope after the baseline is set, without matching changes to time, budget or resources.

Scope baseline: The agreed statement of what will be delivered, typically the SOW plus its accepted change orders. Scope creep can only be measured against it.

Change order: A priced and dated amendment to the SOW that both sides accept. A commitment becomes controlled scope the moment it becomes a change order.

Account brain: The Tandem product block that assembles account state from Slack, email, CRM, tickets and calls, with the source attached to every fact.

Account state: What the account brain holds: what was promised, decided, and at risk for one customer, kept current as new evidence arrives.

Critical path: The sequence of dependent tasks that sets the earliest possible go-live date. Unrecorded work reaches it silently, which is why the slip appears late.