电商crm系统管理模板：围绕数据打通开展精细化运营

电商 CRM 项目最容易出现的尴尬，不是系统里没有客户数据，而是运营看见了客户、订单和活动记录，却回答不了三个实际问题：这条客户记录对应谁、现在应该做什么、做完之后有没有效果。我的判断是，数据打通不是把更多接口接进系统，而是建立一条可核对、可执行、可复盘的业务链路。下面这套管理模板从数据源、身份匹配、运营动作和效果验收四个层面展开，示例数字均为情景模拟，不代表行业平均水平。

一、先讲核心结论：CRM 管理的重点不是“接了多少数据”

1. 数据连通只是起点，可用才算完成

我判断一个电商 CRM 项目是否真正落地，不会先问接入了几个平台、同步了多少字段，而会先追问：运营能不能用同一套规则找到目标客户？订单变化能不能及时反映到客户状态？一次运营动作能不能回到客户记录上？如果这些问题没有答案，接口再多，也可能只是把混乱从几个系统搬到一个系统里。

数据打通的交付物至少包含四项：数据源与字段目录、客户身份匹配规则、数据异常处理机制，以及能够被业务团队执行的运营流程。少了其中任何一项，后续的客户分层、自动化触达和效果评估都会受到影响。

因此，我更愿意把 CRM 项目验收分成两层。第一层是技术验收：数据是否按约定传输、更新、记录错误。第二层是业务验收：目标人群能否被正确识别、运营任务是否被执行、结果是否能按统一口径复盘。前一层回答“数据有没有进来”，后一层回答“数据有没有改变决策”。

2. 用“客户，事件，动作，结果”判断有没有闭环

我建议用一条简单链路检查 CRM 管理是否完整：客户是谁，发生了什么事件，系统或运营人员采取了什么动作，最后观察到什么结果。例如，客户完成首次购买后进入新客人群；在约定时间内收到与商品使用相关的内容；随后记录是否再次购买、是否咨询售后。每个环节都要能说明数据来自哪里、由谁维护、何时更新。

这条链路的好处是能迅速暴露“看上去已打通、实际上断点很多”的情况。客户身份无法匹配，后续动作就可能发错对象；订单状态定义不一致，复购判断就可能出错；触达记录没有回流，团队就无法判断动作是否执行；结果口径不统一，复盘就会变成各说各话。

3. 管理模板要能被业务和技术共同维护

模板不是一张字段越多越显得专业的表格。它应当让运营知道哪些条件可以用于人群筛选，让技术知道字段如何映射，让管理者知道异常由谁处理。表格里的每一项都应有明确用途；如果一个字段没有来源、维护人和使用场景，先不要急着纳入核心模型。

接下来所有清单都以“最小可用”为原则。先把一个具体场景做准确，再扩展到更多系统和人群。这样既能避免前期投入过大，也能尽早发现身份匹配、字段口径和协作机制上的真实问题。

二、背景和真实场景：数据为什么会“都在，却用不上”

1. 一次购买会在多个系统里留下不同记录

在常见电商业务中，订单、会员、客服、广告和营销活动可能分别记录在不同工具或平台。订单系统重视交易状态，会员系统关注账户资料，客服系统保留咨询过程，营销工具记录触达任务。各系统关注点不同，字段命名、更新时机和客户标识也可能不一致。

举例来说，同一位消费者可能在不同渠道使用平台账号、手机号或会员编号留下记录。订单系统显示一笔已付款订单，售后系统稍后记录退款，营销名单却仍按下单时的状态筛选。如果系统之间没有约定主键、状态变化和同步规则，运营看到的客户状态就可能过期或互相矛盾。

这类问题并不一定表现为“系统报错”。更常见的情况是页面可以打开、报表也有数字，但同一客户被重复计算，退款订单仍进入复购人群，或者运营动作执行之后没有结果回传。技术上“有数据”，不等于业务上“数据可信”。

2. 数据打通要先画数据地图，而不是先采购更多工具

我通常建议先把业务目标写在数据地图前面。例如，团队想改善新客首购后的承接，就需要知道客户何时完成首购、订单是否取消或退款、商品属于什么类别、是否发生售后，以及后续运营动作是否实际执行。没有明确场景时，列出几十个系统和几百个字段，反而容易把项目推向“先全部接入再说”。

