摘要

  • Fastly 称，与 Ingram Micro 的合作是其在新加坡的首个分销协议，可让转售商和系统集成商进入平台，并获得培训、技术赋能与市场支持。
  • 公告没有公开某个终端客户的签约销售方、实施方、工单入口、事故负责人、计费安排或服务等级义务。
  • 买方可以把新的本地渠道视为选择增加，但在把它叫作完整的本地服务之前，仍应取得逐项责任表。

多了一条路，不等于已经交付了一支运营队伍

9 月 1 日的 Fastly 公告称，这一合作是 Fastly 在新加坡的第一份分销协议。公告提到 Ingram Micro 的转售商和系统集成商网络，也提到培训、技术赋能和市场支持。对原先不容易接触该平台的企业来说，这可能降低寻找合适商业和技术对话的成本。

不过，进入供应商的通道不是客户服务运行图。公开文字没有说明每个终端客户由谁签约和开票，也没有说明谁配置生产环境、谁持有变更权限、谁接收首张支持工单、谁向 Fastly 升级、谁负责事故沟通，或谁对某一具体服务承诺负责。它同样没有公布价格、折扣、利润、排他性、客户数量或已完成部署的结果。

这不是对两家公司作负面推论。上述安排很可能存在于后续的客户、分销商、转售商和集成商合同中。需要避免的是另一种推论：既然有了分销协议，就认为服务责任已经完整移交。买方知道可以从哪里购买，不代表它已经知道系统在夜间故障时由谁动手。

渠道伙伴不是单一的运营角色

Fastly 的 渠道伙伴计划本身就区分了推荐、转售和服务交付。页面说明，推荐伙伴不必承担交易、实施或服务管理；转售商可参与转售、分销和采购履约；对于实施或管理某些高级安全服务的伙伴，则另有技术认证描述。

这些是计划层面的角色说明，不是新加坡协议的细则，也不能证明 Ingram Micro 或某个下游转售商会承担其中全部工作。但它解释了为什么“伙伴”一词不能回答运营问题。同一平台可以由一家公司引介、另一家公司交易、集成商实施，再由供应商和服务商在不同层级提供支持。

客户可以保留配置权和上线批准权，只采购渠道和专家资源；也可以采购一次性实施，或持续托管。它可以让 Fastly 处理平台问题，让其他团队看护应用。公告没有替客户选择其中任何一种模式，因此读者也不应替公告补上这种选择。

平台入口、支持和托管仍是不同的服务面

Fastly 的客户支持页面把支持计划、直接联系专家、自助文档、上线和专业服务帮助分别呈现。其 Managed CDN 页面描述的又是另一种形态：在客户私有网络中部署，由 Fastly 与客户基础设施团队共同设计，并配有例行监测、维护和支持。

这些页面并不分配新加坡合作中的职责。它们只证明，在 Fastly 自己的产品表述中，平台访问、支持、专业帮助和私有网络托管并不是同一种服务。分销商出现后，这些边界不会自然消失。购买普通 CDN 的企业，未必拥有与购买私网托管方案相同的权限、升级路径和持续服务关系。

所以“本地支持”应当被拆开问。它是售前培训、商务联系人、首轮诊断、配置协助、供应商工单协调，还是长期托管？每一种都可能有价值，但没有被写入承诺的那一种，不能由营销词自动推导出来。

订单之前需要的一张责任表

实用的文件不必冗长。它应列出客户、合同销售方、分销商、实施伙伴以及 Fastly 的直接角色；随后按动作分配账户管理、生产凭据、配置变更、安全策略审核、监测、首响、升级、事故沟通、日志访问、续约和退出。

关键是把“可以做”与“必须负责”分开。集成商可以完成部署，却不一定有长期修改生产环境的授权；转售商可以履行采购，却不一定运行服务；Fastly 可以支持其平台，却不必为客户的应用逻辑负责。客户也可保留最终批准权，同时委托日常工作。真正需要写清的是这些责任之间的接点。

检验方法不是演示文稿里是否出现“local support”。而是出现真实工单时，谁接收、何时交接、谁能修改、谁向客户解释。商业层面也要同样具体：谁销售、谁续约、这份订单适用什么价格基础和补救条款。分销关系本身无法替代答案。

后续可以观察、今天不宜假定的证据

具名的联合服务包、适用的培训或认证、客户案例、明确的支持层级或公开升级流程，都会让角色更清楚。公告暂未披露这些内容，并不证明它们不存在；它只意味着不能把它们当成已经证实的事实。

公告中的 AI、云原生应用和 API 也应被恰当地理解。它们说明目标市场与平台定位，而不是证明合作已经带来特定 AI 负载、新增容量、可测量的延迟改善或某个客户的韧性成果。采购判断仍要回到实际工作负载、控制权和可得到的合同条款。