美洽的客服软工单通常由一组核心字段组成：工单编号、客户信息（姓名、联系方式、用户ID）、渠道来源、问题分类、优先级、状态、处理人、创建/更新时间、对话记录、附件、标签、满意度、内部备注与工单历史，此外还支持丰富的自定义字段以满足电商订单、退款、物流等场景的扩展需求。
先说为什么这些字段重要
用通俗的话讲，工单字段就是客服工作的“元数据”，每一项都承载着判断、分配和追踪的依据。想把一件事从“顾客抱怨”变成“问题解决”，需要把信息结构化；字段做的，就是把对话和业务上下文变成可以被自动化、统计和审计的东西。说白了，字段越清晰，服务越高效，数据越可靠。
核心字段一览（概念先行）
下面先把常见字段按用途分组列出来，方便你快速对照自己的需求：
- 标识与时间：工单编号、来源会话ID、创建时间、更新时间、预计解决时间、SLA截止时间。
- 客户与业务信息：客户姓名/昵称、客户ID、联系方式（邮箱/电话）、国家/语言、账号/企业信息、订单号、商品SKU等。
- 问题与分流：渠道来源（微信/邮件/网站/跨境平台）、问题分类/子类、标签、优先级、来源URL或商品页面。
- 处理与跟踪：当前状态（新建/处理中/待客户/已关闭）、处理人/团队、处理历史、转接记录、合并记录。
- 内容与证据：对话记录、留言内容、附件（截图/发票）、内部备注、客服评分/满意度。
- 自定义与扩展：业务自定义字段，例如退款金额、物流单号、售后类型、合规标签等。
用表格更直观地看常用字段（含说明与典型格式）
| 字段名（UI） | 说明 | 典型格式 / 取值 |
| 工单编号 | 系统分配的唯一标识，用于检索和引用 | 字符串，例如：MQ-20250301-000123 |
| 客户ID | 内部用户主键，关联用户画像与历史 | 数字或UUID |
| 客户联系方式 | 电话、邮箱或第三方账号 | +86-139xxxxxx / [email protected] |
| 渠道来源 | 会话来源，便于拆分与规则分配 | web/微信/WhatsApp/邮件/工具类平台 |
| 问题分类 | 用于统计、路由与知识库检索 | 订单问题/退款/物流/技术 |
| 优先级 | 影响工单排队与SLA处理顺序 | 高/中/低 或 数值 1-5 |
| 状态 | 工单生命周期状态 | 新建/处理中/待客户/已关闭/已转接 |
| 处理人 | 当前负责人或团队 | 用户名或团队名 |
| 对话记录 | 完整的客服与客户往来历史 | 文本/富文本/时间戳分段 |
| 附件 | 截图、发票、合同等证据 | 文件链接或二进制对象 |
| 标签 | 灵活打标，便于筛选与分组 | 退款/优先客户/欺诈疑似等 |
| 满意度 | 客户评价或评级结果 | 1-5 分 或 好/中/差 |
| 内部备注 | 仅客服可见的处理线索或风险提示 | 文本 |
每个字段怎么用——从现实场景讲起
好，现在把字段逐一拆开说清楚它为什么存在和怎么用，避免你在实际配置时摸不着头脑。
工单编号与来源会话ID
工单编号是检索、日志和外部系统对接的锚点。来源会话ID（例如某条WhatsApp或网页会话的原始ID）则帮助把“消息流”还原成一条时间线。*如果两个字段丢失，审计和合并都会变得很困难。*
客户信息与联系方式
客户姓名、ID和联系方式不是冗余，那是客服的身份证明。跨境场景下，最好把国家代码和首选语言也记录下来，这样分配给会说该语言的客服，就会更顺畅。
渠道来源与来源URL
渠道字段不是只写“网站”就完事了，细到平台（Amazon/Shopify/自有站）和页面（商品页/支付页）会直接影响问题分类：订单异常多半来自支付页，退货咨询来自订单详情页。
问题分类与标签
分类是体系化，标签是灵活补充。分类用于宏观统计和路由（比如把“退款”直接路由到售后团队），标签用于临时标记（比如“高危客户”、“需要主管复核”）。两者配合，既能跑报表又能灵活筛查。
优先级、SLA与预计解决时间
务必把这些字段和工单状态联动。很多企业会设置自动化规则：若某工单优先级为“高”，且SLA剩余时间小于2小时，则自动升级并提醒主管。*这些逻辑靠字段执行，字段必须准确。*
对话记录与附件
完整的对话记录并不是简单的聊天文本，理想状态下每条消息都带时间戳、发送者角色（客户/机器人/客服）和媒体类型。附件需要存储元信息（上传者、上传时间、与订单关联等），便于后续取证。
内部备注与处理历史
内部备注是客服与内部同事交流的地方，*请区分“内部”与“对客户可见”*，避免敏感信息误曝光。处理历史应该是可审计的链条，记录每一次状态变更、转接、合并、处理人和时间。
自定义字段（Business Fields）
不同企业的业务不同，退货金额、物流单号、发票编号、所属站点等都需要字段化。实践经验是：先把最常用的业务字段做成标准字段，再把低频、实验性字段做成自定义字段池。
关于字段设计的好习惯（小贴士）
- 命名规范：统一前缀（如 biz_、sys_、cust_），避免歧义。例如 biz_order_no 比单写“订单号”更清晰。
- 字段类型：区分枚举、字符串、数值与时间戳。枚举字段利于做规则，时间戳建议统一使用 ISO 8601。
- 最小必要原则：只记录必要的敏感信息。若非必须，尽量不要把完整支付卡号等敏感数据存入工单。
- 默认与历史：为关键字段（状态/优先级）记录变更历史，便于SLA计算和回溯。
- 与外部系统的映射：设计字段时同时考虑 CRM、ERP、仓储系统的字段映射，降低对接成本。
自动化场景：字段如何驱动流程
工单字段不只是记录，它们是自动规则的触发器。常见用途包括：
- 基于渠道和问题分类自动分配到指定队列。
- 当附件包含发票且问题分类为退款时，自动标记为“待财务确认”。
- 优先级与SLA字段触发升级和催办通知。
- 根据客户标签触发VIP处理流程或免排队策略。
- 客服在备注中写入“需法务介入”，自动抄送法务邮箱并创建二次工单。
跨境与多语言的特殊字段
出海企业常常面临语言和合规问题，以下字段非常有用：
- 首选语言：决定是否启用实时翻译或分配给对应语种客服。
- 翻译状态：表示是否已自动/人工翻译及翻译质量评估。
- 国家/地区：用于税务、法律与物流策略判定。
- 合规标签：特殊商品、禁运标识或出口限制等。
权限、审计与数据保护
字段设计还必须考虑谁能看、谁能改、谁能导出。敏感字段需要加密存储并做访问审计。内部备注应设置可见范围，只有授权角色才可查看。审计链（谁在什么时候改了哪个字段）对纠纷处理和法务是关键证据。
典型实施流程（按步骤走）
- 梳理业务场景：列出需要的业务字段（订单、退款、物流等）。
- 梳理客服流程：定义状态流、转接规则与SLA。
- 字段建模：确定字段类型、默认值与可选枚举。
- 对接外部系统：明确API字段映射和同步策略。
- 上线前演练：模拟高并发、字段缺失、合并/转接场景。
- 上线后监控：校验字段完整性和SLA达成率，并迭代优化。
一个简短的字段映射示例（UI 字段 ⇆ API/后端键）
| UI 字段 | 后端/API 键 | 说明 |
| 工单编号 | ticket_no | 唯一索引，用于外部引用 |
| 客户ID | customer_id | 关联用户中心 |
| 渠道 | channel | 入线平台标识 |
| 问题分类 | category | 枚举值 |
| 内部备注 | internal_note | 仅限员工查看 |
常见问题与小技巧（那些容易踩的坑）
- 字段膨胀：把所有想要的都塞进去会让表单臃肿。技巧是分层：必要字段必须填写，次要字段采择填。
- 枚举滥用：问题分类随意新增标签会破坏统计口径。控制枚举来源并定期清理。
- 合并冲突：两个工单合并时字段冲突（例如不同的优先级）要有默认规则：取高优先/保留最新/合并备注。
- 权限漏配：忘记限制内部备注或敏感字段的导出权限，会导致数据泄露风险。
- 时间格式混乱：不同系统使用不同时间格式会影响SLA计算，一律使用标准化时间戳。
最后，几点“实战建议”——像在做客服那样看字段
- 把自己当成客服：看到字段第一反应应该是“我能靠它立刻处理这单吗？”如果不能，就是设计欠佳。
- 先做可用，再做完美：先把最关键的 10% 字段做稳，后面再扩展。
- 运营与客服要协同：字段不仅是技术事，更多时候是流程和思维的体现，定期把一线客服的反馈纳入字段优化。
- 关注指标驱动：把字段和报表指标挂钩，哪些字段能直接提升首次响应率、解决率、CSAT，就优先打磨。
写到这里，我忽然想到一个现实中常见的小例子：有家公司把“订单号”放在对话里，但没有把它作为结构化字段，结果客服每次都得手动查找、复制粘贴，处理效率被拖慢不少。把常用业务项结构化后，自动拉单、自动匹配历史就能节省大量时间——这正是字段的价值所在。