DocConduit Case Studies Client Interview Pipeline
From discovery call to spec doc, in the time it takes to make coffee.
A 45-minute client interview is a goldmine of context — buried in 45 minutes of conversation. Turning it into a usable spec used to be an afternoon of listening back and writing. Now it's one webhook call: audio in, six versioned documents out, committed to GitHub before the kettle boils.
The shape of the problem.
Every project starts with a conversation. The hard part isn't the call — it's everything that happens after.
A discovery call is dense with the things that actually matter: what the prospect is trying to accomplish, the workflow that's eating their team, the constraints you'd never guess from a brief, and the offhand comment in minute 32 that turns out to be the whole project. None of it is structured. All of it has to be turned into something usable — an executive summary for you, a requirements list for whoever's building, a clean brief for the client to confirm you heard them right.
The traditional way: re-listen to the recording, scrub for the good bits, take notes, write four or five separate documents in different voices for different audiences, version-control nothing, and hope nobody asks a month later "what did we say we were building?"
The cost isn't the writing. The cost is the two to four hours of focused desk time per discovery call — time that doesn't exist on a busy week.
The pipeline, end-to-end.
One webhook. Audio in, GitHub commit out. Six purpose-built LLM prompts in between — four of them running in parallel.
The shape matters. Intake and clean happen once. Extract fans out — four short, single-purpose prompts run in parallel, which costs the same as one big prompt but takes a quarter of the wall time. Compose fans back in, weaving the four extractions into the two final deliverables. Store commits everything to a per-client GitHub folder so you can `git log` your way back through every revision.
What each node is actually doing.
Seven nodes do the work. Each one is intentionally small — a focused prompt or a single API call — so the failure modes stay legible.
-
Audio upload → metadata fix
The webhook accepts a binary upload of any common audio format. A tiny Code node patches the binary metadata so Groq's API doesn't reject it — the kind of "30 minutes of debugging" detail that lives forever in a workflow once you find it.
webhookcode -
Groq Whisper transcribe
Speech-to-text via Groq's hosted Whisper endpoint. The choice matters: Groq's inference is fast and cheap enough that a full 45-minute call costs pennies, not dollars. The output is a single transcript string with rough timestamps.
groqwhisper -
Prompt 0 — Cleanup + extract client name
Raw transcripts are messy. Filler words, repeated sentences, half-finished thoughts. This prompt strips the noise and pulls the client's name out of the conversation so downstream documents can title themselves correctly. Doing it once here makes every later prompt cheaper and sharper.
groqcleanup -
Prompts 1–4 — The extraction fan-out
Four small prompts running in parallel, each with one job:
1. Executive Summary. One paragraph. What is this person trying to accomplish, in language you'd use with another founder.
2. JTBD + Pain Points. Jobs-to-be-Done framing with the concrete pains underneath each job — the raw material for your value prop.
3. Requirements. A functional list. What must the thing do.
4. User Stories. "As an X, I want Y so that Z." Developer-ready.
Each prompt is short and single-purpose, which produces higher-quality output than asking one giant prompt to do everything — and running them in parallel cuts the wall time roughly 4×.
groq × 4parallel -
Prompt 5 — Blueprint / Web App Spec
The first composition step. Reads all four extractions and writes the single design document you'd hand to an engineer. This is the artifact that would normally cost a half-day to write — and the one most likely to get out of date if it isn't version-controlled.
groqcompose -
Prompt 6 — Client Brief
Same content as the spec, rewritten in client-friendly language. Now you have two documents from the same source: one for engineering, one to send back to the prospect to confirm you heard them right.
groqtranslate -
Commit all to GitHub
A Code node packages the transcript and every generated document into a per-client folder and commits them to GitHub. Six months from now, when a client says "I thought we were building X," you can pull the original brief and the spec that came from it. Version control as a feature, not an afterthought.
githubarchive
What it actually saves.
The numbers below are for a typical 45-minute discovery call. Your mileage varies with audio quality and how much detail you want in the brief — but the order of magnitude doesn't.
Why we built it for ourselves first.
Two reasons. First — we eat our own cooking. If we're going to tell a law firm or a removals company that document automation will give them their week back, we'd better be using it on our own week. Second — discovery is the most leveraged document in the whole client relationship. If the spec is wrong, everything downstream is wrong. Versioning it, committing it to GitHub, and being able to point at exactly what the client confirmed in week one is worth more than the hours saved.
Same archetype, different domain: a Wyoming law firm runs 150-page PDFs through six scenarios and gets back signed, summarized, delivered. We run audio through a similar fan-out and get back a versioned spec docset. Unstructured input → structured artifacts → system of record. The pattern travels.
What's the document loop eating your week?
Tell us about the one your team keeps getting stuck in. We'll tell you — within 24 hours — whether automation is the right fix, or whether the process itself needs fixing first.
Book a 15-min workflow audit