Fnac联网商品还能不能接？云服务只承诺到2027年，先把“卖完”算到“售后结束”

平台观察

2026-11-09

258

一张采购表最容易让人误判的地方，往往不是采购价，而是“服务到哪一天”这一栏。

Fnac联网商品云服务生命周期判断（原创专题配图）

Fnac联网商品云服务生命周期判断

假设一家准备上的中国卖家，正在考虑接一批联网空气质量监测器。硬件规格没有变，采购价、毛利和包装都已经算过，真正卡住采购的是供应方的一句话：云服务目前只书面承诺到2027年6月30日。

这句话看起来只是生命周期信息，实际上已经碰到了商品能不能继续卖的问题。因为这类设备的价值可能不只在“传感器能不能亮”，还在App、账号、云端历史数据、远程查看、自动化规则以及固件更新。今天卖出去一台，交付完成，并不意味着卖家的责任也在今天结束。

所以，这批货值不值得接，不能只问“2027年以后云还在不在”，而要把两个日期放到同一张纸上：上游服务最后一天，和你最后一单交付后还要承担什么责任。

先把“能用”拆开：断网以后到底还剩什么

采购前最该做的不是继续谈单价，而是拿一台样机真正断网。

这里可以用一个匿名示例说明判断方法。假设这款设备离线实测后，仍能在机身屏幕显示当前温湿度和空气质量读数，按键也能切换页面；但首次激活需要指定App和账号，历史曲线、远程查看、家庭成员共享、自动化提醒都要经过云端，固件更新也依赖厂商服务器。当前没有付费订阅，但如果供应商未来把某项功能改成订阅，卖家没有得到任何价格或续费承诺。

这个结果和“设备支持联网”完全是两回事。

采购表里至少要把下面几层分开：离线真实可用功能、指定App、账号体系、云服务、固件更新、订阅依赖。哪一项是必须的，哪一项只是增强功能，也要写清楚。

尤其是离线能力，不能从产品详情页里抄一句“支持本地使用”就算完成。真正有意义的证据，是断开Wi-Fi或拔掉网关以后，设备还能不能完成开机、核心测量、核心控制；恢复联网后，历史数据是否补传；账号注销、服务器不可用或者App下架时，设备还能留下什么。

这一步看似和Fnac无关，实际上决定了后面的所有账。如果核心功能离线就消失，那么上游云服务的截止日期就不再只是“供应商什么时候停止维护”，而是这批库存还能不能继续承担消费者购买时看到的功能承诺。

“明年”一定要改成具体日期

卖家内部讨论最危险的一句话，就是“明年再说”。

现在是2026年10月。假设供应方写的是“service available until next year”，采购表里不能填“2027年”，而应该把它改成一个可计算的日期。本文示例直接假设为：云服务持续至2027年6月30日，之后停止；供应方没有承诺续费、第三方迁移、继续提供API、继续提供账号服务，也没有承诺历史数据一定可以导出。

接下来不要只问“能不能续”。真正应该让上游书面确认的是四件事。

第一，起止时间。到底从哪一天开始算，哪一天结束，是否按自然日还是某个时区，最后一天是完整服务还是到当天某个时间点。

第二，终止条件。是正常生命周期结束，还是供应商可以因商业、技术、合规、基础设施变化提前停止？提前终止有没有通知期？哪些情况属于例外？

第三，更新责任。在服务截止前，哪些固件、安全更新和App兼容更新仍然会提供？是否只保证“修复严重问题”，还是仍保证原有核心功能可以继续运行？如果手机操作系统升级导致App失效，谁负责兼容？

第四，真实退出能力。云停掉以后，设备能不能完成出厂重置？还能不能使用核心离线功能？历史数据能不能导出？账号能不能解绑？有没有本地接口或真正可用的替代服务？这些都应该有实际测试或书面依据。

“我们理论上可以迁移”“以后可能提供新服务器”都不能进入采购结论。没有明确起止日期、没有迁移承诺、没有可验证退出路径，就只能按“没有”处理。

Fnac卖家最容易漏掉的，是交付日而不是采购日

这也是这类商品最容易算错的一笔账。

假设供应方服务截止日是2027年6月30日。卖家如果在2026年11月采购，2027年3月开始销售，和2027年6月才把最后一批货卖出去，看起来都是同一款硬件，实际上面对的风险完全不同。

再做一个纯假设算例。假设最后一单在2027年6月30日完成交付，商品售价为249欧元，单件硬件采购及现有履约成本合计165欧元，表面贡献是84欧元，按249欧元售价为分母的表面贡献率约33.7%。这里的84欧元只是采购筛选用的单件贡献，不是净利润；正常采购、平台费用和履约等原本就会发生的共同成本，不能因为这次生命周期风险被重复算成“新增成本”。若只看这84欧元，采购很容易通过。

