Most CRM AI features are configured once and applied uniformly. A single prompt, a single model setting, a single output format served to every user regardless of role. The intent is simplicity. The outcome is that nobody gets quite what they need, and the feature gets used by the people whose work happens to fit the default — and ignored by everyone else.

This is not a minor inconvenience. It is the primary reason AI features in CRMs have high demo appeal and low sustained adoption. The gap between what the feature does and what the user actually needs at their specific moment in their specific workflow is wide enough that using the feature requires more effort than not using it. So most people don't.

Per-user AI configuration addresses this directly. When the intelligence your CRM surfaces is shaped by who is asking — their role, their current deal context, their preferred output format — the output is useful enough to act on immediately rather than requiring further interpretation. That is the difference between an AI feature that changes how people work and one that gets demoed in the sales cycle and ignored in production.

What Different Roles Actually Need from CRM Intelligence

Account ExecutivesAn AE's primary intelligence need is deal-level: what is the current health of this opportunity, what has changed since the last interaction, what is the highest-leverage action to take today. The relevant context is the deal record — stage, time in stage, last interaction date, stakeholder engagement, close date history, value. The useful output is a prioritised action, not a summary. "Your three highest-risk deals this week, and what to do about each one" is valuable. "Here is a summary of your pipeline" is not — the AE already knows their pipeline.

AEs also need AI that understands the difference between genuine deal signals and noise. A deal where the economic buyer just replied with a question is different from a deal where a junior contact sent a calendar invite. Weighting matters, and the weighting that is right for an AE managing complex enterprise deals is different from the weighting that is right for someone closing high-velocity SMB.

Sales Development RepresentativesAn SDR's intelligence need is primarily pre-contact: what do I need to know about this account and this contact before I reach out, and what is the most relevant angle given what I know about them? The useful output is account context — recent news, relevant signals, suggested opening — not pipeline analysis. An SDR does not manage a pipeline in the same sense an AE does. Their CRM AI should be optimised for the outbound motion: research synthesis, personalisation signals, and talk track suggestions based on the prospect's industry and role.

Serving an SDR the same deal health analysis an AE gets is a category error. It produces output that is structurally irrelevant to their work and trains them to ignore the feature.

Customer Success ManagersA CSM's intelligence need is account health and expansion signal: is this customer getting value, are there indicators of churn risk, and are there natural moments to discuss expansion? The relevant data is usage patterns, support ticket history, NPS trends, and engagement with the product or service. A CSM using CRM AI that is configured for new business prospecting will find nothing useful. The context, the signals, and the actions it should recommend are entirely different.

Sales ManagersA manager's intelligence need is aggregate and comparative: which reps are at risk this quarter, where is pipeline coverage thin, which deals need intervention, where is coaching most needed. They need the system to surface exceptions — the things that are not working as expected — not summaries of normal activity. A manager who opens their CRM AI and sees a digest of everything happening is getting a report. A manager who sees "three deals at stage 3 with no economic buyer engagement" and "two reps whose stage conversion rate dropped this month" is getting intelligence.

The Configuration Dimensions That Matter

Dimension What it controls Why it matters per role
Data scope Which CRM objects and fields the AI has access to when generating output An SDR needs account and contact data. An AE needs deal and interaction data. A CSM needs account health and usage data. Giving all roles access to all data produces unfocused output.
Output format How the AI presents its output — action item, summary, analysis, suggested message AEs want prioritised actions. SDRs want research briefs. Managers want exception alerts. The same underlying analysis formatted differently has completely different utility across roles.
Trigger condition What causes the AI to generate output — a record view, a stage change, a time-based schedule, a data threshold An AE benefits from AI that triggers on deal activity changes. An SDR benefits from AI that triggers when a new prospect is added. A manager benefits from AI that runs on a daily schedule across the team.
Custom prompt context Role-specific instructions that shape how the AI interprets the data and what it emphasises An enterprise AE's prompt should emphasise multi-stakeholder engagement and contract complexity. An SMB AE's prompt should emphasise velocity and next-step immediacy. A CSM's prompt should weight churn signals differently from expansion signals.
AI provider and model Which underlying model powers the feature for a given user Relevant when different roles have different latency tolerance or output quality requirements. Less important than the above — the configuration around the model matters more than the model itself for most sales intelligence use cases.

What Good Per-User AI Configuration Looks Like in Practice

The practical implementation does not require every user to configure their own AI settings from scratch — that is a recipe for low adoption of the configuration interface itself. The right model is role-based defaults with user-level overrides.

RevOps or Sales Ops defines the baseline configuration for each role: what data the AI accesses, what format it uses, what prompt context applies. A new AE who joins the team gets the AE configuration automatically. They can adjust it if their specific situation warrants — if they cover a specialist vertical, for example, and want the AI to weight certain signals differently — but they do not need to configure it from zero to get useful output on day one.

This is the configuration model that drives adoption. The default is useful enough to act on immediately. The customisation layer is available for users whose work has specific requirements that the default does not serve well. The result is that AI features get used because they produce relevant output, not because they were mandated in the onboarding process.

The Adoption Test

The most direct way to assess whether your current CRM AI configuration is working is to ask a simple question to users across different roles: in the last week, did the AI in your CRM surface something you acted on? Not something you found interesting. Something you acted on — sent a message, reprioritised a deal, escalated something to a manager.

If AEs, SDRs, and CSMs all give different answers — if some roles are acting on AI output and others are not — the configuration is not working for the roles where adoption is low. The issue is almost never that the AI is not capable enough. It is that the output is not close enough to what that role needs at that moment in their workflow to be immediately actionable.

Closing that gap — role by role, workflow step by workflow step — is the actual work of CRM AI configuration. It is less glamorous than the model selection conversation and considerably more important.

Ask your SDRs and your AEs the same question: "What did your CRM AI tell you this week that you acted on?" If the answers are the same — or if both groups say nothing — your AI is configured for a generic user who does not exist on your team.