CRM采购不走弯路：一份RFP模板搞定供应商决策

在CRM采购过程中，决策常常会以可预见的方式偏离正轨。销售团队渴望管道自动化，IT部门坚持本地化部署选项，市场部需要原生邮件集成，而财务部门则质疑为何一笔20万美元的支出缺乏明确的投资回报率。当采购部门介入时，局面往往是四家供应商、三种意见、零共识。一份CRM RFP（提案请求书）能通过统一各方对“理想方案”的认知，在供应商首次演示前就解决这一乱象。本指南将带你了解如何撰写一份供应商认可的CRM RFP、各部分应包含的内容、如何公平评分，以及决策后应采取的步骤。文末还附有免费模板和评分矩阵，可直接下载并根据需求调整。

什么是CRM RFP，何时应使用？

CRM RFP（即客户关系管理提案请求书）是一份正式的采购文件，用于定义贵组织对CRM系统的需求，并邀请合格供应商提交结构化响应。它将模糊的采购意向（“我们需要更好的CRM”）转化为一份有据可查、可比较、经得起推敲的评估工具。通过预先设定评估标准，它支持客观且与利益相关者对齐的供应商筛选流程。

何时使用CRM RFP

并非所有情况都需要RFP。对于仅有五人团队和简单管道的场景，快速演示对比可能已足够。但在以下情况，正式的CRM RFP很有必要：

• 正在替换现有CRM，且涉及迁移复杂性（数据历史、集成、定制化）
• 多个部门（销售、市场、服务、RevOps）将使用该系统，且各有独特需求
• 预算需经正式采购审批（常见于中端市场和企业级交易）
• 签约前需经过法务或安全审查
• 需对比两家以上供应商，并建立一致的评估框架

CRM RFP的核心价值不在文档本身，而在流程。撰写过程迫使内部在接触供应商前就完成需求对齐。这种对齐使最终决策对管理层和将使用系统的团队都更具说服力。

RFP能提供而演示不能提供的

供应商演示往往经过精心打磨，旨在展示产品优势而非短板。CRM RFP将你的需求前置，让供应商响应你的用例而非他们的。你将获得：

• 围绕你的需求而非供应商叙事的可比响应
• 明确的范围，减少签约后关于包含内容的意外
• 基于文档化标准和评分的可辩护选择——当高管或董事会成员询问为何选择某平台时，这一点至关重要

免费下载CRM RFP模板和评分矩阵

在深入操作指南前，先获取所需工具。下载内容包括：

• 涵盖本指南全部13个部分的可编辑CRM RFP模板，含可调整的占位语言
• 供应商评分矩阵，涵盖功能适配、技术架构、集成、安全、AI能力、定价和供应商健康度等加权标准
• 一页式CRM RFP清单，确保发送前覆盖所有部分

根据组织定制模板

该模板面向评估2至5家CRM供应商的中端市场和企业级买家，但可灵活缩减。如果是较小团队：

• 若无正式审计要求，可简化或移除安全合规部分
• 将集成需求缩减至最重要的3至5个系统
• 调整评分矩阵权重以反映实际优先级（小型销售团队通常更关注易用性而非API架构）

若处于受监管行业（金融、医疗、政府），则应扩展安全合规部分，并增加供应商特定认证要求。

CRM RFP应包含的部分

一份完整的CRM RFP包括业务目标和成功标准、功能需求、技术需求和架构预期、集成需求、数据迁移和数据质量要求、安全隐私合规要求、AI能力和AI治理要求，以及供应商响应说明和提交时间表。以下是各部分的具体内容。

执行摘要和业务目标

这是供应商首先阅读的部分，为整个评估定下基调。应说明：

• 为何发布此RFP：当前配置中哪些环节出错、缓慢或缺失
• 目标是什么：具体的业务成果，而非软件功能
• 如何定义成功：判断实施成功的指标或里程碑

