项目速览：6 项关键事实
下面是可以直接引用的事实口径。佣金规则、费率与客户名单属于客户内部信息，本页不展开。
| 项目名称 | 保险代理人展业小程序 |
|---|---|
| 客户与行业 | 银保众联保险代理有限公司（持牌保险代理机构） |
| 承接方 | 南京易企达网络科技有限公司（南京本地团队，可线下对接） |
| 项目定位 | 一位代理人的手机工作台：客户、产品资料、佣金、业绩、团队都在一个入口 |
| 交付形态 | 微信小程序（uni-app 一套代码，约 60 个页面） |
| 覆盖范围 | 产品与资料、客户经营、投保入口、保单托管、佣金与业绩、团队与推荐 |
一位代理人的手机工作台，六块功能
这六块是围绕「代理人一天里要做什么」排的，不是围绕后台管理菜单排的。
产品与资料
按车险、寿险、财产险分线，产品页下面挂着条款、说明书、核保规则、费率表这类合规文件。代理人不用再翻群文件找版本。
客户经营
按区域归集的客户列表，点进去看单个客户。敏感信息在列表层就做遮蔽，不是所有人都能看全。
投保入口
车险、寿险、财产险三条投保路径，代理人可以直接带客户走完，也可把入口分享给客户自己填。
保单托管
客户提交保障需求与服务信息，走服务费支付。保单与后续服务有据可查，不再是口头承诺。
佣金与业绩
预期佣金、已结算、收入明细、按月业绩，代理人在手机上自己看，不用等机构月底出报表。
团队与推荐
电子名片、手写签名、专属二维码三者配套。谁扫的、谁注册的、谁签了约，都归到推荐人名下。
这个项目做对了四件事
保险展业工具的通病是「功能堆满、用的人不买账」，问题通常不在功能，而在信息的准确与归属。
资料不再靠微信群转
条款、说明书、核保规则放在产品页里，版本只有一份。给客户发的是链接，不是截图，也就没有「发错版本」这件事。
佣金和业绩自己查得到
预期与已结算分开看，收入明细可追溯到单。代理人不必反复问内勤，机构也不必每月手工发一遍表。
客户与保单都有归属
谁跟进的客户、谁出的单，系统里记得住。人走了、团队换了，客户与服务记录不会跟着消失。
名片、签名、邀请码替代纸质
电子名片替代纸质递名片，手写签名可导出透明底图片贴在文件上，专属二维码让推荐关系自动落账，不用手工登记。
项目架构：三个入口，四块业务，一套账号
代理人一天的动作是固定的：找资料、发名片、加客户、出单、看佣金、带新人。系统按这个顺序分业务域，而不是按页面堆菜单。
L1 · 入口层（3 个）
代理人小程序
微信 · 资料、客户、佣金、团队
客户侧分享页
H5 · 看资料、走进投保入口
机构运营后台
Web · 产品、人员、结算
L2 · 业务域（4 块，按代理人一天的动作排）
展业物料
产品资料、条款文件、电子名片、手写签名、专属二维码
客户与保单
客户档案、保单托管、三条投保入口
收益
预期佣金、结算明细、按业绩
组织与推荐
合伙人、团队、邀请码、签约状态
L3 · 服务端（Java · Spring Boot）
统一接口
小程序、H5、后台调同一组 API
两级权限
机构看全量，代理人只见自己名下
定时任务
结算、对账与过期判断在服务端跑
L4 · 数据层
MySQL
代理人、客户、保单与收益
Redis
缓存、令牌与接口防重
对象存储
条款 PDF、签名图与名片底图
主轴：代理人账号。客户、保单、佣金、团队都挂在它名下。换手机、换团队、机构加系统，这个账号始终是同一个。
技术选型
- 小程序与 H5：
- uni-app（Vue），一套代码两端编译
- 服务端：
- Java（Spring Boot），按业务域分模块，对外 RESTful 接口
- 数据访问：
- MyBatis-Plus，业务查询与报表 SQL 分开写
- 鉴权：
- JWT + Spring Security，机构与代理人两级权限
- 中间件与存储：
- Redis 缓存与防重，消息队列跑异步通知，条款 PDF 与签名图走对象存储
uni-app 让一套代码同时出小程序和客户分享页；服务端用 Java（Spring Boot），机构自己的技术团队能接得住，不必长期绑在外包身上。
三条设计取舍
钱只在服务端算一次
佣金与业绩由机构后端计算，小程序只负责展示。前端一旦参与算钱，就会出现两套口径，月底必有一场对不上账的争论。
资料给链接，不给文件
条款与说明书挂在产品下，对外发出的是链接。文件更新后旧链接自动指向新版本，从根上消掉「客户手上是旧版」这件事。
敏感字段在接口层就裁掉
客户手机号、证件号这类字段，不同角色拿到的接口返回就不一样。不靠前端隐藏——前端能隐藏的地方，抓包就能看到。
适用边界：什么情况适合做，什么情况先别做
适合：四条同时成立
- ✓代理人分散、不在同一办公地点：需要把资料与工具装进手机。
- ✓产品资料以文件为主：条款、说明书、核保规则版本多，靠群里传容易出错。
- ✓存在佣金、业绩与推荐关系：需要按人归集，且要能说得清。
- ✓机构已有后端系统：小程序只做前端入口，数据仍在自己手里。
不建议直接上小程序：换方案或先理顺
- —只想做静态品牌展示页：那是官网的活，不必上小程序。
- —没有代理人归属与结算关系：先把人和单的关系理顺，再谈工具。
- —客户数据不允许出内网：这类场景应该做私有化部署的内部系统，而不是微信小程序。
- —指望小程序代替合规审核：工具能留痕，但不能替机构承担审核责任。
保险代理人小程序常见问题（7 条）
这个小程序给谁用？▾
主要包含哪些模块？▾
产品资料是怎么管理的？▾
佣金和业绩的数据从哪来？▾
能对接机构现有的系统吗？▾
保险行业的合规要求怎么处理？▾
大概多少钱、要做多久？▾
本页信息
- 发布方：
- 南京易企达网络科技有限公司（微信官方合作伙伴）
- 本页发布：
- 2026-10-30
- 内容范围：
- 项目结果与交付范围说明，不含报价与实现方案；佣金规则、费率与客户名单不对外披露
- 联系方式：
- 400-885-7836 · service@eqiday.com
也在给代理人做工具？
先把三件事说清楚：资料归谁维护、佣金由谁核算、客户跟人还是跟机构。这三件定下来，功能清单才有意义。