需求只写好用的售票系统是第一个坑
需求文档不应是功能列表的复制粘贴。要描述票种、渠道、闸机、支付、实名、退改规则、对账要求和每日订单曲线。写清楚当前设备和网络状况，标注哪些必须兼容、哪些可以替换。
模糊需求只会引来模糊方案。不同供应商的支持差异极大：可能是原生功能、第三方插件、定制报价或仅表示有意愿。需求越可测试，方案越可比较。
把演示当验收是最大的陷阱
演示通常走最顺利的正向流程，不展示售罄、双人同座、支付超时、闸机离线、出票失败、退款后票仍可用等异常。采购方应准备异常脚本，要求供应商在演示中现场操作关键异常场景。
演示环境与生产环境不同，设备型号、网络状况、数据规模、第三方接口权限都可能不一样。演示通过只能证明供应商理解了需求，不能证明系统已经就绪。
案例墙不等于交付能力
供应商展示的客户Logo可能来自集团其他子公司合作、短期试用、硬件分包甚至非票务项目。每个案例至少核对客户主体、项目名称、实施时间、模块范围、当前运行状态和是否同一法人。
案例与采购项目的相似性比知名度更重要。一个规模中等但票种、渠道和闸机高度相似的案例，参考价值超过一个大型但仅部分模块在用的知名案例。
数据迁移不能留到上线后
历史订单、会员、储值、年卡和黑名单的迁移不是简单的CSV导入。字段映射、编码对照、状态转换、时间戳处理和差异清洗都需要提前试迁至少两次，用抽样验证金额、状态和关联关系并约定差异阈值和修复时限。
不能迁移的数据要有替代查询方案；迁移失败的回退路径必须经过测试。合同约定迁移范围、责任、次数和合格标准，不签约免费迁移不限量却不知具体含义。
忽视培训等于自动制造失败
窗口人员培训不足会导致上线当天长时间排队；财务不熟悉新报表会拖延对账；IT不掌握管理员权限会在故障时完全被动。每个关联岗位都要有基于真实场景的培训和过关考核。
切换后第一个节假日和第一个结账周期是高发故障期，应安排驻场和远程支持。培训不只是上线时的活动，系统升级和流程变更后同样需要。
常见问题 FAQ
为什么不选最便宜的？
初始低价可能不包含接口、定制、设备和培训；用总拥有成本、退出成本和可替代性综合评价。
参考同行推荐就够了吗？
同行推荐是重要参考，但需确认同行票种、规模和渠道与本项目相似，并独立核验案例状态。
是不是应该等所有功能都完美再上线？
等待完美同样有风险；用最小可用范围先解决核心痛点再迭代扩展比一次试图覆盖所有场景更可控。