项目启动会若只确认上线日期和名单，很快会遇到两个追问：员工问隐私时谁负责说明，测评后出现需要支持的线索时谁接手。人事、工会和EAP都参与员工关怀，却不承担同一种工作。启动会把职责写成可检查的动作，后续的通知、汇总和个别服务才不会彼此挤占。
先把项目决定和个人服务分到不同桌面
人事可以确认服务对象、组织单元、实施时间、名单来源和企业提供的支持资源。工会可以参与员工沟通、活动协同和项目反馈，关注服务是否可获得、哪些群体缺少入口。EAP服务方负责个人支持的受理、专业服务安排和需要由专业路径处理的后续工作。
启动会上要避免把“共同参与”写成共同查看。人事和工会需要的通常是项目进度、参与覆盖和足以安排资源的汇总信息；预约原因、量表作答、个人报告和会谈内容由EAP及经授权的专业人员按服务目的处理。每类材料先写接收角色、用途和保存位置，后续出现临时需求时就有可回看的基线。
用任务表替代笼统的负责人名单
一张能执行的任务表至少列出八项：确认名单、发布项目说明、发送入口、接收技术问题、处理个人服务申请、查看团体汇总、安排资源改进、处理项目结束后的查询。每项后面写一名主责人、一名必要的协作人、完成时间和可查看的资料类别。
例如，工会协助转发通知时，只需要看到通知文本、覆盖范围和反馈渠道；它不需要获得未完成名单背后的作答信息。人事复核名单时，需要处理在岗状态和组织归属；它不需要看个人测评解释。EAP收到服务申请后，可以按既定流程处理支持或转介，向项目组回传的内容保持在服务状态和资源需求层面。分工写到这一层，交接人才不会把“配合项目”理解为“可以打开全部资料”。
先约定异常由谁接住
启动会还要列出三种容易被遗漏的异常。第一种是名单或联系方式错误，由人事更正来源并通知项目管理员刷新范围。第二种是员工提出入口、隐私或服务说明疑问，由指定沟通角色提供一致答复，避免多人分别解释。第三种是出现需要尽快由专业人员联系的明确信息，接收者按既定服务流程交给EAP或指定专业人员，不在工会群或部门群里扩散。
这些规则要配一条回传边界。项目组可以知道异常是否已转交、入口是否恢复、资源是否需要增配；个人服务的具体内容不进入普通项目例会。这样既让项目有处理能力，也让员工明白求助不会自动变成管理记录。
上线前用四个账号走一遍流程
纸面分工完成后，分别用人事、工会、EAP和员工账号测试一次。人事账号应能看到自己负责的名单或项目运行信息；工会账号应只看到约定的活动和汇总范围；EAP账号应进入受控的服务任务；员工账号只看到自己的入口和报告。再测试一次人员调岗、通知退回和项目负责人请假的情形，检查任务是否能移交、旧权限是否收窄。
橙星云可将项目发放、报告查看、团体统计和角色权限置于同一项目框架中。企业在启用前仍需自行确认具体角色和服务协议的安排。启动会留下的任务表、异常路径和测试记录，会成为项目运行中判断“该由谁处理、该给谁看”的依据。