A step-by-step guide to turning an ordinary recorded sales call into a structured lead record: who the customer is, what they want, and what to do next — with the real legal, technical and AI-accuracy questions answered at each step, in plain language.
This page is for one situation: your salespeople talk to customers on ordinary phone calls — not a company call centre, just a person selling a loan, a card or a policy from their own phone — and right now, what they learn on that call lives only in their head, or in a WhatsApp message to themselves, or nowhere at all.
How to read it. Each of the six steps opens with a short story in plain words, written so that someone who has never touched a computer program can read it and understand what is happening and why. Read the six stories top to bottom and you will understand the whole product in about ten minutes.
Underneath each story are the technical details, and below those, the ways of doing it folded away behind a +. Open one only when you are actually building that step.
Everything on this page is written so that a plain-language explanation of the logic is also, as it happens, the easiest thing for another AI system to read correctly — the same clarity that helps a non-technical person helps a machine parsing this page later.
This guide leans on a page already built for a related product. Guide 21 covers turning any recorded call into searchable text — ingest, transcribe, separate speakers, flag sensitive numbers. Step 2 below reuses that work rather than repeating it, and flags the one place a phone-recorded sales call behaves differently from a call-centre recording.
A phone call happened. Somewhere on a phone, a recording of it exists. You want six things out of that one fact, none of which the recording gives you by itself:
Six steps. Each one produces something the next one needs.
Read this table once and the rest of the page is detail.
| # | Step | In plain words |
|---|---|---|
| 1 | Get the recording off the phone | Move the audio file from the salesperson’s device to somewhere your business actually controls, and tell the customer they are being recorded. |
| 2 | Turn it into words, and know who’s who | Reuse Guide 21’s pipeline — with one important difference this page flags. |
| 3 | Ask the AI to pull out the lead details | Turn a paragraph of conversation into a short, structured form: name, phone, interest, next action. |
| 4 | Save it without making a duplicate customer | Make sure "9876543210" and "+91 98765 43210" are recognised as the same person. |
| 5 | Decide what happens next | Turn the AI’s summary into one dated action, and know which "speed matters" claims are real. |
| 6 | Let the manager see what’s been forgotten | A simple view of every promise that is now overdue, and a nudge sent before the customer notices. |
This is a general sales-operations pattern, not something unique to fintech. It applies wherever a person sells by phone. It sits in the fintech section of this site because that is where it was asked for, and because the legal box in Step 1 is written specifically for an Indian regulated business. The engineering in Steps 2–6 is the same for any industry.
Ramesh sells personal loans over the phone. He uses his own Android phone, and somewhere in its settings, call recording is switched on. After every call, a small audio file sits in an app on his phone. Nobody else in the company has ever seen it.
That file is the entire raw material for everything on this page. If it never leaves his phone, nothing downstream can happen — and if his phone is lost, sold, or simply full and quietly overwriting old files, that customer’s conversation is gone forever.
Why "OEM recorder" specifically, and not just any recording app? In 2022 Google changed the rules for its Play Store so that most third-party call-recording apps — including well-known ones like Truecaller’s — had to remove the feature, because it relied on an accessibility permission Google said was being misused for remote call recording [3]. What survived is the recorder that comes built into the phone by the manufacturer — Samsung’s, Google’s own Pixel Recorder, Xiaomi’s — because that one is part of the phone’s own operating system, not a Play Store app. That is what "OEM recording" means: whatever call recorder the phone’s maker put on it.
And every phone maker behaves differently about what happens to that file next, which is the actual engineering problem in this step.
Google’s own Recorder app, on the “Save & share recordings & transcripts” support page, describes saving a recording and its transcript to the person’s Google Drive, and a separate account-level backup setting for the app’s library [1].
What this means for you: on a company-issued Pixel phone signed into a company Google account, this is the least engineering of any option here. Read the setting carefully before relying on it — confirm whether the backup toggle you turn on actually syncs every new recording automatically, or whether someone still has to open the app and tap "save to Drive" per recording, and test it with one real call before rolling it out.
The catch: it is a personal Google account feature. If salespeople use their own personal phones and their own personal Google accounts, the recordings sync — to their Drive, not yours. You still need a company-controlled account.
Samsung’s own page on backing up a Galaxy device lists “Voice recorder: recordings” among the data types Samsung Cloud backs up — and does not mention Google Drive anywhere [2]. So the built-in path, if there is one, goes to Samsung’s own cloud, not to a folder your business can read. Other manufacturers each have their own recorder with their own save location and their own cloud, if any.
What this means for you: on most non-Pixel Android phones, nobody is quietly doing the upload for you. You need one extra piece: a small always-on app on the phone that watches the recordings folder and pushes new files to your own cloud storage the moment a call ends. Several file-sync apps on the Play Store do exactly this for a generic folder — check that whichever one you pick can watch the specific folder your phone’s recorder actually writes to, because that folder name is not standard across brands.
If the phones are company-owned, a mobile device management (MDM) tool gives you a cleaner version of the same thing: it can be configured centrally to sync a folder on every managed phone, without relying on each salesperson to keep a sync app running.
Tell the customer, and get a real yes. Section 6(1) of the Digital Personal Data Protection Act, 2023 states that consent “shall be free, specific, informed, unconditional and unambiguous with a clear affirmative action, and shall signify an agreement to the processing of her personal data for the specified purpose” [4]. A recorded “this call may be recorded for quality purposes, do you agree?” with a spoken yes, at the start of the call, is the affirmative action the law is asking for. A customer who simply stays on the line without being asked has not given that agreement.
What the interception laws do and do not cover. The Telecommunications Act, 2023 lets only central or state government officers — not private businesses — intercept or suspend telecom services, and only for defined public-safety reasons, with written reasons recorded [5]. Its predecessor, the Indian Telegraph Act, 1885, carried the same government-only interception power [6]. Neither law is about a business recording its own sales call — that is governed by the DPDP Act above, not by these.
A 2025 Supreme Court ruling you will see cited online — read what it actually says. In Vibhor Garg v. Neha (14 July 2025), the Supreme Court held that a spouse’s secretly recorded phone call with the other spouse can be used as evidence in a divorce case, because the marital-communication privilege in Section 122 of the Evidence Act does not apply to disputes between the married couple themselves [7]. This is a ruling about spousal evidence privilege in matrimonial litigation. It is not a general ruling that any business may record any customer without telling them. Do not let anyone tell you it settles the sales-call question — the DPDP consent requirement above is what applies.
Keep the recording secure once you have it. Section 43A of the Information Technology Act, 2000 makes a company that fails to maintain “reasonable security practices” over sensitive personal data liable to compensate anyone harmed by the resulting damage [8]. A customer’s recorded voice, name and financial interest is exactly that kind of data.
Feeds into: Step 2. If it breaks: nothing downstream has anything to work with, and the consequence is invisible — the recording is simply never seen again, and nobody is told that happened.
You now have an audio file in a folder you control. The next job — turning it into readable, searchable text with the agent and the customer told apart — has already been written up in full, step by step, on this site. There is no reason to repeat it here.
Guide 21 covers exactly this: opening the file safely, finding the speech, transcribing it, and working out who said what. Follow its Steps 1 through 6 on the file this page just collected.
But read this one difference first, because it changes Guide 21’s own advice. Guide 21’s best piece of advice is: record each speaker on a separate audio channel and you never need to guess who said what. That advice assumes a call-centre system that can do that. A phone’s own built-in call recorder cannot — it captures both sides of the conversation mixed onto one channel, because that is simply how a phone call sounds to the microphone. On this page, working out who is speaking — diarization, in Guide 21’s Step 5 — is not optional. Budget for it, and expect the roughly 6–7% error rate Guide 21 reports for a two-party telephone call, not zero.
Ingest and fingerprint the file (Step 1), find the speech (Step 2), transcribe it (Step 3), align word timings (Step 4), separate the speakers (Step 5), and punctuate if your transcriber has not already done it (Step 6). Each of those steps carries its own licence comparison, published accuracy figures, and Hindi-specific guidance, which this page does not repeat.
Step 3 of this page hands the transcript to an AI and asks it to work out who said what — which customer detail was mentioned by the customer, and which promise was made by the agent. If the speaker labels feeding into that step are wrong roughly one word in fifteen, the AI can misattribute a promise to the wrong person. This is a genuine, bounded error rate, not a rare edge case, so the next step is written to ask the AI to flag anything it is unsure about rather than guess.
Some phone systems for sales teams — a dialer, a SIM-box, a cloud calling app — can record the agent and the customer onto separate channels even when the call happens on a mobile network, because the recording is made by the software, not by the phone’s built-in recorder. If your team already uses one of those, Guide 21’s "record separately and skip diarization" advice applies to you directly, and this step becomes much cheaper and much more accurate.
Feeds into: Step 3, which needs the transcript with speaker labels attached. If it breaks: everything after this step confidently processes the wrong words, attributed to the wrong person.
Here is the actual new idea on this page. You have a transcript — a page of back-and-forth conversation. A manager does not want to read that page. A manager wants six or seven short facts: the customer’s name, their phone number, what they are interested in, what was promised, and when someone should call them back.
You can ask an AI language model to read the transcript and fill in exactly those fields, as a small structured form rather than a paragraph. This is the same idea as a person reading a letter and copying the important bits onto a form — except the AI can do it in seconds, for every call, all day.
The one thing you must guard against is the AI inventing an answer when the transcript does not actually contain one. If nobody mentioned a budget, a careless AI can still confidently write a number into the "budget" field — because language models are built to produce a plausible-sounding answer, not to leave a field blank. A wrong number sitting in a lead record looks exactly as certain as a correct one.
Two separate things need to go right here: the AI’s answer has to actually be in the right shape — a form your database can read, not a stray sentence — and it has to be true to the call, not invented. The three options below handle the first problem differently. The technique after them is how you handle the second.
OpenAI’s own documentation states plainly that Structured Outputs “ensures the model will always generate responses that adhere to your supplied JSON Schema” [9]. Of the three, this is the most confident published guarantee that the field shape — the right fields, the right types, nothing missing — will be correct.
It does not promise the content is true, only that the form itself is filled in correctly. That is what the grounding technique below is for.
Anthropic’s documentation also uses the word “guarantee”: structured outputs “guarantee schema-compliant responses through constrained decoding” [10]. It then lists three specific situations where the output can still fail to match your schema: a safety refusal, a response cut off by hitting the token limit, and a difference only in the capitalisation of a fixed-choice value. Design for those three cases explicitly — check for a refusal, set a generous token limit, and normalise capitalisation before comparing values — rather than assuming “guarantee” means zero exceptions.
Google’s own documentation is more cautious: “while output is syntactically correct JSON, always validate values in your application” [11]. That is a guarantee about the punctuation of the JSON — the brackets and commas are correctly placed — not about whether the values inside it are correct or even present. If you use Gemini for this step, add your own checks that required fields actually contain something, rather than trusting the shape alone.
Whichever provider you use, apply the same fix. Anthropic’s own guidance on reducing hallucinations recommends two things directly relevant here: “allow Claude to say ‘I don’t know’”, and for longer documents, “ask Claude to extract word-for-word quotes” before drawing a conclusion, so the answer is grounded in the actual text rather than invented [12].
Applied to this step: for every field in your form, ask the AI for the exact sentence from the transcript that supports it, and instruct it explicitly to write “not mentioned” rather than guess when a detail was not actually said. A lead record with an honest blank field is far safer for a manager to act on than one with a confident, invented number.
Feeds into: Step 4, which needs a phone number field to match against existing customers. If it breaks: an invented detail enters your customer database looking exactly as certain as a real one, and nobody downstream has a reason to question it.
The AI in Step 3 wrote out a phone number exactly the way it heard it read aloud, or exactly the way the agent typed it into a note. One call it might be “9876543210”. Another time, for the very same person calling back a week later, it might be “+91 98765 43210”, or “098765-43210”.
To a person, those are obviously the same phone number. To a database doing a simple text match, they are three different strings, and your system will happily create three different customer records for one real person — splitting their history across records a salesperson will never think to look for.
The fix is to agree on one exact written shape for a phone number, and convert every number into that shape the moment it is saved, never the way it happened to be typed.
E.164 is the international numbering-plan standard itself, published by the ITU [13]. Google maintains and publishes the library most other software uses to apply it correctly: libphonenumber, described in its own repository as “Google’s common Java, C++ and JavaScript library for parsing, formatting, and validating international phone numbers”, released under the Apache 2.0 licence — free to use, including commercially [14].
What it actually solves for you: given a messy number in almost any written form, and the country it was dialled from, it works out the correct country code, strips the formatting, and produces one consistent E.164 string you can safely compare. It also tells you whether the number is even a real, dialable number in the first place — catching an agent’s typo before it becomes a permanent bad record.
Ports of the same library exist for most common programming languages, so this is rarely something you need to install as a separate service — it is usually a small library call inside whatever already saves the lead record.
If your whole system today is a spreadsheet, you do not need a database to start. Add one column that always stores the normalised E.164 number, generated by a formula or a small script, and use that column — never the raw typed number — whenever you check “have we seen this person before.” The moment you outgrow a spreadsheet, that same normalised column becomes the key your real database matches on, with nothing else to redo.
Two people can genuinely share a phone number — a shared family or office line is common. And one person can genuinely have two numbers. Normalising the digits removes the accidental duplicates caused by typing the same number differently. It cannot and should not try to guess the real-world cases where one number is two people or one person is two numbers — leave those to a human reviewing the record, and do not build automatic merging on phone number alone without a second confirming detail, such as a name.
Feeds into: Step 5, and every later report a manager runs on "how many customers do we actually have." If it breaks: the business quietly believes it has more customers than it does, and a returning customer is treated as a stranger on every call.
You will hear, confidently, that you have five minutes to call a lead back or you have lost them — that responding within five minutes makes you a hundred times more likely to qualify the lead than responding half an hour later. It is repeated everywhere. It is worth knowing exactly where that number comes from before you build a system around it.
The real, checkable study says something a little different, and still genuinely important. A 2011 Harvard Business Review article, drawing on a separate study of 1.25 million sales leads received by 29 business-to-consumer and 13 business-to-business US companies, found that firms that tried to contact a lead within an hour were nearly seven times as likely to have a meaningful conversation with the decision-maker as those that tried even one hour later — and more than sixty times as likely as firms that waited 24 hours or longer [15]. One of the article’s three authors was, at the time, the CEO of a company that sells lead-routing software — a real conflict of interest worth knowing, even though the finding itself is checkable and has held up.
The “100 times more likely within five minutes” figure people actually quote traces back to a different, non-peer-reviewed report, self-published by that same lead-routing company, not to the HBR study. This page could not independently verify that number. Use the real, checkable finding — speed measured in the first hour matters a great deal, roughly seven-to-sixty-fold — and be sceptical of anyone quoting the more dramatic five-minute figure as settled science.
Either way, the practical lesson is the same: turn the AI’s summary from Step 3 into one dated action immediately, not at the end of the day when someone gets around to reviewing the call.
A short list of if-this-then-that rules, written by whoever runs the sales team: if the customer mentioned a specific loan amount, assign to a senior agent within the hour; if they asked to be called back on a specific day, set that date exactly; if nothing concrete was said, set a generic three-day follow-up. This needs no AI at all for the decision itself — only Step 3’s extracted fields to trigger the right rule. Most teams should start here, prove the pipeline works end to end, and only add AI-suggested actions once the basic version is trusted.
Once the rules above feel too rigid, ask the same AI from Step 3 to suggest a next action and a reason, using the same grounding technique — quote the sentence that justifies the suggestion. Show the suggestion to the salesperson as a pre-filled default they can accept or change with one tap, rather than an instruction that fires without anyone looking at it. The person who spoke to the customer remains the one who decides; the AI removes the blank-page problem of "now what do I write."
Do not let the system automatically message the customer a specific promise — an interest rate, an approval, a discount — based on the AI’s summary of the call. Step 3’s extraction can misread a figure, and a promise sent automatically to a customer is much harder to walk back than a wrongly-dated reminder to a colleague. Keep the human in the loop specifically at the point where anything is promised to the customer in writing.
Feeds into: Step 6, where the due date this step sets becomes the thing a manager is watching. If it breaks: the extraction in Step 3 was accurate for nothing, because no action was actually scheduled from it.
A salesperson genuinely means to call the customer back on Thursday. Thursday is busy. Friday is busier. By the following week, neither the salesperson nor anyone else remembers that promise was ever made — and the customer, who does remember, quietly calls a competitor instead.
This is not a technology problem to solve with a clever algorithm. It is the plainest problem in sales management, and it already has a plain, well-established answer: a due date on every promise, and a simple screen that sorts everything into overdue and upcoming, so a manager does not have to ask each salesperson individually what they have forgotten.
You do not need to invent this pattern. Two of the world’s largest CRM companies build exactly this feature, and their own documentation is a good, free description of how to build a simple version yourself.
HubSpot’s own documentation on creating tasks describes setting a due date and a dropdown to “select when an email reminder should be sent to the task owner” [16] — the reminder goes to the person who owns the promise, automatically, ahead of the deadline.
Salesforce documents the same idea from the manager’s side: its Activity Timeline separates upcoming activities from overdue ones, with its own independent sort order for each, specifically so a manager can see at a glance what has and has not been actioned [17].
The version worth building is small: one table with columns for customer, promised action, due date, and owner; one query that separates rows where the due date has passed from rows where it has not; one reminder sent to the owner the day before the date arrives.
A shared spreadsheet with those same four columns, and conditional formatting that turns a row red once its due date has passed, delivers most of the value of a purpose-built dashboard for a small team. Do not let "we need a proper system" become a reason to delay having any visibility at all — start with the spreadsheet on day one and replace it once volume genuinely outgrows it.
If you want the reminder to reach an agent or a customer over WhatsApp rather than email, the WhatsApp Business Platform requires any message sent outside a 24-hour window since the customer last messaged you to use a pre-approved template message, and Meta’s own pricing page states that “rates vary based on the template’s category… and the recipient WhatsApp phone number’s country calling code” [18]. In practice: design your reminder as a template, submit it for approval before you need it, and check the live rate card for your country rather than assuming a fixed price, since Meta moved from conversation-based to per-message pricing on 1 July 2025 and rates are reviewed periodically.
Feeds into: nothing further — this is the point of the whole pipeline. If it breaks: everything upstream still worked, and the business is no better off, because the one person who could act on a forgotten lead was never told it existed.
A weekend version. One shared cloud folder that a sync app copies recordings into (Step 1). A cloud transcription API with punctuation and diarization switched on, run by hand on each new file (Step 2). A single prompt to an AI, asking for a JSON object with name, phone, interest, next action and next-action date, with the quote-first grounding instruction built into the prompt (Steps 3 and 5). A spreadsheet with a normalised-phone-number column and conditional formatting for overdue rows (Steps 4 and 6). No code beyond a phone-normalisation library call. Buildable by one technically-minded person in a few days.
A proper first version. An always-on watcher that moves new recordings automatically (Step 1). A queued pipeline that transcribes and diarizes every new file without anyone triggering it by hand (Step 2). A structured-output call to one AI provider with the grounding technique and an explicit "not mentioned" option for every field (Step 3). A small customer database, keyed on the normalised phone number, that updates an existing record instead of creating a new one (Step 4). A rules engine, simple enough to be a spreadsheet of if-then rows, deciding the next action (Step 5). A dashboard with an overdue view and an email or WhatsApp reminder (Step 6).
An enterprise version. Everything above, plus: an audit trail linking every lead-record field back to the exact transcript quote it came from, so a manager can check the AI’s work in one click; a second AI pass that flags low-confidence extractions for manual review instead of trusting them outright; integration with whatever CRM or loan-origination system already exists, rather than a new database of its own; and a consent record stored against every call, proving the customer was told before recording began.
Every figure, quote and legal citation on this page traces to one of these. Legal text is read from the government or Indian Kanoon source directly, not from a summary of it.
Checked September 2026. Prices, model behaviour and platform policies in this field change monthly; the date is part of the claim.
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.
Nothing is sent from here. The link carries only this page’s title and address.