店铺运营包括哪些方面，基础课里不能只讲选品、上架、推广和数据分析，还要讲客服如何与运营、仓储、物流、商品团队一起把问题解决。客服回复得快，不代表买家的问题已经解决：系统显示有货，仓库却找不到实物；客服承诺了处理方案，运营还没确认活动规则；售后已经退款，同类问题却一周后再次出现。真正决定体验和经营效率的，往往不是某个岗位够不够努力，而是问题能不能被准确接住、交给合适的人、持续跟到结果，再回到流程中复盘。

一、先讲核心结论：客服管理的重点不是“管回复”，而是“管问题闭环”

1. 客服不是孤立岗位，而是店铺运营的前线传感器

我判断一家店铺的客服协同是否成熟，不会先看客服话术写得多漂亮，而会追问三个问题：客服发现异常后交给谁？接手的人需要哪些信息？处理结果由谁通知买家并记录？这三件事如果答不清楚，客服再勤奋，也可能只是把问题在聊天窗口里暂时压住。

客服每天接触的内容，通常包含商品理解、页面承诺、库存状态、发货履约、退款诉求、物流异常和使用反馈。它们表面上是一条条咨询，背后却对应着不同业务环节。客服能够直接处理的只是其中一部分；其余问题需要运营、仓储、物流、商品或负责人共同判断。

因此，客服管理的核心结果不是“回复完了”，而是“用户的问题有明确状态，内部问题有明确负责人，处理结果有记录，重复问题能推动改进”。这一判断也决定了本文的顺序：先明确协同对象，再设计流转规则，最后讨论指标、案例与不同规模店铺的取舍。

2. 把“回复完成”和“问题解决”分开统计

很多团队把一段对话结束、工单关闭或退款完成，直接当作问题解决。但这几个动作不一定等价。买家可能收到了一条回复，却没有得到确定方案；订单可能做了退款，但商品页面的错误描述仍然存在；仓库完成了补发，客服却没有把物流信息回告买家。

我建议至少区分四个状态：已受理、处理中、待外部确认、已闭环。状态的目的不是增加文书工作，而是让每个人都能看懂问题卡在哪里。比如“待仓库核实”必须包含接手人和预计反馈时间；“已闭环”则应意味着内部处理完成、买家已获知结果，必要的原因标签也已补齐。

3. 先建立最小闭环，再逐步增加管理动作

团队刚开始规范客服协同时，不必一次上线复杂系统或制定几十页制度。我会先要求每个跨部门问题能回答五个问题：发生了什么、目前谁负责、还缺什么信息、下一步何时反馈、最终如何告知买家。只要这五项不再依赖某个人“记得”，协作就已经从口头默契向可复用流程迈了一步。

小店可以用共享表格或现有客服工具完成记录；问题量较大时，再考虑工单、权限、自动提醒和数据看板。工具可以降低遗忘和重复录入，却不能替团队决定谁有权批准补偿、谁负责确认库存，也不能替代对问题根因的判断。

二、客服为什么总在“救火”：先看问题发生的业务场景

1. 买家只看到一个店铺，内部却往往分成多个环节

对买家来说，商品页、客服、仓库和物流都是同一家店的服务。对内部团队来说，它们可能属于不同岗位、不同班次，甚至不同外包团队。用户问“什么时候发货”，客服看到的是订单状态，仓储掌握的是实际拣货情况，运营掌握的是活动页面承诺，物流团队看到的则是包裹轨迹。任何一个环节的信息不一致，最终都会回到客服窗口。

这就是客服协同容易失灵的原因：用户的问题是连续的，内部的信息却是分散的。只要求客服“态度好一些”“主动沟通”无法弥补信息断点。团队需要把问题类型映射到具体的确认路径，并规定哪些信息能由客服直接判断，哪些信息必须由其他岗位提供。

2. 三类高频场景，最能暴露协作缺口

库存与发货场景。客服查询系统显示有货，但仓库实物不足；或者订单状态已经更新，物流信息还没有同步。此时客服若直接给出确定承诺，可能制造第二次投诉；若只回复“正在核实”，又没有约定下一次反馈节点，买家会感到被搁置。

商品与页面信息场景。买家反复询问规格、适用范围或活动条件，客服每次都靠个人经验解释。这可能不是客服培训不充分，而是商品页面信息不完整、不同渠道口径不一致，或新旧版本资料没有同步。把问题仅归为“客服不会答”，就会错过源头修复机会。