示例语言：“[公司]发布此RFP，旨在用统一销售、市场和服务数据的平台替换当前CRM，覆盖[X]个业务部门，将手动数据录入减少[Y]%，并支持[地区]的[Z]名用户。成功将通过管道可见性、预测准确性和新代表上岗时间来衡量。”

提示：目标不要过于模糊，否则任何供应商都能声称满足。“提高销售效率”不是可衡量目标。“上线90天内将代表数据录入时间减少30%”才是。

公司背景和利益相关者

为供应商提供足够背景，使其能做出有意义的响应：

• 公司规模、行业和地理覆盖
• 当前CRM或技术栈（正在替换什么及原因）
• 按角色划分的用户数量（销售代表、经理、管理员、服务代理）
• 参与评估的具名利益相关者，包括其角色和职责

可附上RACI或利益相关者表格，列出决策者、审批者和供应商将向其演示的人员。这也有助于供应商调整响应复杂度。

项目范围和假设

定义范围内外事项。这是防止签约后意外的重要部分。

• 被评估的模块或能力（如销售自动化、服务台、营销自动化）
• 用户数量和许可模式假设
• 推广阶段：是全面企业部署还是试点？
• 地理或监管限制（欧盟数据驻留、HIPAA、FedRAMP）
• 明确不评估的内容——例如，若营销自动化不在本次RFP范围内，应明确说明

功能需求

这通常是最长的部分，也是评分时引用最多的。功能需求定义CRM必须做什么：对团队重要的流程、自动化、报告能力和用户体验要素。按模块或用户组组织。

常见类别：

• 销售：线索和商机管理、管道阶段、活动跟踪、预测、配额管理、邮件和日历集成
• 市场（如适用）：联系人细分、活动跟踪、线索评分、表单捕获、归因
• 服务（如适用）：案例管理、SLA跟踪、知识库、客户门户
• RevOps/管理：自定义对象、流程自动化、报告和仪表板、用户权限、审计日志

使用需求表格格式。列出每个需求，标记为必须拥有、应该拥有或可有可无（MoSCoW），并留出供应商响应列（是/部分/否+评论）。

提示：在需求表格旁附上5至10个工作流特定场景。例如：“描述您的平台如何处理通过网页表单进入、分配给代表、并在管道中14天无活动的线索。有哪些自动化选项？”场景响应比勾选答案更能揭示实际产品行为。

技术需求和架构

对IT和系统团队而言，此部分与功能需求同等重要。涵盖：

• 部署模式：云（SaaS）、本地或混合
• 正常运行时间和SLA承诺：供应商保证的可用性是多少？
• 性能基准：页面加载时间、API吞吐量、数据量处理
• 移动支持：原生应用、离线能力、支持的操作系统版本
• 浏览器兼容性和可访问性标准（WCAG 2.1）
• 定制架构：平台如何处理大规模自定义字段、对象和工作流？
• 发布节奏：供应商多久推送更新？破坏性变更如何沟通？

集成需求

集成需求是许多RFP的薄弱环节：列出工具但未定义数据流。对每个集成，明确：

• 系统名称和版本
• 数据流方向（单向同步、双向、事件触发）
• 需在系统间流动的数据对象和字段
• 同步频率要求（实时、近实时、每日批量）
• 集成归属：原生连接器、中间件（Zapier、Make、Workato）或自定义API

常见CRM RFP集成类别：

• 营销自动化（HubSpot、Marketo、Pardot）
• ERP和财务（NetSuite、SAP、Salesforce CPQ）
• 通信工具（Outlook、Google Workspace、Slack、Teams）
• 支持和工单（Zendesk、ServiceNow、Intercom）
• BI和分析（Tableau、Power BI、Looker）
• 数据丰富（Clearbit、ZoomInfo、LinkedIn Sales Navigator）

示例RFP问题：“描述您与[ERP系统]的原生集成。哪些数据对象双向同步？同步延迟是多少？同步失败时有哪些监控或警报？”

