几十行脚本收几百块，客户会不会觉得贵？
客户买的不是代码行数，而是省下的时间和"有人帮我弄好"的确定性。同样一段脚本，会的人觉得简单，卡在安装和使用上的人觉得很值。报价时不要按代码量算，而是讲清楚它帮客户每天省多少时间、包含哪些服务（环境配置、文档、答疑）。把各项拆开写，客户更容易理解价值。真正让客户觉得贵的，往往是交付后用不起来。
客户买的不是代码，是省下的时间和确定性。
为什么不能按代码量算
- 几十行代码，可能帮客户每天省下两三个小时；
- 客户自己研究，可能要花好几天还不一定成功；
- 你能快速写出来，是因为你积累了经验，这本身就有价值。
对一个卡在安装和操作上的人来说，有人帮他配好、讲明白，就省了大量的事。
报价时讲什么
| 讲这个 | 不讲这个 |
|---|---|
| 每天能省多少时间 | 代码有多少行 |
| 解决了什么具体问题 | 用了什么技术 |
| 包含哪些服务 | 写代码花了多久 |
把服务拆开写
- 脚本定制：完成什么功能；
- 环境配置：帮客户装好、配好；
- 操作文档：图文说明；
- 答疑期：多长时间内有问题可以找你。
拆开以后，客户知道钱花在哪里。从自用脚本做成服务的思路见「把自己在用的脚本做成小服务：从身边人最烦的重复动作切入」。
什么才会让客户觉得贵
- 交付后用不起来；
- 出了问题找不到人；
- 文档看不懂；
- 和描述的功能不一样。
所以与其担心价格，不如把交付做扎实，见「交付的标准只有一条：在客户电脑上能跑通」。
价格也不是越低越好
太便宜反而会让客户怀疑质量，也让你没有动力做好售后。定价的更多思路见「小工具怎么定价：全免费没人付费，太便宜也不一定好」。
一个判断方法
问自己：如果客户用了这个脚本，一个月下来省下的时间值多少？如果远高于你的报价，就不用担心贵。
小结
价值来自帮客户解决的问题，而不是代码的长短。把省下的时间讲清楚，把交付做扎实，价格自然站得住。