How to Use ChatGPT to Turn a Project Scoping Call Into a First-Draft HLD and BOM

The short answer: ChatGPT can turn a rambling scoping-call transcript into a structured first-draft High Level Design outline and a starting Bill of Materials in an afternoon instead of a week. What it produces is a working draft for a certified architect to correct and own — not a design, and not a quote. The risk is not that it writes badly; it is that it writes confidently about things nobody actually said.

The scoping call went well. Ninety minutes with the client's operations lead, their finance director joining for the last twenty, and a reasonably clear picture emerged: three floors of a new office, roughly 180 staff, existing network gear that is out of support, a preference for staying on Microsoft, and a hard date in November because the lease starts then.

Then the transcript sits in a folder for eleven days.

Not because anyone is lazy. The presales engineer who ran the call is on two other opportunities, and turning ninety minutes of overlapping conversation into a document that a client can compare against another vendor's is genuinely a day of work. So it waits. Meanwhile the client, who is comparing vendors, receives someone else's document first.

That eleven-day gap is the problem worth solving, and it is a drafting problem rather than an engineering one.

Why the Gap Between "We Talked About It" and "It's Written Down" Costs Projects Weeks

A scoping call produces a shared understanding that exists only in the heads of the people who attended. Everything downstream — the equipment list, the price, the timeline, the internal approval, the comparison against a competitor — depends on that understanding becoming a document.

The document is slow to produce for reasons that have nothing to do with technical difficulty. Conversation is disorderly: the requirement discussed in minute four gets revised in minute sixty-one. Half the content is not requirements at all. Crucially, the gaps only become visible once you try to write it down — nobody notices that the number of wireless access points was never actually discussed until a section needs a number in it.

The cost of the delay is concrete. The client's memory of the call decays, and with it the sense that you understood them. In a competitive situation the first credible document frames the comparison, and everyone after it is judged against that frame. Internally, nothing can be quoted or scheduled until scope is written.

What is needed is not a better architect. It is a faster path from conversation to a reviewable first draft.

What ChatGPT Can Actually Draft From a Call Transcript

Modern versions of ChatGPT handle long documents well and can work from a transcript file directly. The capability that matters here is unglamorous: restructuring unstructured text into a defined shape, faithfully, without getting bored on page fourteen.

Two outputs are genuinely useful.

A first-draft High Level Design outline

Given a transcript and a specified document structure, it will produce a populated skeleton: business context and drivers, current state as described, requirements grouped by domain, stated constraints, assumptions, and — most valuably — what was explicitly placed out of scope.

The out-of-scope and assumptions sections are where this earns its keep. Human-written first drafts habitually under-record both, because at the time everyone remembers what was agreed. Six weeks later, in a change-request conversation, "we never said we were doing the CCTV" is worth having in writing.

Ask it to distinguish clearly between what was stated on the call and what it inferred. A well-instructed draft will mark inferences; an unguided one will blend them into confident prose, which is the single most dangerous property of this output.

A starting equipment and software Bill of Materials

From the same transcript it can extract everything implying a purchase — switches, access points, firewalls, licences, cabling, the UPS someone mentioned once — into a structured list with quantities where quantities were stated and an explicit "not specified" where they were not.

This is a checklist, not a BOM. It has no part numbers you can order against, no compatibility validation, no pricing, and no knowledge of what a real design would require but nobody happened to mention. Its value is that it takes twenty minutes instead of a morning, and it surfaces the omissions early: a list showing eleven "not specified" quantities is a precise agenda for the follow-up call.

Never send this to a client as a quote. Pricing depends on volume agreements, regional availability and lead times that live with a supply-chain team, not in a transcript.

A Practical Workflow — From Raw Transcript to a Document an Architect Can Review

1. Clean the transcript before it goes anywhere. Remove client names, company names, site addresses and any commercial figures discussed. Most of this is a find-and-replace to "Client A", "Site 1". Do this first, every time, before the file goes near a general-purpose AI tool.

