What an AI CRM actually does today

Why the claims all sound the same

Language models became cheap enough to embed in ordinary software at roughly the same moment for everybody, so every vendor shipped a similar first wave of features and described them in similar words. That makes marketing pages nearly useless for comparison. What separates one implementation from another is not the model; it is what the model is allowed to read, and what it is allowed to do with the answer.

Those two questions (grounded in what, and who acts on the output) are the whole evaluation. Everything below is a way of asking them about a specific feature. If you want the wider context of what the software is for before the AI question, what a CRM is covers it.

What can AI reliably do in a CRM today?

Job	What it does	What it is worth
Summarizing	Compresses a long account history (forty emails, a dozen notes, three quotes) into a paragraph.	Handover. The highest value and the lowest risk of the three.
Drafting	Writes a first version of a reply, a follow-up or a call recap from the thread and the record it sits on.	Typing. The blank page disappears; the judgment stays with the person.
Prioritizing	Ranks open deals and new inquiries, or suggests the next step on one, from stage, age, value and recent activity.	Attention. It changes what a rep opens first on a Monday.

Summarizing is the one most buyers underrate. It turns covering somebody’s accounts while they are away into a short read instead of an afternoon of scrolling, and because the output is read by a colleague rather than sent to a customer, a mistake in it is cheap.

A useful summary preserves names, dates, commitments and uncertainty, and can be traced to source records. It should not convert an unknown into a confident statement.

Prioritizing is the one that gets mislabeled. A ranking can come from explicit rules an administrator writes or from a model trained on past deals, and vendors call both “AI”. Ask which one you are looking at, because the two fail in different ways and are corrected in different ways.

Where the data comes from, and why it decides everything

An assistant that ranks your deals against a general model of how deals behave is guessing about your business. One that works from your own won and lost deals is describing it. Ask which one you are being sold, and ask it in those words.

• Grounded in your records. The output cites something you can open: this deal, that email thread, those notes. You can check it in one click.
• Grounded in general text. Fluent, plausible, and unconnected to your customers. Useful for phrasing, not for judgment.
• Grounded in nothing much. Scores with no visible reasoning. If nobody can say why a deal is at seventy rather than forty, nobody will act on the seventy for long.

This is also why a thin CRM produces a poor assistant. If half the deals have no close date and the notes field is empty, there is nothing to reason over, and the assistant will produce something confident anyway. Fixing the data model is a prerequisite, not a follow-up task. What a CRM database is, and how to keep it clean is the companion to this guide for that reason.

What a score is, and what it is not

A deal score is a ranking device. It is good at putting fifty open deals in a sensible order and poor at telling you the probability of any one of them closing, and the two get conflated constantly, usually by the person building the forecast.

• Use it for: triage, prioritizing a call list, noticing that a deal has gone quiet, spotting the inquiry nobody picked up.
• Do not use it for: the committed forecast, a commission decision, or anything a person cannot explain to the customer it concerns.
• Watch for: a score that only ever moves when someone updates the record. That is not insight, it is a rewritten field, and it means your reporting and your scoring are measuring the same act of data entry.

Rules use explicit thresholds; learned models infer patterns from historical data. Either way, explain what the score predicts, the signal categories, update time, and known limitations. Do not use a sales score for an undisclosed legally significant decision about a person.

In Senitix CRM, scoring is not part of Senitix AI. An administrator builds rule-based scoring profiles that score leads, contacts and deals from their fields, so every point on a record traces back to a rule somebody wrote; plan availability is on the pricing page. Senitix AI does a different job: asked about a deal or a lead, it returns a short, ranked list of next steps, each with the reason behind it, and the rep decides what to do with it.

Three properties separate a score people go on using from one they quietly stop opening.

• It is legible. The reader can see the two or three inputs that moved it, in plain words, in the list beside the number rather than inside a settings screen.
• It is dated. A number with no timestamp cannot really be read. Nobody can tell whether it reflects this morning’s call or a recalculation from last month.
• It is reviewable. Somebody can pull the deals that scored high last quarter and count how many of them closed. A score nobody audits drifts, and nobody notices.

Almost none of that is a question about the model. A score reads fields, so whether the close date, the value and the last activity are actually filled in decides more than any tuning the vendor did, and that condition belongs to the CRM database rather than to the assistant sitting on top of it. Agree in advance what the number is allowed to change. Reordering a call list is one decision. Moving a stage, or firing an email, is another, and it deserves its own argument.

Drafting, and the line it must not cross

Generated text is at its best on the messages nobody enjoys writing: the third follow-up, the summary of a call, the polite chase on an overdue decision. It is at its worst on anything carrying a commitment (a price, a date, a scope, a concession), because a language model will produce a fluent sentence whether or not it has grounds for it.

The control is simple and it is not a technical one. A draft is a draft until a person has read it and pressed send. That single rule is what makes the rest of the category usable, and it is worth asking any vendor to state plainly: does anything the assistant produces reach a customer without a human seeing it first? An assistant that acts on its own may be marketed as autonomy; in a sales context it is an unreviewed message from your company, with your name on it.

AI can prepare an email, a meeting recap or the note that explains a quote. Product price, delivery, contract terms and personal details remain source-of-truth fields that a user verifies.

Where AI should not be trusted yet

