系统上线之后的事，往往比上线之前多。
售后和维护
- 响应时效约定清楚，这是售后的核心。
- 迭代计划建议按季度排。想到什么做什么，最后会堆一堆半拉子工程。
长期不动的系统也会有安全问题，定期检查别省。
说白了，故障分级挺有用。小问题几小时解决，大问题几小时响应，分清楚。具体还得看情况。
换个说法，对接人换了要及时通知，不然关键时刻找不到人。
先想清楚要什么
备份机制一定要有，而且要定期验证能恢复。
- 系统升级要提前通知，别在业务高峰做。
- 已知风险提前告知，这是负责任的做法。
这事吧，升级改造前先评估影响。动一处可能牵一片，别想当然。
维护范围要说清：改文字算不算，改结构算不算，加页面算不算。
- 应急预案写给谁看、谁来启动，这些要明确。
上线只是开始，后面的维护才是常态。
- 备份要自动化，靠人记着肯定会有忘的那天。
网站上线只是开始。内容更新、数据查看、小改小动，这些才是长期的活。
- 小问题攒一批一起提，双方都省事。
合同里一定要写清楚交付物：源码给不给、后台有没有、后期维护谁负责。
我记得，备份这事别嫌麻烦，出一次事就知道值了。
维护的范围提前写清楚，免得后面每次都要重新谈。
售后响应时间要写进合同。出问题几天没人理，谁都受不了。
说实话，安全更新别拖。框架出了补丁不及时打，被攻击的概率就上去了。
先说个前提，每个页面得有个明确目的，不然写着写着就不知道在干嘛了。
跳出率这个指标要结合场景看。有些页面用户看完就走，未必是坏事。
验收条件前期定好，免得最后各说各话。
我自己踩过，改版之前先把老站的数据摸清楚：哪些页面有流量，哪些词有排名。别一改全没了。
链接地址尽量简短好懂，一串乱七八糟的参数，观感很差。
点击区域别太小，手机上手指没那么精准，这个细节很影响体验。
谈需求先问痛点，客户最难受的那个点，往往就是系统该解决的第一件事。
旧站哪些内容要保留，提前标出来。别到迁移的时候才发现重要内容没留。
先确认收录。没被收录的页面，后面做再多也是白搭。
光有视觉没有信息的站，中看不中用，用户看完还是不知道你是干嘛的。
做这一行久了，我发现好网站的标准其实很朴素：用户能快速找到他想要的东西。
- 表单能少一项是一项。我统计过，每多一项，填完的人就少一截。
顺便提一句，想被引用，内容得有明确的结论，模棱两可的那种很难被选中。
关于页面数量，我建议先做精几个核心页，比铺一堆空页面强。别等出问题才想起来。
上传自动压缩能省很多麻烦，指望人工处理不现实。
老实说，手机端的体验单独拎出来看，别用电脑的感觉去代替。这两边差别可以很大。
后来才发现，搜索友好的结构最好一开始就规划好，事后补代价很大。
上线的头几天要盯紧。有问题早发现，影响范围小。
视频和图片的搜索量涨得挺快，有资源可以顺手布局。
周期和节奏
听起来简单，内链这块容易被忽略。相关内容之间互相链一下，用户停留时间明显不一样。
按钮要像按钮。有些设计做得好看，用户根本不知道哪儿能点。
产品页最容易写砸。参数列得再全，用户关心的实际上就那几个点。
前期需求说得越具体，后期返工越少，这条基本不会错。
关于价格，模板站几千块能搞定，定制开发一般要贵不少。主要差在设计和功能的工作量。这点挺重要。
先列旧站的毛病，再谈新站要什么，这个顺序比较靠谱。
后台要能自己改内容。改个电话还要找技术，这种后台用起来很痛苦。
时间上要现实一点，定制站动辄说几天交付，质量很难保证。
在苏州做本地服务，网站上把位置和服务范围写明白，用户心里有底。
配图这事别敷衍，能用图说清楚的就别写字。
大概就这些，做站这事急不得，前期想清楚最省钱。