Salesforce employs thousands of engineers and has practically ingested data from every major enterprise on the planet. They have a market cap of around $200B. But still, it is a manual process for a sales representative to figure out which accounts to prioritize and which features to pitch to which customers in order to gain revenue for their company. This is not a data problem, but an inference problem. The data already exists in the salesforce instance of all the relevant companies, but there is a gap between having data and knowing what should happen next. CRMs like Salesforce’s serve as a memory layer to store every deal, interaction and contract. However, without inference, it is just an expensive filing cabinet. That’s why all the world’s leading SaaS companies are building the action layer called AI Recommendation Engines. The Fundamental Limitation of CRM In all fairness, CRM systems were designed to just be a filing cabinet. They store things like: What were the login times of the customers, what features or add-ons have they purchased, how many support tickets have they raised, etc. But storing the data doesn’t translate into revenue. The revenue teams are paid to act forward and decide which accounts are worth investing in and which accounts are at a risk of churning before their renewal date. And subsequently, which features should be sold to the customers in order to expand the ARR. This is where CRM falls short. It cannot synthesize this data into a ranked, actionable recommendation. That synthesis requires something CRM was never designed to provide: intelligence. Enter the AI Recommendation Engine AI Recommendation Engines are supplemental to CRMs. They have a separate architectural layer that sits above the data and produces outputs that CRMs were not intended to do. These are ranked and human readable recommendations that are tied to individual accounts. At a very high level, the system works in three stages: Context assembly: The system first pulls together a dynamic payload of signals about a given user. These are signals like product usage patterns, feature adoption gaps, account health scores, contract terms and behavioral signals. These are also not static in nature. So, an ideal assembly would run and update this data frequently with most recent data and purge the last ones that are not relevant anymore.
Scoring and ranking: This layer is often backed by a model that has learned from historical outcomes and evaluates each potential recommendation for the account and assigns weights to them. These weights reflect the expected business impact of each recommendation, for example, which action is most likely to drive expansion, prevent churn or accelerate adoption for this specific customer.
Synthesis. A language model will then take the weighted recommendations and generates a human-readable rationale. Recommendation is not just "recommend feature X" but something like "this account has three developers on the buying committee and has not yet explored your API capabilities, so a targeted developer onboarding session has driven a 40% activation rate in similar accounts." The output is a recommendation a customer success manager can act on immediately, without needing to interrogate a dashboard. Context assembly: The system first pulls together a dynamic payload of signals about a given user. These are signals like product usage patterns, feature adoption gaps, account health scores, contract terms and behavioral signals. These are also not static in nature. So, an ideal assembly would run and update this data frequently with most recent data and purge the last ones that are not relevant anymore. Context assembly: Scoring and ranking: This layer is often backed by a model that has learned from historical outcomes and evaluates each potential recommendation for the account and assigns weights to them. These weights reflect the expected business impact of each recommendation, for example, which action is most likely to drive expansion, prevent churn or accelerate adoption for this specific customer. Scoring and ranking: Synthesis. A language model will then take the weighted recommendations and generates a human-readable rationale. Recommendation is not just "recommend feature X" but something like "this account has three developers on the buying committee and has not yet explored your API capabilities, so a targeted developer onboarding session has driven a 40% activation rate in similar accounts." The output is a recommendation a customer success manager can act on immediately, without needing to interrogate a dashboard. Synthesis. Why This Is Harder Than It Sounds Building and using an AI Recommendation Engine in production surfaces comes with problems that are not resolvable cleanly. Trust It is entirely possible for an AI Recommendation Engine to recommend a feature or a product that is not based in reality. The recommendation is only as good as the data fed into the engine that resulted in the said recommendation. If there is a crucial piece of data missing, the recommendation might be stale or disconnected from what the user really wants. One meaningless recommendation from the engine that gets dismissed by the customer, means the customer never trusts future recommendations from the system. Cold Start Problem Recommendation Engines work well for customers or accounts for which data is available. The data like usage patterns, feature adoption sequences or behaviors take time to accumulate. Therefore, for the new accounts which have thin data, the system will generate recommendations with low confidence. The result of this low confidence recommendation is in-turn trust erosion. Hallucination All LLMs are at the risk of hallucinating if proper guardrails are not implemented. This is a non-theoretical risk as this happens frequently. The architecture has to treat LLM as a synthesis layer so that once the scored and structured input is provided, the inference layer is not treated as a reasoning engine operating in vacuum. Freshness Account signals have to be refreshed frequently, otherwise a recommendation generated from stale data can become counterproductive. The architecture of the pipeline has to be designed to ingest data in real-time, rather than in batch processing. What This Means for the CRM Market There is a misconception that CRM vendors will simply add AI to their products and this will close the gap. However, that is not entirely true. The assumption is that incumbents will layer intelligence on top of existing data assets and still maintain dominance. However, this view does not take into account that the AI Recommendation engines are very different from what CRM vendors would build. CRM-native AI will operate on CRM-native data like contact records, deal stages, email logs and it will answer CRM-shaped questions like summarize this account, draft this follow-up email, predict this deal's close probability. But an AI Recommendation Engine operates on a broader product surface like usage telemetry, feature adoption, in-product behavior, support signals. It is a product-led intelligence system and not a sales-process intelligence system. The companies building it are doing so inside their product and data infrastructure, not inside their CRM. This is why the most sophisticated AI Recommendation Engines are being built in-house, inside engineering and product teams, not procured from CRM vendors. The data they require lives in data warehouses and product analytics pipelines, not in Salesforce objects. The architecture is closer to a recommendation system than a CRM plugin. The Emerging Category We are in the early innings of a market transition that will look obvious in retrospect. In the same way that CRM consolidated the memory layer for enterprise revenue teams in the 1990s and 2000s, AI Recommendation Engines will consolidate the action layer over the next decade. The signals are already there. Retention teams at enterprise SaaS companies are being reoriented around AI-driven intervention. Customer success platforms are racing to incorporate recommendation logic. Revenue operations teams are building scoring pipelines that would have been infeasible three years ago. The pieces are assembling. What is not yet clear is where the value accretes. Does it go to the CRM incumbents who layer in intelligence? To the product analytics platforms who own the underlying telemetry? To a new category of AI-native revenue intelligence vendors? Or does it stay inside engineering teams at companies sophisticated enough to build it themselves? My view: the early advantage goes to companies who build it internally, because the architectural integration required across product data, ML pipelines, and customer-facing workflows is too bespoke to be productized quickly. But within five to seven years, this will be a standalone product category, and the companies that figured it out internally first will have written the playbook everyone else follows. My view What to Get Right from Day One If you are building in this space, whether as an engineer, a product manager, or a revenue leader, here is what I have found matters most: Design for explainability from the start. Recommendations without rationale are recommendations that do not get acted on. The synthesis layer is not a feature, it is the product.
Treat the LLM as a synthesis layer, not a reasoning engine. Feed it structured, scored inputs. Do not ask it to reason from raw data. The scoring logic belongs upstream.
Invest in signal freshness early. A batch pipeline that refreshes overnight will feel broken the moment a customer success manager acts on a stale recommendation. Near-real-time matters more than perfect coverage.
Measure field adoption, not just model accuracy. A recommendation engine with 80% precision that nobody acts on is worse than a simpler system with 60% precision that drives behavior change. The metric that matters is actions taken per recommendation surfaced.
Build for cold-start explicitly. New accounts are often the highest-priority accounts. Do not let thin data produce either silence or false confidence. Design for explainability from the start. Recommendations without rationale are recommendations that do not get acted on. The synthesis layer is not a feature, it is the product. Design for explainability from the start. Treat the LLM as a synthesis layer, not a reasoning engine. Feed it structured, scored inputs. Do not ask it to reason from raw data. The scoring logic belongs upstream. Treat the LLM as a synthesis layer, not a reasoning engine. Invest in signal freshness early. A batch pipeline that refreshes overnight will feel broken the moment a customer success manager acts on a stale recommendation. Near-real-time matters more than perfect coverage. Invest in signal freshness early. Measure field adoption, not just model accuracy. A recommendation engine with 80% precision that nobody acts on is worse than a simpler system with 60% precision that drives behavior change. The metric that matters is actions taken per recommendation surfaced. Measure field adoption, not just model accuracy. Build for cold-start explicitly. New accounts are often the highest-priority accounts. Do not let thin data produce either silence or false confidence. Build for cold-start explicitly. The CRM era gave enterprise revenue teams a shared memory. The AI Recommendation Engine era will give them a shared intelligence, a system that knows not just what happened, but what to do next. That shift is already underway, mostly invisibly, inside the engineering teams of the companies you use every day. The filing cabinet is getting a brain.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

AI Recommendation Engines: The Next Frontier in CRM

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Year of AI in My Life as an Engineer

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

A Year of AI in My Life as an Engineer

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps