How to turn a discovery call into a tailored multi-site solution proposal in under an hour

TL;DR: Convert the transcript into a structured requirements table first, get the customer to confirm that table, and only then generate the proposal. The requirements table is the entire trick — it is what makes the proposal feel tailored and what stops the model inventing technical commitments you cannot deliver.

The problem: momentum dies in the drafting

A good discovery call ends with the buyer energised. Then you go away to “put something together,” and the something takes eleven days because you need input from pre-sales, pricing from the carrier desk, and a site list from the customer that nobody chased. By the time it lands, the urgency is gone.

This is particularly brutal in enterprise connectivity, where a single opportunity might span MPLS circuits, SD-WAN overlays, SIP trunking and dedicated internet access across dozens or hundreds of sites, each with its own access dependencies and lead times. The complexity is real. The eleven days are mostly not.

What you need

• A transcript of the discovery call (see the MEDDPICC scoring workflow for the recording setup).
• Claude or ChatGPT on a paid tier.
• Your own approved building blocks: standard service descriptions, SLA language, implementation phase templates, and a rate card or pricing guardrails. This is the part you must supply — the model cannot know your commercial reality and should never guess it.
• A proposal template you already use and legal has already seen.

Step 1: Extract requirements, not a summary (10 minutes)

A summary of a discovery call is useless for proposal writing. You need a structured, testable requirements list.

“Here is a transcript of a discovery call with a prospective customer. Extract a requirements table with these columns: Requirement | Stated or Inferred | Verbatim quote | Owner who said it | Open question.

Cover: sites and locations, current provider and contract end dates, bandwidth and performance needs, voice requirements, security and compliance constraints, timeline and any hard deadline, budget signals, and success criteria.

Rules: if something was implied but not stated, mark it Inferred and put the exact ambiguity in the Open question column. Never fill a gap with a typical or industry-standard value. Missing information is the most useful output here — I would rather see fifteen open questions than a complete-looking table that is half invention.”

Expect 20-40 rows, of which a third will be Inferred. That third is the difference between a proposal that fits and one that gets politely ignored.

What the table looks like filled in

Four rows from a real extraction, abbreviated:

• 42 UK sites, 3 in Ireland | Stated | “We’ve got forty-two here and three across in Dublin and Cork.” | Infrastructure Manager | Open: are the Irish sites in scope for this procurement or a separate contract?
• Current MPLS contract ends March | Stated | “The existing arrangement runs to the end of March and we’re not renewing on the same terms.” | IT Director | Open: is that contract end or notice deadline? Notice period unknown.
• Voice migration in scope | Inferred | “…and obviously the phone system’s ancient.” | Infrastructure Manager | Open: is voice actually in scope for this RFP or a separate future project? “Obviously” is doing a lot of work here.
• Two sites need higher resilience | Inferred | “The distribution centres can’t go down, really.” | Operations | Open: which sites specifically, and what does “can’t go down” mean contractually — dual circuits, diverse routing, four-hour fix?

Notice what the Inferred rows do. “Obviously the phone system’s ancient” is exactly the kind of aside a rep hears, mentally files as “they want voice too,” and builds a proposal around. It might mean that. It might equally mean “that’s a problem for next year.” Getting that wrong is the difference between a proposal that wins and one that arrives priced 40% above what they asked for.

Step 2: Send the table back to the customer (the step nobody does)

Before writing anything, email the requirements table:

“Before I put pricing together, here’s my understanding of what you need — including the bits I wasn’t sure about. Could you correct anything wrong and fill the gaps? It’ll save us a round trip.”

Three things happen. You get the site list without chasing it separately. You look rigorous rather than eager. And if they will not spend fifteen minutes correcting a table, you have learned something important about the deal that no amount of proposal polish would have told you.

Step 3: Generate the technical solution narrative

With a confirmed table, and your own service descriptions pasted in:

“Using ONLY the confirmed requirements table and the service descriptions I have provided, draft the solution section of a proposal. Structure it as: (1) our understanding of their situation, in their own words from the quotes; (2) proposed solution per site category — group sites, do not list all of them individually; (3) how each element maps to a specific stated requirement, referencing the requirement row; (4) implementation phases with dependencies; (5) explicit assumptions and exclusions.

Hard rules: do not state any bandwidth, SLA figure, lead time or price that is not in my service descriptions. Where a value is needed and not supplied, write [CONFIRM WITH PRE-SALES]. Do not use the words ‘seamless’, ‘robust’, ‘cutting-edge’ or ‘best-in-class’. Write for a technical evaluator who will check your claims.”

That banned-words instruction is not stylistic fussiness. Vendor-speak is precisely what makes proposals interchangeable, and technical buyers read it as a signal that nobody engaged with their problem.

Step 4: The mapping check

Before it goes anywhere, run the adversarial pass:

“Act as the customer’s technical evaluator. For each requirement in the confirmed table, state whether the proposal addresses it fully, partially, or not at all. Then list every claim in the proposal that is not traceable to a requirement or to my service descriptions. Finally: what is the strongest objection you would raise, and what have we not addressed that you would expect a serious vendor to cover?”

This routinely catches two failure classes: requirements you quietly skipped because they were awkward, and confident sentences that crept in from nowhere. Fix both before sending.

Step 5: Pricing stays human

Let me be unambiguous: do not let a language model calculate or suggest pricing. Not the monthly recurring charge, not the install charge, not the discount. It will produce numbers that look reasonable and are wrong, and in a multi-site deal a plausible-looking error compounds across every location.

What AI can legitimately do on pricing:

• Build the site-by-site table structure for you to populate.
• Check arithmetic consistency once you have entered real figures — totals, term calculations, per-site averages.
• Draft the commercial narrative around numbers you supplied.
• Sanity-check that every site in the requirements table appears in the pricing table. This catches the classic omission that turns into a margin problem later.

Step 6: The executive summary, written last

Write it last and address it to the economic buyer, not the technical evaluator:

“Write a one-page executive summary for [role] who did not attend the technical calls. Lead with the business outcome and the cost of doing nothing, both in the customer’s own words from the transcript. Then the approach in three sentences, the commercial shape, and the decision we need from them. No technical acronyms without expansion. Under 400 words.”

Realistic time budget

• Requirements extraction: 10 minutes
• Customer confirmation: 1-2 days elapsed, 5 minutes of your time
• Solution narrative: 15 minutes
• Evaluator check and fixes: 15 minutes
• Pricing: however long your carrier desk takes — unchanged by any of this
• Executive summary and formatting: 15 minutes

So under an hour of your working time, against a genuine same-day turnaround if pricing is straightforward. The elapsed-time win comes from the confirmation step removing an entire clarification cycle.

What breaks

• Garbage transcript, garbage proposal. If discovery was shallow, this workflow produces a well-structured document about nothing. It amplifies the call; it does not replace it. Fix the discovery first — the discovery prep guide helps.
• Invented technical detail. The single biggest risk. The “only from my service descriptions” constraint plus the mapping check catches most of it, but a pre-sales engineer must read anything technical before it goes out.
• Over-tailoring. Quoting the customer six times reads as attentive; twenty times reads as a trick. Two or three verbatim quotes maximum.
• Confidentiality. Customer transcripts and site lists are sensitive. Use a tier with training disabled and check what your employer permits before uploading anything.

Once it is won, the same transcript has a second life — turning a customer call into a case study uses the same raw material for marketing.