145 lines
5.5 KiB
Markdown
145 lines
5.5 KiB
Markdown
# 首个试点画像：路边餐饮摊主与私厨服务
|
||
|
||
## 1. 文档状态
|
||
|
||
- **用途**：为原型、种子数据和流程演示提供一套可运行的虚拟内容。
|
||
- **状态**：假设数据，必须在朋友确认后替换。
|
||
- **目标**：验证“路边餐饮摊位日常经营 + 私厨定制服务”的个人品牌小程序闭环。
|
||
- **访谈结论**：订单流程、微信身份、配送、私厨报价和后台处理规则见 [07-requirements-interview-decisions.md](./07-requirements-interview-decisions.md)。
|
||
|
||
## 2. 经营者画像
|
||
|
||
经营者是一名有稳定客源的餐饮摊主，平时通过固定摊位售卖成品套餐，也接受熟客的私厨菜品定制。当前主要依靠路过客流、熟人介绍、朋友圈和聊天沟通获客。
|
||
|
||
### 当前问题
|
||
|
||
- 路过客户能看到摊位，但不了解经营者本人和菜品特色。
|
||
- 成品套餐、私厨定制和临时菜单分散在聊天记录中。
|
||
- 客户询问菜品、人数、预算和日期时，经营者需要反复沟通。
|
||
- 私厨案例和客户反馈无法长期沉淀。
|
||
- 经营者需要一个可以直接转发给客户的品牌入口。
|
||
|
||
### 期望结果
|
||
|
||
- 客户能快速了解摊主和菜品风格。
|
||
- 客户能查看日常套餐和私厨服务说明。
|
||
- 客户能提交私厨需求，减少重复沟通。
|
||
- 经营者能在后台集中查看和处理咨询。
|
||
- 通过作品和反馈逐步建立个人餐饮品牌。
|
||
|
||
## 3. 品牌定位示例
|
||
|
||
以下内容仅用于原型，不代表最终文案：
|
||
|
||
**品牌名称**：阿成家常菜 / 待确认
|
||
|
||
**一句话定位**：街边烟火味的家常菜，也为小型聚餐定制一桌热饭菜。
|
||
|
||
**品牌介绍**：每天在附近摊位制作现做套餐，主打分量足、口味家常、适合快速用餐。除日常套餐外，也承接家庭聚餐、朋友小聚和小型活动的私厨菜品定制。
|
||
|
||
**核心信任点**：现做、家常口味、可沟通调整、熟客反馈、经营者本人负责制作。
|
||
|
||
## 4. 小程序内容示例
|
||
|
||
### 4.1 首页
|
||
|
||
- 顶部：品牌头像、摊主照片或招牌照片
|
||
- 定位短句：现做家常套餐｜私厨菜品定制
|
||
- 主要按钮：查看今日套餐、预约私厨
|
||
- 代表服务：日常成品套餐、家庭聚餐私厨、小型活动定制
|
||
- 代表作品：招牌菜、聚餐案例、季节菜品
|
||
- 反馈：客户对味道、分量和服务的评价
|
||
- 联系区域：营业时间、摊位位置、微信/电话
|
||
|
||
### 4.2 服务项目
|
||
|
||
#### 日常成品套餐
|
||
|
||
- 类型：成品餐
|
||
- 价格：示例“￥18-35 / 份”，待确认
|
||
- 描述：当天现做的家常套餐，适合工作日午餐或晚餐。
|
||
- 预约方式：可咨询当日供应情况，不保证预留
|
||
|
||
#### 家庭聚餐私厨
|
||
|
||
- 类型：私厨定制
|
||
- 价格：示例“根据人数和菜单报价”
|
||
- 描述：适合家庭聚餐、生日、小型聚会，可根据人数、口味和预算沟通菜单。
|
||
- 预约方式：需要提前沟通日期、人数、地点和预算
|
||
|
||
#### 小型活动定制
|
||
|
||
- 类型：私厨定制
|
||
- 价格：示例“面议”
|
||
- 描述：适合朋友聚会、工作室活动和小型聚餐，提供菜品组合建议。
|
||
- 预约方式：提交需求后由经营者联系确认
|
||
|
||
## 5. 私厨预约字段调整
|
||
|
||
通用预约表单需要增加餐饮场景字段。第一版仍然不做支付和自动排班，但应收集足够信息，减少来回沟通。
|
||
|
||
### 必填字段
|
||
|
||
- 称呼
|
||
- 手机号或微信号至少一项
|
||
- 服务类型
|
||
- 期望日期
|
||
- 用餐人数
|
||
- 用餐地点或区域
|
||
|
||
### 可选字段
|
||
|
||
- 预算范围
|
||
- 口味偏好：清淡、辣、家常、其他
|
||
- 忌口或过敏信息
|
||
- 菜品偏好
|
||
- 其他备注
|
||
|
||
### 表单说明
|
||
|
||
页面需要明确提示：
|
||
|
||
> 提交需求后，经营者会根据日期、人数、地点和菜品要求联系确认。提交不代表预约已确认，也不产生费用。
|
||
|
||
这段说明很重要，因为第一版没有支付、自动排班和即时确认能力。
|
||
|
||
## 6. 预约状态建议
|
||
|
||
沿用通用状态，但在餐饮后台显示更容易理解的文案：
|
||
|
||
| 系统状态 | 页面文案 | 说明 |
|
||
|---|---|---|
|
||
| pending | 待联系 | 客户刚提交需求 |
|
||
| contacted | 沟通中 | 已联系，正在确认菜单或细节 |
|
||
| completed | 已完成 | 已完成本次餐饮服务 |
|
||
| cancelled | 已取消 | 客户或经营者取消 |
|
||
|
||
第一版不增加“已确认”状态，避免在没有支付和排班能力时造成履约承诺。若真实业务需要，可在试用后增加 `confirmed`。
|
||
|
||
## 7. 餐饮场景下的作品分类
|
||
|
||
- 招牌菜
|
||
- 日常套餐
|
||
- 家庭聚餐
|
||
- 小型活动
|
||
- 季节菜单
|
||
|
||
## 8. 必须向朋友确认的问题
|
||
|
||
1. 实际品牌名称和摊位名称是什么？
|
||
2. 是否允许公开摊位位置、营业时间和联系方式？
|
||
3. 私厨服务是否到客户家制作，还是统一地点出餐？
|
||
4. 是否接受外送、打包或仅现场用餐？
|
||
5. 私厨最少几人起订？
|
||
6. 通常需要提前几天预约？
|
||
7. 是否有固定价格区间或只接受咨询报价？
|
||
8. 是否存在过敏原、忌口和食品安全提示？
|
||
9. 哪些作品图片可以公开使用？
|
||
10. 客户反馈是否可以公开显示姓名或头像？
|
||
|
||
## 9. 对第一版需求的影响
|
||
|
||
此试点不改变整体产品边界，但会调整预约表单的字段。支付仍然不实现；私厨报价、订金和最终确认全部通过经营者与客户沟通完成。
|
||
|
||
如果朋友的真实业务以“日常成品套餐”为主，首页应优先展示今日/常见套餐；如果以“私厨定制”为主要增长方向，首页主按钮应优先引导私厨需求提交。这个选择需要用真实经营目标确认，而不是由系统默认。
|