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