「跨境工单系统需要什么功能」这个问题，大部分团队是拿功能清单去问供应商的。清单发出去，报价回来，比参数，比功能数量，比谁家的功能多。
这个方式的问题在于：功能清单是从供应商那边来的，不是从你的业务场景来的。二十个功能里可能有三个真正在用，剩下十七个是为不存在的场景做的。
更有效的做法是先回答一个问题：工单在你的业务里到底代表什么。答案不同，需求清单完全不同。
先确定工单在你这里的三种可能身份
第一种：售后问题的记录。客户投诉、退换货、物流异常。这是最常见的理解，也最容易做成一个简单的表单系统。这种情况下真正需要的只有三件事：谁能处理、处理到哪一步、什么时候算结束。功能上不需要工作流引擎。
第二种：销售机会的容器。询盘进来、跟进中、报价、样品、成交。这类工单的核心不是「处理」而是「推进」，需要的是阶段、下一步、承诺时间。这也是为什么很多团队把 CRM 叫工单系统——它们本来就是一回事。
第三种：跨部门协作的交接。客户问题需要客服、仓储、供应链三方共同处理，工单的作用是让三方知道现在轮到谁。这类工单的重点是可见性，而不是字段。
三种身份需要的系统不同。先确定是哪一种，能砍掉大半不必要的需求。
按「谁在处理」分层，而不是按功能分层
真正有用的需求清单是按角色写的。同一个功能，对不同角色的价值完全不同：
一线处理人需要的是快。打开就能看到完整上下文、历史沟通、客户信息，不需要切换页面。一线每天处理几十条，任何多一次点击都是损失。他们不需要报表，也不需要配置权限。
团队负责人需要的是看积压。谁的队列堵了、哪种问题在反复出现、哪些客户被反复转手。这类需求不需要实时，能按小时刷新就够。
管理者需要的是追溯。谁在什么时候改了什么、这条工单的处理过程、当时是谁决定的。这类需求是事后用的，优先级最低，但缺了它出问题时就查不清。
按这个分层做需求，会发现大部分被当成「核心功能」的需求其实属于第三优先级，而一线要的「一次打开看到全部上下文」才是真正影响效率的东西。
多语言场景下必须单独提的三条
跨境团队的多语言需求不是「加个语言选项」，有三个具体的点经常被漏掉：
一，翻译不能作为唯一存储形式。 如果工单正文只存译文，那客户在三个月后说「你们当时承诺过」时，你无法回溯原文说了什么。原文和译文必须同时保留，且工单详情页上要能一键切换查看。
二，分配要按语言和能力，不按优先级。 一个西班牙语工单在队列里排第一，也不应该分给不会西班牙语的人。优先级和语言是两个独立的排序维度，工单系统的数据模型要能同时表达。
三，回复时间目标要按语言分别设定。 德语工单天然比英语工单往返更多次，用同一个响应时间目标去考核，结果只有两个：要么客服在赶时间降低质量，要么考核失效。分语言的设定逻辑在 WhatsApp 消息太多管不过来：用数据工单实现自动分配与跟进 里有展开。
评估时最容易踩的三个坑
只看演示，不看自己的数据导入。 演示用的是厂商准备好的干净数据。真正要问的是：能不能导入你现有的历史聊天记录，字段能不能对上，导入失败的部分怎么办。这一步几乎所有人都跳过，然后在上线前发现历史数据全丢。
被「AI 自动回复」吸引。 自动回复的第一版大多用于分类和转派，而不是替人回复——后者一旦出错，代价是直接的客户关系损失。分类和转派是安全的，替你说话不是。这一点在 多语言客服的翻译质量 里展开过。
忽略离开成本。 工单系统里沉淀的是客户上下文。如果合同到期而数据不能完整导出，那么前六个月的所有录入都是在给一个将来会失去的系统打工。这一条要在签约前谈，而不是等到期时再谈。
一个可以今天就做的自查
把最近 20 条真实工单拿出来，逐条回答：谁处理的、当时有没有查历史记录、最后有没有结论、结论写在哪里。
四个问题里有一个答不上来的比例超过一半，说明当前的工单系统在记录层面而不是在管理层面。管理层面的需求清单，等这一层补齐了再谈。
延伸阅读：WhatsApp 数据工单的全流程展开了工单如何承接聊天数据，聊天归属与状态设计里有对应的队列规则。
来源说明：本文参考《打造高效跨境工单系统，功能需求全攻略》（https://www.163.com/dy/article/JL5SV1F00518CPJB.html）一文，该文讨论了工单系统的功能需求。本文将需求重新按「谁在处理」与工单的三种业务身份组织，多语言场景的三条独立需求、三个评估坑与自查方法，均为我们自己的运营分析，未采用来源中的产品推荐与效果表述。