看送水通演示前，先把自己的订单、水票和桶账场景整理成清单，逐项核对送水通适用范围，判断哪些环节需要现场确认。
内容类型：经营建议。本文为送水通编辑整理的经营知识，具体做法请结合门店实际情况与当地要求。
先带自己的业务场景，而不是只看功能列表
看送水通演示前，最有效的准备不是列一堆想看的按钮，而是把自己水站最近一周真实发生的业务场景整理出来。演示时间有限，如果只让演示人员从头到尾讲一遍，很容易看完觉得功能很多、回来却不知道哪些和自己有关。正确做法是：先写下你店里每天重复发生的动作，再带着这些动作去逐项核对送水通的适用范围。
建议按三条线整理：订单线、水票线、桶账线。订单线记录客户从哪里下单、谁确认、谁配送、异常怎么处理；水票线记录客户买票、用票、退票、转赠的实际情况；桶账线记录满桶、空桶、押桶、欠桶在客户、水站、送水员之间怎么流转。每条线挑两三个最常出问题的场景，演示时直接问“这个场景在系统里怎么走”。
整理场景时不要只写顺利流程，更要写例外。比如客户临时改地址、送水员当天请假、客户把水票转给另一个地址使用、退桶时押金记录找不到。例外场景往往才是判断一套送水通系统是否贴合自己门店的关键。
订单场景核对清单：从下单到完成的字段
订单线要核对的是：客户下单时系统记录哪些字段，门店确认时改哪些字段，配送完成后回写哪些字段。带着你自己的订单本，逐项对照。常见需要确认的字段包括：客户名称与联系电话、送水地址与楼层、桶型与数量、预约时段、下单渠道、备注、订单状态。
重点问清楚状态流转：待确认、待配送、配送中、已完成、退单分别由谁操作、在哪个环节切换。如果你的门店经常出现客户改时段或改地址，就要现场确认修改后是否留痕、原记录是否还查得到。如果你的客户习惯电话或微信下单，要确认这些渠道的订单怎样进入系统，是否需要人工录入。
还要核对异常处理：客户拒收、送错地址、数量不符、临时取消，这些情况在系统里怎么记录、怎么和正常订单区分。演示时最好用你真实遇到过的异常场景提问，而不是泛泛地问“能不能处理异常”。
水票与桶账场景：把资产流转讲清楚
水票线的核心是分清购票人、用水人和结算对象。带着你店里实际的水票类型去核对：纸质票、电子票、赠票、单位月结分别怎么登记，核销时记录哪些信息，退票和转赠怎么处理。如果客户把家庭水票转给单位使用，要现场确认系统能否分开记录原购票人和实际用水人。
桶账线要核对满桶、空桶、押桶、欠桶四种状态在客户、水站、送水员之间的流转。带着你现在的桶账本，问清楚：客户押桶记录怎么建、退桶时怎么查押金、客户欠桶和水站欠水厂是否分开登记、送水员待交桶怎么核对。这些字段如果对不上，后续对账会很麻烦。
需要提醒的是，涉及水厂的部分要特别确认：送水通水厂版规划中，水厂相关需求目前只能作为经营方法和需求整理来讨论，不能假设系统已经具备水厂端功能。演示时如果涉及水厂对账，应明确问清楚当前版本覆盖到哪里。
相邻问题：只有一个门店的小水站要不要看演示
很多单店老板会问：我就一个门店，客户也不多，有必要看送水通演示吗？这个问题没有统一答案，但可以用上面的清单自测。如果你的订单、水票、桶账主要靠记忆和纸本，且很少出错，可以先整理需求再决定；如果已经出现水票对不上、桶账混乱、送水员交接不清，就值得带着场景去看演示。
判断标准不是门店大小，而是业务复杂度。客户数量、送水员人数、水票类型、是否有多地址客户、是否涉及单位月结，这些都会影响管理难度。演示时重点看系统能否覆盖你最痛的环节，而不是功能数量多少。
最后提醒：产品具体功能和外部渠道按实际配置与演示确认，不能从宣传材料推断。收费、试用、售后等政策也应以官方实际说明为准，不要根据演示内容自行假设。
