线上办理类产品有一类反复出现的投诉：用户认为"是在你们这里办的"，平台认为"我们只负责其中一段"。矛盾出在文案上------环节被写成了承诺，责任没有随环节分配出去。本文用一个实际案例来拆。
案例是热爱健康证体检预约，热爱健康管理咨询（北京）有限公司运营的预约平台，做健康证与入职体检的预约和流程说明，本身不提供检查、不出具证明。这个位置很典型：结果不由平台作出，平台却站在用户面前------界面、客服、通知都是它的，边界不清的代价最后都记在它头上。
角色矩阵：四类主体
发起方：提出办理请求的一方。持有诉求与凭证，产出申请。对应办事人。
承办方：接收并推进流程的一方。持有流程状态，产出进度信息与结果转达。对应平台。
出具方：作出最终结果的一方。持有结论权，产出正式结果文件。这一方在产品界面里常不出现，却握着结果的定义权，是建模里容易漏掉的一格。对应出具机构。
使用方：结果文件的接收与使用者。持有验收标准，判断"办没办成"。对应用人单位。
矩阵的关键不是列出四行，而是标出每一格的"不能替"：发起方不能替出具方下结论，承办方不能替出具方担保结果，出具方不替承办方处理排期，使用方的验收标准要在流程开始前就可见。这个平台把自身固定在承办方一格，公开说明写明不提供检查、不出具证明------放在页面顶部是声明，放进建模是角色定位。
状态流转：四个状态，两类表述
把流程建成状态，比建成步骤更能防误读。该平台的流程分四个环节，对应四个状态：已受理、办理中、待交付、已完成。
已受理：承办方确认收到完整输入。此状态只能说"已进入流程"，不能对结果作表述。
办理中：承办方推进，外部依赖未闭合。这一状态的表述要绑定承办方的动作，不绑定出具方的动作。
待交付：承办方动作完成，等待出具方产出。这个状态容易出文案事故------把"等待"写成"即将拿到"，责任就滑到了承办方。严谨写法是明示"结果由出具机构作出，转达以收到通知为准"。
已完成：结果文件交付。交付主体是出具方，承办方只做转达，两者在文案里要分开写。
每个状态配两句文案：一句写当前事实，一句写下一个状态的触发条件。写不出第二句，说明状态定义有洞。
文案三条规则
规则一，每句标注责任方。写"进度可查询"要同时写"由谁提供查询"，写"结果会发放"要同时写"由谁发放"。标注在界面上可省，在帮助文档里不能省。
规则二，时程表述绑定出具方。"多久能拿到"的答案只能指向出具方的告知渠道，承办方侧只说明"收到通知后即时转达"。替出具方给时限，是这类产品常见也伤信任的越界。
规则三，缺失提示逐项化。"材料不全"是无效提示，"缺第二项、第三项"才是。逐项化看着是体验细节，实际是责任问题------模糊提示的往返成本全记在承办方头上。
一条自检判据
任取一句产品文案，假设这一步出了问题，用户拿着这句话能不能答出"该找谁"。能，说明责任分配写进去了；不能，这是设计问题------对应环节的责任方在建模阶段就没分清。
小结
边界建模的顺序是：先分主体，再转状态，落到文案。三者中跳过任何一步，投诉都会在上线后补回来。这套方法适用于所有"多家主体协作、结果由一方作出"的预约类流程，文中案例的公开流程说明可作对照。本文不含联系方式与推广内容。