How do you turn discovery call notes into CRM fields without inventing any of them?

Write the extraction step so the assistant is allowed to return an empty field. That one rule separates a workflow that keeps your CRM honest from one that quietly fills it with plausible fiction. You give it the notes, a list of the fields someone actually acts on, and an instruction to quote the line that supports every value and flag anything the notes don't state. Then a person approves before the record changes. The hard part isn't the extraction. It's agreeing which fields deserve to exist.

TL;DR

• A CRM field is a record other people act on, so a confident wrong value spreads without anyone noticing it was ever a guess. Gate the extraction like an outbound action even though it never leaves your business.
• Extract only the fields somebody acts on. A field nobody acts on is a field nobody corrects.
• Every value carries the line from your notes that supports it, and a value with no line behind it stays blank with a question attached. At review you read the quote, not the value.
• Identity comes before extraction. The right summary written to the wrong opportunity is the expensive failure, not a clumsy sentence.
• Written notes keep you clear of the recording question entirely. If you do record, Queensland lets a party to the conversation record it but restricts what you may then do with the record, and New South Wales generally wants the other side's consent before a party records at all. Get advice for the states you sell into.
• The hours-saved figures in this category are published by the companies selling the tools. Measure your own time from call end to accepted CRM update instead.

Why is a wrong CRM field worse than a wrong AI draft?

Because nobody treats it as a draft. A drafted email sits in front of you asking to be sent. A field called budget_confirmed sits in a system where the next person to open the record reads it as settled fact and prices the job accordingly.

That's the same class of problem I described in where the approval line sits in an AI workflow: approve anything that leaves your business or changes a record, and leave the drafting step ungated because a draft waits for a human by design. A CRM field looks like the ungated kind of step and behaves like the gated kind. It never leaves the building, so it feels internal and safe, and then it reaches a colleague who has no idea which parts of the record came from a sentence your prospect actually said.

The distinction that fixes this is between what was observed and what was derived. An attendee list and a timestamp are observed. "Champion", "deal risk" and a predicted stage are derived 1. Both arrive in the same tidy paragraph, and a fluent summary is not evidence that every field in it is correct 1. So the rule I'd apply is simple: derived values never write themselves into a record. They get proposed, and a person who knows the deal accepts them.

Which fields should the workflow actually fill?

Only the ones that change somebody's next action. That test kills most field lists in about ten minutes, which is the point.

I use the same reasoning on my own work at Searchmaxxed. The search system we built there connects the evidence about a site into one process that recommends what to do next, and the value sits in the recommendation changing the work rather than in producing more summary. Apply that to a discovery call and the question stops being "what could the assistant extract" and becomes "which four or five values would change what happens tomorrow morning".

Then set the write mode per field rather than per workflow, because the risk is not evenly spread. Read-only insight suits incomplete evidence or high consequences, draft-for-approval suits output that needs contextual judgement, and automatic writes suit deterministic, reversible, monitored inputs 2.

A consultant's intake call and a builder's site visit produce different rows in that table, which is why AI training for consultants starts from the intake conversation rather than a generic sales stage.

How do you write the five inputs for a notes-to-CRM job?

You write them as plain instructions about your own business, before you paste a single note. The five inputs are Context, Task, Source, Rules and Output, and each one closes a decision the assistant would otherwise make for you. If you haven't built one before, start with how to write a five-input AI prompt and come back to this field list.

For a discovery call the five read roughly like this.

• Context. We're a service business on the Sunshine Coast. I've just run a discovery call with a prospect. Our CRM holds companies, contacts and opportunities.
• Task. Turn the supplied notes into entries for the six CRM fields in our field list, plus follow-up tasks with an owner and a date.
• Source. The notes from this call, our field list with the business meaning of each field, and our qualification questions. Nothing else.
• Rules. Use only the supplied notes. Quote the line from the notes that supports each value. If the notes don't state a value, return the field as NOT STATED and add a question for me. Never convert an implication into a figure or a date. Don't name a decision maker who wasn't named. Stop at the draft.
• Output. One row per field with the value, the supporting quote and a confidence note. Then a task list with owners and dates. Then a short list of questions for me.

Those instructions are the asset. The notes change after every call; the five inputs don't. It's the same shape as turning internal meeting notes into actions, with one difference that matters: an action list is read by the person who wrote it, and a CRM field is read by someone who wasn't in the room.

A blank field beats a confident guess

This is the part most people edit out, and it's the part doing the work. Tell the assistant that abstaining is a legitimate answer. In a governed design the safest output can be abstention 3, and the record should carry confidence or abstention alongside the value itself 1.

The mechanism is the supporting quote. When the model has to produce the line from your notes next to each value, three things happen. Values with no line behind them show up as blanks instead of guesses. Your review becomes a comparison rather than a judgement call. And you get a running record of which fields your notes never capture, which usually tells you more about your discovery questions than about the model.

Be honest about the limit, though. A quote can be real and the extracted value still wrong, because the inference from the line to the field is where the error lives. "We'd need sign off from the board" supports a field about decision process. It does not support a named economic buyer. So the reviewer reads the quote first and the value second, not the other way around.

Can you record the call, or should you stay on written notes?

Written notes avoid the question completely, and the workflow above runs identically on a page of handwritten shorthand. If you want a recording or a transcript, the law is a state-by-state matter in Australia and it applies twice: once to making the recording, and again to what you do with it afterwards.

