把商机线索和投标项目放在同一个看板上，问题通常不在看板本身，而在两类状态的“主语”不同：发现阶段回答的是“这条线索值不值得投入”，执行阶段回答的是“这个项目走到哪一步了”。两者共用一列状态时，负责找商机的人把卡片拖到“跟进”，负责投标的人再拖到“标书编制”，中间语义就被覆盖，后来的人看不出这张卡到底在评估阶段还是执行阶段。建议的拆分方式是：发现层和执行层各用一套状态，中间只留一个明确的交接动作——“转为投标项目”。两个看板可以放在同一个工具里，但不共用状态字段。

商机发现层与投标执行层应各有独立状态集，中间只保留一个交接动作：转为投标项目。适用场景是同一团队既找商机又跟标、目前共用一个看板；操作上先冻结发现层四个状态（新发现、待确认、已转项目、已放弃），再把执行层收敛为报名、保证金、标书编制、已提交、结果；验证方式是用一周状态变更日志检查跨层修改；边界是两块看板可放在同一工具里，但状态字段不要共用。

在商机发现层只保留线索状态

发现层的状态只描述线索的评估进度，不描述投标动作。建议固定为四个，字段同时收敛：

• 新发现：从招标信息、业主沟通、渠道转介等处刚录入，尚未做资格和匹配度判断。此时只要求最少字段——来源、项目名称、线索负责人。
• 待确认：已指派专人做初步核实，需要确认招标主体、资质门槛、报名截止时间、我方能投的标段。这个状态允许停留较久，但不能跳过。
• 已转项目：已通过评估，且已在执行层建卡。这是发现层的终态，不再继续在此层流转。
• 已放弃：评估不通过或来不及投。放弃要填原因，便于后面回看。

发现层建议保留的字段：线索来源、项目名称、招标人、预计金额区间（可留空）、线索负责人、评估结论、转项目时间。不要在这层出现“保证金”“标书”这类执行字段，一旦出现，说明有人把执行层的动作提前做在了发现层。

在投标执行层只保留项目状态

执行层的状态描述的是“一个已经决定要投的项目推进到哪一步”，建议按五个节点收敛：

• 报名：已完成或正在办理报名、获取招标文件，尚未进入实质编制。
• 保证金：处理保证金缴纳或保函开立，需要记录缴纳方式与截止时间。
• 标书编制：商务标、技术标、资格文件在编写与内部评审。
• 已提交：标书已递交（线上或线下），等待开标。
• 结果：中标、未中标、废标或撤回，都落到这个状态并记录结果。

这五个状态是按“动作是否完成”划的，不用“跟进中”“处理中”这类模糊词，否则状态等于没有。执行层字段建议包括：项目负责人、投标主体、报名截止时间、保证金截止时间、递交时间、开标时间、结果。

如果两块看板放在同一个工具里，用分组或视图区分即可，不必新增状态。字段配置骨架大致如下（字段名按你实际工具替换）：

boards:
  - name: 商机发现
    state_field: lead_state
    states: [新发现, 待确认, 已转项目, 已放弃]
  - name: 投标执行
    state_field: bid_state
    states: [报名, 保证金, 标书编制, 已提交, 结果]
handoff:
  action: 转为投标项目
  require: [招标人, 报名截止时间, 投标主体, 项目负责人]

关键点是两个 state_field 不同名。同名状态字段是串台最常见的来源。

把两个看板的交接点设成‘转为投标项目’

交接点只允许一个方向：发现层 → 执行层。执行层的项目不允许被改回线索状态；如果项目确实要停，用执行层的“结果”状态记录撤回，而不是退回发现层。这样两层日志才能各自解释。

转项目时需要补齐的字段（缺项不放行）：

• 招标人、项目名称、投标主体（以谁的名义投）
• 报名截止时间、递交时间
• 项目负责人（执行层责任人，可以和线索负责人不是同一人）
• 是否已获取招标文件

确认动作建议由两个人完成：商机责任人提交转换，投标负责人确认接收。工具支持的话，把“转为投标项目”做成按钮或自动化规则，转换时自动建卡并写入项目负责人；不支持的话，至少在卡片上留一条“转项目确认人 + 时间”的评论。验证方式很直接：发现层“已转项目”的每条记录都应能在执行层找到对应卡片，执行层每张卡也都应有来源线索。

给每个状态指定唯一责任人

同一状态多人可改，是状态互相覆盖的直接原因。建议每个状态只指定一个“写入责任人”，其他人可读或评论。示例矩阵如下：

表里的更新频率是“超过就视为异常”的阈值，不是打卡要求。比如“待确认”超过设定间隔没动，责任人要给出结论——转项目或放弃，而不是让它一直挂着。

用一周状态变更日志检查串台

分层是否有效，不看配置写得多整齐，看一周日志里有没有跨层修改。状态变更日志建议至少包含：时间、卡片ID、来源看板、原状态、新状态、操作人。

{"ts":"...","card":"L-1024","board":"lead","from":"待确认","to":"标书编制","by":"user_a"}

然后做两件事：一是找“来源看板为 lead、新状态属于执行层状态集”的记录，这类就是典型串台；二是看从“已转项目”到执行层首次状态变化之间的时间点，如果间隔明显偏长，说明交接动作没有在转项目时完成，而是靠后面的人补。用一段简单筛选即可（jq 或直接在日志查询里过滤）：

# 假设日志为 JSON Lines
jq -c 'select(.board=="lead") | select(.to | IN("报名","保证金","标书编制","已提交","结果"))' status.log

如果这类记录为零，说明两层状态基本守住了边界；如果集中在某一个人身上，通常是权限配置问题，而不是习惯问题——把该人从发现层的状态写入权限里去掉，比反复提醒更有效。需要结合你们实际用的工具确认是否支持字段级权限和操作日志；做不到字段级权限时，退一步的办法是把两块看板做成两个独立视图，让默认视图只显示本层状态。