You build a four stage pipeline. Capture the audio, transcribe it, extract structured fields with a language model, then write those fields into the CRM through its API. Each stage is boring on its own. The value comes from removing the twenty minutes a person spends retyping after every call.
We get asked for this constantly, usually by a founder who is doing all the sales themselves and losing the details. It is one of the few AI automations where the payoff is obvious and the failure mode is mild. A bad summary wastes a minute. It does not email a customer.
This walkthrough covers the real constraints at each stage, including the file size limits and per record rules that catch teams out. Where a number is quoted, it comes from the vendor's own documentation.
Because the cost hides in small pieces. A twenty minute write up after a forty minute call is a fifty percent overhead on the call itself. Do six calls a day and you have spent two hours transcribing your own memory instead of selling.
The worse cost is the calls nobody writes up at all. Those become the deals where a follow up promise is missed, or where the next person to speak to the client asks a question that was already answered. Both are trust problems, not admin problems.
What we see in practice is that teams do not skip notes because they are lazy. They skip them because the CRM form has eleven fields and the call is over and the next one starts in four minutes. Automating the pipeline removes the choice.
Capture, transcribe, extract, write. Capture gets an audio file out of the meeting platform. Transcribe turns audio into text. Extract turns unstructured text into named fields. Write puts those fields into the CRM against the right record.
Keeping them separate matters more than it sounds. If you buy one tool that does all four, you cannot swap the weak stage without replacing everything. We have had to unpick a few of those, and it is always the extraction stage that turns out to be the weak one.
Each stage should also be able to fail independently and retry. A transcription that times out should not lose the recording, and a CRM write that hits a permissions error should not lose the transcript. That is normal integration hygiene, covered in our piece on API integrations.
Either a meeting bot joins the call or the platform records natively. Zoom, Google Meet and Microsoft Teams all support cloud recording, and tools such as Fireflies and Otter join as a participant. Native recording is usually cleaner because there is no extra attendee for the client to react to.
Consent is not optional here and it varies by jurisdiction. Some places require every party to agree, others only one. The safe default we recommend is to announce the recording at the top of the call and to log that you did. It costs eight seconds and removes an entire category of risk.
Whichever route you pick, get the file out into your own storage. If the recording only ever lives inside a vendor's product, your automation depends on that vendor's export path staying free and staying available.
The main limit is file size, not length. OpenAI's speech to text documentation states plainly that files can be up to 25 MB, and lists the supported input formats as mp3, mp4, mpeg, mpga, m4a, wav and webm. A long call in a lossless format will blow through that.
The fix is to compress before you upload rather than after you fail. A mono mp3 at a modest bitrate is fine for speech and will fit an hour of conversation comfortably. If a recording is still too large, split it into chunks and stitch the transcripts.
Model choice matters for what you get back. The same documentation names gpt-transcribe as the general recommendation, gpt-4o-transcribe-diarize for speaker identification, and whisper-1 for timestamps, subtitles or translation. If you need to know who said what, pick the diarization model up front. For audio beyond thirty seconds it tells you to set chunking_strategy to auto or a voice activity detection configuration.
You ask for a schema, not a summary. The prompt should name every field you want, say what type it is, and say what to return when the call did not cover it. Null is a valid answer and you want the model to use it rather than guess.
The fields we would start with are next step, next step owner, next step date, budget mentioned, timeline mentioned, blockers, competitors named, and a three sentence summary. That is enough to be useful and short enough to check quickly.
The rule that saves you is to require evidence. Ask the model to return, alongside each extracted value, the sentence from the transcript it came from. It makes review fast, it makes bad extractions obvious, and it discourages the model from inventing a budget number nobody said.
It is a normal API call with unglamorous limits. HubSpot's engagements endpoint accepts a POST to /engagements/v1/engagements and supports five types: EMAIL, CALL, MEETING, TASK and NOTE. For note type engagements, the documentation states the body of the note is limited to 65536 characters.
One detail catches people out. HubSpot's documentation notes that tasks created through the API will not trigger user notifications. So if your automation creates a follow up task and nobody is watching the task list, the follow up quietly does not happen. Post to Slack as well, or accept that the task is a record rather than a reminder.
Association is the other thing to get right. A note attached to nothing is worse than no note, because it looks like the work was done. Resolve the contact and the deal before you write, and fail loudly when you cannot.
Any of the usual three, and the choice is mostly about cost shape. n8n's own pricing lists Starter at 20 euros a month billed annually with 2.5K workflow executions, Pro at 50 euros with 10K executions, and Business at 667 euros with 40K executions. Enterprise is a custom execution count.
Those numbers matter because a call pipeline is not a high volume workflow. Six calls a day is under two hundred executions a month, which sits inside the smallest plan with room to spare. This is not the automation that blows a budget.
n8n also publishes a self hosted community edition on GitHub, which is the route we take when a client wants the transcripts to stay on their own infrastructure. Our comparison of Zapier, Make and the alternatives goes into where each one fits.
It breaks on the boring edges. Two people with the same first name in the CRM. A prospect who joins from a personal email so the contact lookup fails. A call that was mostly small talk, where the model manufactures a next step because the schema asked for one.
The most common failure we see is silent success. The pipeline runs, writes something plausible, and nobody notices it was wrong until a deal review. That is why the evidence sentence matters, and why the first month should include a human reading every output.
Rate limits are the other one. If you backfill six months of recordings in one afternoon, you will hit the CRM's limits and lose records unless you queue and retry. Build the retry before the backfill, not after it.
Anything that leaves your company. Do not let this pipeline send the follow up email, update a deal stage, or change a forecast number. The output is a draft and a record. A person decides what happens next.
We hold this line on every automation we build, and it is not caution for its own sake. The value of the automation is that it removes typing. The risk of the automation is that it removes judgement. You want the first without the second.
The same principle drives how we set up scoring and routing, which we cover in our piece on AI lead qualification. Let the system prepare the decision. Keep the decision.
Start with one call type and one field. Take discovery calls only, extract only the next step and its date, and write it as a note. Run it for two weeks and read every output. That is a small enough surface that you will actually find the failures.
Once that is trustworthy, add fields one at a time. Every new field is a new way to be confidently wrong, so it earns its place by surviving the same two week review. Most teams stop at six or seven fields, which is usually the right number.
If you want a second opinion on the pipeline before you build it, or you would like us to put one together alongside your site work, we are happy to help. You can reach our team at phoenix.studio and we will be straight with you about which parts are worth automating and which are not.
Tell us where you want to go. We'll tell you how we'd get you there.