私活免费维护期给多久合适

先分清是缺陷、环境问题还是新需求。我在[交付后客户说不能用，先分清三件事](/articles/customer-says-broken-after-delivery)里写过判断顺序，别一上来就认领。

建议写，至少写清楚范围和不包含项。**具体条款以当地法律法规和双方约定为准**，请以专业意见为最终依据。

2026-10-12 维护期,售后边界,交付说明,接单避坑

有个客户在验收当天问我：「后面有问题你是不是一直管？」我当场没答上来。私活免费维护期一般多久，这个问题我后来越想越觉得问错了。 回去我把做过的几单翻出来对了一遍，得出的结论是：不该给一个笼统的天数，而该按「修什么」分成三档来承诺。

私活免费维护期一般多久：先看它在保什么

大部分人谈维护期的时候，脑子里想的是「多久之内出问题我负责」。这个说法太粗，所以后面一定会吵。真正要拆开的是三类事。

一类是你写的东西本身有毛病，比如按了按钮没反应、数据对不上；一类是客户换了环境，比如换了手机、换了浏览器、服务器欠费；一类是客户想要新东西，只是他管这个叫「改一下」。

第一类是你的责任，后两类不是。 维护期这个承诺，本质上只该覆盖第一类。

我把维护按「包什么」分成三档，谈的时候直接摊给客户看：

|------|---------|---------|------------|

免费那一档，我建议只承诺「发现缺陷就修」，不承诺「随时响应」。 响应时效是另一件事，我在私活售后响应时间，别随口答应里单独写过。

对比这三档你会发现：真正让双方扯皮的从来不是天数，是范围。

免费保修档适合上线即结束的项目。 我做过的烧烤店小程序那单就是这一类——交付收入 ¥3000，其中我手写的代码不到 20 行。代码量小、逻辑简单，出问题的概率本身就低。

付费维护档适合客户没有技术团队的项目。 客户连服务器在哪都说不清的时候，你给他一个免费承诺，他三个月后连密码都忘了，最后还是来找你。

按需服务档适合后面还有活的项目。 如果客户后面还要做第二期，免费期的价值就不在修 bug，而在维持联系。这时候给得宽松一点没关系，你的目标不是省工时，是别断掉这条线。

我选「免费保修 + 写清边界」，不给笼统的天数承诺。

原因很简单：我给不出一个通用数字。项目复杂度不一样、客户技术底子不一样、我后面手上有没有别的活也不一样。硬给一个数，要么自己吃亏，要么客户觉得你在推脱。

我现在的做法是把三句话写进交付说明里：我写出的缺陷免费修；不是我造成的环境问题、服务器欠费、第三方接口变动排除在外；新增需求不算维护，重新评估工时。

这三句话写进去之后，售后扯皮明显少了。因为它把「是不是你的锅」这个争论提前解决了。

具体这段时间写多长、怎么在合同里体现，以当地法律法规和双方合同约定为准。

最难的不是定规则，是在成交前把规则说出口。很多人怕说了丢单，就含糊过去，结果交付后吃闷亏。

我的顺序是：报价的时候就一起说，不单独拎出来强调。把维护期当成交付方案的一部分，而不是一条免责声明。 语气上它是「我这边交付是怎么安排的」，不是「我先跟你划清责任」。把这件事说顺了，私活免费维护期一般多久就不再是个要吵的问题。

Q：私活免费维护期一般多久合适？

A：没有通用数字。我的做法是不给天数，改成按范围承诺——只包我写出的缺陷，环境和新增需求另算。真要写时间，就写短一点并明确边界，比写长但含糊安全。

Q：免费期内客户说不能用，算不算我的责任？

A：先分清是缺陷、环境问题还是新需求。我在交付后客户说不能用，先分清三件事里写过判断顺序，别一上来就认领。

Q：维护期要不要写进合同？

A：建议写，至少写清楚范围和不包含项。具体条款以当地法律法规和双方约定为准，请以专业意见为最终依据。