Onboard New Clients from WhatsApp Conversations

A new client just sent you 14 voice messages, 23 text messages, 6 images, and a "so basically that's what I need, let me know!"

You now have to turn this chaos into a project brief. And you know that anything you miss now will come back as a "but I told you about this" later.

This is the freelancer onboarding problem. Clients do not write briefs. They talk. They send scattered thoughts across multiple messages over multiple days. They contradict themselves between Tuesday's voice message and Thursday's text. They assume you caught everything.

The first week of any freelance project is really just a translation exercise: turning unstructured WhatsApp conversations into structured requirements.

Why onboarding from WhatsApp goes wrong

The medium creates the problem:

• Voice messages are unstructured. A client will bury a critical requirement in minute 2 of a 4-minute voice message, surrounded by unrelated context.
• Messages arrive out of order. The client thinks of things across days and sends them as they come. Monday's requirements might contradict Friday's.
• Confirmation is ambiguous. A thumbs-up emoji on a message could mean "I read it," "I agree," or "I will think about it."
• Important details hide in casual language. "Oh and the logo should probably be blue" is a design requirement disguised as an afterthought.
• Nothing is prioritized. Everything arrives at the same level of urgency.

The result is that you start work with an incomplete understanding, and the gaps show up later as rework, delays, and arguments about what was agreed.

Why voice messages deserve special attention

Voice messages deserve extra scrutiny because they are the format where clients are least guarded. When a client types a message, they tend to keep it brief and intentional. When they record a voice message, they think out loud. That thinking-out-loud quality is exactly what makes voice messages valuable and also exactly what makes them dangerous to process manually.

WhatsApp stores voice messages in .opus format, a compressed audio codec that is not natively readable by any project management tool or text editor. When you export a WhatsApp chat with media included, the resulting .zip file contains a _chat.txt transcript of all text messages alongside every media attachment, including those .opus voice message files. Without a transcription step, those files are effectively invisible to any analysis you try to run. ThreadRecap transcribes .opus voice messages using OpenAI's transcription models, with accuracy that varies by recording quality, accent and language. On a clear recording it reliably surfaces requirements, deadlines, and references that would otherwise require repeated manual listening.

The cost of a missed requirement

A critical client requirement buried mid-way through a long voice message is not a hypothetical edge case. It is the norm. Clients frequently open a voice message with scene-setting ("so I was thinking about the project…"), reach the substantive requirement at the midpoint, and then close with reassurances ("anyway, I trust you to figure it out"). If you listen once at normal speed without taking structured notes, the midpoint detail is the most likely to be lost. Text transcription converts a temporal, unsearchable recording into a document you can read, search, and reference during brief compilation.

What a good client brief looks like

A brief extracted from WhatsApp onboarding conversations should capture:

• Project goal - What the client actually wants, distilled from all the noise
• Specific requirements - Extracted from voice messages, text messages, and shared references
• References and examples - Images, links, screenshots they shared, with context
• Timeline expectations - Any dates or deadlines mentioned, explicit or implied
• Budget and payment terms - If discussed (scope, price, payment schedule)
• Open questions - Contradictions, gaps, or ambiguities that need clarification before you start

The brief does not need to be long. One page is usually enough. What matters is that it is structured and confirmable.

Separating confirmed requirements from casual mentions

One of the most consequential distinctions in any client brief is the line between a confirmed requirement and a casual mention. Treating casually mentioned features as confirmed requirements is a leading cause of unpaid scope creep in freelance projects. A client who says "maybe we could also add a newsletter signup" is not commissioning a newsletter integration. They are thinking out loud. If you build it and invoice for it, the conversation becomes difficult fast.

The brief template below uses a "must have" versus "nice to have" split for exactly this reason. Anything phrased with hedging language ("maybe," "could be nice," "at some point," "not urgent but") belongs in nice-to-have until the client explicitly confirms it. This is not about being ungenerous; it is about making the scope boundary legible to both parties before work begins.

A complete onboarding brief should ultimately cover: project goal, must-have requirements, nice-to-have items, shared references, timeline, budget terms, and open questions. Each of those seven categories maps to a potential source of downstream conflict if left undocumented.

Extracting a brief from WhatsApp

The manual way

Read through all messages and voice messages. Take notes on requirements, deadlines, and references. Try to organize them into categories. Follow up on anything unclear.

This works but is slow and error-prone. Voice messages are especially difficult because you cannot search them or skim them.

The faster way

1. Export the WhatsApp conversation as a .zip file. Include media so that voice messages with requirements get transcribed.
2. Upload to ThreadRecap and run the analysis to get the big picture of the conversation.
3. Ask targeted questions in the chat that opens with the recap to extract specific categories:

• "List all requirements the client mentioned, grouped by topic"
• "What deadlines or timeline expectations were discussed?"
• "Are there any contradictions in what the client requested?"
• "What questions need to be answered before starting work?"

1. Compile the results into a one-page brief using the template below.
2. Send it back to the client for confirmation.

Working from the recap

The analysis produces a structured overview of the whole conversation: key topics, decisions, action items, and tone. This is the right starting point for any onboarding thread because it gives you a map before you go looking for specifics. From there, the chat attached to the recap lets you ask targeted questions against the full transcript, including any transcribed voice message content. For onboarding, you will typically do both: read the overview first to orient yourself, then ask one or more questions to extract the specific categories your brief needs.

Client brief template

Project brief header

• Client: [Name]
• Project: [Name or description]
• Brief date: [Today]
• Based on: WhatsApp conversation [Date range]
• Status: Draft - awaiting client confirmation

Project goal

[2-3 sentences describing what the client wants to achieve, in plain language]

Requirements

Must have:

• [Requirement 1]
• [Requirement 2]
• [Requirement 3]

Nice to have (mentioned but not confirmed):

• [Requirement 4]
• [Requirement 5]

References shared

• [Description of image/link/screenshot 1 and what it relates to]
• [Description of image/link/screenshot 2 and what it relates to]

Timeline

• [Deadline or milestone 1]
• [Deadline or milestone 2]
• [Overall expected completion]

Budget and payment

• [Agreed price or price range]
• [Payment schedule if discussed]
• [Any conditions]

Open questions

• [Question 1 - needs answer before starting]
• [Question 2 - contradicts something else the client said]
• [Question 3 - not mentioned but important for the project]

Using the template with ThreadRecap output

When you receive a Full Summary from ThreadRecap, the output will typically group content into themes and flag contradictions where they exist. Copy the requirements section of the summary directly into your must-have list, then review it against the raw transcript for any casual mentions that did not make the summary but do appear in the Custom Prompt output. The open questions section of the brief is a good place to document anything where the summary noted conflicting statements. Contradictions across a long WhatsApp thread are common because clients genuinely change their minds between messages, and surfacing those contradictions before you start is more useful than discovering them mid-project.

The confirmation trick

This is the most valuable step in the entire process. When you send a structured brief back to the client and they say "yes, that is right," you now have documented agreement on scope.

Send it like this:

"Hi [Name], I put together a brief based on our conversations. Please review and confirm before I start:

[Paste brief]

If anything is missing or incorrect, let me know and I will update. Once you confirm, I will use this as the project scope."

This does three things:

1. Catches misunderstandings early - before you start working on the wrong thing
2. Creates a scope anchor - if they change their mind later, you have a reference point
3. Signals professionalism - clients trust freelancers who clarify before executing

If the client adds requirements after confirming the brief, you can reference it: "This was not in the confirmed brief. Happy to add it. Here is the impact on timeline and cost." That is scope management, and it starts at onboarding.

Why written confirmation matters more than verbal agreement

A WhatsApp voice message saying "yeah that all sounds right" is not a confirmed brief. It is an informal acknowledgment. The distinction matters when, three weeks into a project, the client insists that a feature you did not build was always part of the plan. A confirmed written brief creates a scope anchor: any requirements added after confirmation can be formally assessed for their timeline and cost impact. That anchor does not need to be a signed contract. A client replying "confirmed, looks good" to a WhatsApp message containing the brief is sufficient for most freelance relationships. The key is that the brief exists as a discrete, reviewable document rather than being dispersed across a thread of casual messages.

Common onboarding pitfalls

Starting work before confirming the brief. The excitement to begin is real, but unconfirmed scope is the number one cause of freelancer frustration.

Ignoring voice messages. Clients who send voice messages often put their most important thoughts there because it is easier to talk than type. If you skip them, you miss context.

Not asking about budget early. If the client's budget does not match the scope they described, you need to know before you invest time in planning.

Treating "nice to have" as confirmed. If the client mentioned something casually ("maybe we could also add..."), flag it as unconfirmed. Do not include it in your estimate or timeline.

Exporting without media. WhatsApp gives you the option to export a chat with or without media. Exporting without media produces only the _chat.txt transcript, which omits all voice message content. If your client used voice messages for any substantive part of the conversation, an export without media will produce an incomplete transcript. Always export with media included when voice messages are present.

Related workflows

• After onboarding, send client summaries after every call to keep documentation going
• If the client discussed negotiation terms or pricing, extract those separately
• Use a scope change log to track any additions after the confirmed brief

Your next client conversation is your project brief