退款与异常处理场景。客服收到超出授权范围的诉求，既担心拒绝导致升级，也担心自行承诺后无法兑现。若团队没有分级权限和升级条件，客服容易反复请示，买家则不断重复描述。问题不在于员工不愿负责，而在于组织没有明确可执行的决策边界。

3. 不要用一句“加强沟通”掩盖信息链路缺失

“加强沟通”听起来正确，却没有说明沟通的对象、内容、时点和回执方式。真正能执行的协同要求应当像这样：客服收到疑似缺货问题后，登记订单号、商品规格、当前系统库存和买家诉求；仓储确认实物状态；运营核对页面承诺和活动口径；指定负责人给出处理方案；客服在约定节点向买家同步进展。

我会特别关注“是否有人确认接手”。群里发出一条消息，不等于责任已经转移。消息被看到，也不等于有人会处理。没有接手确认、处理时限和结果回传的协作渠道，本质上只是信息广播，不是工作流。

三、常见误区：看似在管客服，实际把系统性问题推给客服

1. 只考核回复速度，忽略回答是否准确、问题是否解决

首响时间是重要的过程指标，但它只回答“客服多久开始回应”，并不代表买家得到了正确方案。若团队只追求快速回复，客服可能用大量模板消息迅速接待，却没有核实订单、库存或规则；短期看响应更快，后续却可能出现重复咨询、承诺不一致和升级投诉。

我的判断是，速度类指标适合做“发现异常的入口”，不适合单独代表服务质量。应至少与解决结果、重复联系、信息准确性和合规情况一起观察。指标之间出现冲突时，要先找流程原因，而不是简单加大考核力度。

2. 把所有问题都升级，造成负责人被低价值事项淹没

另一种极端是客服遇到不确定问题就转交主管。这样看起来风险更低，实际上会让主管成为单点瓶颈，客服也失去在授权范围内判断的能力。升级机制不应等同于“凡事请示”，而应明确哪些问题由客服直接处理、哪些需要跨部门核实、哪些需要负责人审批。

可以先用三级权限划分：客服可按标准独立处理；需要业务岗位核实事实；需要主管或店长作出例外决策。每一级都应有对应信息清单。比如申请补偿时，不能只传一句“买家不满意”，还要说明订单状态、问题证据、已尝试方案和建议处理选项。

3. 责任表写了岗位名称，却没有写“动作和交付物”

“仓储负责发货、运营负责活动、客服负责售后”属于岗位说明，不是协同流程。跨部门问题需要进一步说清楚：仓储要反馈实物库存还是包裹状态？运营要确认页面口径还是审批特殊方案？客服要回告买家还是继续追踪物流？如果交付物没有写明，任务就容易变成彼此等待。

我建议责任表至少包含“受理人、事实核查人、决策人、执行人、买家沟通人、复盘归属”六个角色。小团队可以由同一个人承担多个角色，但在每个具体问题上仍要明确谁负责下一步。

4. 把每一条投诉都当成个案，不做重复问题归因

单次投诉可能只是偶发情况，但同一商品规格反复被问、同一仓库反复错发、同一活动规则反复产生误解，就不应继续逐条解释。客服记录的价值，不只是证明处理过，还在于发现问题在商品、页面、履约或规则环节的聚集。

不过，标签数量多并不意味着归因准确。客服可以标记“买家反馈疑似少件”，但最终原因可能是仓库漏装、运输破损、商品组合理解不同，或售后信息记录不全。团队应把客服标签视作线索，结合订单、包裹、商品批次和页面信息再判断，不能直接把标签当成根因。

四、专业判断逻辑：先分问题，再定责任、权限和升级路径

1. 用“问题类型、影响范围、紧急程度”完成初步分级

客服接到问题时，不应只按买家情绪强弱决定优先级。声音大不一定风险最高，语气平静也不代表影响范围小。更稳妥的判断顺序是：先识别问题属于哪类业务，再判断影响多少订单或用户，最后评估是否存在时效、资金、合规或安全风险。

例如，单笔订单的普通物流查询通常可按标准路径处理；同一批商品出现多个相似质量反馈，就需要核查批次或供应环节；页面价格、活动条件或库存承诺出现系统性错误，则应同时评估受影响范围，并由有权限的人决定是否暂停相关操作或更新口径。