• Anything with a number in it. Prices, quantities, discounts and dates should come from the catalog and the record, not from generated prose.
• Compliance and contractual language. A plausible sentence about a data processing obligation is a liability, not a time-saver.
• Deciding who gets attention permanently. Scores encode the past. If last year’s good customers all came from one channel, an unwatched score will keep sending you there.
• Anything you would not want quoted back. Assume any generated line may end up in a customer’s inbox screenshot. That is a useful editing standard.

What is agentic CRM, and what would it need?

Agentic is the word the category has moved to, and it asks for more than the last one did. A generative feature drafts something when somebody asks it to. An agent plans several steps and carries them out, which only means anything if it can act while nobody is watching.

So it is worth naming what you would be granting, rather than arguing about the term. An agent that works a queue on its own needs standing write access to records, the right to open and close tasks, and usually the right to send something outward. It needs all three at the moments when nobody is looking, because not looking is the point. The useful question is not whether software can be built that way. It is where the approval boundary sits, and that is a product decision rather than a technical limit.

• Reading and preparing. Safe. A proposal that sits on the record costs nothing when it is wrong.
• Writing to an internal field. Recoverable, as long as the change is logged and somebody reads the log.
• Anything that leaves the building. An email, a price, a date. Not recoverable, because the customer has already read it.

Much of the work people picture handing to an agent is deterministic already, and an ordinary rule is easier to explain than a plan the software invented: when a stage changes, create the task; when a quote goes out, schedule the chase. CRM workflow examples walks through five processes and the kind of tool that runs each one. The steps an agent would chain are the ordinary capabilities set out under CRM features, working on the same records and stages that CRM software already keeps.

Our own implementation sits on the first line of that list by design. Senitix AI works inside Senitix CRM: it writes a daily digest, answers questions from the records a user can already open, drafts and rewrites email, summarizes threads and suggests next steps. It never sends an email by itself, and when its copilot proposes a change to a record, nothing is written until the user confirms and the user’s permissions are checked again at that moment. That is the boundary worth asking every vendor to state plainly: where it sits today, what is written to a log when something crosses it, and who is allowed to move it.

What should you ask an AI CRM vendor?

1. What does the assistant read? Which objects, which fields, and does it stop at the permission boundary of the person asking.
2. Can it act without a person, and can human review be switched off? If it can act, on what, and who decides whether review stays on.
3. Is our data used to train a shared model? Ask for the answer in the data processing agreement rather than in an email.
4. Which model provider and sub-processors are involved, and where is data processed and retained? This is a data protection question with a documented answer, or it should be.
5. Are its actions logged? A suggestion accepted, a draft sent, a field changed: each should leave a trace somebody can read later.
6. What is metered? AI requests are frequently counted. Ask for the number, whether it applies per user or per workspace, and what happens when it runs out mid-month.

The second question matters more than it looks. A product that lets human review be switched off has made a different safety choice from one that does not.

Our own answers, for comparison. Senitix AI reads only what the requesting user is already allowed to open, and it drafts but does not send. Requests are counted per user per day, alongside a monthly budget per user, and AI pauses for that user when either one is reached while the rest of the CRM keeps working; the exact daily and monthly allowance on each plan is published on plans and pricing. The Data Processing Agreement lists our sub-processors and the written notice we give before that list changes; ask us the training question too, and ask for the answer in writing.

A short vocabulary

Deal scoring

A ranking of open deals by how likely they are to progress, calculated from the record by rules or by a trained model rather than from opinion.

Next-best action

A suggested next step on a record, shown with the context that prompted it, for a person to accept or dismiss.

Grounding

Restricting what a model may answer from: ideally your own records, so the output can be checked against something.

Hallucination

A fluent, confident statement with no basis in the data. The failure mode to design against, not one to be surprised by.

Human in the loop

A person reviews and approves the output before it has any effect outside the system.

Prompt

The instruction and the context given to the model. In a CRM most of it is assembled from the record, not typed by you.

Summarization

Compressing a long history into a short readable account. The lowest-risk use of a language model in sales software.

Drafting

Producing a first version of a message for a person to edit and send. Never the send itself.

Sub-processor

A third party that processes your data on the vendor’s behalf, including a model provider. It belongs in the data processing agreement.

How do you judge an AI CRM after ninety days?

Not by whether people like it. By whether a specific job got shorter: the time between an inquiry arriving and someone replying, the number of accounts a covering rep can pick up in a morning, how often a deal sits untouched past its close date. Write the two you care about down before you switch anything on, because afterward everyone remembers the demo rather than the baseline.

Start with low-risk summaries and rewriting. Classify correct, corrected and rejected outputs. Test source visibility, permission boundaries and representative privacy cases. Decide with time saved, accept, edit and reject rates, material errors and usage spend, not a novelty score.

Ninety days is the horizon that works. A month tells you whether the outputs are safe to look at, but not whether anyone still opens them once the novelty has gone. A year is long enough for everybody to forget what they agreed to look at in the first place.

Then look for the work that stopped. Nobody announces that a job got easier; they stop mentioning it. Ask the two or three people who used the feature most what has fallen off their week, and hold that against the two measures you wrote down. If nothing has fallen off, switching the feature back off is a more honest answer than more training. Whatever you keep has to survive becoming ordinary, which is the test that decides the rest of your CRM best practices.

If you are still comparing systems, choosing the best CRM for your team sets out how to test claims like these against your own data, and what each Senitix plan includes is published on plans and pricing.