作品细节
订单流程。
带状态筛选的订单表格、在侧边抽屉中打开的单个订单，以及背后的库存数量。
概述
Relay 是一个概念项目，客户是一家虚构的家居品牌：它直接面向消费者销售，业务规模已超出电子表格所能承载的范围。订单来自线上商店，库存分散在两个地点，三个团队用三种不同的工具回答同样的问题。项目需求是：打造一个全公司共同使用的内部平台。
项目需求
- 问题
- 订单、库存与客服分散在不同工具中，全靠复制粘贴衔接。
- 限制
- 必须兼容现有的线上商店、物流承运商与财务工具——无需耗费一个周末做数据迁移。
- 方案
- 在这些工具之上构建一个内部平台：订单流程、实时库存、角色权限与数据看板。
处于这一阶段的品牌，往往靠东拼西凑的工具运转：订单在店铺后台，库存在电子表格里，退货在共享邮箱中，其余一切都在聊天群里。每一次交接都是一次复制粘贴，而每一次复制粘贴都可能导致发错货。
Relay 把订单的完整生命周期集中到一个界面上。订单通过集成从线上商店同步进来，依次经过清晰的状态——新订单、打包中、已发货、已送达——并保留各自的历史记录。库存按地点分别统计，订单付款的那一刻即完成预留，因此屏幕上的数字就是货架上的数字。
角色决定每个人能看到什么。客服可以退款，但不能改动库存；仓库可以打包和打印面单，但看不到营收；创始人则拥有数据看板。每一项操作都会记录操作人和时间，问题由记录来回答，而不是靠记忆。
关于此概念项目
这是为虚构客户打造的概念项目，用以展示我们在客户合作中遵循的流程与标准。
方法
先为业务建模，再绘制界面。
数据模型先行
在绘制任何界面之前，先为订单、商品、库位与人员建模。模型正确了，大多数界面就只是清晰的表格和简短的表单。
一个状态，一个负责方
每个订单只有一个状态，也只有一个团队负责推进。任何人打开订单，首先看到的就是下一步操作。
集成，而非替换
线上商店、支付、物流与财务工具继续发挥各自所长。Relay 通过 API 与它们同步，成为实际开展工作的地方。
交付内容
为日常使用它的人而打造。
数据以概念项目需求为准。
模块
5个模块
订单、履约、库存、客户与分析——统一的导航、统一的搜索、统一的权限体系。
角色
四种角色，一套权限模型
所有者、运营、仓库与客服，每个角色只拥有工作所需的操作权限。每一项变更都有记录。
集成
4项集成
店铺订单、支付、物流面单与财务数据导出，各自配有同步状态与错误日志。
状态
为忙碌的日子而设计
每张表格都设计了空状态、加载中、未同步与出错状态，即使 API 响应缓慢，订单也不会看起来像是丢失了。
技术栈
- Next.js
- TypeScript
- PostgreSQL
- Prisma
- 基于角色的访问控制
- Webhooks
- Vercel