久享生活
六个月建设总图
团队规划会｜从 PRD 到北京首城，用统一框架对齐产品、供给、履约、组织、投入与验收。
六个月要交付的，不只是 App，
而是一套可运营的首城系统。
90 天完成交易、权益、核销与结算。
商品、仓配、商家、客服与财务同步到位。
唯一主责、关口验收、投入分账。
所有工作围绕一条主线：跑通交易—权益—到店—结算的首城闭环。
红酒交易
商品、支付、仓配、售后，建立可控的用户首单。
会员积分
购酒得积分，形成进入联盟场景的权益理由。
到店核销
商圈、套餐、预约、动态码和门店服务。
总部经营
订单、积分、分润、客服、权限与报表。
项目是否达标，以五项可运行能力判断，而不是以页面数量判断。
可交易
用户可下单、支付，积分即时入账。
可履约
仓配、物流、退款与售后可执行。
可核销
积分能在联盟门店完成体验。
可结算
分润、提现、账务与复核闭环。
可运营
商品、商家、客服、总部稳定协同。
三端不是三个独立项目，而是同一笔业务的三个工作界面。
用户 App
商城、订单物流、积分会员、商圈、预约、核销码与客服。
商家 App
扫码核销、项目、员工、多门店、分润、提现与联系总部。
总部 PC 后台
运营、招商、仓配、财务、客服、超管；角色权限分离。
一期只建五项开城能力；扩展想法进入二期池，不挤占 90 天基线。
商品、支付、冷链、退款、库存
LBS、套餐、预约、抵扣、核销
等级、账本、冻结、扣减、回冲
分润、提现、权限、报表
用户 App、商家 App、总部后台
规则先于开发：积分、分润、结算要成为可执行、可追溯、可复核的系统能力。
购酒积分
实付 1 元 = 10 分；100 分抵 ¥1；只抵异业，单笔最高抵 50%。
现金分润
成交店 70%、平台 15%、引流方 15%；积分抵扣部分不分润。
结算复核
商家申请提现，财务复核；积分调账双人复核；变更走正式流程。
所有团队最终服务于一条用户旅程；任一环节断裂都会损伤首城体验。
注册登录
账号、协议、购酒年龄确认。
选酒支付
商品、库存、地址、支付与订单。
积分到账
积分账本、等级与可用余额。
找店预约
LBS、套餐、时段与导航。
到店核销
动态码、扫码、防重复。
客服售后
IM、工单、退款与异常处理。
商家端必须成为门店每日可使用的服务与结算工具。
入驻：资质、协议、门店、项目、套餐。
培训：员工账号、预约、核销与异常流程。
运营：券单确认、总部协同、分润与提现。
六个月只跨越三个经营关口：系统可交付、首城可服务、团队可持续。
系统建设
交易履约 → 积分到店 → 结算移交
- 三端产品完成
- 真实路径验收
- 源码环境移交
开城准备
把系统接入真实的货、店、账与服务
- 商品仓配就绪
- 首批商家可核销
- 客服财务可承接
试运行与稳定运营
真实订单验证，问题闭环，形成周机制
- 受控试运行
- 异常与 SOP 修订
- 周度经营机制
开发只是一条线；公司侧资源必须沿同一时间轴并行投入。
三个开发周期都以可用业务结果验收，而不是以完成页面数量验收。
M1 · 交易与履约
登录、商品、下单、支付、亦庄发货、冷链轨迹、退款。
- 公司同步准备商品与仓配规则
- 完成账户及支付通道
M2 · 积分与到店
积分账本、商圈、套餐、预约、抵扣、动态码核销。
- 公司同步准备首批商家
- 完成套餐与店员培训
M3 · 结算与移交
分润、提现、客服、权限、报表、监控、源码环境移交。
- 公司同步准备财务客服
- 完成运营权限配置
M4 的交付不是“系统上线”，而是让货、店、账、服务达到承接用户的标准。
货
首批 SKU、库存、图文、价格、包装、出库 SOP。
店
首批商家、套餐、员工账号、核销演练、服务边界。
账
提现、复核、异常单、对账、权限与报表口径。
服务
客服坐席、话术、FAQ、工单和问题升级机制。
M5 用小范围真实订单跑通端到端流程，把问题留在放量之前。
每日记录问题，每周复盘关闭。交付物包括系统缺陷清单、SOP 修订项、商家培训补强项和异常案例库。
M6 的交付是一套每周重复运行的经营闭环，不是一次活动。
数据、问题、责任、下周动作
商品与库存
上架、库存、出库、售后
招商与门店
拓店、培训、核销质量
用户与服务
订单、权益、客服、客诉
对账与结算
分润、提现、复核、报表
项目投入要拆成三张账；开发费不是项目全部投入。
系统建设
PRD 锁定：¥1,000,000 含税，90 天，按三期结果验收。
公司基础设施
苹果、支付、短信、云、Redis、地图、物流等公司名下资源。
北京开城运营
货盘、仓配、招商、培训、客服、人员、物料与首批推广。
外部团队交付系统；公司用五个明确岗位把系统接进真实经营。
项目负责人
范围、资源、验收、问题升级与跨团队拍板
1 人 · 全周期产品对接
M1–M3：PRD、测试、验收
M4–M6：版本与周复盘
商品仓配
M1–M3：商品与规则输入
M4–M6：上架、库存、异常
招商商家
M1–M3：画像、准入、协议
M4–M6：拓店、培训、维护
财务客服
M1–M3：结算、工单规则
M4–M6：对账、客诉闭环
责任图只突出两件事：谁最终拍板，谁真正执行。
招商交付不是名单，而是可上架、可核销、可服务、可结算的联盟供给。
首批验收：用户看得到套餐、到店能核销、商家知道异常处理、财务能按规则对账。
用户下单前，要把四件事说清楚：卖什么、怎么发、多久到、出问题怎么办。
哪些酒可以卖？
确认 SKU、资质、图片文案、售价与实时库存，避免用户买到无货商品。
输出：商品上架清单订单由谁发？
明确拣货、复核、包装、出库时间、盘点和库存预警。
输出：仓库出库 SOP送哪里、多久到？
明确配送范围、冷链时效、运费、物流轨迹和破损责任。
输出：配送规则表坏了或退货怎么办？
明确拒收、破损理赔、退款时限、订单状态和积分回退。
输出：售后处理 SOP研发不是拿到 PRD 就能独立做完；三类业务答案必须按时交给研发。
研发需要知道“商品怎么卖、订单怎么履约”
需提供商品字段、价格库存、仓库、物流、退款和异常规则。
缺少时：只能做页面，无法跑真实订单。M1 起持续提供 · 商品/仓配负责人研发需要知道“积分在哪里用、门店怎么核销”
需提供商家准入、协议、项目套餐、抵扣和核销规则。
缺少时：商圈和核销只能停留在演示。M1–M4 · 招商负责人研发需要知道“用谁的账户、谁有权拍板”
需开通支付、苹果、云、短信等账户，并明确权限、财务口径和验收人。
缺少时：支付、上架或最终验收会被卡住。M1–M2 · 项目负责人风险管理不是写一句“持续关注”，而是提前约定什么时候报警、谁来处理。
开发中不断加功能
报警信号：有人要求研发直接插入 PRD 外需求。
处理动作：先登记变更，评估工期与费用，批准后再进入新基线。
主责：项目负责人系统完成但没有货和店
报警信号：M3 结束仍没有可售 SKU 或可核销套餐。
处理动作：商品、仓配、招商与开发同周推进，按月验收准备清单。
主责：业务负责人支付、上架或通知被卡
报警信号：M1 第二周仍有主体资料或账户未提交。
处理动作：建立账户清单，逐项标负责人、提交日和预计开通日。
主责：项目对接人每种会议只解决一种问题，并留下可追踪的书面结果。
解决“现在卡在哪里”
逐项检查开发、商品、商家、账户和人员准备。
留下：问题、责任人、完成日期决定“能否进入下一阶段”
看交付是否验收、风险是否可控、资源是否到位。
留下：通过 / 整改 / 暂停结论判断“这个需求现在要不要加”
评估对范围、工期、费用、测试和上线时间的影响。
留下：批准或拒绝的变更记录确认“上线后有人能接住”
确认测试、权限、客服、SOP、监控和回退方案。
留下：上线检查清单本次会需要定下三件事；其中第一件，是让所有人按同一个版本工作。
把产品需求定成研发、设计、测试共同执行的正式版本
PRD 是产品需求文档；基线就是评审通过、正式定稿、可作为开发和测试依据的版本。
每件关键工作只设一位最终负责人
项目、账户、商品仓配、招商、财务客服分别落实到具体姓名。
会后产出：RACI 责任表钱按阶段结果释放，不一次性混在一起
开发费、基础设施、开城运营分账管理；上一关验收后再进入下一关。
会后产出：投入台账 + 放行条件把今天的决定，变成三份可执行文件。
没有文件、责任人和日期的“共识”，不会自动变成项目进度。
PRD 基线版 V1.0
所有人按同一版需求开发和验收。
责任人与联系人清单
每条工作线明确唯一主责和协同人。
M1 行动与账户清单
列明任务、完成日期、前置资料和检查方式。