2. 建立一张能指导动作的问题流转表

协同表格不必追求复杂，关键是字段足够让接手人继续工作。建议每条记录包括：问题编号、订单或商品标识、发生时间、问题分类、买家诉求、已核实事实、尚待确认事项、责任人、升级条件、下一次反馈时间、最终处理结果和复盘标签。

其中“已核实事实”和“买家诉求”必须分开写。比如“买家说包裹少了一件”是诉求描述；“订单含两件商品、仓库称重记录显示某重量、物流签收正常”才是核查事实。把二者混成结论，容易在部门间传递未经验证的判断。

3. 规定转交的“最小信息包”，降低来回追问

客服转交问题时，最好一次提供接手岗位做判断所需的信息。物流异常可以包括订单编号、发货时间、物流节点、买家反馈和当前处理动作；库存异常可以包括商品规格、系统库存、实物核查结果、活动状态和待确认的页面承诺；商品反馈可以包括型号或批次、使用条件、问题描述和可核验材料。

不同品类需要的信息不同，因此不建议照抄一套固定字段覆盖所有问题。更实用的做法是先选择本店咨询量最高、跨岗频率最高的三到五类问题，为它们分别设计信息清单，再根据实际退回补充的情况调整。

4. 为每次升级设置明确的“升级触发器”

升级应由客观条件触发，而不是只由客服个人感觉决定。常见触发条件包括：超出退款或补偿授权；同类异常在短时间内重复出现；涉及多笔订单或多个买家；现有规则无法覆盖；确认信息互相矛盾；可能涉及平台规则、消费者权益或账户安全的风险。

如果触发条件出现，客服应停止做未经确认的承诺，同时告知买家正在核实什么、下一次何时反馈。这里的“何时反馈”应依据团队可实现的处理节奏设定，不要照搬不适用于本店的统一分钟数。无法按约定时间给出最终结论时，也应提供阶段进展，而不是静默等待。

五、用模拟缺货案例看完整协同：别让客服替所有环节“猜答案”

1. 场景：系统显示有货，仓库实物却不足

下面用一个明确标注的模拟案例说明流程。某买家在活动期间下单，咨询何时发货；客服系统显示商品可售，仓储初步核查后发现实物数量不足，运营还需要确认活动页展示的库存承诺。此时客服若直接承诺当天发出，可能形成新的服务风险；若只说“稍后回复”，又没有内部责任人和反馈节点。

第一步，客服核对订单编号、商品规格、下单时间、页面承诺和当前订单状态，并把买家最关心的问题写清楚：是能否按原订单发货，还是接受其他方案。客服不先推断“仓库漏发”或“系统错误”，而是把已知事实与待确认事项分开记录。

第二步，仓储核查实物库存、已拣未发订单和同款商品的实际可用数量；运营确认活动期间库存设置、页面信息和同类订单情况。若是个别订单差异，由责任人确认单笔方案；若同款多笔订单出现相同情况，则应扩大核查范围，避免只处理眼前一单。

第三步，指定一个业务负责人汇总判断，客服作为买家沟通责任人。方案确定后，客服用清楚、可执行的语言说明当前状态、可选方案和需要买家确认的事项。内部处理结束后，记录结果和原因标签；如果发现系统库存与实物库存的同步流程有问题，则另建改进事项，不把“已联系买家”当成根因已解决。

2. 关键不在“谁背锅”，而在每个环节交付什么

这类案例常常引发部门间争论：库存是运营设置错了，还是仓库盘点不准？我更建议先把“处理用户问题”和“分析根因”分成两个工作面。处理面要尽快确定谁回应用户、谁核实事实、谁批准方案；根因面再根据库存记录、页面设置、拣货信息和订单时间线查证。

如果一开始就急着定责，团队可能只忙着解释自己的环节，买家仍然没有明确答复。反过来，如果只补发或退款，不做根因记录，同样的差错还可能继续发生。好的协同不是每次都找到一个“犯错的人”，而是让下次同类问题更容易被发现、更不容易扩散。

3. 用情景模拟数据找流程短板，不伪装成行业基准

