How to Turn Client Discovery Calls Into Searchable Project Notes in 2026

A client explained the approval process during discovery. Two weeks later, you need the exception they mentioned. You have the recording, but the answer is buried inside it.

OGAD (Off Grid AI Desktop) can turn a saved call recording into text, help you draft requirements, and let you query the checked notes in a project. Use local speech and chat models to process the material on your computer after setup. This workflow uses the free core app.

Download OGAD | Desktop releases

What would you like to do with Off Grid AI?

Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.

Write to [e-mail], join our Slack community, or talk to us on Reddit.

For a small CRM implementation firm, this means the person configuring the system can find the original requirement without asking the client to explain it again. The same method works for a consultant preparing a process map or a developer writing an implementation brief.

What should you keep from a discovery call?

Keep the client's current process, desired change, exceptions, and open questions separate. A call contains suggestions as well as decisions. Searchable notes are useful when those distinctions survive the summary.

Suppose a client describes how new leads reach its sales team. Most leads go to the next available representative. Existing customer enquiries go to the account owner. International enquiries need a manager's review.

A summary such as “Distribute leads automatically” loses the details that determine the configuration. A useful brief would contain:

Part of the brief	What to capture
Current process	Who receives the enquiry today
Agreed requirement	The assignment rule the client approved
Exception	What happens for an existing customer
Open question	Who handles enquiries when the account owner is absent
Next action	Who will supply the current account-owner list

Your source material determines what belongs in each row.

What do you need to start?

You need OGAD, the recording saved as an audio file, a local transcription model, and a local text model. Download the app and required model files while connected. Project search also needs its local indexing model ready before you work offline.

The model-setting steps below use an Apple Silicon Mac. The core saved-audio and project features are also available on Windows; speech runtime setup can differ by platform. Linux packages are available in 0.0.54-beta.108; that is a beta release. These steps do not depend on Pro meeting capture.

Use a recording that you are permitted to process. If you already have a checked transcript, start with that text and skip speech recognition.

Keep each client's material in a separate project. This makes the source selection clearer when you move between engagements. It is an organisation method, not a claim that projects provide a multi-user access-control system.

How do you turn the audio into working notes?

Start with one call. Transcribe the saved audio, check important passages, and ask the local chat model for a structured brief. Keep the transcript as evidence alongside the shorter notes.

1. In Models, download a transcription model and a text model that fit your computer. Select local models for both tasks.
2. In model settings, open Transcription. Set Current model and Spoken language. Use a multilingual model if the call is not in English.
3. In chat, open the + menu and choose Attach files. Select the audio. Formats include MP3, WAV, M4A, and FLAC.
4. Wait for processing, then open the attachment's text preview. Check names, numbers, exceptions, and statements containing “not.”
5. Copy the text into a local editor if it needs corrections. Save the checked transcript as a clearly named .txt or .md file. Attach that version to a new request.

If the recording is a video, export an audio file first. The ordinary video attachment route reads sampled visual frames; it does not transcribe the full soundtrack. The audio extraction implementation shows these separate paths.

Try this request with the checked transcript:

Create a discovery brief from this transcript. Use headings for current process, agreed requirements, exceptions, open questions, and next actions. Keep suggestions separate from approved decisions. Include a short supporting quote for each requirement. Use “Unclear” where the transcript does not establish an owner or decision. Do not invent dates or commitments.

Review the brief against the source. A polished answer can still turn a tentative idea into an apparent agreement.

How do you make the notes searchable across a project?

Open Projects > New project, enter the engagement name, and press Enter. Open Knowledge & settings > Knowledge base > Add files to add the checked transcript and brief. Wait until indexing finishes and leave their retrieval switches enabled. Then open Chats > New chat inside the project.

The project controls accept documents and show indexing progress. Project retrieval supplies relevant passages rather than requiring you to paste every call into each question.

Use filenames that show the source and date:

• 2026-09-09-discovery-checked-transcript.txt
• 2026-09-09-discovery-brief.md
• 2026-09-16-client-approved-requirements.md

Now ask a narrow question:

Search this project's documents. What did the client say should happen to an existing customer's enquiry? Give the source and separate the original proposal from any later approval.

Open the returned source before changing the configuration. A retrieved passage helps you check an answer; it does not establish that the answer covered every document.

How should you handle changing requirements?

Keep dated decisions and make their status explicit. If the client changes an assignment rule, add the new approved note and identify which earlier decision it replaces. Ask the model to show conflicts instead of silently choosing a version.

A useful request is:

Compare the discovery brief with the approved requirements. List differences that affect lead assignment. For each difference, name both source files. Mark anything that needs client confirmation.

Review the proposed differences, then update your own project brief. The model can help you find the issue; you still decide what becomes an implementation task.

If an older document should no longer influence answers, disable it in the project's document list. Keep the original in your own records when needed.

What should you check when an answer is weak?

Symptom	Useful next step
A requirement is missing	Search with the client's original wording and check the transcript
Two clients appear mixed together	Check the active project and its included files
The answer cites an old decision	Check document dates and disable superseded material where appropriate
A long call produces incomplete notes	Divide the transcript by topic and review each section
Offline processing fails	Check that speech, chat, and indexing setup completed before disconnecting

A full transcript can exceed a model's usable context. For a long workshop, create separate checked notes for lead intake, qualification, handover, and reporting. Add those to the same project rather than asking one prompt to preserve every detail.

Start with the next requirement you need to confirm

Download OGAD, add one checked discovery transcript, and ask one question you can verify. The first useful result is a requirement you can trace back to the client's words.

Local processing applies when you select local models. Remote model connections and sharing documents through other services have separate network and data handling requirements.