数据迁移和数据质量要求

数据迁移是CRM实施中最常被低估的部分。据Gartner称，数据质量差每年给组织造成平均1290万美元的损失，而CRM迁移是公司可能运行的最高风险数据事件之一。此部分应定义：

• 迁移的数据：联系人、账户、商机、活动、附件、自定义对象、历史记录
• 数据量和年限：总记录数、历史数据追溯时长
• 数据质量基线：已知重复率、不完整字段、格式不一致
• 数据清理预期：迁移前由谁清理数据，你还是供应商？
• 验证和对账流程：如何确认迁移后准确性？
• 回滚计划：迁移失败或上线后发现数据损坏怎么办？

提示：要求供应商提供示例数据迁移计划，以及从你当前CRM迁移过来的客户参考。关于迁移简单性的供应商声明往往经不起真实数据的检验。

安全、隐私和合规

此部分对中端市场和企业买家不可妥协，也是采购和法务最严格审查的部分。涵盖：

• 数据驻留：数据存储在哪里？能否限制在特定区域？
• 加密：静态和传输中加密；密钥管理实践
• 访问控制：基于角色的访问、SSO、MFA要求
• 认证：SOC 2 Type II、ISO 27001、FedRAMP、HIPAA BAA可用性
• 审计日志：记录哪些用户操作？日志保留多久？能否导出？
• 事件响应：供应商的泄露通知SLA；漏洞沟通流程
• 子处理器列表：供应商与哪些第三方共享数据？
• GDPR/CCPA合规：数据主体请求处理、数据删除能力、同意管理

示例RFP问题：“提供您最新的SOC 2 Type II报告。描述您如何处理GDPR下的数据主体访问请求，包括响应时间承诺和数据提取或删除的技术流程。”

AI能力和治理

AI能力现已成为CRM平台的标准评估标准，但AI声明的内容差异巨大。AI治理要求涵盖控制、可解释性、可审计性和可接受使用政策。分两部分构建此部分：

第一部分：AI能力

• 原生提供哪些AI功能？（预测性线索评分、交易智能、对话智能、生成式内容、预测模型）
• 哪些数据训练模型：仅你的数据，还是供应商用户群的聚合数据？
• AI预测如何在UI中呈现？是否显示置信度分数或解释？
• 按用户角色开启或关闭AI功能的控制有哪些？

第二部分：AI治理

• 供应商是否维护AI使用政策？能否审查？
• 平台如何处理影响受监管决策（信贷、招聘、医疗）的AI生成输出？
• AI驱动操作有哪些可审计性？用户能否追溯记录被标记、评分或推荐的原因？
• 供应商如何处理模型漂移——何时重新训练模型？如何通知你？
• 若不想数据用于训练共享模型，有哪些数据退出选项？

提示：若AI治理是贵组织的董事会级关注点，可要求供应商提供书面AI伦理声明或负责任AI政策。大多数企业供应商都有；响应质量是衡量其重视程度的信号。

服务、培训和采用

实施失败很少是软件问题。麦肯锡研究一致表明，大规模技术项目最常因变更管理缺口而非技术问题失败。此部分应涵盖：

• 实施服务：谁交付实施（供应商、认证合作伙伴或混合）？典型参与模式和周期如何？
• 项目管理：供应商是否提供专职项目经理？实施工作计划如何？
• 培训：有哪些入职资源（现场培训、视频库、沙盒环境、认证项目）？
• 采用支持：供应商是否提供持续成功管理（CSM）？节奏如何？
• 支持层级：按严重程度的响应时间SLA、可用渠道（电话、聊天、邮件、社区）、专属与共享支持
• 合作伙伴生态系统：你所在地区是否有认证实施合作伙伴？

定价和商业条款

此部分看似简单，却在供应商比较中引发最多困惑。CRM定价因供应商结构不同（按席位、模块、联系人、功能层级）而难以比较。要求供应商提供：