再假设供应商愿意把支持窗口延长，但要求一次性支付1800欧元，计划销售300件，那么新增支持成本就是6欧元/件，调整后单件贡献为78欧元，按249欧元售价计算约31.3%。如果另一条已经书面确认可用的替代方案，需要一次性和按量合计5100欧元，仍按300件摊销，就是17欧元/件，调整后贡献67欧元，贡献率约26.9%。这两个数字都只是示例，不能当成Fnac或任何供应商的实际收费。真正要比较的是：为填补生命周期缺口新增多少钱，以及这笔钱买来的支持是否覆盖到实际销售责任，而不是单纯比较谁的采购价更低。

法国现行消费者法对带数字元素的商品有专门的合规和更新规则。法国《消费者法典》L.217-3规定，卖家对交付时存在、并在交付后两年内出现的合规缺陷承担责任；如果销售合同约定数字内容或数字服务持续提供，相关责任还会跟随约定的持续提供期限。对带数字元素的商品，L.217-19又要求卖家在法定情形下确保消费者获得维持商品合规所需的更新：一次性提供数字元素时，是消费者基于商品类型、用途、合同情况可以合理期待的期间；约定持续提供时，则适用相应的持续期间规则。

这意味着，“供应商只承诺到2027年6月30日”绝不能自动翻译成“2027年7月1日以后消费者自己负责”。真正要看的，是消费者买到的商品究竟承诺了什么，数字服务属于什么供给模式，商品的核心功能是否依赖它，以及销售页面、合同和说明中给了消费者怎样的合理预期。

法国法还要求，销售前应以清晰易懂的方式提供商品及数字要素的基本特征，包括功能、兼容性、互操作性等信息；对于带数字元素的商品，生产者还应向专业卖家告知其提供的软件更新在多长时间内保持与商品功能兼容，卖家再把相关信息提供给消费者。这个信息链条很重要：供应商告诉卖家“更新到哪天”，并不意味着卖家就可以把所有消费者责任也截断到那一天。

欧盟《2019/771号指令》也采用了类似逻辑：带数字元素的商品需要在消费者可以合理期待的期间获得维持合规所需的更新；如果数字内容或服务是持续提供的，卖家的相关责任还会与约定的持续提供期间发生联系。更关键的是，指令同时承认卖家在因交易链上游的行为或不作为而对消费者承担责任后，可以向上游责任方追偿。也就是说，供应链里的追偿问题可以往上谈，但不能反过来把消费者面对的销售责任提前压掉。

如果继续用日期倒推，假设某订单适用“持续提供数字内容或服务不超过两年”的法定情形，最后交付日是2027年4月7日，那么相关两年窗口会走到2029年4月7日，距离本文假设的云服务截止日2027年6月30日还有647天。这个647天不是说卖家当然有权要求一个没有承诺续期的云服务商继续服务到2029年，而是说明：不能把上游的停服日期，直接当成卖家对已售商品责任的截止日期。

Fnac自己的规则，也没有把售后责任推给云服务商

再看Fnac当前的Marketplace规则，卖家与买家的合同关系不能混淆。Fnac当前公开的Marketplace条款页面标示更新时间为2026年3月4日；其买方条款还特别说明，并非所有卖家都能提供额外的商业SAV，但这不等于法定保障可以被删掉。

Fnac的Marketplace说明明确把订单管理、客户服务和售后服务放在合作卖家一侧；其帮助页面写明，消费者从合作卖家购买的商品由该卖家负责处理售后，卖家需要在48个工作小时内回复。当前Marketplace条款还要求卖家用法语回复Fnac客户服务和买家邮件，期限为2个工作日；对产品争议，卖家负责解决，如果收到投诉后8个工作日仍未解决，Fnac有权在事先通知卖家后向消费者退款，并从应付卖家的款项中扣除。

这几个时间点不是让卖家去做“售后排班表”，而是提醒采购人员：联网商品的售后责任是一个真实存在的业务边界，不能因为上游说“云服务明年结束”就从采购模型里删除。

Fnac还要求卖家对商品描述、特性和相关保证信息负责，并明确要求商品信息不能误导买家。对于带数字元素的商品，这一点尤其敏感：如果页面把远程控制、云端历史、自动化等写成商品功能，就不能只在内部采购备注里知道这些功能依赖第三方服务。

