需构建支持多部门协作与SLA监控的售后工单系统，核心包括：一、基于角色与部门的自动路由机制；二、工作日历驱动的SLA倒计时引擎；三、JSON Schema驱动的多级审批流程；四、状态机约束的不可逆流转；五、复合索引与乐观锁保障高并发性能。
如果您计划使用PHP构建一个支持多部门协作流转并具备SLA时效监控能力的售后工单系统，则需围绕工单生命周期管理、部门路由规则、时间节点追踪与状态变更审计进行核心设计。以下是实现该平台的关键构建路径：
一、基于角色与部门的工单路由机制
该机制确保工单能根据预设规则自动分派至对应部门或处理人，避免人工干预导致的延迟与错配。需在数据库中建立部门表、岗位表、用户-部门关联表，并在工单创建/转交时触发路由判断逻辑。
1、定义部门编码与优先级字段，例如：tech_support（技术部）、billing（财务部）、cs（客服部），并为每个部门配置默认处理组ID。
2、在工单提交接口中，依据问题类型、关键词匹配或客户等级，查询路由策略表获取目标部门ID。
立即学习“PHP免费学习笔记（深入）”；
3、调用分配函数将工单状态设为“已分派”，同时写入assign_to_dept_id与assign_time字段，并向该部门负责人推送站内通知。
4、当工单被手动转交时，校验当前用户是否具备转出权限，并记录transfer_from_dept_id、transfer_to_dept_id及transfer_time。
二、SLA时效规则引擎与倒计时存储
SLA监控依赖于可配置的响应与解决时限策略，需将规则与工单实例绑定，并通过定时任务或状态变更钩子实时更新剩余时间。所有时限计算必须基于工作日历排除节假日与非工作时段。
1、在slas表中定义规则项，包含sla_name、start_status、target_status、time_limit_minutes、is_working_day_only、holiday_list_json等字段。
2、工单进入start_status时，调用calculate_sla_deadline()函数生成deadline_at时间戳，并存入ticket_sla表的deadline_at字段。
3、每次工单状态变更前，检查当前时间是否超出deadline_at；若超时，则自动将sla_status设为“已逾期”，并触发告警事件。
4、在工单详情页前端，通过AJAX轮询ticket_sla表中的remaining_seconds字段，动态渲染距离SLA截止还剩0天4小时12分样式倒计时。
三、多级审批与跨部门协同流程建模
为适配复杂售后场景，系统需支持串行审批、并行会签、条件分支等流程模式。流程定义应与具体工单解耦，采用JSON Schema描述节点行为，由统一引擎解析执行。
1、在process_definitions表中保存流程模板，例如：{"name":"硬件故障升级流程","nodes":[{"id":"n1","type":"assign","dept":"tech_support"},{"id":"n2","type":"condition","expr":"$ticket.priority == 'high'"},{"id":"n3","type":"assign","dept":"senior_tech"}]}。
2、工单创建时选择模板ID，系统自动初始化process_instances记录，并将当前节点设为n1，status为“待处理”。
3、处理人完成操作后，调用engine_execute_step()传入当前节点ID与操作结果，引擎依据schema跳转至下一节点或终止流程。
4、所有节点操作均写入process_logs表，包含node_id、operator_id、action_time、result_data，供后续审计与SLA归因分析使用。
四、工单状态机与不可逆变更约束
状态流转必须遵循预定义的有向图结构，防止非法跳转（如从“已解决”直接回到“新建”）。每个状态需明确允许的下一状态集合，并在更新前强制校验路径合法性。
1、在ticket_statuses表中定义全部状态码及其名称，例如：0→新建、10→已受理、20→处理中、30→需客户反馈、40→已解决、50→已关闭。
2、在ticket_status_transitions表中声明合法转移对，如from_status=10, to_status=20, is_allowed=1；from_status=40, to_status=50, is_allowed=1。
3、在update_ticket_status()方法中，先查询transition表确认from_status与to_status组合是否存在且is_allowed=1，否则抛出异常并返回状态变更不合法：当前不可从【已受理】跳转至【已关闭】。
4、每次成功变更后，在ticket_history表插入一条记录，含old_status、new_status、changed_by、changed_at，用于追溯全生命周期轨迹。
五、MySQL索引优化与高并发写入保障
随着工单量增长，查询响应与状态更新延迟将成为瓶颈。需针对高频查询字段和外键关系建立复合索引，并采用乐观锁机制应对多部门并发操作同一工单的冲突场景。
1、在tickets表上创建联合索引：KEY idx_dept_status_time (assign_to_dept_id, status, created_at)，加速部门视图与超期工单扫描。
2、为ticket_sla表添加KEY idx_ticket_sla (ticket_id, sla_name)，支撑SLA规则快速绑定与更新。
3、在更新工单状态SQL中加入version字段比对：UPDATE tickets SET status=?, updated_at=?, version=version+1 WHERE id=? AND version=?，若影响行为0则重试或提示工单已被他人修改，请刷新后重试。
4、对process_logs与ticket_history表启用分区策略，按created_at字段按月划分，提升历史数据归档与查询效率。