• 3年总拥有成本（TCO）：软件许可、实施、培训、支持、集成及任何超额成本
• 定价模式说明：按席位、联系人还是统一费率？计费中“用户”如何定义？
• 模块和附加功能定价：基础层级包含什么？哪些单独定价？
• 折扣和合同灵活性：多年折扣、扩展条款、提前终止条款
• 价格保护：合同期内价格是否锁定？上调上限如何？
• 实施成本估算：固定费用还是按时计费？包含什么？

在RFP中使用标准化定价表，让每个供应商填写相同格式。这是确保商业比较公平的单一最高价值举措。

供应商响应说明

此部分告诉供应商如何准确响应。减少此处歧义可直接提高响应质量。明确：

• 响应格式：首选文件格式（Word、PDF）、页数或字数限制、必需部分
• 必需附件：安全问卷、参考列表、示例实施计划、定价模板
• 联系点：所有问题指定一位联系人；不得直接联系利益相关者
• 问题和澄清截止日期：供应商提问截止日期；答案共享给所有响应者
• 提交方式：邮件、门户或加密文件传输
• 评估标准摘要：告知供应商将按功能适配、技术能力、集成深度、安全、AI、服务和定价评分——即使不分享具体权重

RFP时间表和里程碑

清晰的时间表使流程按计划推进，并向供应商传递组织准备就绪的信号。典型CRM RFP时间表如下：

里程碑	建议时间
向供应商发布RFP	第0周
供应商提问截止	第1–2周
答案分发至所有供应商	第2–3周
提案提交截止	第4–5周
评分和入围筛选	第5–6周
入围供应商脚本化演示	第7–8周
参考核查	第8–9周
最终决策和谈判	第9–11周
合同签署	第11–12周

较小评估可压缩此时间表；企业级交易若涉及安全审查或法务修订则应延长。

如何逐步撰写CRM RFP

以上部分告诉你包含什么内容。本节带你了解如何从头构建文档。

第1步：定义目标、用例和成功标准

从业务成果而非功能开始。收集每个将使用CRM的团队（销售、市场、服务、RevOps、财务、IT）的意见，回答以下问题：

• 我们正在解决哪些具体业务问题？
• 90天时成功是什么样？12个月呢？
• 最重要的3至5个用例是什么？
• 当前配置中哪些环节出错，新CRM必须修复？

将目标记录为目标和成功标准表格。每个目标应附带指标。此表格成为执行摘要和评分标准的支柱。

提示：在撰写任何RFP语言前，与每个利益相关者群体进行结构化发现会议。每团队两小时工作坊足够。目标是共享词汇——销售和市场常使用相同词汇但含义不同（什么是“合格线索”？）。在RFP前达成一致可节省数周的来回沟通。

第2步：将目标转化为需求

目标确定后，将其转化为功能和技术需求。对每个目标，问：软件必须做什么来支持此成果？

使用MoSCoW框架：

• 必须拥有：不可妥协；不满足则取消供应商资格
• 应该拥有：重要但部分满足可接受
• 可有可无：锦上添花；缺失不影响决策
• 本阶段不拥有：明确排除在范围外

按模块（销售、市场、服务、管理）和类型（功能、技术、集成）分类需求。此结构直接映射到评分矩阵。

第3步：绘制集成和数据流

整理当前技术栈列表——每个接触客户数据的系统。对每个系统，定义是否需要与新CRM集成，并记录上文集成部分概述的数据流要求。绘制简单数据流图有助于利益相关者直观理解连接关系。即使白板草图也能很好地转化为RFP附件。此步骤的输出是集成需求表——每个集成一行，定义方向、频率和数据对象。

第4步：编写清晰的供应商说明和时间表

需求起草后，编写供应商说明和时间表。要具体。模糊的说明会产生不一致的响应，使评分更困难。

