★ FEATURED ARTICLE 简介这是一套2021年12月修复的PHPlivechat在线客服系统完整安装包面向需要快速搭建自有在线客服的站长、企业管理员和PHP开发者。系统支持无限坐席并提供安卓手机APP客服端让客服人员脱离浏览器也能随时接待访客安装过程采用网页引导直接填写数据库信息和后台账号密码即可完成无需手工导入数据库。包体共451个文件约133.83MB其中php文件承担登录、会话、消息等核心业务逻辑js与html/css负责前端交互和界面渲染png等图片资源用于图标与表情mp3提供消息提示音apk为安卓客服端安装包另含sql、配置文件等辅助内容。资源已获得1107人学习下载附有详细的搭建教程和APP绑定教程并额外提供客服专属聊天链接说明适合从零开始部署或二次开发在线客服系统的用户。1. 为什么 PHPlivechat 还是值得折腾从“无限坐席”到手机端接单的完整链路很多小团队选在线客服系统要么被商业版的按坐席收费劝退要么被 SaaS 版不可定制的地方憋死最后兜兜转转还是回到开源 PHP 方案上来。PHPlivechat 这套系统在 2021 年 12 月的修复版里把老版本在 PHP 7.4 环境下的兼容问题、坐席数量限制、手机端客服入口这几件事情一起收口了这也是它到现在还能被重新部署到新主机上的原因。这篇文章按一线部署的顺序拆开讲先搞清楚它的架构和“无限坐席”是怎么回事再把它跑起来打通手机 APP 客服端最后列一下修复版也躲不过去的几个坑。2. 先搞懂这套系统再动手架构逻辑、坐席上限与修复版的真相2.1 原生 PHP 的架构决定了运维成本和排错路径PHPlivechat 这套系统最核心的卖点不是界面好看而是技术栈足够老、足够稳。它不需要 Node.js、不需要 Redis、不需要单独部署消息队列PHP MySQL 就能把访客聊天窗口、坐席后台、会话记录和基础的管理能力全部撑起来。对没有专职运维的小团队来说这个特性意味着你只需要一台普通主机、一个域名把源码放进去配好数据库剩下的事情就是日常备份和偶尔看一眼日志整个系统的维护面比现在主流的商业客服产品小得多。排错路径也因此变得非常直观。商业 SaaS 客服系统遇到问题你只能提工单等对方排查但 PHPlivechat 是跑在自己主机上的从浏览器请求到 Nginx、PHP-FPM、MySQL 每一层都能看到日志出了问题顺着链路查就行。常见的“访客端能打开但消息发不出去”要么是伪静态规则没配好要么是 AJAX 请求被 PHP 报错拦住了这两种情况都能在十分钟内定位到具体文件。2.2 “无限坐席”是配置问题不是玄学PHPlivechat 的坐席数量上限一般取决于两个地方一个是安装时写入数据库的配置记录一个是启动时从源码里读取的常量判断。很多流传的版本把上限写死在代码里比如 3 个、5 个、10 个也有的版本把上限放在数据库某张配置表里后台界面可以直接改。标题里标注的“无限坐席”通常只是打包者在源码里去掉了坐席数判断或者把判断值改成了一个足够大的数字并不是什么特殊的黑匣子技术。拿到源码包之后你不需要急着登录后台去试先直接在源码目录里搜一下坐席相关的关键词看看这个版本到底把限制放在哪里cd /var/www/phplivechat grep -rn seat_limit\|max_agents\|agent_limit\|max_seats --include*.php . | head -20这条命令会把源码中所有出现坐席限制关键词的位置列出来。输出为空说明这个版本大概率已经在发布前清理了限制逻辑输出里有具体的位置比如if ($agents 3) { exit(seat limit reached); }这种写法说明限制还存在于代码中需要你自己找到对应的常量或数据库配置项调整。还有一种情况是限制在数据库里后台“系统设置”页面会有一个“最大坐席数”的输入框把它改成你团队实际规模或者改成 9999效果一样。部署完成后用一个简单方法验证建三个坐席账号同时登录后台开三个无痕窗口分别登录如果都能正常进入工作台并且能收到访客会话说明坐席上限确实不存在。如果第三个账号登录时被提示“坐席数已满”或“请联系管理员扩容”那就要回头检查上面 grep 命中的代码位置。提示坐席数限制在很多版本里属于授权条款的一部分。个人学习、内部使用调整一下问题不大但如果是商业项目对外运营建议先确认你拿到手的源码包的授权边界避免后续被版权问题找上门。2.3 “2021年12月修复版”到底修复了什么老版本 PHPlivechat 在现有主机环境里部署失败绝大多数不是设计问题而是 PHP 升级带来的兼容性灾难。PHP 7.4 开始早期版本里大量使用的each()、get_magic_quotes_gpc()这些内置函数被彻底移除老代码跑到一半直接抛出 fatal error白屏、登录闪退、接口 500各种现象都会冒出来。修复版的主要工作就是把这类废弃调用替换成当前 PHP 依然支持的写法比如把each()循环改成foreach把数据库连接从老旧的mysql_*系列函数迁到mysqli或PDO。第二个常见的修复点是 JSON 返回格式。老代码里用json_encode()输出中文时默认会转成\uXXXX的转义序列访客端和坐席端如果前端解析逻辑写得不严谨就会出现消息内容显示成乱码的怪问题。修复版一般会把JSON_UNESCAPED_UNICODE这个选项加上让中文直接以原文输出前后端传消息就不会再出现“能收到但全是转义符”的情况。第三个修复点是伪静态规则和入口文件。老版本默认依赖 Apache 的.htaccess做路由如果你用的是 Nginx规则少一段就会导致访客窗口能打开、发送消息的请求却全部 404。修复版通常会把 Nginx 的 server 配置示例一并整理在教程里这也是为什么这个版本号被标成“最新可用”的原因。拿到手之后第一件事不是改代码而是对照教程检查运行环境确认这三点都已经处理过再开始部署。3. 本地把 PHPlivechat 跑起来环境清单、目录部署与首个坐席对话3.1 环境版本清单先用 PHP 7.4 跑稳再考虑 8.0这套系统虽然轻量但环境版本不是随便装的。以修复版的兼容性来说PHP 7.4 是最保守的选择PHP 8.0 以上可以运行但需要你额外做一轮完整测试尤其是登录、发消息、历史记录导出这几个核心流程。MySQL 5.7 或 8.0 都没问题唯一需要注意的是字符集数据库、数据表、连接层三处要统一用 utf8mb4否则中文消息会变成问号。组件建议版本关键点PHP7.4pdo_mysql、mysqli、openssl、mbstring 必须启用MySQL5.7 或 8.0数据库字符集设置为 utf8mb4Web 服务器Nginx 1.18 或 Apache 2.4Nginx 需要配伪静态Apache 默认支持 .htaccess主机配置1 核 1G 起步并发坐席 10 人以内完全够用我在给某公司的模拟项目X部署时踩过一个教训直接用 PHP 8.1 跑老代码访客端打开正常但客服端一登录就抛mysqli_fetch_array()的参数类型错误。原因是老代码里把查询结果传进了预期为数组的函数PHP 7.4 只是告警不中断到 8.1 直接变成致命错误。所以除非你确认源码包已经针对 PHP 8 做了适配否则老老实实用 7.4省下的排错时间比什么都值。3.2 解压与权限源码放进 Web 目录后的三件事源码包拿到手先别急着解压确认一下压缩包结构。常见做法是包里有一层文件夹比如phplivechat/直接解压到 Web 根目录即可。如果包里放着数据库脚本、教程文档、源码三个子目录就把源码目录里的内容复制到/var/www/phplivechat下而不是把整个包都扔进去。目录结构决定了 Nginx 的 root 路径开始就要摆正。unzip phplivechat_202112_fix.zip -d /var/www/ cd /var/www/phplivechat # 如果包里带配置示例先复制成正式配置没有就跳过这一步 cp config.sample.php config.php 2/dev/null || true # 设置 web 用户权限PHP-FPM 才能正常读写会话和缓存 chown -R www-data:www-data /var/www/phplivechat chmod -R 755 /var/www/phplivechat # 如果存在上传目录或缓存目录需要给写权限 chmod -R 777 /var/www/phplivechat/uploads 2/dev/null || true chmod -R 777 /var/www/phplivechat/cache 2/dev/null || true第一段命令把压缩包解压到 Web 目录第二段复制配置示例文件。注意2/dev/null表示如果包里没有这个文件就安静跳过不会中断脚本。后面两条权限命令是这套系统最容易出问题的地方www-data是 Nginx 和 PHP-FPM 的默认运行用户如果不把目录属主改掉PHP 写入 session 或缓存文件时会报 permission denied表现为登录后马上又跳回登录页。3.3 数据库初始化先建库、导数据、再改配置数据库部分的操作顺序很重要先建库、再导入、最后改连接配置三步不能乱。导入的时候留意一下database.sql文件的开头有的脚本里自带CREATE DATABASE语句有的没有。如果带MySQL 导入时会自己创建数据库如果不带你需要先手动建库否则会报No database selected。# 进入 MySQL创建独立的数据库账号和数据库 mysql -u root -p # 建议创建一个专用账号不要把 root 直接给 Web 项目用 CREATE DATABASE IF NOT EXISTS phplivechat DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER phplivechatlocalhost IDENTIFIED BY 换成你的强密码; GRANT ALL PRIVILEGES ON phplivechat.* TO phplivechatlocalhost; FLUSH PRIVILEGES; EXIT; # 导入表结构注意 database.sql 的路径要以实际压缩包为准 mysql -u phplivechat -p phplivechat /var/www/phplivechat/database.sql创建专用数据库账号的意义在于万一源码存在 SQL 注入漏洞攻击者拿到的也只是这个库的权限而不是整个 MySQL 实例。导入完成后编辑config.php文件把数据库连接信息替换成你自己的。配置块大概是这样的结构各版本字段命名略有不同?php // 数据库连接配置块字段名以你拿到的源码包为准 $db_host 127.0.0.1; $db_name phplivechat; $db_user phplivechat; $db_pass 换成你的密码; $db_charset utf8mb4;连接信息里最容易忽略的是$db_charset。PHP 7.4 的mysqli默认字符集是 latin1如果配置里不显式指定 utf8mb4即使数据库和数据表都是 utf8mb4查询结果返回时也会被转成 latin1中文在页面上显示成黑色菱形问号。这个问题在部署时几乎遇不到报错提示但一上线就会被访客截图吐槽属于典型的“翻车不知道翻在哪”的坑。3.4 Nginx 配置伪静态、PHP-FPM 和静态资源缓存数据库就绪后把 Web 服务器配置指到源码目录。Nginx 用户需要特别注意伪静态规则。很多老版本源码依赖 Apache 的.htaccess做 URL 重写迁移到 Nginx 后如果只配置了location /没有配套的try_files页面能打开但所有向 PHP 脚本发起的 AJAX 请求都会变成 404。下面是我在线上常用的一份 server 配置按实际情况替换域名和 PHP-FPM 的 socket 路径server { listen 80; server_name your-domain.com; root /var/www/phplivechat; index index.php; client_max_body_size 20M; # 主路由如果请求的不是真实文件交给 index.php 处理 location / { try_files $uri $uri/ /index.php?$query_string; } # PHP 请求交给 PHP-FPMsocket 路径按 PHP 版本调整 location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } # 静态资源缓存 30 天减少访客端重复加载 location ~* \.(js|css|png|jpg|jpeg|gif|svg)$ { expires 30d; add_header Cache-Control public, no-transform; } }这份配置里有三个要点。try_files $uri $uri/ /index.php?$query_string是伪静态的核心它让不存在的路径回退到入口文件消息接口才能正常路由。fastcgi_pass后面的 socket 路径必须和系统里实际安装的 PHP-FPM 版本一致可以用php -v查看版本再在/run/php/目录下确认 socket 文件名。静态资源缓存那段可视情况保留对访客端聊天窗口的打开速度提升很明显但客服后台如果你经常改样式开发期间建议先注释掉。3.5 跑通首个访客对话十个步骤验证全链路部署完成后先别急着配置坐席按下面的步骤把整条链路走一遍。打开http://your-domain.com/正常情况下会进入访客聊天窗口的页面右侧有聊天浮窗填个昵称就能开始聊天。此时你可能会觉得界面简陋这是正常的访客端和客服后台本来就是两个入口。接着打开http://your-domain.com/admin/首次访问会进入初始化页面创建一个管理员账号设置系统名称和站点 URL。管理员创建完成后进入“坐席管理”页面新建两个坐席账号分别设置好密码。然后打开两个无痕窗口一个模拟访客发消息一个用坐席账号登录后台。如果坐席后台的会话列表里能看到访客的会话卡片点进去能回复说明整条链路已经通了。最后做一次重启验证把 Nginx 和 PHP-FPM 重启确认系统能自动恢复访客再次发消息时不会丢会话。这一步很多人会跳过但实际线上出过的问题恰恰是重启之后数据库连接池没有预热第一个访客请求直接超时。重启后用 curl 探一下首页返回 200 就说明服务恢复了。4. 手机 APP 客服端怎么接从 REST 接口到消息轮询脚本4.1 先搞清楚你手里的是真 APP 还是套壳 WebView标题里写着“带手机APP客服端”拿到安装包之后第一件事是分辨它的实现方式。市场上流传的客服端 APP 分两种一种是原生开发的 Android 应用界面是原生控件启动快、支持系统通知另一种是用 WebView 加载客服后台 H5 页面的“套壳 APP”体积小、开发成本低但体验完全依赖网络和浏览器内核。分辨方法很简单装上 APP打开客服登录页然后开飞行模式如果界面还能显示说明壳里已经缓存了本地页面一旦断网就白屏说明它只是个浏览器。绝大多数流传版本都是 WebView 套壳因为原生 APP 每次改版都要重新编译打包而客服后台的需求变动太频繁用 H5 承载可以随时改服务器端代码不需要用户重新安装。套壳 APP 的优点是部署简单你只需要把 APP 里的接口地址改成你自己的域名登录、会话列表、消息收发全部复用网页版逻辑。缺点是它在 Android 后台容易被系统杀死锁屏后收不到新消息提醒这就要靠 4.2 的轮询方案配合保活机制解决。4.2 最小可用的消息拉取脚本PHP 半小时写完坐席客户端如果手里只有网页后台而没有现成的 APP 安装包还有一个更务实的路子用 PHP 写一个命令行轮询脚本模拟客服端去拉取最新消息。这个方案特别适合值班场景——客服人员不需要一直盯着后台页面脚本检测到新消息后通过系统通知弹出来比守着 Web 页面省心得多。?php // client_poll.php // 轮询拉取新消息的最小实现适合放在值班服务器或安卓 Termux 里跑 $api_base https://your-domain.com; // 改成你的系统域名 $agent_token agent_login_token; // 坐席身份标识可从登录接口获取 $since_id 0; // 本地已处理消息的最大 ID断线重连时能续上 $interval 5; // 轮询间隔单位秒 while (true) { // 用 file_get_contents 发起 GET 请求够用且不需要额外扩展 $url $api_base . /api/messages.php?token . urlencode($agent_token) . since_id . $since_id; $resp file_get_contents($url); if ($resp ! false) { $data json_decode($resp, true); if (is_array($data) !empty($data[messages])) { foreach ($data[messages] as $msg) { $line sprintf([%s] 访客 %s: %s\n, date(H:i:s), $msg[sender_name], $msg[content]); echo $line; // 这里可以接入系统通知命令触发桌面端提醒 // exec(notify-send 新消息 . $msg[content] . ); $since_id max($since_id, (int)$msg[id]); } } } else { // 请求失败时退避避免连续请求把服务器打崩 sleep(15); } sleep($interval); }since_id是这套脚本的核心游标每次循环只拉取大于本地 ID 的新消息不会重复处理历史数据。断线重连后脚本从上次处理到的位置继续不会漏消息。$interval的取值很重要5 秒对单人值班够用如果坐席数量多建议改到 10 秒否则每增加一个坐席终端服务器就要多扛一份轮询压力20 个坐席同时在线时5 秒间隔会让 PHP-FPM 的请求量明显上升。4.3 四个参数按现场调整轮询间隔、超时、重试退避和设备保活轮询方案的调参水平直接决定了服务器能不能扛得住。下面这组参数是我在多个项目里调出来的经验值按团队规模微调即可参数经验值说明轮询间隔5 秒单人值班或坐席数少于 10 时很稳坐席多就调到 10 秒HTTP 超时10 秒PHPfile_get_contents默认超时偏短建议显式设置失败退避2 / 5 / 15 秒连续失败时逐级拉长间隔避免雪崩APP 保活前台 5 分钟 / 后台 15 分钟安卓系统会杀后台进程需要配合前台服务保活第一个坑是file_get_contents的超时设置。PHP 默认的超时时间是 60 秒但如果你不设置stream_context_create底层 socket 超时可能只有几秒网络抖动时请求会频繁失败。建议用curl替代可以精确控制超时时间和重试策略。第二种坑是 APP 锁屏后进程被系统回收轮询脚本直接停摆消息提醒就断了。套壳 APP 的常见解法是引导客服人员把 APP 加入电池优化白名单同时开启通知权限这是安卓系统层面的问题代码里改不了多少。4.4 给手机端补上“未读计数”和“新消息声音提醒”轮询脚本在终端里能打印消息但对真正拿手机值班的客服来说只靠控制台输出不现实。一个实用的做法是在脚本里检测到新消息时通过系统命令触发提醒Linux 桌面环境用notify-send安卓 Termux 环境可以用termux-notification两者都是系统级的通知能力不需要额外付费服务。# 在消息循环里加入通知命令以 Linux 桌面为例 notify-send 在线客服新消息 访客X: 消息内容 -t 5000如果你拿到的是套壳 APP未读计数通常已经内置在 H5 页面里了。只需要确认 APP 的 WebView 开启了 JavaScript 和通知权限未读数会显示在桌面图标角标上。调试这个功能时要注意很多国产手机 ROM 对后台通知有严格限制需要手动在系统设置里允许应用自启动否则锁屏后角标永远停在旧数字上客服会以为一直没人咨询。5. PHPlivechat 部署常见问题排查修复版也躲不过去的 5 个坑5.1 登录后台秒回登录页会话目录与 Cookie 域名的双重问题现象输入管理员账号密码点击登录页面刷新一下又回到登录页没有任何报错信息。看 Nginx 日志也找不到异常PHP 错误日志是空的。原因最常见的是 PHP 会话写入目录不可写。PHP 默认把 session 文件写到/var/lib/php/sessions这个目录的属主如果不对session_start()会失败登录状态存不进去页面每次跳转都视为新会话。其次是 Cookie 域名问题config 里的站点 URL 填写的是localhost但你用 IP 访问后台Cookie 无法匹配登录状态一样存不住。解决先用php -r echo session_save_path();查看实际的 session 目录然后chown -R www-data:www-data /var/lib/php/sessions和chmod 733 /var/lib/php/sessions。改完重启 PHP-FPM。如果还是闪退检查 config 中的站点 URL 是不是直接访问的域名确保没有把127.0.0.1和正式域名混用。5.2 访客窗口能发消息但坐席端一直不刷新轮询接口与浏览器缓存现象访客端发送消息成功气泡正常展示但坐席后台的会话列表停留在旧状态刷新页面才能看到新消息。原因坐席后台的消息列表是靠前端定时轮询接口拉取的如果轮询的 AJAX 请求被浏览器缓存拦截前端拿到的永远是同一个响应看起来就是“一直不刷新”。另一个原因是 Nginx 配置里没有禁用 PHP 动态请求的缓存某些浏览器会缓存 GET 接口的响应。解决在 Nginx 配置的 PHP location 里加上add_header Cache-Control no-cache, no-store, must-revalidate;强制动态请求不缓存。同时检查坐席后台页面的轮询脚本确认它的 URL 是不是带随机参数比如?_t当前时间戳。如果代码里没有加在源码的轮询地址后拼接一个时间戳变量这是最常见的修法。5.3 数据库导入后中文全是问号utf8mb4 的三个断面要一致现象部署完成后在后台能看到菜单是中文但访客发送的中文消息存进数据库后变成??????导出的聊天记录也是一堆问号。原因连接层字符集没有跟着数据库走。MySQL 的字符集设置有三个层面数据库、数据表、连接。数据库和表是 utf8mb4但 PHP 连接配置里的$db_charset保留默认值 latin1写入时把中文转成了无法表示的字符查询显示自然就是问号。部分版本的 SQL 导入脚本里没有写SET NAMES utf8mb4也会导致同样问题。解决第一步在导入 SQL 文件前先执行mysql -u root -p --default-character-setutf8mb4 phplivechat database.sql第二步确认config.php里的$db_charset必须是 utf8mb4第三步检查数据库表的真实字符集用SHOW CREATE TABLE chat_messages;查看如果表不是 utf8mb4用ALTER TABLE转换。三步全部完成后再测试发消息。5.4 手机 APP 消息延迟严重服务器时区与轮询间隔的双重影响现象用 APP 值班时访客发来消息手机上的新消息提醒晚了 3 到 5 分钟才出现有时干脆不提醒打开 APP 手动刷新才能看到。原因延时有两种来源。一是手机后台的轮询脚本被系统限制只能每隔十几分钟唤醒一次二是服务器的时区设置不正确PHP 取date(Y-m-d H:i:s)写入的时间戳比实际时间慢几分钟前端比较时间差时永远认为“没有新消息”。解决先改服务器时区timedatectl set-timezone Asia/Shanghai或修改php.ini里的date.timezone然后重启 PHP-FPM。改完数据库已有的时间字段可能还是旧时区不用管新消息的时间戳对上了就行。APP 端延迟问题去系统电池设置里把客服 APP 加入白名单同时确保轮询脚本用的是前台服务模式。如果两项都做了还是延迟把轮询间隔从 5 秒改成 3 秒试试但这会带来更大的服务器压力坐席数量多时不推荐。5.5 换域名后整个系统跳回旧地址数据库里写死的站点 URL现象把系统从测试域名迁移到正式域名后台能登录但访客端的链接、页面跳转、接口请求全部指向旧域名浏览器报跨域错误。原因这套系统在安装时会把站点 URL 写进数据库配置表前台生成链接时读取的是数据库里的值而不是通过 HTTP 请求自动识别。只改 Nginx 配置是不够的数据库里的旧域名不变系统生成的所有 URL 就还是旧地址。解决登录 MySQL找到配置表把站点 URL 更新为新域名-- 先查出配置表里和 URL 相关的记录 SELECT * FROM settings WHERE setting_name LIKE %url% OR setting_name LIKE %site%; -- 根据查询结果更新字段名以实际表结构为准 UPDATE settings SET setting_value https://your-domain.com WHERE setting_name site_url;更新完还要检查两个地方config.php里如果有硬编码的域名值一并替换以及前端 JS 文件里是否有打包时写死的接口地址。有些版本会把接口地址写在js/config.js里这个文件不清理干净页面打开还会向旧域名发请求。全部替换后强制刷新浏览器缓存再用浏览器开发者工具看 Network 面板确认已经没有旧域名的请求残留。6. 让这套系统更顺手在线状态检测、消息导出与坐席分配的一个改动6.1 用 cron 定时刷新在线状态避免客服离线不被发现PHPlivechat 的客服在线状态依赖前端定时向服务器发心跳请求。如果客服人员直接关闭浏览器没有走正常退出流程系统里的状态可能还停留在“在线”。这时访客发消息消息没人接客服团队却毫不知情。用一个 cron 定时任务模拟心跳可以缓解这个问题# 每 2 分钟触发一次在线检测脚本脚本内部会清理超时会话 */2 * * * * curl -s https://your-domain.com/cron/check_online.php /dev/null 21这个脚本可以在源码的定时任务目录里找没有就自己写一个查chat_sessions表里更新时间超过 5 分钟的会话把对应的坐席状态改成离线。这样即使有人直接拔电源关电脑状态也能在几分钟内被修正。6.2 聊天记录导出一条 SQL 搞定昨日全量对话客服系统运营一段时间后导出聊天记录做质检是很常见的事情。后台未必有现成的导出按钮直接查数据库更省事SELECT sender, content, created_at FROM chat_messages WHERE created_at CURDATE() - INTERVAL 1 DAY AND created_at CURDATE() ORDER BY id ASC;把结果导出为 CSV 就能用 Excel 打开了。如果只想导出某一个坐席的对话在 WHERE 条件里加上agent_id 你的坐席ID数据量不大时这样查没问题数据量大就按时间分段查别一次拉一个月。6.3 坐席分配从“轮流”改成“空闲优先”默认的坐席分配规则往往是轮流分配不管当前坐席手上有多少个正在进行的会话新访客一律排给下一个。结果是有的坐席忙不过来有的坐席闲着没事干。改动思路很简单在源码里找到分配坐席的函数把“按顺序选下一个”改成“从当前会话数最少的坐席里选一个”。这个改动涉及到的代码量不大但效果立竿见影。我第一次在某公司的模拟项目X里改完这个逻辑后访客平均等待时间从 40 多秒降到了 10 秒以内坐席的接待量也均衡了很多。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