为了让管理者知道该看什么，可以对一周内同类问题做一次小样本复盘。以下数字是情景模拟，不是行业平均值：假设共记录30起疑似缺货问题，其中12起在转交时缺少关键信息，9起没有明确接手人，6起没有按约定回告买家，3起最终确认与库存同步有关。每个问题可能同时存在多种缺口，因此各项不应简单相加成总问题数。

这组模拟观察的管理价值在于：若“信息缺失”和“责任不明”比根因本身更常见，优先改善转交字段与接手机制，可能比先采购新系统更有效；若多数问题都集中在某一商品或某个履约环节，则需要查业务源头。真正的数据要从本店记录中计算，并在复盘时保留样本范围、时间区间和分类口径。

六、客服协同看哪些指标：用组合判断替代单项排名

1. 过程指标：检查问题有没有被正确接住

过程指标关注操作是否到位，可以包括信息完整率、明确责任人比例、按约定节点反馈比例、升级信息齐全率和状态记录完整率。它们适合用来发现流程是否可执行，不宜直接当作个人绩效的唯一依据。

例如，信息完整率可以定义为：跨部门转交记录中，必填字段齐全的事项数除以跨部门转交总事项数。定义时必须说清“必填字段”有哪些、统计的工单范围是什么、跨部门事项如何识别。不同团队用不同口径，就不能拿结果直接横向比较。

2. 结果指标：观察用户问题和内部问题是否真正改善

结果层可以观察一次解决率、重复联系率、问题按期闭环率、同类问题复发率和投诉升级比例。每个指标都要区分适用范围。比如一次解决率可能受商品复杂度、物流异常和外部规则影响，不应把所有品类、所有咨询场景混在一起看。

我更看重“同类问题复发率”与“问题按期闭环率”的联动。如果按期闭环率提高，但同类问题持续复发，说明团队可能越来越快地处理个案，却没有解决源头；如果复发减少、闭环速度暂时变慢，则需要判断是不是为了查清根因而增加了核验步骤，而不是立刻认定效率下降。

3. 质量与风险指标：识别“快但错”和“省事但不合规”

服务准确性、未授权承诺率、抽检不合格率、规则风险事件和严重投诉等指标，能补充效率数据看不到的风险。对于涉及平台规定、退款处理、发货承诺和消费者权益的事项，应以发布和执行当时的官方规则为准，并由店铺指定负责人定期核对，不要把旧话术当作永久有效的规则。

管理者还应避免用单一“满意度”替代所有质量判断。满意度受买家预期、商品体验、物流和价格等多种因素影响。出现低分时要回看具体会话、订单环节和解决结果，判断问题来自沟通方式、商品本身还是履约过程。

4. 建立指标口径表，防止团队“数字对了，含义不一样”

每个指标至少应写清定义、分母、统计周期、数据来源、排除范围和责任人。比如“问题闭环时长”可以从首次受理算到内部方案完成，也可以算到买家已获知处理结果；两种口径都能用，但不能混在一起比较。

初期不用追求很多指标。我通常建议从三个层次各选一到两个：过程层选择信息完整和责任确认；结果层选择按期闭环和重复联系；风险层选择未授权承诺或抽检准确性。团队先保证数据稳定，再考虑细分到班次、品类、问题类型和渠道。

七、按团队规模落地：小店要轻，大店要有权限和审计

1. 一人多岗的小店：先把“谁接着做”写清楚

小店可能由店主兼运营，客服同时跟仓库和物流沟通。此时最常见的误区，是觉得团队小就不需要流程。实际上，人少意味着一个人缺席就可能让问题无人跟进，更需要一份简洁的责任清单。

小店可以从共享表格开始，只记录跨岗事项，不必把每条普通咨询都录入。表格设置问题编号、当前负责人、下一步动作、反馈时间、状态和结果即可。每天固定一个时间检查未关闭事项；如果问题不多，也可以由负责人在交接时逐条确认。

在小店，优先做三件事：明确客服可自行处理的边界；规定什么情况必须找店主确认；确保未完成事项在换班或下班前有人接手。先把遗漏降下来，再决定是否需要付费工具或更复杂的自动化。

2. 有客服班组和专职运营的团队：把交接从个人习惯变成机制

团队达到多个班次后，口头交接就容易产生信息损耗。此时应有统一问题分类、班次交接字段、责任人分配和超时提醒。交接不应只写“这个单子有问题”，还应写当前事实、已经联系过谁、对买家说过什么、还有什么待确认。