发布前确定RFP分发列表。正式评估3至5家供应商是合适范围。少于3家缺乏真正竞争；多于5家评分成为文书管理练习。

第5步：构建CRM RFP清单

发布RFP前，运行最终清单。以下为精简版：

• 执行摘要反映协商一致的业务目标
• 所有利益相关者已审查并批准需求
• 功能需求按MoSCoW和用户角色分类
• 集成需求表包含方向和频率
• 数据迁移范围和数据量已文档化
• 安全和合规要求与法律/监管基线匹配
• AI能力部分包含治理问题，而非仅功能问题
• 定价模板标准化供应商提交成本的方式
• 供应商说明明确格式、联系人和截止日期
• 时间表经采购或法务审查批准
• 评分矩阵权重在响应到达前已最终确定

最后一点至关重要：权重必须在阅读响应前锁定。看到供应商提案后调整标准会损害流程完整性。

CRM RFP评分标准和评估矩阵

CRM供应商评估矩阵将供应商响应与加权评分标准进行比较。加权评分标准通过区分“哪家供应商总体最佳”与“哪家供应商最适合我们”来提高评估的公平性和一致性。

应评分哪些类别

CRM评估矩阵的标准评分类别及典型权重范围：

类别	建议权重范围
功能需求适配	25–35%
技术架构和性能	10–15%
集成能力	10–15%
数据迁移和质量支持	5–10%
安全和合规	10–15%
AI能力和治理	5–10%
实施和服务	10–15%
定价和总拥有成本	10–20%
供应商健康度和参考	5–10%

根据优先级调整权重。高增长销售团队可能将功能适配权重设为40%，定价设为15%。受监管行业的企业可能将安全权重设为25%。

在每个类别内，按1–5分制评分：

• 5分：超出要求；在参考或产品中已验证
• 4分：完全满足要求
• 3分：满足要求但有微小差距或变通方案
• 2分：部分满足要求；存在重大差距
• 1分：不满足要求

将分数乘以类别权重获得加权分数。求和得到最终综合评分。用此构建入围名单。

如何运行入围筛选、演示和试点

初步评分后，缩小至两三家供应商进入演示阶段。演示应脚本化。为供应商提供特定场景而非开放式产品导览。

脚本化演示格式：

• 在供应商沙盒中端到端运行你的前三个用例
• 包含边缘案例或失败场景（“展示当交易停滞且代表错过跟进时会发生什么”）
• 要求实时配置——让供应商实时构建简单自定义对象或工作流
• 让各利益相关者群体的用户参与通话；演示后立即记录分数

对于高风险决策，考虑付费概念验证（POC）：有真实数据和真实用户的时间限定、范围明确的试点。POC增加时间但显著降低复杂部署的实施风险。

如何公平比较“CRM提案”定价

CRM定价易被供应商和内部倡导者操纵。为公平比较：

• 要求所有供应商填写相同定价模板（RFP中的标准化表格）
• 构建3年TCO模型，包括第一年许可+实施+集成、第二三年按合同费率许可、支持和培训成本、估算内部IT/管理员工时
• 警惕扩展触发因素：按联系人定价、存储上限、API调用限制、随规模激活的功能层级门槛
• 请求两种定价场景：当前人员编制和1.5倍人员编制，以了解成本如何扩展

CRM RFP示例供应商问题

以下示例问题可直接调整到RFP中，按类别组织以匹配评分矩阵。

功能和工作流问题

• 演示您的平台如何处理线索路由。描述逻辑选项、分配规则、轮询与加权分配。
• 您的管道管理如何支持多种管道类型（如新业务与续约）？阶段和必填字段能否因管道而异？
• 描述您的预测方法。是基于规则、AI辅助还是两者兼有？销售经理如何调整或覆盖预测？
• 您的活动源如何揭示交易风险？使用哪些信号？警报可配置程度如何？
• 描述您与Microsoft 365和Google Workspace的邮件和日历集成。是原生还是第三方？哪些内容双向同步？

