#!/usr/bin/env python3
"""Build traceable internal sales review, not live pipeline or published SKU facts."""
from pathlib import Path
import csv,json
from sales_analysis import load_sales
BASE=Path(__file__).resolve().parent
LOCAL=BASE.parents[1]/'config/local/delivery-project-command-center'
S=load_sales()
def csvwrite(path,fields,rows):
 with path.open('w',newline='',encoding='utf-8-sig') as f:
  w=csv.DictWriter(f,fields);w.writeheader();w.writerows(rows)
rows=[{'evidence_id':c['key'],'project':c['name'],'source_date':S['sourceDate'],'source_row':c['sourceRow'],'source_path':S['sourcePaths'][0],'fact':c['facts'],'observed_software':c['observed'],'observation_state':c['observationState'],'source_grade':c['sourceGrade'],'review_grade':c['grade'],'not_proven':c['gaps'],'freshness':'historical','allowed_use':'内部产品化候选评审；非实时状态/对外承诺'} for c in S['cases']]
csvwrite(BASE/'sales-case-evidence.csv',list(rows[0]),rows)
rows=[{k:p[k] for k in ['id','name','count','priority','buyer','trigger','promise','demo','proof','gaps','counter','next','roles','quote','accept']} for p in S['packages']]
csvwrite(BASE/'sales-offer-candidates.csv',list(rows[0]),rows)
(BASE/'sales-source-audit.json').write_text(json.dumps({'sources':S['hashes'],'case_records':S['caseCount'],'software_pending':15,'observed_pending_confirmation':13,'independent_project_count':None,'current_wecom_access':'850003 authorization expired','browser_access':'login required','commercial_status':'hypotheses; no accepted SKU/quote/margin conclusion'},ensure_ascii=False,indent=2))
text='''# 交付项目如何转成更容易成交的产品包

评审稿 · 2026-09-10 · 仅内部使用

## 先把销售主线收窄

建议先验证“职工食堂规则与结算”这条主线：把人员身份、餐次/班次、补贴、消费退款和对账组织成可重复演示与可验收的产品范围。不要一次把全部软硬件、营养、食安、AI和部署能力都装进同一个默认报价。

这是从历史项目中提出的D级产品化假设，不是已经验证的最优市场。当前缺少对应合同范围、毛利、回款、实施工时与商机漏斗，不能据此判断哪类最赚钱或给出年度收入预测。

## 这次资料能说明什么

- 使用8月28日项目产品功能矩阵28条案例记录，回查其引用的案例基表。两份文件存在继承关系，不能当成两份独立证据。
- 28条中，15条“实际软件状态”为待补证；其余13条仍为“已观察/待逐项目确认”。这说明案例池可用于找线索，但还不能直接做一份成熟产品清单。
- “城市副中心”“C08”可能为同项目不同点位，其他别名也未做全局消歧；28是记录数，不是独立客户数。
- 原行级A/B标签不证明每一项功能均启用、硬件均签收、产品均验收。只取具体记载的事实，规划/仅登记降为D，其余历史材料按B使用。
- 当前企业微信项目表CLI返回850003文档授权过期；浏览器要求登录。最新进度、当期延期、资源负荷和实际售后未完成事项尚未核实。

## 三种销售动作分开做

**向同类新客户复制：** 选择已验证的业务流程，把“一个主要购买理由 + 一条演示路径 + 一页交付边界 + 一份验收清单”带出去。先问具体问题、预算责任人和采购节点，再决定方案范围。

**向存量客户增购：** 先核实对方未启用什么、现在遇到什么问题。案例被映射到某个产品方向，不等于该客户有增购需求。未发生的需求只作为访谈假设，不列入已确认商机或收入预测。

**把交付能力变成收费服务：** 将新设备协议、指定平台适配、专属部署、迁移、驻场与维保单列核价。只有服务频率、人天、SLA、续费意愿都明确后，才讨论持续收费；不能把一笔集成项目收入当作订阅收入。

## 产品包建议与具体案例

'''
for p in S['packages']:
 cases=[c for c in S['cases'] if c['package']==p['id']]
 text+=f"### {p['name']}：{p['priority']}\n\n"
 text+=f"历史映射 **{p['count']}条案例**："+'、'.join(c['name'] for c in cases)+'。这些是候选映射，不是当前已售产品数量。\n\n'
 text+=f"**对客户怎么讲：** {p['promise']}\n\n"
 for key,label in [('buyer','买方与影响者（假设）'),('trigger','切入时机（待访谈）'),('why','为什么考虑这一方向'),('demo','建议演示路线'),('proof','成交前应补齐的证据'),('gaps','不能直接承诺'),('counter','反方检验'),('quote','报价范围建议'),('accept','验收口径建议'),('next','下一步')]:
  text+=f"- **{label}：** {p[key]}\n"
 text+=f"\n销售第一问：**{p['question']}**\n\n"
 text+='材料事实抽样：\n\n'
 for c in cases[:2]:text+=f"- {c['name']}〔{c['key']}〕：{c['facts']}；实际软件状态：{c['observationState']}。\n"
 text+='\n'