2. Give it your own document template, not a generic request. Paste the actual section headings your firm uses for an HLD. "Draft an HLD" produces something generic; "populate these eleven sections from this transcript" produces something your reviewer recognises.

3. Instruct it to separate stated from inferred, explicitly. Something like: use only what is in the transcript; where a section has no supporting content, write "Not discussed on the call" rather than filling it in; mark anything reasonable but unstated as an assumption. This single instruction is most of the quality difference between a useful draft and a liability.

4. Generate the HLD outline first, then the BOM separately. Two passes with narrow instructions beat one pass asking for everything. The BOM pass should be told to output quantity "not specified" wherever a number was not said aloud, and never to infer one.

5. Read it against your own memory of the call before anyone else sees it. You were there. You are checking for two things: content that is subtly wrong, and content that is confidently present but was never said. The second is harder to spot precisely because it reads well.

6. Turn every "Not discussed" and "not specified" into a numbered question list. This is the highest-value artefact of the whole exercise. It is the agenda for the follow-up call, and clients read a specific question list as evidence you were paying attention.

7. Hand the draft to the architect as a draft, labelled as one. The document must carry a visible status — "AI-assisted first draft, unreviewed" — until a qualified person has gone through it. The failure mode is a draft escaping into an email thread and acquiring authority it never earned.

8. Let the architect correct, add, and own it. They will change things, and they will add requirements nobody mentioned because they know what a design of this type actually needs. That work is the design. Everything before it was transcription with structure.

9. Keep the prompt and template, and improve them. The second project is much faster than the first because the reusable asset is the instruction set, not the output.

An AI-Drafted HLD vs a Certified Architect's HLD vs No Written Design at All

• An AI-assisted first draft. Hours instead of days, captures assumptions and out-of-scope items thoroughly, and surfaces gaps early. It carries no professional accountability, cannot judge whether the design is sound, and will present inference as fact unless instructed otherwise. Correct use: an input to the architect's work, never a substitute for it.
• A certified architect's HLD. Someone qualified has decided the design will work, sized it properly, and put their name to it. That accountability is the actual product — it is what a client is buying when they ask for a design, and what a vendor stands behind at delivery. It costs skilled time, which is exactly why the transcription-and-structuring part is worth automating.
• No written design at all. More common than anyone admits: a verbal agreement, an equipment list in an email, and an invoice. It works until the first disagreement about scope, at which point there is no document to point at and the argument is settled by whoever is more persistent.

The realistic combination for most firms is the first feeding the second. The gain is not a cheaper design; it is a faster response, better-recorded assumptions, and architects spending their time on judgement instead of formatting.

Where a Draft Document Actively Misleads

Constraints that were never mentioned do not exist in the transcript. A building's riser capacity, a landlord restriction, a compliance requirement the client assumed you knew about — none of it is in the recording, so none of it is in the draft. The document will look complete while missing the thing that determines the design.

Invented specificity is the characteristic failure. Asked to produce a professional document, a model will supply plausible detail: a model number nobody discussed, a switch count that follows from an assumption it made silently. It reads exactly like the correct parts, which is what makes it dangerous.

Transcription errors propagate. Automatic transcription mishears technical terms and numbers routinely, and "fifty" becoming "fifteen" produces a sentence that reads perfectly and is wrong. Verify every number against the recording, not the transcript.

Confident prose disguises weak sourcing. A draft asserting the client "requires 99.9% availability" when someone said "we can't really afford downtime" has manufactured a specification. That number will end up in an SLA discussion.

There is no vendor accountability behind it. A document is only worth what the organisation issuing it will stand behind. An unreviewed AI draft, however good it looks, commits nobody to anything — which is fine while it stays internal, and a real problem the moment a client treats it as a proposal.

Getting This Right — Confidential Client Data, Document Ownership, and When to Bring in IT

