01 / 从门店扩张需求出发
加入小特科技时，公司希望扩张线下门店，但缺少好用的门店系统。我接手这项工作，从客户信息和工单管理开始梳理需求，逐步覆盖车辆施工、售后质保，以及内部的绩效、工资计算、财务对账和线上订单线下核销。
问题跨越了多个角色和业务环节。系统需要把门店的日常工作组织起来，同时让总部运营与财务能够基于同一套业务记录开展工作。
02 / 我负责什么
系统逻辑关系与结构、低代码配置、验证测试、上线、操作文档、培训，以及使用反馈后的迭代。移动端业务逻辑、页面跳转和信息关联。
低代码平台支持及时调整结构与规则。我的工作重点是把业务需求转化为可执行的字段、关系、状态、权限与流程，并在实际使用中验证。
03 / 业务结构与使用角色
系统服务于店长、销售、施工技师、财务、管理层和运营人员，也通过满意度表单与电子质保卡连接外部用户。
| 业务范围 | 系统承载的工作 |
|---|---|
| 客户与服务 | 客户信息、线索、业务预约、工单和车辆施工 |
| 交易与履约 | 收款、财务对账、线上订单线下核销 |
| 门店资源 | 物料、仓储、员工、绩效与工资计算 |
| 售后与用户反馈 | 售后记录、电子质保卡、满意度表单 |
把常用操作放在同一个工作台
预约、定金、工单核销和退款分别组织为操作入口，异常工单查询与质保卡申请也能在同一页面找到。门店人员可以从手头的任务进入相应流程。
从渠道入口开始记录线索
渠道入口覆盖电商、内容平台、合作运营和私域导流，便于在录入时区分线索来源，再与客户和门店业务关联。
超过 33 万条记录包括客户、工单、收款、物料、仓储、员工、绩效、售后与质保卡等业务数据。这些记录来自系统覆盖的多个业务环节。
04 / 把重复操作交给工作流
一个具体例子是工单与收款汇总的关联：新增工单后，流程查询收款信息表；存在对应记录时更新，不存在时新增。这个工作流把业务触发、查询、判断分支和数据写入连接起来。
围绕业务变化配置规则
流程列表还包含预约状态更新、客户状态标注、导流信息变更及门店匹配等规则，分别通过工作表事件与自定义动作组织。列表中同时存在启用和停用流程，因此不将列表总数作为上线成果。
跨系统流转
系统还通过自动化与 webhook 连接企业微信、小程序、ERP、飞书和明道云。
跨系统集成让订单、客户和门店工作能够沿着业务链继续流转，也要求在规则配置时考虑不同系统分别承担的职责。
05 / 权限不止是“能否登录”
不同使用者需要看到和处理不同的信息。我在系统中设计角色，并分别配置记录范围、操作和字段权限，让业务协作有明确边界。
记录与操作
通过角色配置数据可见范围，以及新增、查看、编辑等操作权限。
字段
在具体应用项中继续配置字段能否新增、查看或编辑，将权限细化到业务信息本身。
移动端设计也延续了角色差异。例如，线索录入中的导流同事默认取当前操作人，GM 或店长可手动修改。权限规则因此成为交互设计的一部分。
06 / 让交互遵循业务上下文
从页面关系，到操作细节
先看整体页面，再放大阅读字段与交互规则。
页面如何串成业务流程
沿着连线查看页面跳转，再结合下方录屏了解实际操作。
- 按来源显示字段：选择线上销售经理导流时，展示相应的导流来源选项。
- 给出符合角色的默认值：导流同事默认取当前操作人，GM 或店长可以手动更改。
- 继承已有信息：车辆选择取用客户基础信息；只有一辆车时默认选中。
- 按订单状态组织查看：客户页面区分排期中、进行中和已完成，关联预约、施工项目、门店及款项信息。
07 / 上线、培训与持续迭代
交付包含验证测试、上线、文档、截图说明、录屏和飞书会议培训。我也根据使用反馈持续迭代系统，覆盖从初建到日常使用的过程。
在内部工具中，业务规则与操作习惯需要一起落地。因此培训、解释和反馈收集也是本人职责的一部分。
08 / 2026 年：迁移到飞书多维表格
2026 年，将门店系统平台从明道云迁移至飞书多维表格。新的工作方式结合飞书卡片、多维表格和机器人 webhook，重点是加速业务信息在协作环境中的流转。
| 原平台 | 迁移后的组合 | 工作重点 |
|---|---|---|
| 明道云 | 飞书多维表格 + 卡片 + 机器人 webhook | 业务信息记录、通知与协作流转 |
这次迁移延续了同一条产品主线：围绕使用者的工作方式，选择能够承载业务结构与信息流转的平台。
09 / 项目结果与能力沉淀
系统于 2022–2026 年持续投入业务使用，支撑 5 城 11 家直营门店，累计沉淀超过 33 万条业务记录。它覆盖了客户、施工交付、内部资源管理和售后质保等多个环节。
这段经历体现了我从业务需求出发，设计系统结构、配置自动化、处理权限、参与交互设计，并推进测试、培训和迭代的实践。低代码是实现方式，完整的业务落地过程是这项工作的核心。