集成和API问题

• 提供您的REST API文档。在估算量下速率限制如何？支持哪些认证方法？
• 是否提供与[特定ERP/MAP/支持工具]的原生集成？描述数据对象、同步频率和已知限制。
• 集成失败如何呈现和解决？是否有监控仪表板？集成支持问题的供应商SLA如何？
• 描述您的事件驱动集成（Webhooks）方法。哪些事件触发Webhooks？失败和重试如何处理？

数据迁移和质量问题

• 描述您的数据迁移方法。从[当前CRM]迁移使用哪些工具或流程？典型迁移项目包含什么？
• 原生提供哪些数据去重和丰富能力？平台如何处理迁移后创建的重复项？
• 数据导入期间进行哪些验证？系统如何呈现和处理失败或格式错误的记录？
• 提供一位从[当前CRM平台]迁移且数据量相似的客户参考。

安全和合规问题

• 提供您最新的SOC 2 Type II报告或关键发现摘要。
• 描述您如何处理GDPR下欧盟用户的数据驻留要求。
• 存在哪些基于角色的访问控制？能否为敏感数据（如薪酬、合同条款）配置字段级权限？
• 您的泄露通知SLA是什么？描述客户数据暴露事件的事件响应流程。
• 如何管理和沟通子处理器列表的变更？

AI和自动化问题

• 描述提议包中每项AI驱动功能。对每项：使用哪些数据？输出如何呈现？能否按用户或角色禁用？
• 您的AI是仅使用我们的数据，还是跨客户群聚合数据训练？有哪些退出机制？
• AI预测如何向用户解释？代表能否理解线索为何被评分为某分数？
• AI驱动自动化有哪些可审计性？管理员能否查看AI采取的操作日志及触发条件？
• 您是否有已发布的负责任AI政策？如何处理可能影响受监管决策的AI功能？

CRM RFP技巧：协调利益相关者并避免延误

RFP的技术内容相对容易——人员管理才是挑战所在。

如何防止供应商偏见

供应商偏见是CRM评估偏离正轨的最常见原因之一。当利益相关者偏爱他们曾使用过的供应商或看过特别炫酷的演示时，就会发生。为防止：

• 在任何供应商互动前锁定评分标准和权重。不要让演示改变标准。
• 尽可能盲评。让评估者在参加演示前先评分书面响应。
• 要求所有供应商沟通通过单一联系点。利益相关者与供应商代表之间不得有私下沟通。
• 使用多元化评估委员会。若仅销售评分，会偏向销售；纳入IT、RevOps以及财务或采购声音。

何时应让法务和采购介入？

比你想象的更早。常见错误：在合同阶段才让法务介入，然后发现供应商标准DPA不符合合规要求。此时你已投入六周评估时间。

在以下情况让法务介入：

• 定义安全和合规要求时（他们了解合同要求）
• 编写供应商说明时（他们可标记责任或知识产权语言问题）
• 向供应商发布RFP时（你的RFP是法律文件；供应商响应在某些司法管辖区可能构成要约）

当合同总价值超过采购阈值、项目需要正式供应商审批流程，或合同超过12个月时，让采购介入。

处理变更管理的最佳方式是什么？

变更管理并非从上线开始，而是在RFP流程中就应启动。最有效的方法是在RFP本身包含变更管理问题：要求供应商描述其用户采用方法、提供哪些变更管理资源，并分享采用曾是挑战的参考案例及解决方式。

内部方面，在每个受影响团队中确定一名变革倡导者参与评估。他们在推广期间成为内部拥护者，这比管理层自上而下的指令有效得多。

选定供应商后该做什么

工作说明书和成功计划

签约前，以书面形式定义以下内容：

