The CRM already has calls. Someone says it is time to add AI. In the next meeting that sentence has become a chat on the website, a score nobody can explain, or a project to replace the CRM. None of those is the first step. The first step is a decision your people already make when a call ends, written so a model can return fields and a person can disagree with them.
I have taken a call from the telephony side, through a later pass, and onto a card in a CRM that serves more than one company. The useful shape was boring. The call ended. The card was already there. A structured note arrived after, and a second attempt at the same call did not create a second note. Reporting came after a person could read one result. That is a place to start. A new product is not.
1. Write the decision the team already makes
After a call, someone already decides something. The script was followed or it was not. A price was promised or it was not. The next step was written on the card or the card is blank. A manager will be coached on this call or they will not. Pick one of those. If you cannot point at the argument the team had last week, you do not have a task for a model yet. You have a wish that the calls become "smarter".
Write the decision as fields, not as a paragraph the model may compose. A yes or no the team already uses. A short reason, taken from a list they already argue with, not from an open essay. The next step, in the same words the card already has. A person who was not on the call should be able to read the note and say "this is wrong" in one sentence. If they cannot, the note is decoration. Decoration does not change a Monday morning.
Leave the rest of the call alone. A model that tries to judge tone, script, price and the next task on day one will be wrong in four ways, and the team will stop reading it. One decision, reviewed on real calls, is a product. Four decisions, unread, are a demo.
2. A chat on the site is a different purchase
A chat widget talks to people who are not in your CRM. It needs a tone, a limit on what it may promise, and a way to hand a person to a human. That is a front door. Call review talks about conversations your managers already had. The result has to sit on a card someone opens on purpose. The recording, the manager and the company are already known. You are not attracting a visitor. You are leaving a note where the work already is.
Teams buy the chat because it is visible in a sales deck, and they postpone the call note because it is not. Then they are surprised the CRM looks the same. If you need a front door, buy a front door, and keep it off this list. If you need managers to stop leaving the next step blank, the chat will not type it for them. The note on the card will, and only if a person still checks it.
Do not let the vendor sentence "AI for your customer communication" cover both. Ask which object receives the result. A visitor on the site, or a card that already exists. If the answer is both, you have two projects. Fund the one whose absence you felt last week.
3. The call cannot wait on the model
The manager is not going to sit in silence while a model thinks. Build it so they never have to. The call ends. The card is created the way it is created today, by the telephony you already have. The note arrives after, when the recording can be read. If the model is slow, quiet or wrong, the card is still there and a person can press play. The failure of the note is not a failure of the call.
That later pass has to be safe to run twice. Networks retry. A job that scored the call and then died on the way to the card will be tried again. The second try must find the note it already wrote and stop. A second note that contradicts the first, or a second task in the manager's list, is how the team learns to ignore the feature. On the system I described, the retry was part of the design, not a surprise after launch. Ask for the same before you turn it on: one call, one note, even when the work is delivered twice.
Put the failure where a person looks. A dead job that nobody sees becomes "the AI is random". The card should show that the note is missing, not look like a call that was never reviewed. Someone should be able to run that one call again without running the whole night.
4. The note has to land on the right company
If one CRM serves several companies, or several branches of one company, the recording and the note belong to the company the call was for. A sharp summary in the wrong account is worse than silence. The other company can read a conversation that was not theirs. You will hear about it from them, not from a dashboard.
This is the same boundary as any other shared product, and it breaks in the same boring places: a report that lists every note, a night job that writes a file, a person whose login can see everyone, a new column someone added without the company on it. Check with two logins before you enable the note for all of them. Sign in as company A, open a call that belongs to company B, and confirm you cannot read the note or the recording. The longer map of those breaks is where a shared product mixes customer data. Do this before you discuss how clever the summary sounds.
Branch databases and a shared login are both in play on products like this. You do not need to know which one you have in order to run the two-login check. You need the check to fail closed. If you cannot get a second login, that is the finding. Do not turn the note on while only an administrator can see whether it leaked.
5. What "working" looks like in a week
Take ten calls you are allowed to use. Read the note on the card next to the recording. Disagree with at least one of them, in a specific field, and say why. Disagreement means the result is inspectable. A score of 80 with no sentence is not. If the team cannot find a wrong field, the fields are too vague to coach anyone, and you are not done.
Do not start from a report of every score. A report that hangs, or a report that shows another company's rows, will eat the week you meant to spend listening. Get one card right. The report is the next step, and if it is the thing people already wait on, it has its own pass in reports that make people wait. A model does not fix a report. It gives the report more rows to get wrong.
Keep the telephony, the messages and the accounting you already connected. You are adding a note to a card, not commissioning a new CRM. Anyone who proposes a replacement in the same breath as the first ten calls is selling you a different project. Park it until a person has disagreed with a real note and the note has stayed on the right company.
When to bring in a specialist
You can name the decision and collect ten calls without a developer. Ask for help when the note has to come back onto a card you already run, when a retry would create a second task, or when more than one company shares the CRM and nobody has done the two-login check.
That is the work I take: connect the calls you already have to a note on the card, on the CRM you already run. Services cover that kind of connection, including the later pass and the reporting that should wait its turn. Selected work keeps each result next to the operation that produced it. If you want a second look, message me on LinkedIn. Send the decision you want on the card, and whether one CRM serves more than one company. Do not send recordings of real customers in the first message.