数据地图至少要标清四类信息：数据对象、来源系统、关键字段、更新及责任机制。对订单状态这类容易出现口径差异的字段，还要额外写明业务定义。例如，“完成购买”究竟指支付成功、订单发货，还是过了退款观察期？不同定义会直接改变人群数量和复购计算。

数据地图还应写清“暂不接入什么”。例如，某个字段涉及额外授权、来源不稳定，或者暂时没有可验证的运营用途，就可以先列入待评估清单，而非直接进入 CRM 核心字段。控制接入范围不是保守，而是降低维护成本、缩短验证周期。

3. 客户身份匹配是数据链路中的关键风险点

客户匹配不能简单理解为“手机号相同就合并”。手机号可能缺失、变更，某些场景还可能存在家庭成员共用联系方式等情况。不同渠道标识之间也未必天然可互换。企业应结合业务场景、授权范围和可用字段设计匹配规则，并明确哪些情况允许自动合并，哪些情况需要人工核验。

实际管理中，我会把匹配结果分成至少三类：规则明确、可自动关联的记录；证据不足、暂不合并的记录；出现冲突、需要人工处理的记录。这样做比追求“尽量多合并”更稳妥，因为错把两个人合成一个客户，可能让订单、服务记录和营销动作全部串错。

对于涉及个人信息的收集、使用、关联和营销触达，企业需要结合适用法规、授权机制和内部合规流程进行评估。技术接口能够传输某项数据，不等于企业可以不加区分地用于所有运营目的。身份规则、访问权限和数据保留要求，应与业务、技术及合规团队共同确认。

三、拆解常见误区：为什么“系统上线”不等于运营升级

1. 误区一：接口越多，数据越完整

增加数据源会带来更多观察视角，也会带来更多字段冲突、更新依赖和故障处理工作。若来源系统的客户编号不同、订单状态不同，接入数量增加后，数据治理工作不会自动消失，反而可能更复杂。真正有价值的不是接口数量，而是关键业务问题能否由稳定、可解释的数据回答。

我的建议是先列出“场景所需字段”，再比对“当前可用字段”。对于没有明确场景的字段，先记录来源和潜在用途，不要默认它们都属于首期范围。每多接一个来源，都应同步评估权限、更新频率、字段质量、故障责任和后续维护成本。

2. 误区二：字段统一名称，就代表口径已经统一

把多个系统里的字段都命名为“订单金额”，并没有解决金额是否含运费、是否扣除优惠、退款如何处理的问题。把不同状态都归一成“已完成”，也可能掩盖业务阶段差异。口径统一必须落实到定义、计算条件和例外处理，而不止是表头相同。

我建议对关键字段使用简明的数据字典，至少记录字段定义、来源、类型、更新规则、允许空值情况、计算逻辑和责任人。对于订单状态、客户生命周期阶段、退款金额、活动归因等关键字段，还要写示例，说明边界情况如何处理。

3. 误区三：客户标签越多，精细化运营越好

标签数量并不能证明运营精细。标签若没有明确的使用者、使用场景和刷新规则，很快就会出现同义标签重复、过期标签继续使用、不同团队各自维护一套标准等问题。标签最终应该帮助团队采取不同动作，而不是成为展示客户画像的装饰。

我会要求每个核心标签都能回答五个问题：它来自什么数据、如何计算、多久更新、谁能使用、对应什么动作。若运营团队无法说明标签变化后会采取什么不同策略，该标签就不应优先进入自动化流程。

例如，“近三十天有互动”本身不是完整策略。需要进一步定义互动是指浏览、点击、咨询还是购买，活动重复触达如何去重，退订或投诉客户是否排除，标签在何时更新。定义越清楚，后续越容易复盘和纠错。

4. 误区四：上线后复购上升，就能证明 CRM 有效

业务结果会受到商品、价格、促销、季节、渠道流量、履约和售后等多种因素影响。上线后复购变化，可能与 CRM 有关，也可能同时受到促销节奏或货品变化影响。若没有对照基准和观察周期，直接把变化归因于系统，很容易高估实际效果。

较稳妥的做法是把数据质量、运营执行和业务结果分开看。先判断目标人群是否筛选准确，再确认动作是否实际执行，然后比较观察组与合理对照组的变化。若暂时不能做严格实验，也至少要记录活动条件、同期促销和异常因素，降低错误归因的风险。