建议每周做一次短复盘，重点只看重复发生、影响范围较大和跨岗等待明显的事项。复盘输出必须包含后续动作、负责人和检查时间。没有负责人和检查节点的“经验总结”，通常很难转化成流程变化。

3. 多渠道或多仓团队：先统一口径，再追求自动化

当店铺涉及多个渠道、仓库或外部履约团队时，问题不只是“谁来回复”，还包括状态和数据是否一致。不同渠道的订单字段、售后规则和履约节点可能不同，先统一问题分类和状态定义，再设计自动分派。若基础口径还没对齐，自动化只会更快地把问题送到错误的人手里。

这类团队需要给异常设优先级和可视化看板，但看板应服务于决策：哪些问题等待时间最长、哪些问题影响范围最大、哪些问题反复出现。不要把客服表现简单做成公开排行榜，尤其不能忽略咨询类型、班次负荷和复杂程度差异。

4. 何时考虑工具：看重复劳动和漏跟风险，不看功能清单长短

如果团队常常找不到历史处理记录、跨部门问题靠群消息、状态没人更新、负责人变更后事项丢失，才是考虑工单或协作工具的明确信号。评估工具时，我会问：能否按问题类型分派？能否记录责任人和处理状态？能否提醒待反馈事项？能否导出数据复盘？权限和客户信息管理是否符合店铺要求？

工具选择应以现有业务流程为起点，不要因为功能多就认为更适合。先拿本店真实的十几条问题测试从受理、转交到回告的完整链路，再观察是否减少重复录入和遗漏。若上线后团队仍然不知道谁审批、谁执行，问题属于管理机制，不是换一个软件就能解决。

5. 用小规模试运行控制变更成本

新流程上线前，可以挑一种高频问题试运行一到两周，例如物流异常或商品规格咨询。期间记录每条事项的分类准确性、转交补问次数、等待节点和买家回告情况。试运行不是为了证明流程一开始就完美，而是尽早发现字段太多、责任人不清或反馈时点不合理。

如果新流程让客服录入时间明显增加，却没有减少往返沟通，应删减字段或把信息从已有系统自动带出；如果某些问题仍然频繁卡在审批环节，则要重新划分授权，而不是继续增加提醒。流程应该减少整体摩擦，而不是把记录负担全部压给客服。

八、不同情况下怎么取舍：效率、体验、成本和风险并不总能同时最优

1. 咨询量小、问题简单：保留人工判断，避免过度建设

如果日常问题量不大，且大部分能按标准流程处理，使用共享清单和固定交接可能比建设复杂工单体系更经济。需要接受的代价是自动提醒和统计分析能力较弱，因此要由明确负责人定期检查未闭环事项。

此阶段不必追求所有咨询都打标签，也不必为少量偶发问题建立多层审批。优先把高风险边界写清楚，例如谁能批准例外退款、哪些事项要核对当前规则、哪些问题必须回告买家。

2. 咨询量上升、跨岗事项频繁：优先做统一分类和责任分配

当客服经常重复询问同一信息、运营和仓储反复确认类似事项，人工协同的隐性成本已经上升。此时应先统一问题分类、转交信息包和责任人机制，再考虑自动提醒或工单系统。分类没统一，自动化规则就很难稳定；责任不清，系统也只能留下更多“待处理”记录。

如果团队人力有限，可以先对影响大、复发率高的几类事项做标准化，低频复杂事项继续人工判断。这样能在控制建设成本的同时，先解决最容易造成重复沟通的部分。

3. 高风险、影响范围大的问题：优先准确和可追溯，不以速度压过判断

涉及多笔订单、潜在质量问题、页面承诺冲突、资金或合规风险时，团队应优先确保事实核验、审批权限和记录可追溯。客服可以及时告知买家正在核查，但不应为了追求“马上给答案”而作未经确认的承诺。

需要注意，谨慎不等于沉默。买家沟通仍要有阶段进展和下次反馈时间；内部升级也要有负责人和决策节点。风险场景下，最好的速度不是最快发出一句回复，而是尽快让正确的人拿到足够信息并作出可执行判断。

4. 大促或咨询峰值：先保障分流和支援，再追求精细归因