Assume a scoping-call transcript is confidential, because it is. It typically contains the client's legal name, sites, headcount, current infrastructure and its weaknesses, budget figures, internal politics, and often an offhand remark about a system nobody has patched. That is a useful document to an attacker and an embarrassing one to leak.

Know which tool the transcript is actually going into, and under what terms. Consumer accounts, business tiers and enterprise deployments differ in how data is retained and whether it may be used for training. Confirm the terms for the specific plan you are on, and set a company-level rule about which tools may receive client material — this is the single most common uncontrolled AI risk in a professional-services firm, and it is a governance problem rather than a technical one.

Sanitize by default, not by judgement. A standing rule to strip client identifiers before upload survives deadline pressure; a rule to "be careful" does not.

Decide where the recordings live and how long they are kept. Call recordings and transcripts accumulate in meeting platforms indefinitely by default. If the client's contract says anything about confidential information or return of materials, this is in scope.

Label draft status inside the document. An AI-assisted draft should say so on the page until an architect has signed it off. Version control matters more than usual here because the whole method produces early documents that look finished.

The reviewer must be qualified to reject it. The value depends entirely on someone competent being willing to strike out a whole section. If the review is a formality, the drafting speed is buying you a faster route to a bad design.

Choosing where AI belongs in a presales workflow, writing the instruction templates, and setting the rule about what may be uploaded is AI+ Support work. The tooling, access control and data handling underneath it are ordinary managed IT support. And the part that does not automate — the certified architect who produces the costed, vendor-neutral HLD, the PMP or PRINCE2 project manager who runs the delivery, and the supply-chain team that turns a wish list into a real Bill of Materials with lead times — is our IT professional services practice. If you are drafting other project documents this way, our write-ups on UAT scripts and cutover runbooks for an ERP go-live and reviewing IT service contracts before signing apply the same "AI drafts, a professional owns it" pattern.

Frequently Asked Questions

Can this replace a certified architect's sign-off?

No, and the distinction is not a formality. What a client buys with a design is accountability: someone qualified has judged that the solution will work at that scale, in that building, with that budget, and their firm stands behind it at delivery. A model cannot hold that responsibility. What it replaces is the hours of transcription and formatting between the call and the architect's review.

What happens to the call recording and transcript after this?

Whatever your meeting platform and AI tool's retention settings say, which most firms have never looked at. Recordings sit in the meeting platform, transcripts get uploaded to a chat tool, and copies end up in someone's downloads folder. Decide deliberately: where recordings live, how long they are kept, which tools may receive them, and what happens at project close — particularly if the client contract addresses confidential information.

Does the BOM include real pricing?

It should not, and you should not ask it to. Pricing depends on volume agreements, regional availability, currency, import duties and lead times — commercial facts that live with a supply-chain team and change constantly. A model producing a plausible price is producing a fictional one, and the risk of a fictional number reaching a client is severe. Treat the output as a scoped equipment checklist that procurement then prices.

How is this different from asking ChatGPT to "write me a network design"?

Entirely different, and the difference is the source. Asking for a design invites it to generate a plausible generic architecture from general knowledge, disconnected from your client's building, constraints and budget. This workflow does the opposite: it is explicitly forbidden from adding anything not in the transcript and required to mark gaps as gaps. You are using it as a structuring tool over your own source material, not as a designer.

What if the transcript quality is poor?

Then the draft will be poor in ways that are hard to see, which is a good reason to fix the input. Use a decent meeting platform's transcription, record clearly, and get in the habit of restating numbers on the call — "so that's fifty access points across three floors" — which both confirms the requirement with the client and gives the transcript an unambiguous line. Verify every figure against the audio before it enters a document.

How long does this actually take?

Realistically an afternoon for the draft and question list, against roughly a day before. The larger gain is elapsed time rather than effort: the draft can exist the same day as the call rather than when the engineer next has a clear morning, which in a competitive situation is the whole point.