• 工作说明书（SOW）：实施项目的范围、交付物、里程碑、付款条款和验收标准
• 成功计划：执行摘要中定义的3至5个业务成果，含衡量方法和目标日期
• 执行发起人对齐：确保CRM投资有可见且对结果负责的执行发起人，而非仅IT项目所有权

不要让供应商的标准SOW成为默认。使用RFP的范围部分作为基线，要求SOW映射到你声明的需求。

实施准备和数据准备

CRM实施延迟的最常见原因不是软件，而是数据。上线前：

• 在迁移前而非迁移后审计和清理数据。 识别并解决重复账户、缺失必填字段的联系人、属于非活跃用户的记录
• 映射数据模型。 当前CRM中的现有字段和对象如何映射到新平台？在数据映射电子表格中记录
• 定义配置基线。 第一天启动的最低可行配置是什么？通过锁定上线范围避免范围蔓延，将增强请求移至第二阶段积压
• 建立管理员团队。 确定上线后管理平台的内部CRM管理员，确保他们在上线前而非上线后接受培训

HubSpot Smart CRM围绕统一客户数据构建，因此销售、市场和服务部门的跨团队工作流从第一天起就基于相同的联系人和公司记录运行。这消除了多工具技术栈中最大的集成痛点之一：跨系统保持客户数据同步。

早期胜利和价值实现

规划上线后30至90天的早期胜利。这些并非关于完整ROI，而是快速展示价值以维持组织势头。良好早期胜利目标：

• 管道可见性：销售经理无需询问代表即可查看交易状态
• 活动记录：代表在CRM中记录通话和邮件（即使报告尚未构建）
• 首个自动化上线：一个工作流自动化在生产中运行，即使是简单的任务提醒自动化
• 首个跨团队工作流：一个用例中销售和市场（或销售和服务）查看相同客户数据

设定90天审查，使用成功计划指标。若早期指标正常，你就有扩展推广的证据。若异常，你能及早发现并纠正，而非12个月后。

关于CRM RFP的常见问题解答

小型团队或简单CRM项目需要RFP吗？

不一定。对于25人以下、单一用例（基本管道管理）的团队，使用演示脚本和简单评分表对两三家供应商进行结构化比较通常足够。正式RFP流程（书面供应商响应、法务审查、评分委员会）在以下情况有意义：跨职能需求、合规限制、需要采购审批的显著预算、或考虑三家以上供应商。

应邀请多少家供应商响应？

正式CRM RFP的标准建议是3至5家。少于3家限制竞争和谈判筹码。多于5家造成评分负担而无相应收益：每家额外供应商为每位评估者增加10至20小时审查工作，超过5家后响应间的边际差异趋于下降。入围筛选至两三家进入演示和试点阶段。

什么演示格式能获得最佳同类比较？

脚本化演示配标准化场景。至少在演示前五个工作日向供应商提供演示脚本。包括：你的前三个用例、一个边缘案例或异常场景、以及实时配置请求（让他们实时构建某功能）。以相同顺序、相同评估委员会在场评估相同场景。无脚本演示偏向拥有最佳讲故事者的供应商。脚本化演示偏向拥有最佳产品的供应商。

CRM RFP中定价请求应多具体？

尽可能具体。至少要求供应商填写标准化定价模板，涵盖：当前人员编制和1.5倍人员编制下的按席位或按联系人许可成本、满足声明需求所需的所有模块和附加功能成本、估算实施和入职成本、第二三年按合同费率的定价、以及支持层级成本。模糊的定价请求如“请提供您的定价”会产生无法比较的模糊响应。

何时应要求概念验证或试点？

POC在以下情况有意义：（1）部署高度复杂（大量数据迁移、众多集成、自定义对象），（2）内部对用户采用存在显著怀疑，（3）合同价值足够高，失败实施难以解除，（4）供应商参考客户与你的用例不直接可比。范围明确的POC通常运行4至6周，包含定义的成功标准清单。预期供应商会就POC范围和成本进行谈判；他们如何处理该谈判本身就具有信息量。