促销期间咨询量增加，平时的协作方式可能承受不了峰值。管理者应提前准备排班、常见问题口径、异常升级通道、跨岗支援名单和库存或物流信息更新机制。临时支援人员需要拿到能快速判断的知识清单，不能只把人加进客服队列就认为完成增援。

高峰期间可以先用简化分类保证高风险事项被识别，例如常规咨询、履约异常、商品问题和需主管决策。活动结束后再补做原因归类和流程复盘。把高峰期的每个问题都要求填写复杂字段，可能会拖慢处理；但完全不留记录，又会失去复盘依据。取舍原则是先保留关键事实和责任状态，其他分析字段可以事后补齐。

5. 资源有限时，按“影响范围、复发频率、处理成本”排序

并不是每个客服问题都值得投入同等改造成本。可以用三个维度做简单排序：影响多少订单或用户；是否反复发生；每次处理需要多少人工往返。影响范围大、复发频率高且处理成本高的问题，应优先推动源头改进；偶发且影响很小的问题，可以先保留人工处理。

排序不是为了忽略个别买家的诉求，而是决定管理者先把有限的时间投入哪里。单笔问题依然要得到合理处理；流程改进则应优先减少系统性重复消耗。两者并不冲突，关键是不要把所有问题都当成同一种优先级。

九、把协同机制变成日常动作：一周内可以完成的落地顺序

1. 第一天：盘点最常见的跨部门问题

先从最近一段时间的会话、售后记录和群消息中，找出重复出现的跨岗事项。不要一上来追求覆盖所有情形，先选出频率较高、影响较大或容易升级的三到五类。若数据记录不完整，就从本周开始补齐，不要为了等一份完美历史数据而迟迟不启动。

2. 第二天：为每类问题明确第一责任人和升级条件

每一类问题确定客服受理责任、业务核查责任、决策权限和买家沟通责任。小团队可以一人多责，但必须写清当前事项由谁推进。同步列出需要升级的触发条件，避免客服每次遇到边界问题都临时找人问。

3. 第三天：设计最小信息字段和闭环状态

针对不同问题类型，列出接手人真正需要的信息。字段应能减少追问，不能只是为了“看起来规范”。状态先保留受理、处理中、待确认、已闭环等少数几种，并约定各状态何时更新、谁负责更新。

4. 第四至第五天：用真实事项试跑，记录卡点

挑选正在发生的事项跑完整流程，观察客服是否能一次性提供信息、责任人是否明确、买家是否按节点收到进展、结果是否能被复盘。出现卡点时记录具体环节，不要只写“部门沟通不畅”。例如是字段不清、权限不明、值班人缺席，还是外部物流信息无法及时取得。

5. 第六至第七天：删掉无效动作，确定复盘节奏

试运行后，删除没人使用的字段，补上反复需要追问的信息；明确哪些事项可以直接处理，哪些事项要升级。固定每周或每两周查看一次重复问题和超期事项，形成“问题、证据、原因假设、验证动作、负责人、复查时间”的简短记录。

一周落地的目标不是把流程做成最终版本，而是让团队从“凭记忆和关系协作”转向“有信息、有责任、有状态”。后续可以根据咨询量和业务复杂度逐步增加自动提醒、分类看板和服务质量抽检。

十、结语：客服协同的好坏，最终要看问题有没有离开用户的重复描述

店铺运营的基础课如果只教客服话术、考核响应速度和岗位职责，仍然没有讲透团队协同。客服真正的价值，既在于及时回应买家，也在于把一线反馈转化为运营、仓储、物流和商品团队可以行动的信息。

我认为最值得记住的判断是：问题转交不等于问题解决，内部处理完成也不等于用户已经得到答案；只有责任明确、过程可见、结果回告、重复问题被复盘，才算真正闭环。这比多设几个指标或多买一套工具更基础，也更能解释为什么一些团队回复很快，用户仍然反复追问。

下一步不必先做大规模改造。先挑一种最常见的跨部门问题，整理一张责任表，规定转交信息、接手人、反馈节点和闭环条件；运行一周后，再根据实际记录调整。只要团队能持续回答“现在谁负责、下一步是什么、何时反馈、最后是否复盘”，客服就不再是孤立的接待岗位，而会成为店铺运营中连接用户与内部流程的关键节点。

免费注册

咨询方案

扫码咨询方案