Promised-commitments extractor

A promised commitment is a named action, deliverable, timeline, or commercial term that a specific seller stated as something the company will do for this deal. The output that matters is a list with cites: the promise in one sentence, who said it, and when. Customer Success then checks each row against the signed statement of work. A row that cannot be mapped is a gap for a human to resolve, not a kickoff task.

Do not treat a sales aside as a contractual deliverable. Do not invent a promise.

Keep rows that sound like obligations the customer could reasonably expect delivery to honor:

• "We will" plus a concrete object and, when present, a timebox
• "Included" or "in scope" tied to a named workstream on this account
• A date the customer can put on a calendar
• A named person, team, or support motion the buyer was told they would receive

Leave off rows that are color, not commitments:

• Hypotheticals and discovery ("if you needed region pinning, we could look at it")
• Product capabilities mentioned as table-stakes, not as this deal's scope
• Soft language with no owner or date ("maybe in phase two", "we'll see")
• Roadmap teases that the buyer did not accept as part of the close

If a candidate line has no speaker and no timestamp or message date, omit it. A list that is slightly short is usable. A list that invents scope is not.

This list feeds the sales-to-CS handoff briefing. It is the promise layer, not the full commercial packet.

Work spoken and written sources, not a single recording. Late-stage calls, verbal closes, and the emails that restated scope after those calls are the usual places "we will" shows up. Conversation intelligence tools in this class (Gong, Chorus) hold transcripts. CRM systems in this class (Salesforce) hold the opportunity, quote, and people. CS platforms in this class (Gainsight) hold the account that will inherit the list. None of them is the signed contract.

Run extraction in this order:

1. Closed-won call transcripts, starting with late demo, commercial, and verbal close.
2. Email threads where the AE or SE restated scope, dates, or staffing after a call.
3. Proposal or deck language only as a cross-check. A slide is not a cite unless a named person also said it or sent it.

For each surviving phrase, store:

• The commitment in one sentence, preferring the customer's wording when they repeated it
• Speaker name and role (AE, SE, manager)
• Source type (call or email)
• Timestamp on the recording, or sent date on the message
• Whether the customer affirmed it ("yes, include that") or only heard it

Then strip capability mentions that never became promises. "The product supports SSO" is not "we will configure SSO against your IdP in week two."

Keep this pass aligned with post-call summary and CRM auto-update so opportunity notes and the commitments list do not drift. The CRM note can be a digest. The commitments list still needs speaker, time, and a yes or no on whether the line is in the SOW.

On a verbal-close call at 41:12 the AE says, "We'll throw in a dedicated Slack channel with our SE for the first month." Twelve minutes later the SE says, "SSO is on the roadmap; we could probably do it if you need it." The extractor should emit one row: dedicated Slack with the SE for the first month, AE, 41:12. It should not emit SSO. "Could probably" is not "we will."

CS owns confirmation. Extraction produces candidates. The signed packet decides which candidates are delivery work.

For each cited row, record one of three outcomes:

• In SOW: quote the SOW section or exhibit line that covers it
• Already papered: a paid change order or amendment already exists
• Gap: a named seller promised it, and the signed SOW does not

Pull SOW fields from signed-contract data extraction rather than from memory of the last deck. Match on the obligation, not on shared nouns. A call that mentioned "sandbox" and an SOW line for "non-production environment" can be the same commitment. A call that mentioned "white-glove onboarding" and an SOW that only lists standard implementation hours is a gap, even if both sentences contain the word onboarding.

Send gaps back to the AE before kickoff, with the cite attached. The customer already heard a person say it on a dated recording. Arguing from a summary without the cite wastes the meeting.

Until CS marks a row in SOW or papered, delivery must not schedule it as a contractual deliverable. The Slack row above is a gap if the services table has no Slack coverage. Put it on the exception list. Do not put it on the week-one task board as if legal had already agreed.

Three mistakes show up on almost every noisy first pass.

Turning a maybe into a must is the most common. Modal verbs and hedges are the tell. "We could," "we might," "probably," "if you need it," and "let's take that offline" are not promises. If the model upgrades them to "we will" because the rest of the sentence named a feature, you have invented a deliverable. Keep the original wording in the cite so a reviewer can see the hedge. If the wording is a hedge, the row should not exist.

Missing the signed SOW is the expensive one. A perfect transcript list that never meets the contract will ship asides as scope. If CS confirms against a proposal PDF, a verbal recap, or last week's CRM notes instead of the signed exhibits, the list will include items legal already dropped. Always open the signed file, including exhibits and the assumptions appendix, before you label a row in-scope.

Listing every feature mentioned as a commitment floods kickoff. Discovery calls name a lot of product surface so the buyer can evaluate fit. Those mentions are not commitments. If the extractor lists every noun the SE demoed, CS will spend kickoff triaging a product catalog. Require promise grammar plus a cite, then require an SOW match or an explicit gap. Feature name plus enthusiasm is not enough.

When a gap is real and still open at handoff, route it through the implementation risk flagger so delivery sees the mismatch as a risk, not as silent extra work.

Bring the confirmed list, not the raw extract, into the internal handoff and the customer kickoff.

Internally, walk only the gaps and the in-SOW items that delivery might miss: staffing, SLAs, date commitments, custom work. Do not read every demo feature aloud. The AE should own explaining any gap they created. CS should own whether delivery can absorb it, needs a change order, or must reset the customer with the cite and the SOW line side by side.

On the customer call, use the list as a checksum. Read the in-SOW commitments the customer cares about. For each gap, say that it was discussed, show who said it and when, and state that it is not in the signed scope unless they paper it. That is slower than nodding along. It keeps a friendly aside off the delivery plan until someone papers it.

Feed confirmed in-SOW commitments into the auto-drafted success plan as measurable outcomes only when the SOW already supports them. A success plan that repeats unpapered sales asides will lock the same broken promise into CS rituals.

Quality here is boring on purpose: every promise has a person and a time, every in-scope mark has an SOW cite, and nothing on the delivery plan was invented from a maybe.