Skip to main content
DoneThat

AI Adoption GuideConsultingClose

Follow-On Opportunity Signal Detector

LLM scans final deliverables and client conversations for unresolved problems that signal expansion or follow-on opportunities.

Consulting processSellScopeStaffKickoffAnalyzeRecommendDeliverClose

By Don, DoneThat’s AI coach · updated

Unresolved problems go in the close pack, not the pipeline

The job is to list named problems this engagement identified and did not solve, with evidence, so the partner can decide whether to raise them. It is not to open a follow-on, send a proposal, or time a pitch.

Close quality here means leftovers are not forgotten a week later, and are not treated as sold. The last steering committee already produces sentences like "that's a different conversation." They vanish into the readout. Writing them into the close pack is useful. Creating a qualified row in Salesforce or Microsoft Dynamics is a hunting license.

A scope creep detector flags out-of-SOW requests during delivery. This pass is after acceptance: you are not arguing change orders. You are recording what the work surfaced and left on the table.

Do not auto-pitch. Do not email the client from the model. Do not move a signal into a pipeline stage. The partner still owns whether the client would hear this as care or as mining.

Scan final deliverables and conversations you were allowed to keep

Run the pass after acceptance, on a corpus the engagement is allowed to retain.

Use:

  • Final deliverables: the assessment, recommendation deck, shipped issue log, anything the client signed off as the close pack.
  • Consented conversations: late steering committees, readout rehearsals, and close-out calls recorded with a basis the client accepted. Conversation intelligence such as Gong is a source when those calls were in the project. It is not a warrant to ingest every account recording.
  • Project workspace notes: a Notion page the team used as the working issue list is an artifact. A partner's private notebook is not.

Do not mine private mail. Partner inboxes, 1:1 Slack or Teams DMs, and personal forwards mix gossip and off-the-record asides. Quoting them in a follow-on brief will eventually put them in front of someone who was not meant to see them.

If the client prohibited recording, you do not have a conversation corpus. Scan the written deliverables and the notes the client already received. Do not paste a secret recording into a model.

Tie each leftover back to the signed SOW. A problem that was never in scope is a candidate signal. A problem the team failed to finish inside scope is a delivery miss. Put delivery misses in the lessons learned synthesizer, not on a follow-on list.

A signal is a leftover with a quote, not a sold next phase

List each leftover as a named problem, a SOW gap, and a quote. Do not list it as sold work.

Each item the partner sees should be short enough to reject in one sitting:

  • Problem: a named leftover (safety stock rules, a 3PL renewal), not "further transformation."
  • Evidence: section of the final deliverable, or speaker plus timestamp from a consented call.
  • SOW gap: the exclusion, or the silence, that kept it out of this engagement.
  • Who raised it: client role, not "the team believes."
  • Status: unresolved, deferred by the client, or excluded on purpose. Those are different.

The model will try to turn every leftover into a workstream with a duration. That is treating every leftover as a sold follow-on. Some were left out because of an incumbent, a legal wall, a sponsor who does not want this firm on that problem, or a practice you do not have. Those are still worth recording. They are not opportunities.

Write the list as signals for a conversation. Next-step language, if you include it, should be a question the partner can ask, not a mini-proposal. "You named X; we did not solve it. Do you want a scoped look, or should we leave it?" is the shape. A two-page Phase 2 outline is the wrong shape.

If the partner later wants a real bid, that work goes through a bid no-bid opportunity classifier like any other inbound. Knowing the client does not skip fit, capability, or conflict checks.

Illustrative close: a warehouse diagnostic that named inventory policy and walked past it

The useful close pack quotes the COO's deferred inventory-policy sentence and the 3PL calendar fact. It does not open two opportunities.

This is an illustrative scenario, not a measured engagement.

A ten-week warehouse operations diagnostic. Signed SOW: current-state assessment of two DCs, a bottleneck map, and a 90-day ops roadmap. Explicit exclusions: warehouse-management system selection, inventory policy redesign, and running a 3PL RFP.

The final assessment flags two constraints it will not model. Safety stock rules sit in finance, not in the DC. A 3PL contract comes up for renewal in the next planning cycle; the team notes it as a dependency and stops.

At the readout, the COO says, on a consented steering recording, "the real issue is the safety stock rules, but that's a different conversation." Nobody restates it as a deliverable. BD is already asking whether there is a Phase 2.

What the close pack should hold

Two signals, quoted, not two opportunities:

  • Safety stock / inventory policy. Evidence: COO, readout, "the real issue is the safety stock rules, but that's a different conversation." SOW gap: inventory policy redesign is an explicit exclusion. Raised by: COO. Status: client-deferred, not a failed deliverable.
  • 3PL renewal as a constraint. Evidence: assessment section on network dependencies, not a request to run an RFP. SOW gap: 3PL RFP excluded. Status: calendar fact, useful later only if the partner decides the relationship can take that conversation.

The partner can sit on both, raise inventory policy after the roadmap has landed, or never raise the 3PL item.

What a hunting license does instead

The unconstrained pattern is familiar. The model emits "Phase 2: Inventory Policy and 3PL Strategy" with a suggested close date. Someone creates the opportunity in Salesforce or Microsoft Dynamics as qualified because the COO "asked." An email goes out the afternoon of the readout offering to stay on and fix safety stock.

That is pitching on the last day. The client just accepted a diagnostic they paid for. The leftover sentence was a boundary, not a buying signal. You have taught them that close means a pitch.

If the same leftovers showed up as change-order requests during the ten weeks and were refused, they are residue from the scope creep detector, not expansion. Re-pitching refused scope at close spends goodwill you need for the next real ask.

The partner times the conversation; the model does not

The partner chooses whether and when to raise a signal. The model does not send mail, create a qualified opportunity, or pick the day.

Gate the list on relationship and on whether delivery actually landed. A post-delivery relationship health monitor is the right check before anyone reaches out: contact falling away, sponsor turnover, a quiet account. If delivery was rocky, keep the signals in the pack and wait. Raising unpaid next work while the client is still unhappy about this work is the same last-day pitch with a delay.

When the partner does raise it, they do it as the person who owned the engagement, with the quote in front of them. The conversation can be "leave it," "come back in a quarter," or "send a short scope." Only the last of those becomes a bid, and only after the partner says so.

Do not recycle leftovers into marketing. A reusable case study drafter writes what this engagement did, with consent and anonymization. Unresolved problems are not proof points. Putting "we identified inventory policy as the real issue" in a case study is how a leftover becomes a claim you did not deliver.

If you log anything in Salesforce or Microsoft Dynamics, log an account note or a next-conversation reminder the partner controls. Do not advance stage, forecast value, or assign a close date because a model found a sentence. Notion can hold the close-pack list next to the final deliverable so the next team on the account can see it. That is memory. It is not pipeline.

The system is working when accepted work leaves a short, quoted list of problems the SOW did not solve, and a partner still decides whether the client should hear any of it. It is failing when close day includes a pitch, when every leftover is a sold follow-on, or when private mail is the source.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first