
关于 NexaFlow
线索来自 5 个不同的来源:网站、Zalo OA、Facebook 广告、短信群发、电销。每个来源都带有自己的一组字段。但它们都被“倾倒”到同一个区块中——使得界面成为同时存储业务数据和技术数据的地方。重要信息淹没在导入字段之中。销售人员不得不“挖掘”数据,而不是处理线索。
取得的成果
区块结构:从 1 个混乱区块优化为 10 个功能明确的区块。消除重复字段:移除 10 对。分离导入字段:22 个字段位于专用区块(可隐藏)。打开记录时的页眉:姓名 · 公司 · 状态。快速创建:6 个字段按自然顺序排列。数据安全:0 条记录丢失。耗时:仅需一个上午,而非“无人敢动”。
关键成果
10
隐藏重复项
22
分离的导入字段
10
新的结构化块
6
QuickCreate 字段
0
丢失的记录
1
上午
企业挑战
一个混乱的块
来自 5 个来源的所有数据都倒入一个块中。销售人员不知道先看哪里。重要信息淹没在技术字段中。
10 个隐藏重复项
存在 10 个重复字段,但没有人注意到。相同的数据使用不同的名称导致过滤和报告不一致。
22 个导入字段混入 UI
技术跟踪字段(uid、tracking_code、sms_batch_id...)与业务字段混合,使界面杂乱且难以使用。
QuickCreate Sequence = 0
所有字段的 quickCreateSequence 均为 0,导致快速创建表单无法使用。没有人有时间去修复这些“基础问题”。
从 PostgreSQL 读取数据结构
AI read entire structure: blocks, fields, column names, data types
Cross-checked with Prisma schema to detect inconsistencies
SQL query: SELECT fieldname, fieldlabel, block, typeofdata...
检测重复项 — 字段就在眼前但无人处理
AI compared labels/fieldnames, checked data patterns
Example: salutation vs salutationType — both store titles but different names
Prevented errors in filters and reports
将 22 个导入字段从主界面分离
Metadata from SMS broadcast: uid, tracking_code, timestamp, batch_id
For power users, this is 'junk drawer'
Moved all to Block 10 (hidden) — kept for traceability, can hide/collapse
自我检查并检测遗漏字段 (cf_1764)
After restructuring, AI re-ran checklist
Found cf_1764 (Position/Title) still visible in old block, not moved yet
Didn't just fix, also verified after fixing
QuickCreate:首次真正“快速”
6 fields in actual input order
Name → Company → Phone → Email → Source → Owner
Before: sequence = 0. After: purposeful sequence.
客户评价
"潜在客户来自 Facebook、Zalo、网站、短信……每个渠道都不同。员工打开记录却不知先看哪里。AI 读取数据结构,自动分析并重新整理。几乎不需要简报。它很快理解了运营逻辑。"