简介：这是面向CRM系统前端设计与开发的一份原型资源，适合正在做毕业设计、课程项目或希望了解客户关系管理交互流程的开发者。原型围绕销售、市场营销与服务业务展开，重点展示JavaScript表单验证、jQuery交互优化以及Ajax无刷新数据更新等常见实现思路。资源以RAR压缩包形式提供，整体大小约10MB，因上游未提供文件总数与类型明细，包内具体文件结构需下载后自行查看。目前已有301人学习/下载，说明该原型在实际项目中具备一定参考价值。对学习者而言，可借助页面草图、交互流程图、代码示例与注释，快速理解CRM系统前端模块的组织方式，尤其是客户信息实时查询、订单状态更新和销售数据同步等场景的界面反馈逻辑；同时也能通过界面布局和响应式设计思路，为自己的管理系统搭建提供可复用的原型基础。
1. CRM客户关系管理系统原形：先想清楚再写代码，比选什么框架重要十倍
先说一个反直觉的结论：做CRM客户关系管理系统原形，最难的从来不是技术——列表、表单、弹窗、权限这些谁都能写——而是数据模型。客户和联系人到底算一张表还是两张？跟进记录挂在客户上还是挂在商机上？标签系统要不要一开始就上？这些决定一旦写进代码，后面想改就是伤筋动骨。我见过不止一个团队，框架选的是最流行的，页面做得也像模像样，结果跑到第三个月发现客户去重逻辑根本没法做，因为当初压根没留唯一标识的余地，整个库要重渲。标题里的“原形”，其实就是原型，意思是先花一到两周跑通一条最核心的客户管理链路。这篇笔记就按这套思路，从数据模型到后端接口再到能做演示的页面，带你走一遍决策路径和落地代码，每个选择我都告诉你理由和代价。适合谁看？想快速给客户或领导演示业务闭环的产品经理，需要从零交付一个可运行系统的全栈工程师，还有刚起步想在内部管一管客户线索的小团队——照着抄，能少走弯路。
2. 核心数据模型：客户归属、跟进记录、标签体系是三个必须一开始就定死的决策
2.1 客户表与联系人的关系：偏粗还是偏细，取决于销售场景的复杂度
做CRM原形，最常见的误区是一上来就照着Salesforce抄，建了二十多张表，结果光是搞明白表之间的关系就花了一周，业务方还说不清要不要。我自己的习惯是：先建四张必选表，客户、联系人、跟进记录、用户，另外加一张可选的标签表，加起来五张，先把主链路跑通，后面有需要再加。客户表和联系人表的取舍是第一个决策点。如果你的销售场景是“一个公司多个对接人”，那就拆成两张表，客户表存公司主体信息，联系人表挂在外键上；如果场景极其简单，比如做的是To C的线下门店客户登记，一张表也够。我一般建议拆，因为拆分后做客户去重只针对客户表，联系人可以松散管理。客户字段里必须预留一个“唯一标识候选”——通常是统一社会信用代码或者自定义的客户编号，为后面数据清洗和去重留一条活路。这个字段在原型阶段可以允许为空，但列必须存在。
联系人字段相对简单：姓名、手机、邮箱、客户ID、职位、备注，再加一个“是否主联系人”的布尔位。这里有个容易忽略的点：手机号不要存成整数，要用字符串，因为后面不管对接哪个平台的接口，手机号都有可能带回前缀或分机号，整数类型直接截断，血泪教训。客户表和联系人表看起来简单，但注意索引设计——客户表在“归属销售ID”和“创建时间”上建索引，联系人表在“客户ID”上建索引。这是查询最频繁的两个维度，没索引的话，数据到三万行左右就明显慢了。SQLAlchemy模型建表如下：
from sqlalchemy import Column, Integer, String, DateTime, Boolean, ForeignKey, Text from sqlalchemy.orm import declarative_base, relationship from sqlalchemy.sql import func Base = declarative_base() class User(Base): __tablename__ = "users" id = Column(Integer, primary_key=True) username = Column(String(64), unique=True, nullable=False) display_name = Column(String(64), nullable=False) created_at = Column(DateTime, server_default=func.now()) # 销售负责的客户集合，与Customer建立一对多关系 customers = relationship("Customer", back_populates="owner") class Customer(Base): __tablename__ = "customers" id = Column(Integer, primary_key=True) company_name = Column(String(255), nullable=False, index=True) unified_code = Column(String(32), unique=True, nullable=True) # 唯一标识候选：统一社会信用代码 industry = Column(String(64), nullable=True) # 行业，原型阶段存字符串即可 owner_id = Column(Integer, ForeignKey("users.id"), nullable=False, index=True) status = Column(String(16), nullable=False, default="active") # active/disabled/lead created_at = Column(DateTime, server_default=func.now(), index=True) updated_at = Column(DateTime, onupdate=func.now()) owner = relationship("User", back_populates="customers") contacts = relationship("Contact", back_populates="customer") follow_ups = relationship("FollowUp", back_populates="customer")这段模型里，unified_code是唯一索引字段，这就是前面说的为去重预留的位置。status字段用字符串不用数字枚举，目的是原型阶段可以灵活扩展状态值——比如你要加一个“跟进中”的状态，字符串直接插进去就行，数字枚举就得改代码。owner_id加了索引，因为按销售筛选客户是最高频的查询。关系对象owner、contacts、follow_ups让后续做联表查询时可以直接通过ORM拿数据，省去手动拼接外键的麻烦。注意updated_at没有加server_default，因为数据库触发器不是SQLAlchemy默认行为，ORM会在更新时自动填充，但如果你绕过ORM执行原生SQL，这个字段就不会更新——原型阶段可以接受，生产环境要用数据库触发器兜底。
2.2 跟进记录的时效价值及权限归属：二进制归属还是分组视图
跟进记录是整个CRM系统里数据量增长最快的表，也是销售最看重的东西——客户有没有近期联系过，聊了什么，状态卡在哪，全看这张表。设计跟进记录表时，核心决策是“归属”问题：跟进记录挂在哪一层？有人挂联系人，有人挂商机，我的建议是原型阶段直接挂在客户上，用follow_up_type区分是电话、拜访还是邮件，再通过一个related_contact_id可空字段指向具体联系人。为什么这样设计？因为原型的核心目标是让销售按客户维度查看“最近发生的事”，而不是按联系人维度追溯历史。直接挂客户意味着写查询简单，一个客户ID就能拿到全部记录。如果需要按联系人过滤，加一个可空外键查询即可，完全不影响主链路。
created_by字段必须记录操作人，这是CRM权限设计的数据基础。原型阶段不做复杂权限系统，但要明确一个规则：所有销售只能看到自己的客户和跟进记录。这个规则在模型里不需要特殊表示，在后端查询时统一过滤。如果一开始就设计成“同事之间互相可见”，后面的数据隔离改造会非常痛苦。再要求一个next_follow_up_at字段——下次跟进时间——这是原型系统里最有业务价值的一个字段，所有“今日待跟进”提醒功能都建立在它上面。很多团队把这个字段做成计算值，但我的建议是直接存一个显式的可空时间戳，由销售在跟进时填写，这样查询和排序都简单得多。模型如下：
class FollowUp(Base): __tablename__ = "follow_ups" id = Column(Integer, primary_key=True) customer_id = Column(Integer, ForeignKey("customers.id"), nullable=False, index=True) created_by = Column(Integer, ForeignKey("users.id"), nullable=False) follow_up_type = Column(String(16), nullable=False, default="call") # call/visit/email/other content = Column(Text, nullable=False) # 跟进内容，必填 next_follow_up_at = Column(DateTime, nullable=True, index=True) # 下次跟进时间 created_at = Column(DateTime, server_default=func.now(), index=True) customer = relationship("Customer", back_populates="follow_ups")customer_id和created_at都建索引，因为“某个客户的全部跟进记录”和“某天的所有跟进记录”是两类最典型的查询。next_follow_up_at也建索引，支撑“今天要跟进哪些客户”这种待办查询。内容字段用Text不用String(255)，销售写跟进记录往往一大段，截断会有信息丢失。参数上有个细节值得注意：follow_up_type加了默认值"call"，这样前端就算漏传类型，数据也不会为空。所有字段里，content必填，其余都可空，这是刻意的——跟进记录没有内容就没有任何价值。
2.3 标签系统的边界：原型阶段用字符串列表，不要上多态关联
标签系统是CRM原形里最容易被过度设计的部分。一说到标签，就容易想到多态关联——一张标签表、一张标签绑定表，绑定表里同时存对象类型和对象ID，这样客户、联系人、商机都能打标。听上去很灵活，实际用起来全是坑：查询时要做多态判断，统计时报表要拆着算，最后标签表变成垃圾堆。我的建议是：原型阶段，每个对象上直接加一个tags字段，用逗号分隔的字符串存储，比如"高意向,近期活跃"。查询时用LIKE匹配，统计时在Python里做切分聚合。这个方案的数据冗余是有的，但对于十万行级别的客户数据来说，性能完全不是瓶颈，换来的是极大的实现简单度。
等业务跑到需要标签多维筛选——比如“标签是‘重点客户’且行业是‘制造业’”——再把标签抽成独立表，这是后话。原型阶段把标签做成独立表，最大的问题是没人给标签维护做录入闭环，最后标签字段全是空的，等于白建。字符串存标签虽然“不体面”，但是能跑起来。如果非要结构化，折中方案是做一张单表标签定义表，客户表里存标签ID列表的JSON字符串。我不推荐这个方案，因为翻数据的时候你要解析JSON，加一个标签要改整条记录，并发时还有潜在的写冲突。最简单的最有效，先记住这句话。
3. 搭建后端最小闭环：FastAPI 加 SQLAlchemy，用最短路径把客户增删改查跑通
3.1 REST 资源划分与权限过滤基线
后端选型上，如果用Python，FastAPI是目前做原型最顺手的框架——自带数据校验、自动生成交互文档，省去手动写接口文档的工夫。接口划分遵循“资源”思路：/customers、/contacts、/follow-ups、/users，每个资源一组增删改查。权限基线用最简方案：依赖注入，在查询层统一追加owner_id过滤条件，而不是在每个接口里重复写。这样即使后面加了新的查询接口，只要接入了当前用户依赖，就不会漏掉数据隔离。
一个常见的翻车点是：很多原型系统把权限过滤写在queryset查找之后，结果列表接口过滤了，详情接口没过滤，用别的销售账号翻ID就能看到别人的客户数据。正确的做法是写一个全局依赖，把user_id注入到数据库查询的where条件里，接口里写的所有查询都基于这个依赖。这样设计的基础是用户体系，连登录都没做的情况下，可以直接在请求头里传X-User-Id，后端拿这个作为当前用户。原型阶段这样做没问题，但要在代码里留个注释，提醒后面接入真实鉴权时替换。FastAPI 加依赖注入的例子：
from fastapi import FastAPI, Depends, Header, HTTPException app = FastAPI() def get_current_user(x_user_id: int = Header(...)): if not x_user_id: raise HTTPException(status_code=401, detail="Missing user header") return x_user_id @app.get("/customers") def list_customers( user_id: int = Depends(get_current_user), session: Session = Depends(get_db), keyword: str | None = None, status: str | None = None, page: int = 1, page_size: int = 20, ): query = session.query(Customer).filter(Customer.owner_id == user_id) if keyword: query = query.filter(Customer.company_name.like(f"%{keyword}%")) if status: query = query.filter(Customer.status == status) total = query.count() customers = ( query.order_by(Customer.created_at.desc()) .offset((page - 1) * page_size) .limit(page_size) .all() ) return {"total": total, "items": customers}这个接口示例里，Depends(get_current_user)就是权限过滤基线，所有查询从一开始就强制加上owner_id == user_id的条件。keyword和status是动态条件，传了就过滤，不传就返回全部——None判断比拼字符串SQL安全得多。分页参数page和page_size带默认值，避免前端忘传导致全表返回。注意total和items是分开查的，原型阶段可以接受这种“两条SQL”的方式，数据量上去了再考虑用窗口函数优化。还有一个容易被忽略的点：order_by(Customer.created_at.desc())保证了列表顺序稳定，否则翻页时数据可能在最后一页之后又出现新增的记录插入到前面，用户会以为数据乱了。
3.2 跟进记录的提交与待办查询：两个核心接口的实现逻辑
客户列表的增删改查没什么特别的，真正能体现CRM原形业务价值的是两个接口：提交跟进记录、获取今日待跟进列表。提交跟进接口做的事不复杂——插入一条记录，更新客户上的last_follow_up_at和status——但这里有个隐藏事务问题：插入和更新必须放在同一个数据库事务里，否则可能跟进记录存上了，客户状态没更新，后台对不上。SQLAlchemy的session.commit()默认放在最后统一提交，但要注意捕获异常后要显式rollback。提交跟进接口参数里，next_follow_up_at是可选的，但如果有值，前端应同时把“今日待跟进”对应的提醒标为“已处理”，否则用户明明是去处理待办，但提交完待办还挂在那里。这个逻辑不在后端接口里强制，而是要靠前端跳转时处理好状态变更。接口代码：
from datetime import datetime @app.post("/customers/{customer_id}/follow-ups") def create_follow_up( customer_id: int, payload: dict, user_id: int = Depends(get_current_user), session: Session = Depends(get_db), ): customer = session.query(Customer).get(customer_id) if not customer or customer.owner_id != user_id: raise HTTPException(status_code=404, detail="Customer not found") follow_up = FollowUp( customer_id=customer_id, created_by=user_id, follow_up_type=payload.get("type", "call"), content=payload["content"], next_follow_up_at=( datetime.fromisoformat(payload["next_follow_up_at"]) if payload.get("next_follow_up_at") else None ), ) customer.last_follow_up_at = datetime.utcnow() if payload.get("status"): customer.status = payload["status"] session.add(follow_up) session.commit() return {"id": follow_up.id}注意这段代码里对客户存在性和归属做的双重判断——customer.owner_id != user_id时返回404而不是403，让接口调用者感知不到其他客户的存在，这是数据隔离的规范操作。datetime.fromisoformat用于解析ISO格式时间字符串，前端传YYYY-MM-DD HH:MM:SS就能解析，格式不合法会抛异常，由FastAPI的异常处理器接管返回400。这里有个细节：next_follow_up_at存在数据库里时，建议统一用UTC时间存储，展示时由前端做本地时区转换。这样做的原因是，如果团队成员分散在不同时区，或者后面要接自动化邮件提醒，统一UTC可以避免时区错位。原型阶段图省事直接存本地时间也能跑，但一旦涉及定时任务，坑就会冒出来。取今日待跟进列表的接口思路略过，本质上是一个带着next_follow_up_at在今天的条件查询。
3.3 数据库迁移与初始化数据：别让表结构改动变成翻车现场
原型阶段常有字段调整，最好的做法是引入迁移工具，不仅是为了改库，更是为了记录每次结构变化的缘由。常用的方案是Alembic，它跟SQLAlchemy同出同源，天然适配。初始化顺序是：先定义好模型，然后alembic init alembic，生成版本文件，执行升级。操作看上去不复杂，但实际翻车的往往是环境差异——别人机器上直接upgrade head报错，因为数据库里已经有数据了。建表时不要用drop_all再create_all，这是开发环境的坏毛病，一旦数据重要就后悔药没得吃。规范做法是：开发环境用alembic upgrade head做增量变更，每次模型改动都在本地生成新迁移版本，测试通过后再推到演示环境。迁移引起的字段类型变化，比如字符串变成长文本，Alembic会生成ALTER COLUMN语句，执行时要确认数据库能锁住表，否则线上会直接卡死——原形阶段数据量小，这个坑不太明显，但要养成习惯。
初始化数据也是必要步骤。一张空表很难直观判断业务逻辑是否合理，最少要插入五个虚拟客户、五个联系人、十几条跟进记录。数据要有区分度——不同行业、不同状态、有的有下次跟进时间，有的没有。这样前端页面渲染出来才能看出效果：列表有没有分页、待办排序对不对、状态筛选是否生效。很多团队初始化数据时随手插几句，页面一开全是一个模子里刻出来的，根本测不出问题。
4. 用 Vue 3 搭一个能演示的界面：列表页、详情页、跟进时间线
4.1 页面级路由设计与组件拆分：先画三个页面，少即是多
前端选型上没有必选项，但如果要快速出可演示的效果，Vue 3加Vite是目前搭建成本最低的组合——用它写列表页和详情页不会超过三百行代码。前端页面建议只做四个视图：登录占位页、客户列表页、客户详情页、今日待办页。功能做减法，每多一个页面就多一份维护成本，原型阶段最重要的是把核心链路走通：销售打开客户列表，点进客户详情，填写跟进记录，跳回列表。页面路由设计直接映射这个链路。登录页可以不做真实鉴权，放一个“选择当前用户”的下拉框，把用户ID存到localStorage里，后续所有请求自动带上X-User-Id。这是个偷懒但有效的方案，演示时还能随时切换不同账号看数据隔离效果。客户列表页由三部分组成：顶部搜索框和筛选下拉、中间客户表格、底部分页。表格字段不要贪多，公司名、行业、归属销售、状态、最后跟进时间、下次跟进时间、操作按钮即可。多出来字段让表格横向滚动，观感极差。
客户详情页稍微复杂一点，分为两个区域：上半部分是客户基础信息卡片，下半部分是跟进时间线和填写区。时间线组件自己写最简单的版本就好——按时间倒序渲染出一条一条的记录。组件拆分上，建议把“跟进记录时间线”单独抽成组件，因为它是整段链路里最可能被复用的部分。页面设计一个原则：每个页面只做一件核心事情，不要把跟进记录和客户编辑放在同一个弹窗里，操作路径越短越好。
4.2 接口请求封装与管理跨域：看似琐碎，却是新手最容易卡住的环节
前端代码里最容易卡住的环节不是什么复杂逻辑，而是请求跨域问题。开发环境里，Vite默认跑在5173端口，后端FastAPI跑在8000端口，两者端口不同浏览器就视为跨域。FastAPI需要配一下CORSMiddleware，前端Vite配好代理也好，允许开发期跨域也好，都是可接受的做法。我一般推荐用Vite代理：前端访问/api时由Vite把请求转发到http://localhost:8000，这样最终部署时只需把/api指向后端真实地址，前端不用改动一行代码。接口请求封装用一套统一方法，把X-User-Id统一塞进请求头，避免每次调用时忘了传导致拿不到数据。错误处理统一拦截，出现401或者500时全局提示，不要在组件里去逐段判断错误状态。代码示例走一波：
// src/api/index.js const BASE_URL = "/api"; async function request(path, options = {}) { const userId = localStorage.getItem("user_id") || "1"; const res = await fetch(`${BASE_URL}${path}`, { headers: { "Content-Type": "application/json", "X-User-Id": userId, ...(options.headers || {}), }, ...options, }); if (!res.ok) { const err = await res.json().catch(() => ({})); throw new Error(err.detail || `Request failed: ${res.status}`); } return res.json(); } export const customerApi = { list: (params) => request(`/customers?${new URLSearchParams(params)}`), detail: (id) => request(`/customers/${id}`), createFollowUp: (id, payload) => request(`/customers/${id}/follow-ups`, { method: "POST", body: JSON.stringify(payload), }), };这段封装里，URLSearchParams负责把参数对象序列化成查询字符串，前端传{page: 2, page_size: 20}就能自动拼好。userId从localStorage读取，如果用户切了人要刷新一次页面才生效，这在原型阶段是可接受的。res.ok判断覆盖了所有HTTP错误码，统一往外抛错误，前端页面在catch里做提示即可。这里有个隐藏的坑：FastAPI的422校验错误返回结构是{"detail": [...]}，不是简单的字符串，上面的代码做了.catch(() => ({}))兜底，防止解析失败后抛出的又是另一个错误，导致用户看到两段报错文案。原型阶段的错误提示不用分析得很细，提示“请求失败”加上后端detail信息就足够。
4.3 页面状态管理：不要引入Pinia，用组件内部状态就够了
关于状态管理，原型阶段不要引入Pinia或Vuex。CRM原型的页面间传参非常简单——列表页点击一行，跳详情页时传一个id，用路由参数带着就行。详情页内部的数据通过onMounted里调接口获取，完全不需要全局状态。强行引入状态管理会让前端结构复杂化：要在store里定义state、action、mutation，页面之间还要处理状态同步问题。等确实出现跨页面共享的数据，再引也不迟。这跟后端设计里的“标签系统不要上多态关联”是同一个思维模型——原型阶段一切从简，所有决策都为“快速跑通、快速验证、快速给业务看”服务。业务方看完之后提了修改意见，改前端页面结构远比改数据模型容易。这也是为什么我把数据模型的选型看得比什么都重要，数据模型定的是一棵树的根，前端页面是长出来的叶子。
5. 避开三类经典翻车现场：去重、时区、会话前后端状态不一致
5.1 客户重复数据：做合并功能前，先想清楚合并的归属逻辑
现象：同一家客户公司，销售A录入了一条，销售B又录了一条，两条记录各自带不同的联系人。列表翻页时总看到重复的公司名，销售开始质疑系统的数据结构是不是有问题。
原因：客户表没有强制唯一标识，我前面提到的unified_code预留字段在原型阶段允许为空，结果就是同一家公司的记录被插了两遍。如果是不同销售录的，那owner_id还不一样，数据隔离规则一加，两边都看不到对方那条，重复就变成“不可见”的重复了。
解决：原型阶段做一道简单的去重查询接口：通过公司名前缀匹配或者统一社会信用代码精确匹配，列出疑似重复记录。合并的归属逻辑要提前定好，我的建议是保留最新一条作为主记录，把另一条的状态置为disabled，业务数据比如跟进记录，迁移到主记录的ID下，联系人保留在旧记录里但通过外键指向主客户。不要轻易在原型阶段做自动合并——合并是一个不可逆操作，一旦合并错了，数据恢复的成本很高。这个阶段宁可人工择选，也不要自动化。
5.2 时间显示相差八小时：跟进记录的日期全乱了
现象：销售上午10点在界面上填了一条跟进记录，详情页显示的是凌晨2点。
原因：后端存的是UTC时间，前端直接用new Date()去渲染这个字符串，而浏览器把ISO格式的UTC时间自动换算成了本地时区。如果后端存的是纯字符串“2024-11-20 10:00:00”这种没有时区标记的格式，前端就会认为它已经是本地时间，根本不会做时区转换——两种相反的错位方式会同时出现，数据一多直接变玄学现场。
解决：后端存UTC时一定要带时区标记，比如2024-11-20T10:00:00Z。前端用dayjs统一处理时间显示：先解析成dayjs对象，再用.local().format("YYYY-MM-DD HH:mm")输出。请求参数里传时间给后端时，后端要求ISO格式，前端先转换再传。原型阶段不统一时间处理方案，最后页面上的时间一定是乱的。一条规则记住：后端存UTC+带Z标，前端展示local，传参用ISO。
5.3 跟进状态前后端不一致：提交完成后，列表上的状态还是旧的值
现象：销售在详情页填了一条“已成交”的跟进记录，返回客户列表时，那家客户的状态列还显示着“跟进中”。刷新页面后数据才变过来。
原因：前端列表页的数据在初始化时加载到内存里，跳转详情页、提交跟进、返回列表这个过程中，列表页并没有重新拉取数据。Vue Router返回时组件被缓存了（keep-alive），onMounted不会再触发，自然拿不到新数据。
解决：最省事的做法是不用keep-alive缓存列表页，离开就销毁、回来重新挂载。数据量大了之后再考虑用onActivated钩子刷新，但原型阶段直接不缓存是零成本方案。再补一刀：列表页的onMounted里加一个显式的重新拉取动作await loadCustomers()，不依赖组件生命周期“碰巧触发”。后端的数据模型、前端的状态更新是一致的，只需要约定好哪一步刷新列表，避免“看起来不对”的尴尬。
6. 进阶技巧：用三天模拟数据验证你的原型是否真的能支撑起业务判断
原型做到能增删改查、能提交跟进记录，还不算完事。关键验证是：塞进去三个月量级的模拟数据，看看这个系统是否依然好用。这里有个非常实用的做法——写一个数据生成脚本，在五分钟内生成一千个客户、三千条跟进记录，数据在行业、状态、跟进时间上都有足够分布。然后你去真实地操作一遍：按行业筛选一遍、按“今日待跟进”查一下、翻十页列表看响应速度、改一条客户信息保存、再查一下跟进时间线是否一致。这比“写完了页面就交付演示”靠谱得多，因为很多隐藏问题只有在数据量起来、操作路径复杂之后才暴露。脚本生成数据的要点是模拟真实销售习惯：跟进时间集中在工作日的上午九点到十一点，而不是均匀分布；客户的行业集中在几个枚举值上；下次跟进时间有的设置在今天、有的在三天后，还有少部分是昨天——因为昨天那条代表销售漏跟了，这正好能验证待办页的表现。数据结构长什么样、值不值得扩展，就是看你能否从模拟数据里读出业务层面的判断——比如“制造业客户的转化率明显高于互联网行业”，或者“大部分销售都没有填下次跟进时间”。读不出来，说明字段设计离业务太远，或者页面展示混乱，那就回头调数据模型。我个人的习惯是把这套验证做成“标准动作”而不是“临时抽检”，每次模型改动或字段调整后都跑一遍。跑完这轮验证，你对原型信息系统的边界就有了真实认知——哪些字段是业务方真在用的，哪些是当时凑数加的，要不要在二期补上自动去重和批量导入，就有了准确判断。希望这组思路帮你在做CRM客户关系管理系统原形时，少走几段弯路。
本文还有配套的精品资源，点击获取