四、专业判断逻辑：用一套管理模板把数据变成动作

1. 模板第一张表：数据源与字段目录

我建议把数据源清单作为整个管理模板的主表。它不只是 IT 的接口登记表，也应供运营、分析和管理者共同查看。下面的字段可以作为起点，企业可按实际系统架构增删，不应把示例当成行业统一标准。

字段目录里还要区分“源字段”和“派生字段”。源字段来自业务系统，例如支付时间；派生字段由规则计算，例如首购日期、最近购买间隔。派生字段应记录计算逻辑和版本，避免规则变化后，团队仍把新旧结果混在一起比较。

2. 模板第二张表：客户身份匹配与异常处理

身份匹配表要描述规则本身，而不是只保留一个匹配成功的结果。企业应能回答：用什么字段判断关联、匹配顺序是什么、哪些情况不自动合并、冲突由谁处理、修正记录如何留痕。若匹配规则发生变化，还要保留生效日期，便于解释历史数据的变化。

匹配率不是越高越好。如果提升匹配率的代价是更多错误合并，CRM 的风险反而会上升。建议同时跟踪匹配覆盖、抽样准确性、冲突比例和无法匹配记录的处理时长，避免只优化一个数字。

3. 模板第三张表：标签与运营场景映射

标签管理应从运营任务倒推，而不是先做一份庞大的标签库。建议每个场景单独列出目标、入选条件、排除条件、数据依赖、执行动作、观察指标和停止条件。对于会影响客户体验的自动触达，还应设计频次控制和人工兜底。

标签和动作之间应当是一对一或一对少数的清晰关系。如果同一标签被不同团队用来执行相反策略，就需要重新定义权限和业务口径。一个可维护的标签体系，往往比一个规模庞大但无人负责的标签库更有价值。

4. 模板第四张表：运营实验和复盘记录

对每一次重要运营动作，我建议保留一张轻量实验记录表。记录活动目标、人群规则、执行时间、内容版本、排除条件、观察周期、同期影响因素，以及结果口径。哪怕团队暂时没有条件做复杂实验，这些信息也能减少“记得好像有效”的主观复盘。

如果业务条件允许，可将符合条件的人群划分为触达组和暂不触达的对照组，并确保两组在关键条件上尽量可比。若无法随机分组，也可以采用相近时间段、相近商品或历史同期作为参考，但应明确其局限，不能把相关变化直接写成确定因果。

复盘不要只看点击或成交。对 CRM 运营而言，送达、退订、投诉、退款、客服咨询等反馈同样重要。短期成交变好但投诉明显增加，不一定是一个值得复制的策略。应把客户体验、业务收益和执行成本放在同一张复盘表里讨论。

五、具体案例与数据观察：用一个模拟项目检验管理模板

1. 案例背景：不是系统数量多，而是关键状态对不上

下面以一家有多个线上销售渠道的日用消费品商家为例，演示模板如何使用。该案例为情景模拟，用于说明分析方法，不是某家企业的真实经营数据，也不能据此推断行业平均水平。

假设商家每月有约 10 万笔订单，交易记录来自多个渠道；会员记录约 7.2 万条；客服系统另有咨询和售后记录。项目初期发现，同一客户可能出现多条身份记录，订单系统和会员系统对客户标识的使用方式不同；退款状态更新晚于订单同步，部分复购人群因此纳入了已经退款的订单。

团队原计划一次性导入所有历史字段。盘点后发现，首期的新客承接场景只需要客户标识、有效订单状态、商品类别、购买时间、服务状态和触达记录。于是团队把范围缩小到上述字段，先建立最小链路，再处理扩展需求。

2. 先设定检查口径，再记录基线

为了避免“做完之后才想起怎么衡量”，团队在接入前先定义四类基线：身份记录中的重复情况、订单状态核对差异、同步延迟、运营任务执行及回流完整性。下面的数据均为模拟值，基线只是该情景下的项目起点，不是外部行业基准。

这组基线提醒我们：如果团队只看“接口成功率”，可能看不到订单口径不一致、关键字段缺失和结果回流不足。系统传输成功只是链路的一段；业务数据仍需对账和抽样核验。

3. 先做一条最小链路，观察问题是否真正减少

