Rexfin 背后的支持模式：诚实的 SLA，而非空中楼阁式的承诺

大多数供应商的支持页面读起来千篇一律：7x24 覆盖、正式的正常运行时间保证、隐含着“每张工单背后都有一支庞大团队”的分级升级机制。Rexfin 的支持页面刻意没有这样写。我们宁愿公布真正能够兑现的数字，也不愿公布那些在销售材料里听起来更漂亮的数字。

每一个数字都以真实可用性为准绳

无论一张支持工单落到哪里，最终都会流向一个小团队，分诊、响应和升级是依次进行的，而不是分摊在一批轮值人员之间。因此，我们公布的每一个 SLA 数字背后的统领性原则很简单：绝不承诺运营现实无法支撑的事情。

这决定了两个方面。第一是工具选择：在没有足够工单量支撑的情况下，一个笨重的、带工作流自动化的帮助台平台就是负担，所以支持工作从一个共享的、打了标签的收件箱开始，只有在量级需要时才升级到真正的共享收件箱工具。第二是 SLA 分层。我们的试点层级完全不使用正常运行时间的语言，普通问题当天响应，影响结账的问题尽力在四小时内响应，没有服务积分，一切都明说而不是暗示。付费层级只公布我们今天真正能够兑现的承诺，并在我们自己的测量工具存在已知缺口的地方明确注明。如果有人问为什么试点阶段没有正式 SLA，诚实的答案是：我们不会承诺一个自己还无法可靠测量的数字。

精确定义的海合会日历

支持时间遵循你所在司法辖区自身的工作周和公共假期，而不是一个笼统的假设。阿联酋和沙特客户处在不同时区，近年来两个市场的工作周本身也出现了不同的变化，因此我们按客户逐一确认真实的工作周形态，而不是硬编码一种。斋月会作为一个有明确名称、提前告知的例外，采用缩短工时，而不是悄无声息地放慢速度；假期参照你所在司法辖区真实的、由政府公报公布的日历，而不是一份用不了一年就会过时的固定日期清单。

在回复发出之前，每一张工单都会被归入四个类别之一：影响服务的技术问题、答案中出现的错误或可疑数字、普通的操作咨询，或功能请求。这种分类比听起来更重要。

为什么“一个错误数字”不是普通的支持工单

服务中断是可以被原谅的。每一款 SaaS 产品迟早都会遇到一次，客户大多也能接受。但一个悄悄进入客户已签署的董事会材料的错误数字，是完全不同类别的问题，因为它直击 Rexfin 存在的唯一保证：每一个数字都能追溯到其来源。如果把这类报告当作“页面加载缓慢”的普通工单来处理，将是我们支持流程可能犯下的最具破坏性的错误。

因此，错误数字的报告从不进入普通事故队列。它会被路由到一个专门的数据完整性处理流程：先发现错误，在对外说明之前先判断这是仅限于一个工作区的孤立问题，还是可能在使用相同映射规则或连接器的任何地方重复出现，主动向客户披露（尽可能在客户注意到之前），修正数字并重新发布带有可见修订标记的导出文件，而不是无声覆盖，并将根本原因反馈进我们的验证测试中，以便同类错误今后能被自动捕获。如果问题被证实是系统性的，所有受影响的客户都会被告知，即便是那些尚未察觉的客户也不例外，“没有其他人投诉”从不被视为等同于“没有其他人受影响”。关于这些错误在上线前是如何被拦截的，请参阅验证机制如何运作；关于每一个被引用的数字如何保留一条通向来源的轨迹，请参阅答案审计日志。

在这一点上，我们也坦诚存在缺口：确认哪些其他客户可能共享同一个受影响的映射规则或连接器，目前仍是一项人工检查，而不是自动化查询，因此我们的披露目标数字实际上把两项不同的工作合并成了一个数字。我们宁愿告诉你这一点，也不愿暗示某种尚不存在的工具已经存在。

如果你正在评估我们，这意味着什么

如果你从第一天起就需要一个正式的 7x24 支持承诺，并附带合同约定的正常运行时间积分，我们目前还不是那样的供应商，我们也不会假装是。我们所能提供的，是一个我们公布的响应时间真正能够兑现的支持模式，以及一条针对唯一真正会损害你对我们数字的信任的失败模式的清晰、专用路径。关于每一个被引用数字所经历的验证与溯源层，请参阅安全架构概览，以及更广泛的走进 Rexfin 平台主题。

如果一个错误数字代价高到值得为它单独建立一整套流程，那就值得向任何供应商，包括我们自己，追问一句：一旦有一个数字漏网而过，那一天究竟会发生什么。