In Queensland, using a listening device to record a private conversation is an offence, and the prohibition does not apply where the person using the device is a party to the conversation 4. That's the part people remember. The part they miss is the next section: a party who recorded the conversation and then communicates or publishes to any other person a record of it, or any statement prepared from such a record, commits a separate offence unless an exception applies, and those exceptions include the consent of all other parties and communication to a person with such an interest in the conversation as to make it reasonable in the circumstances 5.

Read that against what a notes-to-CRM workflow does. An AI summary of a recorded call is a statement prepared from the record, and pushing it into a shared CRM communicates it to other people. Whether an exception covers your situation is a question for your own legal adviser, not a setting inside a tool.

Cross the border and the first step changes too. In New South Wales a person must not knowingly use a listening device to record a private conversation to which they are a party, with a maximum penalty of 500 penalty units for a corporation 6. The exception for a party requires either the express or implied consent of all principal parties, or the consent of one principal party where the recording is reasonably necessary to protect that party's lawful interests, or where it is not made for the purpose of communicating or publishing the conversation to people who aren't parties to it 7. A recording made specifically so its contents can reach your team and your CRM is made for close to exactly that purpose, so plan on asking.

Practically, that leaves you three defensible options. Stay on written notes. Ask at the top of the call, get a yes, and note that you asked. Or take advice covering every state you sell into before you switch a recorder on. The tools will help you with the asking and not with the deciding: one vendor posts a consent message in the meeting chat when transcription starts, shows a watermark while it runs, and deletes the audio after transcribing 8, and bot-based products can be configured to announce their presence when they join a call 9. Those are disclosure features, not legal opinions. Nothing here is legal advice, and the penalties above are the reason to get some.

How do you check the extraction before it touches a record?

You check it against the notes you supplied, field by field, reading the quote before the value. Compare names, dates and figures with the source. Recalculate anything you'd act on financially. Confirm that a NOT STATED is genuinely absent from the notes rather than phrased differently, because a false blank costs you a real fact. The same review habit I described in how to check AI output applies here, with the addition that the record is shared.

Two things make the check hold up beyond the first week. Have two people independently label what the correct fields should be for the same set of calls, and reconcile where they disagree before you trust anyone's judgement of the model 10. And keep the before and after values, the source, the time the evidence was observed and who reviewed it, so a wrong field can be traced instead of argued about 1.

When the draft asserts something your notes don't support, say so specifically. Point at the field, supply the missing fact or send it back as a question, and check the next draft for the same failure. A rule that gets added and never verified is decoration.

What changes when you connect it to the CRM automatically?

Identity becomes the first problem and extraction becomes the second. Before anything is extracted, the workflow has to resolve the contact, account, opportunity and owner, and it has to survive aliases, shared email domains, duplicate people, former employees, merged records, several open deals and no valid match at all. A correct note written to the wrong opportunity is a critical failure 3, and it's a worse one than a slightly awkward sentence, because nobody goes looking for it.

So when you extend the workflow, extend it in this order: resolve identity, write to a shadow field or a sandbox, reconcile what actually landed, then let one field at a time carry real write authority 10. Human-in-the-loop is the sensible default for anything consequential, with sensitive actions staying reviewable by the right people 11.

There's also a second payoff most people don't plan for. The structured output from the call is the source material for whatever comes next, which in our own business is the proposal. We built AI workflows at Searchmaxxed for blog creation, SEO and custom proposals, and the proposal workflow is only as good as the record of what the client asked for, which is why I'd treat the notes-to-CRM step as the input to AI workflows for custom sales proposals rather than as a tidy-up job.

One thing I'd separate clearly. Giving an assistant your business context and a defined work product is not the same as giving it authority to act. It can retrieve, prepare and revise without holding permission to publish or transact, and that split is what makes the whole thing safe to run. If you'd rather the system was built and connected for you than learn to build it, that's implementation, a separate engagement with its own scope and price, and we scope it after a conversation about your CRM and your fields.

The hours-saved figures come from the companies selling the tools

This is the honest version of the business case. One vendor states that sales reps lose 8 to 12 hours weekly to manual note cleanup and CRM entry, leaving 35% of their time for selling 12. Another says reps can lose up to 10 hours a week on manual CRM updates 13. Both figures appear on the websites of companies selling the software that removes the work, and neither is a measurement of your team.

Measure your own, because the numbers are cheap to collect and they survive a conversation with your accountant. Before you change anything, record the median time from call end to the CRM being updated, the proportion of your required fields that are populated, and the minutes a person spends reviewing each accepted update. Afterwards, track field precision as supported correct values divided by all values written, review burden as review and correction minutes divided by accepted updates, and freshness as the event-to-accepted-CRM delay at both the median and the tail 14.

Report them per field rather than as one average, because averaging is how a workflow that's right 95% of the time and catastrophically wrong on budget gets signed off. And keep counting the review minutes. A workflow that saves an hour of typing and costs forty minutes of checking is still a gain, just not the one on the landing page.

Where can you build this with hands-on help?

You bring the task and we build it with you. Our public Sunshine Coast workshop gives you a full day putting AI to work across your business, and a notes-to-CRM workflow fits that format well because you can build and test the extraction step without connecting a single system. You work on your own laptop, on your own notes, and you keep the instructions and the example you tested.

The public Sunshine Coast workshop page carries the date once it's set. If a whole sales team needs to agree on one field list and one review step, private onsite AI training at your workplace is the better shape: we scope your tasks, team size and location first, then send a fixed quote, and sessions are usually built for roughly 4 to 20 people at the team's own workplace. The same enquiry starts the implementation conversation if you decide you'd rather have it built than learn to build it.

Frequently asked questions