鼎味肉市DESIGN ATELIER
← 资料目录docs/design/prototypes/customer-miniapp/confirmation-window.md阅读原文

PC-03:按偏好定时间,按提前量说明配送费

原型进展:Study29按用户授权预填费用并实现体验切片;下文“未实现”为本稿形成时的背景。正式档位、报价/支付合同仍待定,演示值不得反推为批准政策。

2026-09-23 · working-draft。用户已明确服务方向及费用原则;细则未冻结,原型未实现。依据:能力台账、业务机制。历史v1保留未经批准的原假设,不再作为当前建议。

1. 用户本轮明确

当前原型只允许确认模拟明天、静态时段及配送费0元,尚不支持新规则。当日确认如何沿用已付计划、已停送安排怎样恢复仍待细化,不能继续用只确认明天排除临近确认。

2. 计算模型:不擅自填价格

提前量Δ = 用户期望送达时刻 − 有效确认时刻。

提前量 已明确 待决
大于2小时 配送费0元 有效确认时刻的技术定义
大于0且小于2小时 分档计费 档位、金额、上限、计费单位
恰好2小时 配送费0元,用户已确认 有效确认时刻的技术定义
所选时间已到或已过 未定义 替代时间与实际承接,不做负数计费

配送基准已明确为用户期望送达时刻,不是司机出发时间。例如期望18:00送达,16:00确认免费,16:00之后确认进入收费范围,具体档位待定。现有原型用时间段,如何让用户明确期望时刻仍需设计,不擅自取时间段起点或终点。有效确认究竟按提交、接受还是费用支付成功计时,以及报价有效期、服务端时钟与时区仍待定义。

3. 用户故事与动线(设计建议)

ID 用户希望 候选结果
CW-01 付完一周食材,安心离开 看清已付范围、下次行动及提前确认免配送费原则
CW-02 提前安排,按偏好收货 选时间→核对食材/地址→配送费0元→确认→明确结果
CW-03 临时决定做饭,仍能得到服务 选时间→显示分档费用→明确同意并处理费用→确认结果,不重付食材
CW-04 看到费用后考虑晚点收货 改时间→更新费用→再次明确同意,不默认改送达时间
CW-05 不接受费用,或完全没打开应用 不自动扣费、不擅自配送,其他日不受影响;食材款按计划规则处理
CW-06 提交断网,想知道成功没 核验原请求和支付结果,不重复收费或伪称确认成功
CW-07 打开时免费,操作中跨档 报价锁定或重新确认机制待定;不能静默涨价扣款
CW-08 商家改时或延误,不想被追加费用 建议不因商家延迟追收费,责任及补退政策待用户确认
CW-09 重复点击、跨设备或打开旧提醒 最新事实一致,旧报价不能直接执行,不重复发货扣款
CW-10 确认后改时间、地址或撤回 进入PC-04变更规则,补退费用条件待定,不悄悄修改原承诺

主线:已付食材 → 选择想收货的时间 → 展示食材、地址和配送费 → 用户明确同意 → 按收费规则处理与核验 → 展示已接受的日期/时间/地址 → 可以离开。

付款与接受配送的内部先后、预留与补偿尚需合同定义;支付失败、结果未知、收费成功但服务未接受必须分别有恢复或退回路径。不能把“配送费已付”当作“服务已接受”。

无需操作的支路仍然保留:无有效确认→不擅自送→记录本次结果及资金处理。两小时不能用作停送截止,实际结束条件待定。

4. 注意力与费用授权

主角是何时方便收货,不是倒计时或加急警告。选时后直接显示费用,免费也明确写0元;解释临近调度成本,不惩罚或责备用户。费用在承诺前可见,不能事后告知。可提供较晚时间,不替用户选择。

食材已付与配送费分开说明。配送费是否单独支付、能否使用计划留存款交PC-05确定;不推导自动余额抵扣,也不要求周付款时选完每天时段。拒绝提醒不影响确认,未读通知不代表同意。

5. 依次待决

  1. 已决:按期望送达时刻,提前量≥2小时免费。下一步补充:如何选择期望时刻及有效确认时刻的技术口径。
  2. 两小时内怎样分档、每档多少钱、按一次配送还是其他单位?多餐合送如何算?
  3. 报价跨档、费用支付失败/未知、确认生效时刻、改时与商家延迟如何处理?

服务范围、最晚可承接时间、原计划当天恢复也未明确。不因尽力承接掩盖真实异常,不把异常常态化成抢资格。

6. 反证与责任

需验证两小时两侧与相等、每档边界、跨日时区、报价过期、重复并发、断网支付未知、改时撤回、异常履约、通知/登录失效与权限。两小时内一律拒送、未同意加费、重复收费、收费成功却无法配送且无恢复、篡改手机时间绕过费用,都将否定方案。以上是验证计划,未执行。

设计主会话维护;用户确认政策;运营、财务、技术实施责任人未指定,仍是实施前未完成项。本轮只改文档,无代码、实际收费、数据迁移或Runtime变更。