客户在官网上传图纸，页面显示“提交成功”，销售邮箱和 CRM 却没有这条询盘。到了第二天，客户从 WhatsApp 追问报价进度，团队才发现邮件接口已经中断十几个小时。合同里虽然写着“故障两小时响应”，服务人员也确实在接到消息后两小时内回复了，但询盘已经丢了。官网询盘表单的 SLA 需要管住发现、通知、临时收件和恢复验证，单写响应时间挡不住这类损失。
先把什么算故障写清楚
表单故障不只包括按钮点不动。提交后没有写入数据库、邮件发送失败、附件被截断、验证码在部分地区打不开、移动端选项无法展开，都可能让买家放弃或让销售拿到残缺信息。合同附件里应列出关键链路，从页面加载、字段校验、附件上传，到数据库入库、邮件通知、CRM 同步和自动回执，每一段都要有验收口径。
严重程度要按业务后果划分。全部访客无法提交，或者页面提示成功但后台没有记录，应定为最高等级；某个浏览器无法上传附件、部分语言页面报错，可以放在次一级；提示文字错位、非必填字段显示异常，通常不需要夜间叫醒技术人员。等级定义里写具体症状，比“重大故障”“一般故障”更容易执行。
计时起点也会引发争议。较稳妥的口径是监控首次报警、服务人员收到可复现的报障、客户提交工单，三者取最早时间。若合同只写“确认故障后开始计时”，服务方可以花很久确认，企业却已经在丢询盘。无法复现时也要先登记，记录访问时间、页面 URL、设备、浏览器、来源地区和附件大小，不能因为暂时没看到报错就关闭事件。
SLA要拆成响应、绕行和恢复
响应时间表示有人接手并说明当前状态，不等于表单已经恢复。合同可以分别约定首次响应、临时绕行方案和正式恢复三个节点。比如最高等级故障在 15 分钟内确认接手，60 分钟内提供备用收件入口，4 小时内恢复并完成验证。具体数字要结合值班能力和业务时区商定，写得过紧却没有夜间值守，最终只会留下无法兑现的条款。
临时方案必须提前准备。页面可以切换到简化表单，保留姓名、公司邮箱、需求说明和产品型号；附件服务故障时，先给出企业邮箱和文件编号，待系统恢复后再补传。涉及图纸、采购合同或身份信息，不能临时改用公开网盘。备用入口的收件人、保存周期和删除规则要与正常表单一致。
通知路径应写到人。网站运营是事件负责人，技术服务人员负责排查，销售负责人确认是否有询盘遗漏；最高等级故障除了工单，还要通过电话或企业即时通讯通知。通知内容至少包含发现时间、受影响页面、当前症状、临时入口和下次更新时间。服务人员只说“正在处理”，销售仍不知道该怎样接住客户。
第三方故障也要有边界。邮件服务、短信验证码、云存储或 CRM API 出问题时，建站服务人员未必能直接修复，但仍要负责定位、联系供应商、启用备用路径并同步进展。合同可以排除第三方的最终修复时长，不能把诊断和绕行责任一起排除。DNS 过期、接口密钥失效、邮箱配额已满等问题，还要写清谁负责续费和日常检查。
恢复之后要验证询盘真的能到销售手里
技术人员看到接口返回 200，只能证明请求得到响应。恢复验收要走一遍完整业务流程，用桌面端和手机各提交一次，测试必填字段、附件、隐藏来源字段和多语言页面。后台应出现记录，通知邮件能到指定邮箱，CRM 字段没有错位，自动回执也不能泄露内部地址。测试询盘要带固定标记，避免销售误当成真实客户。
故障期间可能已经有数据留在队列里。服务人员需要检查失败日志、邮件退信、数据库未同步记录和 CRM 接口重试情况，整理出受影响的时间段与条数。若无法确认是否丢失，应明确写“数量待核”，再从访问日志和成功页访问记录交叉检查，不能凭感觉写成零损失。
事件记录至少保留故障等级、开始与发现时间、首次响应、临时方案启用时间、恢复时间、影响范围、原因和负责人。根因如果只是推测，就标注待复核。后续措施也要能验收，例如增加每五分钟一次的合成提交测试，检查结果进入专用测试邮箱，并在连续两次失败时报警。
签合同前最好做一次小演练。把测试邮箱暂时停用，观察监控多久发现、通知发给谁、备用入口能否切换、恢复后谁确认。演练常会暴露一些很小的问题，比如值班电话已经换人，CRM 测试账号没有权限，或者备用表单仍调用同一个故障接口。提前发现这些问题，比故障发生后争论“两小时响应”是否达标更有用。
表单 SLA 的目标很朴素，买家提交失败时有路可走，销售能知道哪些询盘可能受影响，技术团队也有明确的验收终点。把故障症状、计时规则、责任人和恢复测试写进同一份附件，服务商与企业才是在执行同一套标准。