简介这份PDF资料聚焦Salesforce Einstein AI面向CRM从业者、竞品分析人员及希望了解AI如何落地销售场景的学习者系统梳理了Einstein在客户关系管理中的核心能力与处理逻辑。内容围绕自动化销售活动、精准定位最佳潜在客户、提高成交率、深度连接客户以及Einstein Search五大章节展开并延伸讲解Einstein Activity Capture的账户同步机制、数据流向控制与敏感信息保护策略帮助读者理解Salesforce自2015年布局AI以来的产品思路。资源包为1个PDF文件大小约1.78MB结构紧凑适合作为培训参考或竞品研究材料。目前已有440人学习下载读者可从中获取Einstein AI的功能框架、Outlook与Gmail集成细节、Inbox客户洞察以及Automated Contacts自动补全联系人等具体知识点快速建立对Salesforce智能CRM体系的整体认知。1. Salesforce AI CRM 里 Einstein 到底在做什么从一条销售线索的流转说起一条线索从市场活动进来到最终成单中间要经过分配、跟进、报价、审批、催单五六个环节。传统 CRM 里这些环节靠人盯、靠报表回溯销售经理每天早上的第一件事是翻列表看哪些单子卡住了。Einstein 要解决的正是这个「事后才知道」的问题——它把预测、推荐、生成三类能力嵌进 Salesforce 的对象和流程里让系统在销售还没意识到风险时先给出提示。适合谁用已经上了 Sales Cloud 或 Service Cloud、手里有至少半年历史数据、想让一线销售少填几个字段的团队。如果数据还没沉淀先别急着开 Einstein后面会讲为什么。2. Einstein 的能力分层预测、推荐、生成各管哪一段2.1 三层能力对应的业务对象和触发时机Einstein 在 Salesforce 里不是一个单独的产品而是一组挂在标准对象上的能力集合。按落地顺序我一般把它分成三层来看。第一层是预测类代表是 Einstein Scoring 和 Opportunity Scoring。它挂在 Lead 和 Opportunity 对象上输出一个 0 到 100 的分数触发时机是记录创建或字段更新后异步计算。分数本身不改变业务逻辑但可以被 Flow 或 Apex 读取用来做分配规则。第二层是推荐类代表是 Einstein Next Best Action 和 Recommendation。它挂在 Case、Opportunity 上输出的是「下一步做什么」的建议比如「这条 Case 建议升级到二线」「这个商机建议发折扣审批」。推荐依赖的是策略规则加预测模型策略用 Flow 编排模型用 Data 里的数据集训练。第三层是生成类代表是 Einstein for Sales 里的邮件草稿和通话摘要。它挂在 Activity、EmailMessage 上触发时机是用户点击「生成草稿」或通话结束后。生成类对数据量要求最低但对权限和字段级安全要求最高因为模型会读到记录里的敏感字段。三层不是必须全上。多数团队的上线路径是先开生成类让销售感知到价值再上预测类做分配最后用推荐类串流程。2.2 数据准备哪些对象和字段必须先补齐Einstein 的预测和推荐都依赖 Data 里的数据集数据集来自 Salesforce 对象的字段。上线前必须确认三件事。第一历史记录的闭合状态要完整。Opportunity 的 Stage 必须有过 Won 和 Lost 的样本且比例不能太悬殊。我见过一个团队 95% 的商机都是 Won模型训练出来全是高分等于没预测。常见做法是把 Lost 样本补到至少 20%。第二关键字段不能大面积为空。以 Opportunity Scoring 为例它默认会读 Amount、CloseDate、StageName、LeadSource、Activity 相关字段。如果 LeadSource 有 60% 为空模型会把这个字段的权重压到很低预测就退化成只看金额。第三字段类型要匹配。数据集里数值型字段不能混入文本日期型字段不能写成字符串。检查方法是在 Data Manager 里看字段的 Data Type和对象定义对不上就先在对象层修正。-- 在 Data Manager 里跑之前先用 SOQL 检查关键字段的空值率 SELECT COUNT(Id) total, COUNT(Amount) has_amount, COUNT(LeadSource) has_source, COUNT(CloseDate) has_closedate FROM Opportunity WHERE CreatedDate LAST_N_DAYS:365这段 SOQL 的作用是快速估算字段覆盖率。total 是总记录数has_amount 等是各字段非空计数。如果 has_source 除以 total 低于 0.5说明 LeadSource 不适合直接进模型要么先做补录要么在数据集里排除。参数上LAST_N_DAYS:365 控制时间窗口我一般取一年太短样本不够太长业务形态可能已经变了。2.3 在 Setup 里开启 Einstein 并绑定对象的最小步骤开启路径在 Setup 的 Einstein 相关菜单下不同版本入口略有差异但核心步骤一致。第一步在 Setup 里搜索 Einstein Setup打开开关。这一步会触发后台初始化通常几分钟到半小时期间不要重复点。第二步进入 Einstein Data Manager新建一个 Dataset。Dataset 的类型选「Predictive」还是「Recommendation」取决于你要做的能力。预测类选 Predictive推荐类选 Recommendation。第三步选择对象和字段。对象选 Opportunity字段至少勾选 Amount、StageName、CloseDate、LeadSource、Type。如果要用 Activity 数据还要勾选「Include related records」把 Task 和 Event 关联进来。第四步设置预测目标。目标字段选 StageName目标值选 Closed Won。这里有个坑目标值必须是一个明确的值不能选「所有非 Lost」否则模型学不到边界。第五步训练模型。点 Train 后系统会跑一轮状态从 Queued 到 Running 再到 Completed。训练时间取决于记录数十万级大概十几分钟。第六步把模型分数暴露到对象上。在 Opportunity 的页面布局里加入 Einstein Scoring 组件或者在 Flow 里用 Get Records 读取 EinsteinScore 字段。// 在 Flow 的 Apex Action 里读取 Einstein 分数并做分支 // 假设已有一个返回 Opportunity 分数的 Apex 方法 public class EinsteinScoreReader { InvocableMethod(labelGet Einstein Score) public static ListResult getScore(ListRequest requests) { ListResult results new ListResult(); for (Request req : requests) { Opportunity opp [ SELECT Id, EinsteinScore__c FROM Opportunity WHERE Id :req.opportunityId LIMIT 1 ]; Result r new Result(); r.score opp.EinsteinScore__c; // 分数低于 40 视为高风险触发提醒 r.isHighRisk opp.EinsteinScore__c 40; results.add(r); } return results; } public class Request { InvocableVariable public Id opportunityId; } public class Result { InvocableVariable public Decimal score; InvocableVariable public Boolean isHighRisk; } }这段 Apex 的作用是把 Einstein 分数从对象字段读出来转成一个布尔标记供 Flow 使用。关键参数是 40 这个阈值它不是固定的要根据你模型的实际分布来调。调法是在 Data Manager 里看分数的直方图取 Lost 样本的中位数作为参考。如果 Lost 样本中位数是 35那阈值设 40 就偏保守会漏掉一部分风险单设 30 又太激进误报多。我一般先设中位数跑两周看销售反馈再微调。3. 把 Einstein 预测接进业务流程分配、提醒、审批三条线3.1 用 Flow 做线索分配时的分数阈值怎么定线索分配是最容易看到效果的场景。传统做法是按区域或轮询分配Einstein 上线后可以改成按分数优先分配。具体做法是在 Lead 对象上建一个 Record-Triggered Flow触发条件选「Created」或「Updated」。第一步用 Get Records 读取 Lead 的 EinsteinScore。第二步用 Decision 判断分数区间。第三步按区间走不同的分配逻辑。阈值怎么定我一般分三档80 以上走「优先分配」直接给资深销售40 到 80 走「常规分配」按区域轮询40 以下走「培育队列」进 Marketing 的培育流程。这里有个容易翻车的地方分数是异步计算的Lead 刚创建时分数可能还是空。如果 Flow 在 Created 时立刻读会读到 null。解决办法是把 Flow 的触发时机改成「Created or Updated」并且在 Decision 里加一个「分数为空则走常规分配」的分支。等分数算完后再触发一次 Updated重新分配。// Flow 里判断分数区间的公式字段写法 // 在 Formula 字段里定义分配优先级 IF( ISBLANK(EinsteinScore__c), Standard, IF( EinsteinScore__c 80, Priority, IF( EinsteinScore__c 40, Standard, Nurture ) ) )这个公式字段的作用是把连续分数转成三个离散标签供 Flow 的 Decision 元素直接使用。ISBLANK 判断处理了分数未算完的情况避免空值报错。参数上80 和 40 两个断点要根据你团队的销售容量来调——如果资深销售每天只能接 5 条优先线索那 80 以上的量就不能超过 5 条否则优先分配就失去意义。调法是先跑一周看 Priority 档的日均条数超了就往上提断点。3.2 商机风险提醒什么时候触发、提醒给谁商机风险提醒比线索分配更敏感因为它直接干预销售的跟进节奏。触发时机我一般选两个一是 CloseDate 前 7 天且分数低于阈值二是 Stage 超过 30 天没变化且分数下降超过 10 分。提醒给谁不要只给销售本人要给销售和他的经理各一份但内容不同。给销售的提醒写「这个单子建议今天跟进参考话术如下」给经理的写「这个单子风险分 32已停滞 35 天建议介入」。实现方式用 Flow 加 Email Alert或者用 Einstein Next Best Action 直接推送到销售的工作台。Next Best Action 的好处是推荐和提醒在同一个界面销售不用切来切去。-- 找出符合条件的风险商机用于批量提醒 SELECT Id, Name, OwnerId, StageName, CloseDate, EinsteinScore__c, LastStageChangeDate FROM Opportunity WHERE IsClosed false AND EinsteinScore__c 40 AND ( CloseDate NEXT_N_DAYS:7 OR LastStageChangeDate LAST_N_DAYS:30 )这段 SOQL 的作用是筛出两类风险单临近关闭日且低分的以及长期停滞且低分的。LastStageChangeDate 是自定义字段需要在对象上先建好用 Flow 在 Stage 变化时更新。参数上NEXT_N_DAYS:7 和 LAST_N_DAYS:30 是两个时间窗口前者控制「临近」的定义后者控制「停滞」的定义。我见过团队把停滞设成 14 天结果提醒太频繁销售直接忽略。30 天是个相对稳的起点。3.3 审批流里嵌入 Einstein 推荐折扣审批的实战配置折扣审批是推荐类能力最典型的落地场景。传统审批流是「销售提交折扣申请经理看金额决定批不批」。嵌入 Einstein 后审批页面上会多一条推荐「该商机历史相似单平均折扣 12%当前申请 20%建议驳回或降档」。配置步骤第一步在 Opportunity 上建一个 Approval Process入口条件选「Discount 大于 15%」。第二步在审批页面布局里加入 Einstein Recommendation 组件。第三步在 Data Manager 里建一个 Recommendation 数据集输入字段选 Amount、Stage、LeadSource输出选 Discount。第四步训练后在审批流里引用。这里的关键是推荐数据集的目标字段。折扣是连续值不是分类值所以数据集类型要选「Regression」而不是「Classification」。选错类型会导致推荐结果全是「是/否」没有具体数值。4. 避坑与排查Einstein 上线后最容易翻车的五个点4.1 分数不更新或一直为空现象Opportunity 上的 EinsteinScore 字段一直是空或者创建后几天都不变。原因最常见的是数据集没有重新训练。Einstein 的分数依赖模型模型训练是一次性的不会自动跟着新数据更新。如果数据集建好后没点过 Retrain分数就停在第一次训练的状态。解决在 Data Manager 里找到对应数据集点 Retrain。建议设一个每月提醒或者用 Scheduled Flow 每月自动触发一次。另外检查字段级安全如果运行用户的 Profile 没有读 EinsteinScore 字段的权限Flow 读出来也是空。4.2 预测结果一边倒现象所有商机的分数都在 80 以上或者都在 20 以下没有区分度。原因训练样本的标签分布太偏。如果 95% 的商机都是 Won模型会学到一个「全猜 Won」的策略因为这样准确率最高。这是分类模型的通病不是 Einstein 的 bug。解决在数据集里做样本平衡。常见做法是保留全部 Lost 样本对 Won 样本做下采样让两者比例接近 1:1。或者用「Class Balancing」选项如果 Data Manager 里有这个开关就打开。另外检查目标值定义确保 Won 和 Lost 是互斥且完整的。4.3 推荐结果和业务常识相反现象系统推荐「给这个客户发 30% 折扣」但这个客户历史上从不接受折扣只关心交付速度。原因推荐数据集的特征字段选少了模型只看到了金额和阶段没看到客户行为特征。或者特征字段里混入了未来信息比如把「最终成交价」当成了输入特征导致模型学到的是结果而不是原因。解决在数据集里加入行为类字段比如「历史 Case 数」「平均响应时长」「近 90 天 Activity 数」。同时检查输入字段列表把任何在预测时点之后才能知道的字段移出去。判断方法很简单如果这个字段的值在商机创建时还不存在它就不能当输入。4.4 权限报错导致 Flow 中断现象Flow 运行到读取 Einstein 分数的步骤时报「Insufficient Privileges」。原因Flow 的运行用户上下文没有 Einstein 相关对象的读权限。Einstein 的分数存在一个内部对象上不是直接存在 Opportunity 上Flow 读的时候需要额外权限。解决在 Setup 的 Permission Set 里给运行用户加上「Einstein Sales Analytics」或对应版本的权限集。如果 Flow 是以「System Context」运行通常不会有这个问题但以「User Context」运行就要检查。我一般建议关键 Flow 用 System Context避免权限波动导致业务中断。4.5 训练时间过长或一直排队现象点 Train 后状态一直停在 Queued几小时不动。原因数据集太大或者同时有多个训练任务在排队。Einstein 的训练资源是共享的高峰期会排队。解决先看数据集记录数如果超过百万级考虑做抽样。在 Data Manager 里可以设「Sample Size」一般取 10 万到 20 万就够。另外避开业务高峰训练我一般设在晚上或周末。如果还是排队检查是否有其他数据集在同时训练错开时间。5. 进阶用 Einstein 分数做组合策略以及怎么验证它真的有用上线一段时间后单看分数已经不够了。我一般会做两件事一是把分数和其他信号组合成策略二是用 A/B 对比验证效果。组合策略的例子分数低于 40 且近 14 天无 Activity 的商机自动进「唤醒流程」发一封模板邮件并创建 Task。分数高于 80 且 CloseDate 在 30 天内的自动进「加速流程」提醒销售申请高层拜访。这种组合用 Flow 的 Decision 加 Scheduled Path 就能做不需要写代码。验证方法上最直接的是做对照。把商机随机分成两组一组按 Einstein 分数分配一组按传统规则分配跑一个月后对比两组的 Win Rate 和平均成交周期。注意样本量要够每组至少几百条否则波动会掩盖真实差异。-- 对比实验组和对照组的 Win Rate SELECT Group__c, COUNT(Id) total, SUM(CASE WHEN IsWon THEN 1 ELSE 0 END) wins, AVG(Duration__c) avg_days FROM Opportunity WHERE ExperimentDate__c LAST_N_DAYS:30 GROUP BY Group__c这段 SOQL 的作用是拉出两组的核心指标。Group__c 是自定义字段标记实验组和对照组。Duration__c 是成交周期。参数上LAST_N_DAYS:30 控制观察窗口我一般跑满一个月再看太短的话成交还没发生数据不完整。还有一个验证角度是看销售的采纳率。如果系统推荐了「今天跟进」销售实际点了跟进的比例有多少。这个数据在 Einstein 的 Adoption Dashboard 里能看到。采纳率低于 30% 说明推荐不够准或者提醒方式不对需要回去调阈值或改推送渠道。我自己踩过的一个坑是一开始只看模型准确率觉得 85% 很高结果上线后销售根本不用。后来才明白准确率是离线指标采纳率才是在线指标。模型再准如果推荐的内容和销售当下的判断冲突他就不点。所以调模型之前先调提醒文案和触发时机让推荐出现在销售正好需要决策的那一刻。这个顺序反了后面全是白工。希望帮到你。本文还有配套的精品资源点击获取