模拟项目先完成客户身份映射、关键订单状态校准和服务状态排除，再选择新客承接作为试点。团队并未把所有互动数据都纳入首期，而是先确保首购记录能被识别、退款及取消状态能被正确处理、服务问题客户不会被错误地放入普通促销任务。

在一个月的试运行后，团队按既定抽样规则重新检查。示例结果显示，客户重复记录占比降至约 8%，订单状态抽样差异降至约 3%，关键字段缺失占比降至约 6%，运营结果回流完整率升至约 86%。这些变化说明数据治理环节有所改善，但不能单凭它们证明 CRM 带来了销售增长。

下一步才是评估运营结果。团队可以比较符合条件的触达组与未触达组，也可以先记录两组差异、活动安排和商品条件。如果触达组后续购买变化更明显，还要排查促销、库存、价格和流量变化等因素。数据质量变好是运营评估的前提，不是业务效果已经成立的证明。

4. 用九数云等分析工具时，先核对数据口径和连接边界

在多渠道经营场景中，CRM 更适合承担客户关系和运营任务管理；跨来源的数据整理、业务指标观察与经营分析，可能还需要数据分析工具配合。比如评估
九数云
这类工具时，我会先确认它能否接入企业实际使用的数据源、字段权限和更新方式是否满足需求、导出的指标能否回溯到源数据，以及异常发生后由谁负责处理。

我不会仅凭产品宣传就假定某个平台能够无缝连接全部系统，也不会把“能生成看板”当作客户身份已经打通。具体连接能力、接口限制、同步频率、版本范围和服务条件，都应以正式产品资料、实际测试和合同约定为准。选型时更应拿企业自己的字段目录和一条真实业务流程做验证。

一个实用的验证方法是选取有限范围的脱敏样本，检查源系统记录、分析结果和 CRM 运营名单是否能按同一规则解释。重点核对客户关联、订单退款状态、商品分类、统计时间范围和异常记录。若工具无法说明结果如何生成，或者业务人员不能复核计算过程，报表即使整齐，也不适合直接作为自动化决策依据。

六、落地步骤与行动建议：先验收最小闭环，再扩大范围

1. 第一步：把业务目标写成可核验的问题

项目启动时，不要只写“建设会员画像”“实现全渠道运营”。应把目标改成一个可以验证的问题，例如：新客首购后，运营能否识别正确人群并排除退款订单？售后状态是否会阻止不合适的促销触达？复购提醒能否按商品周期筛选，而不是按统一天数触发？

目标越具体，数据需求越容易收敛。每个目标都应写明目标用户、预期动作、必要数据、责任人和评估周期。如果目标没有对应的业务负责人，或没有人准备使用分析结果，就需要重新判断它是否适合进入首期范围。

2. 第二步：盘点系统、字段和维护责任

先画出客户、订单、商品、服务和营销记录分别存在哪里，再为关键字段指定权威来源。一个字段若在两个系统都有值，就要规定冲突时采用哪个来源，或者明确由谁复核。不要默认 CRM 里最后写入的值就是真实值。

在盘点阶段，应同步确认访问权限、数据用途和保留要求。对敏感字段采用最小权限原则，非必要不在运营界面展示。若企业有多个部门共同使用 CRM，还应确定谁可以建立人群、谁可以发起触达、谁能导出数据，以及相关操作如何留痕。

3. 第三步：用小范围数据完成身份和状态验收

正式扩展前，先选择能够覆盖常见情况的数据样本，检查正常购买、取消、退款、多个账户、字段缺失和状态延迟等边界。只测试“最顺利的一笔订单”容易让项目产生过度乐观的判断。样本范围和检查方法应被记录，方便后续复查。

匹配规则验收时，不只计算有多少记录成功关联，还应人工抽查关联正确性和冲突样本。状态口径验收时，则要与来源系统对账，重点检查订单变更后的更新行为。对暂时无法确认的数据，保留异常状态比强行填入一个看似完整的值更安全。

4. 第四步：选择一个场景试运行并设置停止条件

试运行应优先选择业务价值明确、数据依赖相对简单、错误影响可控的场景。上线前写清目标人群、排除规则、触达频次、执行人和观察指标，也要约定何时暂停。例如，发现退款记录进入促销人群、客户投诉超出团队设定阈值或关键字段大面积缺失时，应先停止自动执行并排查原因。

试运行期间，运营、技术和分析人员要使用同一份问题记录表。每条异常记录发生时间、受影响字段、涉及人群、处理人、修复时间和复核结果。这样才能区分问题来自源系统、同步链路、匹配规则还是运营配置，而不是把所有问题都归结为“数据不准”。

5. 第五步：建立上线后的日常治理节奏

CRM 不是一次性交付。平台字段可能变化，业务规则会调整，商品结构和运营活动也会变化。企业应设置定期检查节奏：日常监控同步失败和关键任务异常；周期性抽查身份匹配和订单状态；规则变更时更新数据字典；阶段复盘时评估标签是否仍然有用。

维护责任最好落实到角色而非笼统部门。例如，运营负责人维护场景和标签用途，数据负责人维护指标定义，技术负责人维护同步链路，服务负责人确认售后状态和排除规则。出现问题时，团队才能找到明确的处理入口。

七、指标与案例复盘：同时看数据质量、执行过程和业务结果

1. 数据质量指标：先证明运营依据可信

数据质量指标要有明确分子、分母、时间范围和样本边界。例如，关键字段完整率可以定义为“满足场景要求且非空的记录数÷该场景目标记录数”；订单状态差异率可以定义为“抽样中与权威来源不一致的订单数÷抽样订单总数”。不同企业的字段重要性不同，不能照抄一个统一阈值。

建议优先观察客户匹配准确性、关键字段完整性、重复记录比例、数据更新延迟、状态差异率和异常处理时长。指标一旦发现异常，应能追溯到具体来源和负责人。如果报表只有一个汇总数字，没有明细和异常日志，它更适合作为提示，不能作为唯一验收依据。

2. 执行过程指标：确认人群和动作有没有按设计发生

运营过程指标包括目标人群覆盖量、排除规则命中情况、任务创建与执行记录、触达结果回流和人工处理时长。它们帮助团队定位链路中的中间断点。例如，名单筛选正确但任务执行率低，问题可能在排期或权限；任务已执行但结果回流缺失，复盘就会受限。

对于自动化任务，还应记录规则版本、生效时间和变更人。否则，团队看到人群规模突然变化时，很难判断是客户行为改变、数据源更新，还是筛选条件被修改。版本管理不一定要复杂，但必须能够回答“当时用了哪一套规则”。

3. 业务结果指标：关注增量，也检查副作用

业务结果可以按项目目标选择复购、转化、客单、服务解决率或退订投诉等指标。选择指标时，不应把所有可能的结果堆在一个看板里，而要区分主要指标、约束指标和观察指标。主要指标说明目标是否达成；约束指标保护客户体验或利润；观察指标用于解释变化。

如果CRM运营要评估增量效果，优先使用可比较的观察组与对照组，并确保两组的商品、周期和促销环境尽量可比。若暂时做不到，应将结论表述为“同期观察到变化”，而不是直接宣称由 CRM 导致。业务结果具有多因素影响，诚实说明归因边界，反而更利于管理层做正确决策。

下面的情景模拟展示了为什么不能只看成交指标。假设某次触达组的短期下单率高于对照组，但退订和投诉也同时增加。此时应进一步查看人群筛选是否过宽、触达频次是否过高、内容是否符合服务状态，而不是只复制下单率较高的做法。

4. 将复盘结论写成可执行的下一轮计划

一次复盘的结论不应止于“数据还需要优化”。可以写成具体责任事项：订单退款状态由哪个系统提供权威值、下次同步检查覆盖哪些订单、身份冲突由谁复核、哪类客户暂不进入自动触达、下一轮活动采用什么比较基准。每项行动都要有负责人和复核时间。

如果某次运营未达到目标，也不一定意味着 CRM 项目失败。可能是商品不适合、触达时机不对、客群条件过宽或观察周期不足。真正有用的复盘，是能把失败定位到数据、规则、执行或业务假设中的某一层，并据此决定继续、调整还是停止。

八、不同情况下的取舍：不要用一套方案处理所有企业

1. 业务规模较小、系统较少：先重视口径和责任

如果企业系统数量有限、运营流程简单，未必需要立刻建设复杂的数据架构。先把订单状态、客户识别、关键字段和运营记录统一起来，再通过一两个高价值场景验证闭环。此阶段最大的风险通常不是技术容量不足，而是字段定义不清、没人负责维护或运营规则频繁变化。

小团队可以先用轻量表格管理数据字典和场景规则，但要避免把临时表格当成永久主数据源。数据规模上升、协作角色增加或手工核对成本持续扩大时，再评估是否需要更系统的治理和分析工具。

2. 多平台、多品牌、多团队：优先明确权威来源和权限

当企业有多个销售渠道、品牌或业务团队时，优先级应从“把数据都汇总”转向“定义哪些数据可以共享、谁有权维护、冲突由谁裁决”。如果不同团队对客户归属、订单口径和营销权限没有共同规则，集中数据并不会自动带来统一运营，反而可能扩大争议范围。

这类企业要特别关注跨系统身份匹配、权限分层、规则版本和变更管理。建议按业务线建立数据责任人，再由统一的数据治理角色维护公共字段定义。共用字段保持一致，业务专属标签则明确适用范围，避免一套标准强行覆盖所有场景。

3. 数据质量较差、历史系统复杂：先治理高影响字段

如果历史数据中重复、缺失和状态冲突较多，不建议一开始追求全量清洗。先识别哪些错误会直接导致客户被错误触达、交易被错误计算或售后被遗漏，再优先治理这些高影响字段。历史上难以准确恢复的数据，可以明确标记为未知或低可信，而不是用猜测补全。

数据治理要权衡修复成本和业务风险。某些低频字段即使不完整，对当前运营决策影响很小，可以暂缓；客户匹配、退款状态和服务问题等字段若出错会造成明显体验风险，则值得优先投入。资源有限时，按影响程度排序比“所有字段都修到百分之百”更现实。

4. 追求快速上线：用短周期试点换取更早反馈

当业务希望尽快看到结果时，可选择一个数据依赖少、风险可控、反馈周期较短的场景试点，但不能省略身份校验、排除规则和停止机制。上线快不等于跳过验收。先用小范围名单、人工复核和明确的异常兜底运行，再根据反馈逐步增加自动化程度。

如果团队没有条件保留对照组，可以先将试点定位为流程验证：确认名单是否准确、动作是否按规则触发、数据是否回流。待流程稳定后，再做业务增量评估。不要把流程验证阶段得到的观察结果包装成已被证明的增长成果。

5. 需要增加分析工具：按业务验证，而不是按功能清单选型

需要引入分析工具时，先整理真实的数据源、字段和报表问题，再选择一条业务链路验证。例如，能否解释某个客户人群的订单口径？能否追溯指标变化的计算逻辑？多角色是否能按权限访问？更新延迟是否满足运营决策需要？遇到源数据变化，维护责任是否明确？

评估像九数云这样的电商数据分析工具时，可以将产品演示和企业自己的业务样本结合。需要核实具体数据源支持情况、授权方式、同步能力、服务范围和费用条件；产品是否符合要求，以正式资料和实际测试为准。工具选型应服务于数据治理和决策流程，不能替代企业对客户身份、业务口径和合规边界的定义。

九、总结：把 CRM 当作一套持续维护的运营规则

1. 最重要的不是客户画像有多丰富

电商 CRM 的价值不在于把客户描述得多完整，而在于团队能否基于可信数据采取合适动作，并且能在动作出现问题时及时纠正。字段、标签和看板都只是中间环节；身份规则、状态口径、权限边界和复盘责任，才决定这些信息能否长期被正确使用。

我建议把“数据打通”拆成三个验收问题：能否找到正确的人，能否依据正确的状态采取动作，能否用可信的方式判断结果。任何一个问题回答不清，都应优先补规则，而不是继续堆叠更多字段和自动化流程。

2. 下一步从一张清单和一个场景开始

现在就可以先做四件事：列出当前 CRM 相关的数据源；为一个具体运营场景筛出必需字段；给身份匹配、订单状态和异常处理指定负责人；选定一个试点，并提前写下数据质量、过程执行和业务结果的观察口径。

下一步，不必追求一次性建成覆盖所有渠道的完整体系。先让一条客户数据链路可追溯、一项运营动作可执行、一次效果复盘可解释，再决定是否扩大范围。精细化运营不是“掌握更多客户数据”，而是减少错误判断，让每次运营动作都更有依据、边界和反馈。

免费注册

咨询方案

扫码咨询方案