4.4 KiB
4.4 KiB
首轮需求访谈决策
文档效力
本文记录首个餐饮试点经过访谈确认的需求。若与早期 PRD、原型或数据文档冲突,以本文为准,后续实现应同步采用这些规则。
产品目标
第一优先级是帮助经营者获得真实订单,覆盖普通套餐和私厨定制。产品方的获利、运营和平台化目标不得损害经营者的实际使用效果。
客户身份
- 品牌、服务、作品和公开反馈允许匿名浏览。
- 客户首次下单时通过
wx.login建立无感微信身份,不要求注册账号或设置密码。 - 后端通过 OpenID 识别客户,客户端不得指定其他客户身份。
- 联系方式仍由客户主动填写,用于实际履约。
- “我的订单”只展示当前 OpenID 创建的订单,不支持通过手机号查询其他微信账号的订单。
普通套餐订单
- 客户选择套餐和数量,页面展示单价和预计总价。
- 预计总价不代表支付或最终应收金额,最终线下结算。
- 保存套餐名称、单价、数量和小计快照,历史订单不受以后调价影响。
- 支持自取和配送。
- 自取填写期望取餐时间。
- 配送填写地点、宿舍楼/具体位置、期望送达时间和可选备注。
- 页面展示可编辑的配送范围说明;第一版不做地图围栏或自动可达判断。
- 客户可选择微信联系、电话联系或无需联系。
- 提交表示经营者已经收到订单请求,不表示订单已确认或已支付。
- 无法满足套餐、时间或配送要求时,经营者再联系客户。
私厨定制需求
- 私厨无法标准化报价,由经营者人工评估、沟通和报价。
- 必填:称呼、手机号或微信号至少一项、期望日期、用餐人数、用餐地点或区域。
- 选填:预算范围、口味偏好、忌口/过敏信息、菜品偏好和补充说明。
- 私厨不自动计算总价,不公开报价和沟通过程。
客户侧状态与操作
客户侧统一展示:
已收到 -> 沟通中 -> 已确认 -> 已完成
\-> 已取消
- “已确认”只表示经营者接受履约,不表示已经支付。
- 客户仅可在“已收到”状态取消。
- 客户不能直接编辑已提交订单;需要修改时取消后重新提交,或联系经营者。
- 私厨只展示粗粒度状态,不要求经营者录入菜单、报价和沟通细节。
后台处理
- 区分普通套餐订单和私厨需求。
- 支持未读标记、状态更新和内部备忘。
- 支持预设标签和管理员自定义标签,一个订单可使用多个标签。
- 建议预设标签:普通套餐、私厨、配送、自取、熟客、重点跟进。
- 标签、备忘、报价和内部沟通内容不得返回客户接口。
- 后台订单可靠落库、未读数和待处理数属于 P0。
- 微信订阅消息属于 P1;仅在主体、服务类目和模板允许时启用,发送失败不得影响订单落库。
数据模型增量
Booking 增加或明确:
customer_user_id
request_type package | private_chef
contact_preference wechat | phone | none
fulfillment_type pickup | delivery | null
requested_time
delivery_address
estimated_amount 单位为分,仅普通套餐预计金额
extra_data 受控行业扩展字段
is_read
status received | contacting | confirmed | completed | cancelled
新增:
CustomerUser:保存 OpenID 和登录时间。BookingItem:保存套餐名称、单价、数量和小计快照。Tag、BookingTag:保存预设/自定义标签及订单关联。
Booking 不包含 paid 或 payment_status。未来支付仍使用独立的 Order、Payment 和 Refund 模型。
API 增量
POST /api/customer/session/wechat
GET /api/customer/bookings
GET /api/customer/bookings/:id
POST /api/customer/bookings/:id/cancel
PATCH /api/admin/bookings/:id/read
GET /api/admin/tags
POST /api/admin/tags
PUT /api/admin/bookings/:id/tags
所有客户订单接口必须使用服务端登录态解析 OpenID。只有 received 状态允许客户取消。
待确认项
普通套餐采用固定菜单、每日菜单,还是“固定套餐 + 每日可用状态”,仍需朋友结合真实维护习惯确认。第一版不得提前实现复杂每日菜单、库存或截止时间规则。