text+='''## 先挑三条演示路线，不同时建设七个大产品

以下是试行验证顺序，需由产品/销售/交付共同评审后确定：

1. **规则结算路线：** 选一个有真实交易依据的员工餐场景，验证消费、退款、补贴和对账。国信的多身份规则可以作为规则候选，但现网启用与版本仍需专项核验；不能把其他项目的交易量嫁接为国信效果。
2. **订餐取餐路线：** 以金斯瑞资料为候选，验证手机订单、厨房分单、打印、核销与退款。现有历史订单量不等于准时取餐率或厨房效率改善，需要补服务结果数据。
3. **称重自选路线：** 以国康同一餐线的现场与配置资料为候选。现场照片、配置和最终签收各证明不同的事，型号冲突未关闭前不发冻结版BOM。

菜单公示与后厨记录作为可单独验收的轻量场景/增购方向。营养持续服务先验证组织者、专业产能和付费方式。特殊部署按项目评审收费，避免免费承诺所有平台与所有外部接口。

## 报价结构与经济性验证

建议按基础产品、场景配置、专项集成、持续服务四段表达。每段写清交付物、数量、版本、责任、验收和不包含事项，客户可以只购买与本次问题相关的部分。

项目贡献的管理测算草案：合同净收入 − 硬件及外采 − 实施人天 − 定制开发 − 差旅 − 售后准备。税费、收入确认与成本归集口径由财务确认，本页不代替财务核算。

| 必须补齐的数据 | 能支持的决定 | 当前状态 |
| --- | --- | --- |
| 同类项目合同与变更范围 | 标准包包含什么、额外工作怎么收费 | 未对齐 |
| 硬件/外采实际成本 | 哪类配置可保留、哪些应换型 | 未对齐 |
| 实施/开发/售后人天 | 是否可复制、应按什么收费 | 缺连续记录 |
| 收款节点与实际回款 | 是否值得接、是否存在资金压力 | 未核实 |
| 当前有效商机与输赢原因 | 优先联系谁、卡在哪个决策环节 | 未接入 |
| 客户可公开案例授权 | 哪些客户名、照片、效果可以外发 | 逐项待核实 |

没有上述基础，不输出市场均价、毛利排名、市场份额、TAM/SAM/SOM或收入目标数字。

## 为什么不能只说“功能多、也有AI、还能出大屏”

优信无限官网同时介绍称重、视觉、订餐、进销存与食安功能，说明这些能力名称已出现在其他厂商的方案中；这只证明对方的公开产品表达，不证明其实际交付效果。[官方方案](https://www.iyouxin.com/)

帆软官网介绍数据整合与经营分析平台，说明图表和数据汇总本身也有通用工具供给。[官方经营分析方案](https://www.fanruan.com/solutions/consumer-business/)

由此提出的销售假设是：把重点放在客户同类场景下的一条完整业务演示、可控的交付边界、异常处理与验收证据。康比特的营养能力可能提供差异价值，但需要用真实服务组织、专业内容和持续交付证据补强，不能仅贴上“健康管理”标签。

## 建议用两周完成第一轮验证

该时长为建议，不是已分派任务或对外承诺。

| 步骤 | 角色建议 | 交付物 | 继续/停止条件 |
| --- | --- | --- | --- |
| 样板冻结 | 交付+产品 | 三条路线的同项目证据包 | 版本/型号/范围冲突未解，不对外承诺 |
| 异常演示 | 产品+测试 | 正常和异常操作录像、结果回读 | 演示失败或靠临时人工改数，先修复 |
| 成本复盘 | 交付+财务 | 同类项目人天、采购、变更和售后成本 | 缺关键成本，不批准标准价 |
| 买方访谈 | 销售+售前 | 买方角色、痛点、预算来源、采购节点 | 未确认经济买方，不计合格商机 |
| 小范围验证 | 销售+交付 | 客户认可的范围、验收与商业条件 | 客户只认可功能却不推进，不当成成交验证 |

本轮没有联系客户、发送材料、报价、修改企微记录或派发人员任务。

## 数据与复核入口

- `sales-case-evidence.csv`：28条案例证据与边界。
- `sales-offer-candidates.csv`：7类候选方向、买方、演示、报价与验收建议。
- `sales-source-audit.json`：源文件哈希、日期和权限状态。
- 本地大屏“产品化与销售机会”：可切换方向与点击案例；“交付经营总览”仍等待最新来源。
'''
(BASE/'sales-analysis.md').write_text(text)
LOCAL.mkdir(parents=True,exist_ok=True)
for n in ['sales-analysis.md','sales-case-evidence.csv','sales-offer-candidates.csv','sales-source-audit.json']:(LOCAL/n).write_bytes((BASE/n).read_bytes())
print('sales analysis: 7 offers, 28 evidence records')