Domínio Visual 不是一家初创公司。它是一家视觉标牌制作企业，做立体字、门头、广告牌、室内导视，服务的客户要求作品在约定日期准时安装到位，而不是在某个假设的 sprint 里交付。
这篇文章讨论的是：当一家真实的服务型企业决定放弃用 Excel、笔记本和 WhatsApp 群聊来管理工单，转而通过定制数字化平台运营时，会发生什么。得到了什么，失去了什么，以及首次尝试时几乎必然踩的坑。
执行摘要
服务型业务有三个长期的运营痛点：每个订单的真实状态分散在多个人的脑袋里，客户历史记录活在聊天记录中，开票取决于谁还记得做了什么。通用软件解决不了这些问题，因为它的词汇不对。真正的方案是围绕企业实际流程设计的平台，状态对应真实的物理阶段，界面让团队任何成员都能上手，无需培训。
对 Domínio Visual 来说，这意味着建模十个状态，从「现场勘查」一直到「开票」；用 MariaDB 搭建围绕工单设计的数据库；前端默认假设使用者正在施工现场，而不是坐在办公室盯着仪表盘。
业务问题
标牌公司是按项目运作的。每张工单要经过多个物理环节：有人去现场测量，有人画版面图，版面交给客户审批，印刷或裁切材料，必要时焊接金属结构，在厂房组装，排期安装，交付，最后才开票。
每个环节涉及不同的人。跑现场的销售不是画版面的设计师。设计师不操作刻字机。现场安装的人很少参与厂房组装。而客户随时会打电话问「我的活儿怎么样了？」，可能打给任何一个人。
没有平台时，答案取决于谁接的电话。每个人只掌握拼图的一块。整合视图并不存在于任何地方，它是散的。
为什么这件事比表面看起来更重要
这个模式里有三项隐藏成本，都在悄悄吞噬利润，却不会出现在损益表上。
第一是协调成本。每个项目在 WhatsApp 里会产生十到二十次确认状态的微型对话。乘以同时在跑的三四十个项目，就意味着每天有好几个小时的熟练人力在做一个系统本该做的事。
第二是返工成本。没有集中的历史记录，重做是常态——因为客户批准过的版面埋在三周前的某封邮件里，或者测量数据是用铅笔潦草记的，没人能认出来。
第三，也是最贵的一项——漏开票成本。装好了但从未开票的活。口头答应的加项从未进入最终报价。Aberdeen Group 几年前有份研究估计，没有结构化数字流程的企业，每年因未开或未收的账单损失营收的 1% 到 3%。这个数字不会出现在任何地方，它悄无声息地蒸发。
对这类企业来说，「数字化平台」意味着什么
不是 CRM。不是 ERP。不是加了自定义状态的 Trello。它是以上这些的集合，但使用的词汇必须精确对应企业的实际工作。
差别微妙却是决定性的。如果软件把工单叫做 deal、opportunity 或 task，团队就永远不会稳定地使用它。如果它叫「工单」，并带有团队脑中早已存在的那些状态——勘查、版面、审批、印刷、裁切、焊接、生产、安装、发货、开票——采用率立刻就上来了。
这就是服务型业务选择定制软件的核心论点：不是功能的问题，是语言的问题。
真正影响业务的技术决策
这里每一个技术选择都是基于运营影响做的，不是基于什么对开发者有趣。
数据库选 MariaDB 关系型，而不是时髦的 NoSQL。因为工单跟客户、工项、历史、开票之间有刚性关系；当会计师年底要跑一条查询时，SQL 是很多人都能读懂的语言。
认证模块对新用户使用 bcrypt，但保留对旧 MD5 的兼容。不优雅，但务实：这意味着老用户在迁移当天不需要重置密码，而这正是「大家都在用」和「一半团队放弃」之间的分水岭。
前端是由 Nginx 服务的高速 SPA，背后是 Node.js 的 Fastify API。本可以做成传统的 Rails 应用、服务端渲染。选择 SPA 来自一个具体需求：现场安装人员需要在手机上更新状态，经常是在信号很差的环境下。带本地状态和异步同步的 SPA 在这种场景下，比每次点击都要完整往返的系统表现更好。
这是这个决定成立的唯一理由。如果所有人都在光纤办公室里工作，一个传统应用会更便宜、更好维护。
建模真实流程：状态的问题
数字化这类业务时最常见的错误，是把真实流程简化成三四个状态：待办、进行中、已完成。图上很干净，现场完全没用。
Domínio Visual 运行着十个独立状态。每个都对应一个物理阶段，以及负责的团队或个人：
- 已关闭（0）——开票后的终态
- 勘查（1）——销售现场测量
- 版面（2）——设计师制作视觉方案
- 印刷（3）——贴膜或材料印刷
- 裁切（4）——字母或硬质材料切割
- 焊接（5）——如适用的金属结构
- 生产（6）——厂房组装
- 安装（7）——客户现场安装
- 发货（8）——物流交付
- 开票（9）——出具发票
- 版面审批（10）——客户在印刷前确认
这种颗粒度不是过度工程。每个状态都对应一个具体的人，他需要知道「现在哪些活在我手上」。把两个状态合并成一个，就意味着这个人要看到跟自己无关的工单。采用率立刻下降。
历史记录：那个解决最多问题的隐形功能
每张工单都关联一张历史表。每次状态变更、每条备注、每个附件，都带时间戳和操作人记录下来。
这是需求调研阶段没人会提，但半年后变成最常用的功能。因为它解决了三个看上去没有技术解法的运营问题：
客户打电话投诉时，任何一个员工都能重建这个项目的准确时间线，不用靠相关人员的记忆。
内部争论「谁对谁说了什么」时，有一份中立记录能在几秒钟内结束讨论。
新员工入职时，能自己理解旧项目的来龙去脉，不用去问五个人。
实践规则是：如果某件事三个月后可能引发「那什么时候……」或者「谁来着……」之类的问题，就必须进历史记录。永远如此。
首次尝试几乎必然踩的坑
值得具体说一下这类项目里几乎都会出现的错误，让正在考虑启动的人知道该避开什么。
错误一：从开票模块开始做。这听起来很合理——开票是钱进来的地方，所以看起来优先级最高。错。如果系统其他部分没人用，开票还是会像以前一样在系统外完成。先从工单的运营状态开始；开票会自然跟上。
错误二：开发前征询全员意见。每个人都想把软件优化成自己那一环的样子，结果是一个充满矛盾功能的科学怪人。挑一到两个能从头到尾看懂业务的资深员工，忽略其他人，直到有可用版本可以让大家反馈。
错误三：不迁移历史数据。没有过去两年项目数据的新系统，是一个空系统。团队会继续回到旧系统查过去的事。数据迁移又枯燥又技术又没面子，但没有它，采用永远是半吊子。
错误四：仪表盘先于流程。图表管理层一周看一次。日常流程所有人都在用。一个没有仪表盘但流程可用的平台从第一天起就有用。反过来则不然。
适用于任何服务型业务的最佳实践
Domínio Visual 做的是标牌，但这个模式适用于任何按项目销售的企业：创意机构、建筑施工、建筑设计、维修工坊、印刷厂、音视频集成商、活动公司。
- 建模团队脑中已有的状态，而不是图上看起来干净的那些
- 每个项目的历史记录是必选项，不是可选项
- 迁移期采用混合认证——不要强迫所有人在第一天重置密码
- 运营数据用关系型数据库；之后如需复杂分析，再导出
- 界面按手机 + 弱网环境设计，而不是办公室显示器
- 开票在运营流程稳固之后再做，绝不提前
- 项目要有一个有决策权的内部负责人，而不是委员会
关于通用软件和定制软件的选择
正确的问题不是「定制是不是更贵？」。是贵。真正的问题是：让团队每天都用这个系统、三个月后不放弃，值多少钱？
通用软件——配上自定义字段的 Monday、Asana、HubSpot——买起来便宜。但维护成本系统性地更高，因为团队必须在脑中把软件的词汇翻译成业务的词汇。这种翻译恰恰在系统最该发挥作用的时刻失灵：有压力的时候、客户发火的时候、工期紧迫的时候。
带着自己词汇的定制软件消除了这种翻译。初始成本更高。五年期的总持有成本几乎总是更低。而拥有结构化运营数据、存放在自己的 schema 里、随时可查询、导出、分析，不依赖第三方受限导出接口——这个价值怎么估都不过分。
这不是普适规则。小团队起步时应该用 Notion 或电子表格，用到痛为止。开始痛的时候，就是该搭建的信号。
安全与业务连续性
一个管理工单、客户数据和开票历史的平台，很快就会变成业务关键系统。这要求三件服务型企业传统上会低估的事情。
备份。不是每周一次。最低每日，理想情况是每小时增量。要做过恢复测试。从未测试过的备份是一种期望，不是一种保证。至少每年两次在独立环境中执行完整恢复。
强制 HTTPS，证书通过 Let's Encrypt 自动续期。这从 2016 年起就是标准，今天还有企业的浏览器地址栏显示破损挂锁。在 2026 年，用 HTTP 提供企业管理应用没有任何技术理由。
按角色控制访问。不是所有人都需要看到所有内容。销售不需要看毛利，就不给看。安装师傅只需要地址和时间，那就只显示这两项。OWASP 几十年前就在讲最小权限原则，这不是偏执，是基本卫生。
GDPR：当软件是自己的，什么会改变
葡萄牙的服务型企业会处理客户的个人数据：姓名、地址、联系方式，常常还有税号。GDPR 第 6 条要求数据处理有明确的法律依据，第 32 条要求采取适当的技术措施。
自有软件在这里给出具体优势：你能实现合理的数据保留策略、在合适的地方做假名化、不依赖外部厂商工单就能响应删除权、以及可审计的操作日志。通用 SaaS 理论上都提供这些；实践中，每一项能力都取决于你买的套餐和客服响应速度。
真实成本：提案里没人说的事
认真做好的项目，有四项成本大多数提案都低估了。
初始开发是可见的部分——应用搭建、设计、测试、上线部署。通常占第一年总成本的 40% 到 60%。
数据迁移总是被低估。从 Excel、扫描的纸质表、旧系统里抽取数据，再转换成一致的格式导入，比任何合理估算都要耗时。至少预留预算的 15%。
上线头几周的培训和陪跑。启动后的前两周决定采用会不会成功。有人随时解答疑问、快速修复小 bug、调整 UX 细节，这就是「团队用上了」和「团队回到 WhatsApp」之间的差别。
持续运维。服务器、备份、安全更新、每月的小改进。这是一笔可预测的月度支出，很多企业喜欢假装它不存在，直到系统崩溃为止。
该启动项目的信号
一些具体信号，从轻到重，表明一家服务型企业正在触碰手工管理的上限：
- 接到客户询问进度的电话，要先问三个人才能回答
- 管总表 Excel 的人去休假了，整个业务就慢下来
- 发现几周前做完的活从没开过票
- 内部讨论的结局是「我以为是你在处理」
- 新员工要花几个星期才搞清楚东西在哪里
- 营收增长 20% 时，协调成本不是线性扩大，而是指数级恶化
如果你认得其中两三个信号，很可能是时候了。如果认得四个以上，两年前就该做了。
核心要点
服务型业务不需要炫酷的技术。它需要一个使用正确词汇、捕获真实工作状态、保留可审计历史、能在现场人员手机上运行的系统。
通用与定制之间的选择，是关于总持有成本的决定，也是关于团队真实采用概率的决定。通用启动更便宜；定制维护和使用更便宜。对于关键运营，定制在三到五年内几乎总是赢家。
迁移更多是变革管理问题，而不是工程问题。软件做好是必要条件，但不充分。没有一位有权威的内部负责人、没有认真的历史数据迁移，再好的系统也只会被半采用。
下一期将看向相反面：什么时候继续用电子表格是对的，什么时候应该抵制过早数字化的冲动。不是所有企业都准备好了，有时候搭系统只是在推迟那些本该先做的运营决定。