因此，产品页面上“能做什么”，供应商合同里“还能支持多久”，以及卖家实际能承担多久，必须是同一套口径。更不要指望临近停服时把页面上的联网功能描述删掉就能把已经售出的责任一起删掉；对已经成立的销售合同，后续责任要看交付、合同约定、数字服务供给方式和适用的法定规则，而不是看你后来把Listing改成了什么。

把最后销售日倒推，而不是拿库存日期往前推

真正好用的采购方法，是先设“最后销售日”，再往前倒推。

假设这批货计划在2027年3月31日前全部卖完，最后一批交付预计不晚于2027年4月7日。供应商云服务到2027年6月30日，看起来还有将近三个月的缓冲。但这并不等于“够了”。

因为你还要问：如果4月交付的消费者在后面遇到App兼容、云端历史或安全更新问题，卖家能否继续获得上游支持？如果6月30日只是“云服务器关闭日期”，那最后一个消费者从4月开始使用的核心联网功能，实际上只获得了很短的确定性服务窗口。

反过来，如果最后销售日设在2026年12月31日，最后交付在2027年1月7日前完成，那么库存虽然还是同一批，生命周期压力就小很多。同一采购价，同一硬件规格，只因为最后销售日不同，风险敞口就可能完全不同。

可以把它简单算成一个“支持覆盖差”：

支持覆盖差 = 上游书面承诺的服务截止日 − 拟最后交付日。

这个数字只是筛选工具，不是法律安全线。比如本文假设服务截止2027年6月30日、最后交付2027年4月7日，账面覆盖约84天；但如果核心功能完全依赖云端，这84天并不能替代法定合规义务，也不能证明消费者合理期待一定只有84天。

所以第二个数字也要算：

责任暴露期 = 预计最后交付后的消费者责任窗口 − 上游确定支持窗口。

这里不要擅自把“责任暴露期”写成固定的两年，更不能写成“供应商只保一年，所以卖家只保一年”。对于带数字元素的商品，具体适用范围和起算点要结合销售合同、数字服务供给方式、商品类型及消费者合理期待判断。法国法对交付后两年的一般合规责任、持续数字服务以及更新义务分别有规则，不能拿一个数字把它们压扁。

这时候再算钱，才知道84欧元到底是不是利润

回到前面的249欧元售价和84欧元表面贡献。

如果最终有两条合规可行路径，就把新增部分单独拿出来算。供应商延长支持，需要新增多少；真实替代服务，需要新增多少；为了准确披露功能和生命周期，需要增加多少产品资料或技术确认工作。这些才是这次决策的新增成本。

不要把原来无论卖不卖这批货都存在的采购、正常履约、平台费用再次算成“生命周期成本”。否则最后很容易出现一种假象：方案看起来特别贵，其实只是把共同成本重复扣了一遍。

真正应该比较的是：

调整后单件贡献 = 原单件贡献 − 新增支持成本 − 预计退款/补偿暴露 − 额外技术或合规成本。

这里的“预计退款/补偿暴露”不是让卖家随便拍一个百分比，而是把已有订单的真实问题、历史投诉、产品测试结果和合同条款拿来估。没有样本，就不要伪造一个“售后率2%”塞进表格。

采购批量也不要为了好看直接做满。若上游只愿意提供有限支持，先把可销售库存控制在能够在确定窗口内完成交付、并且能够承担后续责任的范围。真正的采购门槛不是“仓库还有没有位置”，而是“这批货卖出去以后，谁还能让商品承诺的功能继续成立”。

最后一次谈供应商，不要只问“能不能续”

如果这批货确实有市场，谈判重点应该从单价切到服务边界。

可以把一页纸问题直接发给供应方，要求对方逐项回答：

- 当前型号对应的App、云服务、账号和固件更新分别由谁提供； - 每项服务的开始日期、结束日期和终止条件是什么； - 截止日期前是否仍提供安全更新、兼容性更新和必要的固件更新； - 服务停止后，哪些功能还能离线使用，哪些功能会失效； - 账号能否解绑，数据能否导出，设备能否恢复到可独立运行状态； - 是否存在付费订阅、续费、迁移或第三方替代方案；如果存在，价格、期限和条件是否已经确定； - 如果供应商提前停止服务，卖家是否会获得通知，能否取得必要的数据或迁移支持。

然后把答案和自己的最后销售日放到一起。

这一步也能避免一个常见误区：不要因为供应商愿意写一封“未来可以迁移”的邮件，就把它当成已经存在的替代服务。真正能支撑采购的是已经确定的合同条件、可验证的退出能力和可以在销售前向消费者准确披露的信息。