储能企业做全球售后系统，先定三件事

一家储能电池企业原来靠邮件传全球售后数据，隔着时差，录一次已经过了半天。规划阶段要先定三件事：门户分清、数据分区、工厂差异。本文给出一个平台三个门户的权限切法、必须留在当地与可同步汇总的字段分层、跨时区 SLA 计时的存储与展示口径，以及新接一个工厂时只复制配置的做法。

邮件传数据，断点藏在时差里

全球售后的问题不是没人处理，是处理过程看不见。

海外服务商把工单发到邮箱，国内客服再录一次，录的时候已经过了半天；配件从哪个仓发出、走到哪一步，要靠人发邮件问。几个业务单元各自有一套做法，集团想统计一次全球平均响应时长，得先把口径对齐，再等人交表。

隔时差这一点还会放大上面的问题。国内下班之后，海外的异常没人接，第二天早上看到的是一堆已经等了一夜的客户。

先定谁在什么界面上操作

一个平台，三个门户。

门户	谁在用	能做什么	看不到什么
客户门户	终端客户	报修、查进度、看保修	内部成本、服务商之间报价
服务商门户	海外服务商	接单、填工时、申领配件、请款	其他服务商的数据、客户商务条款
管理门户	厂商售后与质量	派单规则、SLA 监控、台账与报表	按角色限定区域和业务单元

三个门户共用一套工单数据，只是入口和权限不同。分开建三套系统的做法很常见，代价是同一张工单的状态要在三处对齐。

技术上要落成一条约束：三个门户读同一张工单表，权限差异体现在可见列与可执行动作上，不是三个库。

CREATE TABLE service_ticket (
  ticket_no      VARCHAR(32) PRIMARY KEY,
  region_code    VARCHAR(16) NOT NULL,    -- 派单与值班窗口按它路由
  site_country   VARCHAR(8)  NOT NULL,    -- 数据留存与出境判断按它分组
  business_unit  VARCHAR(32) NOT NULL,
  plant_code     VARCHAR(16) NOT NULL,
  portal_scope   VARCHAR(16) NOT NULL,    -- CUSTOMER / PROVIDER / INTERNAL
  provider_id    VARCHAR(32),             -- 服务商行级隔离键
  status         VARCHAR(16) NOT NULL,
  created_at_utc TIMESTAMP    NOT NULL,   -- 统一存 UTC
  customer_tz    VARCHAR(48)   NOT NULL,  -- IANA 时区，如 Europe/Madrid
  sla_target_ms  BIGINT,
  sla_pause_ms   BIGINT       NOT NULL DEFAULT 0,
  first_resp_utc TIMESTAMP,
  closed_utc     TIMESTAMP
);

SLA 计时：存 UTC，按客户时区展示

通用的做法是按区域定值班窗口：谁在非工作时间接急单，哪一级问题必须当天响应，SLA 从哪个时点开始计时。计时口径要写进系统，时间戳统一存在一个时区里，报表按客户所在时区展示。这一条不提前定，上线后一定会有人拿着报表争论某张工单到底超没超时。

流程走向：

• 工单创建：落 created_at_utc → 是否在值班窗口内
• 是否在值班窗口内 →（是）SLA 计时开始
• 是否在值班窗口内 →（否）等待窗口开启：暂停时长计入 sla_pause_ms
• 等待窗口开启：暂停时长计入 sla_pause_ms → SLA 计时开始
• SLA 计时开始 → 首次响应：first_resp_utc
• 首次响应：first_resp_utc → 是否达到 P1 当天响应要求
• 是否达到 P1 当天响应要求 →（超时）升级 + 计入区域达成率
• 是否达到 P1 当天响应要求 →（达成）处理中 -> 关闭：closed_utc
• 处理中 -> 关闭：closed_utc → 报表：按 customer_tz 展示，按 UTC 汇总

三条口径定死：计时起点是创建时点还是接单时点；暂停时长算不算进 SLA；跨区统计用 UTC 排序、用客户时区展示。同一条工单在两个报表里给出不同的超时结论，根因都在没写下来的这三条上。

数据放哪里，先问法务

多个数据中心同步数据，跨中心要审批，访问要限制。

各地对数据留存和出境的要求不一样，这一条要在规划阶段就和法务确认清楚，等系统上线再补，改动会牵扯整个数据链路。技术上要提前定三件事：哪些数据必须留在当地、哪些字段可以同步到集团汇总、跨中心查询走什么审批。

集团要的是全球口径的统计，不是每一条明细都能随时看。把汇总字段和明细字段分开设计，分区和看全局这两件事才能同时成立。

字段层级	举例	放哪里	同步方式
明细 + 个人可识别信息	联系人、电话、现场照片	留在当地数据中心	不同步
业务明细（无个人标识）	故障描述、工时、配件序列号	当地为主	跨中心查询走审批
统计口径字段	工单状态、SLA 达成、区域、机型	允许同步到集团	定时汇总，不带明细

先过法务再建模，顺序不要颠倒。字段分层在上线后调整，牵扯的是整个数据链路。

三个工厂功能不同，流程只有一套

三个工厂功能有差异，一套系统要兼顾各板块需求。

差异通常落在三处：出厂编码和序列号规则不同，保修起算方式不同，配件目录不同。做法是主流程一套，把这三处做成可配置项，由工厂各自维护。新接一个工厂时复制配置，不改流程。

CREATE TABLE plant_config (
  plant_code        VARCHAR(16) PRIMARY KEY,
  serial_rule       VARCHAR(128) NOT NULL,  -- 出厂编码 / 序列号规则
  warranty_start_by VARCHAR(16)  NOT NULL,  -- SHIP / INSTALL / ACCEPTANCE
  parts_catalog_id  VARCHAR(32)  NOT NULL,
  locale_pack       VARCHAR(16)  NOT NULL,  -- 语言包
  currency_code     VARCHAR(8)   NOT NULL,
  flow_template_ver VARCHAR(16)  NOT NULL   -- 主流程版本，工厂不可改
);

补充两件容易漏掉的小事。多语言用语言包切换，字段名、提示语、报表标题都要能从语言包里出，不要把文字写死在页面里。汇率也在系统里统一管，报价、配件价、服务费的结算币种要有一个统一的取数时点，否则月底对账各说各话。

规划的落脚点

这家企业定的目标是把管控流程落实到系统里，靠系统、不靠人。

三件事的次序不要颠倒。门户先定，因为门户决定谁在什么界面上操作；数据分区先过法务，因为它决定数据放在哪里；工厂差异最后处理，它是配置层面的活。

上线检查清单

• 三个门户共用一套工单数据，差异只体现在可见列与动作权限
• 服务商门户按 provider_id 做行级隔离，跨服务商越权测试通过
• 时间戳统一 UTC 存储，展示层按客户时区转换，夏令时切换验证过
• SLA 计时起点、暂停口径写入系统并出过一次一致性核对
• 各区域值班窗口与急单接单人已配置，非工作时段有升级路径
• 字段三级分层经法务确认，跨中心查询走审批并留记录
• 序列号规则、保修起算方式、配件目录做成工厂可配置项
• 字段名、提示语、报表标题走语言包，页面无硬编码文案
• 汇率取数时点统一，月底对账口径可复现
• 新接一个工厂只需复制配置，不改主流程

关于得帆智能

得帆智能成立于 2014 年，目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程，配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统，应用上线后由平台统一承接权限、审计与版本管理。

说明：本文由得帆智能整理发布，文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中表结构、字段分层与流程均为示意，数据留存与出境要求以法务及当地法规为准。