DuDu：嘟嘟是一款开源多渠道客服系统

DuDu 嘟嘟是一款开源多渠道客服系统：把微信公众号、Telegram、WhatsApp、企业微信、钉钉、飞书、抖音、小红书等 13 个渠道的来信，收进同一个坐席工作台，数据留在你自己的服务器上，不按坐席数收费。本篇讲清它适合什么样的团队、从源码部署要走哪几步，以及上线前必须先堵上的几个口子。

DuDu 嘟嘟软件信息一览

版本选择：现在能用的只有源码构建，先看结论

结论先行：现在没有一键安装包可下，能用的唯一路线就是拉源码自己构建；等正式发布包的团队，先别把它排进上线计划。把这一点放在最前面，是为了避免有人按普通软件的思路找安装包找半天。

13 个渠道的具体名单是：微信公众号、小程序、企业微信、钉钉、飞书、QQ、微博、抖音、小红书、支付宝、美团、Telegram、WhatsApp。需要注意一个限定：每种渠道对应的是指定的消息体系，不代表该平台的所有产品和事件都可用。渠道接入还要过三道关：账号申请、平台审核、凭据配置，发送还受对应平台权限与会话规则约束。只看渠道数量就拍板的人，上线后很容易在某个渠道的审核环节卡住。

DuDu 嘟嘟部署与上手步骤

1. 先确认团队有没有维护能力：部署和维护需要相应的开发运维能力，数据库、渠道凭据、服务器都要有人管。没人管的系统，上线就是给自己埋雷。
2. 准备运行环境：按项目要求准备 Java 21 环境与 MySQL 数据库，后端提供认证、授权、持久化、渠道适配以及 HTTP 与 WebSocket 能力。
3. 关键卡点：首次建库后立刻换默认口令：Flyway 会自动迁移，首次空库会创建默认管理员。公开服务之前，必须更换默认口令和 JWT 密钥，数据库口令也不能沿用开发值。这一步跳过，等于把客服后台敞着门放在公网上。
4. 开通企业并划分权限：平台管理员开通企业，企业管理员再配置员工、用户组和渠道账号。开通企业时会记录六位企业 ID，坐席只能看到授权范围内的会话。
5. 逐个渠道接通并实测收发：每接一个渠道，都要走完账号申请、平台审核和凭据配置，再实测收一条、回一条。凭据轮换时保持同一 Bot ID，避免换凭据就丢会话。
6. 关键卡点：先在小范围试跑：先让一两个坐席在 Desk 工作台上跑几天，确认会话列表、历史读取、纯文本回复、草稿同步都正常，再全量切过去。MockPulse 只是可选的本地渠道回调模拟工具，运行客服系统本身不需要启动它。

装完必改设置：这 4 处先调好

1. 默认口令与密钥（入口：首次建库 → 管理员账号 → 更换默认口令与 JWT 密钥）：这是上线前优先级最高的一处。体感差别：换之前，任何一个知道默认口令的人都能进后台；换之后，客服数据才算真正留在自己手里。
2. 员工与用户组划分（入口：企业控制台 Console → 员工与用户组 → 配置访问范围）：坐席按用户组划分访问范围，来访标签和内部备注只在有权限的员工之间共享。体感差别：分好组，A 组的坐席看不到 B 组的会话，离职员工停用账号后历史会话仍然保留可查，交接不断档。
3. 工作台布局与提醒（入口：坐席工作台 Desk → 布局 → 专注、并排、卡片；新消息角标提醒）：三种布局按坐席习惯选，实时来信通过 WebSocket 推送，新消息有角标提醒，会话可以按时间和渠道搜索筛选。体感差别：高峰期消息一多，布局和筛选就是坐席的工作效率，默认布局不一定适合所有人。
4. 操作记录与登录日志（入口：平台后台 Admin → 运营概览与操作记录）：平台管理员可以追溯企业操作与凭据变更。体感差别：出了问题能查到是谁在什么时候动了什么，比事后猜要可靠得多；这个习惯要在上线第一天就建立，而不是出事后才想起来开。

注意事项与常见问题

1. 目前暂不支持发送附件：坐席在工作台上发送的是纯文本回复。客服流程里经常要发图片、文件佐证的团队，要先想好附件走什么旁路，别等上线了才发现发不出去。
2. 没有内置 OAuth 向导和渠道健康监控：渠道凭据要手动配置和维护，渠道挂了不会自动报警。团队里要有人定期巡查各渠道状态，或者自己补一套监控。
3. 接收非文本消息取决于具体渠道：研究过某个渠道，不等于它已经接通；每个渠道实际支持的消息类型以实测为准。签约客户之前，先把你们业务必需的消息类型逐个实测一遍。
4. 三个前端的技术栈要有人hold住：Desk、Console、Admin 三个前端独立管理依赖，用的是 Yarn 4、Vite、Tailwind CSS 和 shadcn。前端出问题时，修的人要分得清是哪个前端、哪套依赖，别三个前端混在一起改。
5. 草稿在设备间同步，但别把它当协同编辑：工作台共享会话数据与草稿，支持浏览器访问和 Tauri 桌面构建。两个人同时回同一条会话之前，先在内部备注里打个招呼，避免重复回复客户。

DuDu 嘟嘟适合谁：横向对比一句话

• 适合：能自行部署维护、对数据私有性有要求、渠道多到一个后台看不过来的小团队、中大型企业和电商商家。
• 不适合：没有技术人力、只想注册个账号马上用、或者客服量很小、一个微信后台就能应付的团队，SaaS 客服反而更省事。
• 一句话选型：要的是数据自留、多渠道合一、不按坐席收费，选 DuDu 嘟嘟；要的是开箱即用、有人兜底运维，选成熟 SaaS 客服；渠道只有一两个的，先把现有后台用好，别为合一而合一。

客服系统选型的本质不是功能清单比长短，而是团队能不能长期把它维护下去。一个需要人维护的开源系统，配上一个愿意维护它的团队，才是划算的组合；反过来，再好的架构，没人管都会慢慢烂掉。

推广

关注「软件教程管家」

回复软件名即取即下：网盘下载链接 + 提取码，一步直达，不用再跳转。

相关推荐

开源项目WallpaperMachine 免费下载开发node-rs 免费下载｜Rust 原生绑定包集合开发Roundhouse 免费下载｜Ruby 静态分析开发Flatcar Container Linux 免费下载开发Nature Skills 免费下载开发bddisasm 免费下载｜轻量级 C 指令解码库