电销APP要哪些功能才够用？移动端打开客户管理系统的话单，录音回传与号码脱敏先配齐，再补上离线缓存和外勤定位两项

自有系统的设备表里有 18 条绑定记录，只对应 4 名员工、17 台设备，也就是说这几个人平均每人绑了 4 台手机；而这 18 条记录里，「是否在线」这个字段没有一条是 true。同一套系统里，通话记录 1400 通的「客户端标识」有 1400 个不同值——它不是一个设备号，是每通电话临时生成的一个串。

这三个数字放在一起，正好说明「电销APP要哪些功能才够用」该怎么答：功能不是越多越好，而是手机这一端要能被服务端认出来、能交出证据。绑了几台设备、哪台在线、这通电话是哪台打的、录音有没有传回来——四个问题答不出来，功能表再长也是摆设。

这篇按「手机端必须配齐的四件事 + 随后补的两件事」来讲，每一项都给字段、给配置、给当场能做的验证。文中数字来自自有系统生产库实测（2026-10-25），只说明字段与结构问题，不涉及任何真实客户信息。

一、电销APP要哪些功能：手机端做四件事，客户管理系统做四件事

移动端最容易做错的地方，是把 PC 端的界面「缩小」塞进手机。正确的切法是按数据归属切：手机负责采集与呈现，服务端负责存储与判定。分成两栏就很清楚。

手机上做的四件事：取号并拨打（客户 ID 与号码一起拿到）、挂机回传（把这一通的结果交回去）、写跟进（语音或几个字）、拍照上传（材料、面签照片）。服务端做的四件事：号码解密（谁能看明文、看了留痕）、录音归集（收、校验、挂到客户上）、归属与撞单判定（谁先跟的、能不能打）、统计（通话量、跟进量、覆盖率）。

为什么一定要这样切？因为手机是不受控的环境。它可能没网、可能被用户手动杀进程、可能被第三方安全软件拦掉后台、也可能被人拿走去翻。凡是「手机说了算」的判断，都会在某个时刻失效。所以号码是否可见、这条客户能不能打、这通电话算不算有效跟进，判定一律在服务端；手机只负责把原始事实交上来。

按这个切法，一份够用的功能清单就出来了：脱敏展示、录音回传、离线缓存、设备与在线状态（这四项是底座），外加外勤定位与拍照上传（这两项按业务需要补）。顺序不能反——先做定位打卡这类「看得见」的功能，再补回传和脱敏，结果是打卡能用、数据不可信。下面逐项说。

二、第一件：号码脱敏——手机是最容易被拍照的那块屏幕

PC 在办公室里，屏幕朝着墙；手机在手上，屏幕朝着任何人。客户号码在手机上全量显示，等于把公司最贵的资产印在一张随时能被拍下来的纸上。所以移动端的脱敏不是「体验优化」，是底线配置。

配法有两条路，选哪条取决于业务：

显示层脱敏——数据库存明文，接口默认返回 138****5678，只有点「查看完整号码」时才返回明文，并且这一次查看要落一条记录（谁、什么时候、看了哪个客户）。这条路成本低，适合坐席需要回拨的场景。

中间号映射——坐席看到的是平台分配的一个临时号码，拨打时由平台转接到真实号码。客户侧看到的也是中间号。这条路对客户信息保护最彻底，代价是每条线路都要支持号码映射，且通话记录里的「被叫号」要区分「显示的号」和「真实的号」两个字段。

不管选哪条，有一个坑要提前避开：脱敏是显示层的事，不是数据层的事。本库客户表 40 个字段里，没有任何一个是「脱敏状态」或者「号码密文」——这其实是好事，说明号码存的是明文，可以正常去重、回拨、核对。反过来说，如果哪家系统把星号直接存进库里，那你事后既不能回拨、也不能跟运营商账单核对。判断方法很简单：在客户列表里复制一个号码，粘贴到记事本，如果带星号，那就是存进库里了。

还有两个与脱敏同一层的小配置，容易被当成「以后再说」，实际应该在第一天就做：一是截图与导出的水印——手机端一旦允许导出客户列表，脱敏就形同虚设，所以要么关掉导出，要么在导出件上打「谁导的、什么时候导的」水印；二是复制粘贴的限制——长按号码直接复制，很多人就是这么把名单带出去的，可以在展示层把号码拆成不可复制的图形或分段文本，成本不高，但能挡住随手一存。

脱敏这一项的验收动作：用坐席账号登录 APP，打开一个客户，看号码是否脱敏；点「查看完整」，看是否要求二次确认、是否在操作日志里留下一条记录；再用主管账号看同一个客户，确认主管能直接看到明文（否则主管没法核对）。三种角色的表现不一样，才算配对了。字段级权限的整套设计，见助贷CRM权限怎么分级。

三、第二件：录音回传——三种失败与一条重传队列

录音是移动端最容易「看起来有、实际没有」的东西。本库 1400 通通话里，有录音文件的 678 通，另 722 通的录音状态停在「待上传」。这个状态最容易骗人：它既可能是「录了、还没传」，也可能是「本来就没录」。

移动端录音失败，逃不出三种原因：

一是弱网。录音文件比文本大得多，一条 3 分钟的通话大约几 MB，在电梯、地下室、地铁里传不上去。做法是本地先落盘（不要只放内存），等有网再传；传输要支持断点续传，而不是每次从头来。

二是切后台。安卓上用户接了电话、切到微信、锁屏，都可能让上传进程被挂起。做法是把上传放进系统级的任务队列（WorkManager / 后台传输），而不是放在页面的生命周期里；页面关了，任务还要活着。

三是超时。服务端处理大文件时如果同步等待，客户端会先超时，然后重试，形成「传了三次都没成功、其实三次都在传」的重复。做法是客户端带一个幂等键（比如「通话流水号 + 文件校验值」），服务端见到同一个键就直接返回上次的结果。

比这三点更重要的是状态字段要拆开。一个「录音状态」字段不够用，至少要拆成两个：录音是否存在（有 / 无，由客户端在挂机时判定并上报）、传输状态（未开始 / 传输中 / 已校验 / 失败待重试）。拆开之后，「722 条停在待上传」这种模糊状态就消失了——你会看到「无录音 300 条」和「传输失败 422 条」，前者要去查权限和设置，后者要去查网络和队列。这两件事的处理人都不一样。

还有一条容易被忽略：回传要带校验值。文件传上去之后算一次哈希，和服务端存下来的哈希对一下，对不上就重传。没有这一步，你会得到一批「大小对、内容坏」的录音——能播放，但播到一半断了，而这种问题往往要到质检的时候才发现。录音的存储与调阅见助贷通话录音怎么管理，录音怎么用来做分析见通话录音分析怎么做。

这一项的验收动作：找一台手机，打一通 3 分钟电话，然后依次做三个破坏动作——飞行模式 30 秒再恢复、立刻杀掉 APP、锁屏放置 5 分钟。三个动作之后回到 APP，看这通电话的录音是否 ①最终状态是「已校验」②只有一条录音 ③能正常播放到结尾。三条都过，回传才算配好。

四、第三件：离线缓存——缓存哪五个、坚决不缓存哪三个

外勤场景下没网是常态，所以移动端必须能离线用。但「离线可用」和「离线存客户数据」是两件事，很多系统为了体验把整张客户表缓存到手机上，这是把风险从服务器搬到了更容易丢的地方。

可以缓存的五类：① 当天要打的名单（客户 ID + 脱敏号码 + 姓名首字）；② 该客户的跟进记录摘要（最近三条，纯文本）；③ 字典与话术模板（只读，随版本更新）；④ 待上传的录音与照片（本地文件，加密存储）；⑤ 待提交的跟进草稿（带时间戳，标明未同步）。

坚决不缓存的三个：① 完整手机号与身份证号（离线状态下无法做「谁看了」的留痕，泄了也查不出来）；② 其他坐席的客户（离线缓存往往是整表下发，一旦下发就等于把权限绕过去了）；③ 合同与流水原件的完整副本（这类文件应当「用时下载、用完即焚」，而不是长期躺在手机上）。

缓存还要有一个「清理规则」，否则手机会变成一个移动数据库：任务完成后 24 小时内清掉名单缓存；已同步的录音与照片立即删本地副本；员工离职或设备解绑时远程下发清空指令。第三条最容易被跳过，但它恰恰是「离职带走客户」这条风险链上的一环，相关机制见客户公海池怎么设计里的回收与解绑部分。

离线还有一个技术细节：冲突怎么合并。坐席在飞机上给客户 A 写了跟进，同时主管在 PC 上把客户 A 转给了别人。回到有网时，这条跟进应该跟谁走？建议规则是「跟进记录跟着客户走，不跟着人走」——即按客户 ID 落库，同时把「记录人」和「当时归属人」都存下来。这样不管归属怎么变，这条沟通事实都还在。

这一项的验收动作：手机开飞行模式，完成三件事——打开一个客户的详情、写一条跟进、拍一张照片；然后关掉飞行模式，看三件事的结果：详情能不能打开（缓存生效）、跟进是否自动提交（草稿同步）、照片是否挂到了这个客户下（文件归位）。三件都成，离线才算可用。

五、第四件：设备与在线状态，别拿会话表算在线人数

这一项最不显眼，但它决定了前面三项能不能被追责。先看本库的两个实测。

设备表：18 条记录 / 4 名员工 / 17 个不同设备号。平均每人绑了 4 台多（一人 2 台、两人各 5 台、一人 6 台）。「是否在线」字段 18 条全是 false，最后活跃时间最早停在 2026-08-27、最新到 2026-10-23。这说明设备表建了、也写入了，但「在线」这个状态没有被持续维护——没有心跳，就没有在线。另外 18 条里 16 条版本号是 1.0.0、2 条是空的，说明版本上报也不完整。

会话表：23 条记录 / 23 名员工 / 8 个 IP。看 User-Agent 会发现问题：15 条是浏览器、7 条是 Python-urllib、1 条是 curl。也就是说，这张表记的是「谁在访问接口」，其中混进了服务端脚本。拿它算在线人数，会把接口调用算成在线人力。这不是这张表的错，是「用错了表」。

所以第四件要配的是三样东西：

设备绑定关系——一台设备绑一个员工，字段至少五个：设备号（系统级唯一，不是自己生成的串）、平台、APP 版本、绑定时间、最近心跳时间。这里要特别提醒：本库通话记录里的「客户端标识」1400 通有 1400 个不同值，它不是设备号，是每通电话生成的流水标识。用它去判断「这台手机打了多少电话」是判断不出来的，要做这件事必须另建绑定关系。

心跳——APP 在前台时每 60 秒上报一次，退到后台就停。服务端据此维护「最近活跃时间」，超过 5 分钟不在线。心跳要轻（不要每次都带一整包客户数据），要能容忍失败（丢了就等下一次）。

换设备与解绑——换手机要能自己解绑（否则一个人占着 6 个设备位），离职要能强制解绑并清缓存。这两条不做，设备表迟早变成一张「历史上谁用过什么手机」的流水账。

这一项的验收动作：拿两台手机分别登录同一个账号，看是否触发「已在其他设备登录」的提示；把其中一台的网断掉 6 分钟，看服务端的在线状态是否变成离线；再用「在线人数」这个指标和实际打开 APP 的人数对一次，对不上就说明取数取错了表。

再补一句版本管理：设备表里 2 条记录的版本号是空的，这意味着你没法回答「还有多少人用着旧版本」。移动端和 PC 最大的不同是你无法强制升级——应用商店审核、用户不点更新、企业内分发渠道滞后，都会让旧版本活很久。做法是服务端按版本下发能力开关：新功能只在某个版本号以上可见，旧版本继续可用但缺功能，并且把「版本分布」做成一个能看的数。这一条不做，每次修完一个回传的 bug，你都不知道到底修好了多少人手上的那一版。

六、外勤定位与拍照上传：位置字段该落到哪一格

先说一个实测结论：本库 74 张表里没有任何一个经纬度字段——按 lat / lng / geo / location 检索全部列，命中的只有 platform（设备平台）和 template（模板）这两个词，属于误匹配。带「地址」字样的字段只有 leads.register_address、channels.branch_address 这类文本地址。也就是说，外勤定位在这套系统里不是「开个开关」，而是要新建字段。

新建的时候有三个决定：

决定一：定位是「签到那一刻取一次」还是「持续上报」。持续上报耗电、耗流量，且很容易滑向「监控员工」，多数机构不需要。建议只在三个动作时取一次：签到、拍照上传、签退。取一次就要落一次，落四个字段——经度、纬度、精度（米）、来源（GPS / 基站 / 手工填写）。

决定二：精度要存，且要能判定。同一个「打卡」动作，GPS 精度 20 米和 3000 米是两回事。存了精度，才能定规则：精度大于 500 米的签到标为「位置待核」，不作为考勤依据。这一条能挡住绝大多数「在家打卡」的争议——不是靠人去查，是靠字段自己说明。

决定三：谁能看位置。位置信息的敏感度高于客户名单，默认应当只有直属主管能看，且只能看「最近一次」，不能拉历史轨迹。这一条要和权限体系一起配，别单独开一个「定位报表」给所有人。

拍照上传这一项，重点不在拍照，在归档与命名：照片必须挂到具体客户或具体进件记录上，文件名带业务编号，而不是存在手机相册里等人工整理。上传后要能按客户查到「这个客户交过几张材料、什么时候交的」。如果这一层不做，照片就是一堆散图，检查时找不出来。

这一项的验收动作：在一个陌生地点签到，然后看这条签到记录的四个字段是否都有值、精度是否合理；再上传一张照片，去客户详情页看这张照片是否出现在这个客户的材料列表里。位置有了、归档也有了，这项才算落地。

七、移动端字段清单：显示什么、藏什么

把上面几节收成一张表，就是一份可以直接拿去配的清单。判断标准只有一条——手机上显示的每一个字段，都要能回答「被别人看到会怎样」。

必须在手机端显示的：客户姓名（可只显示姓 + 先生/女士）、脱敏号码、来源渠道、阶段、最近一次跟进时间与结果、下次跟进时间、负责人（自己）、待办提醒。这些是坐席当场要用到的，缺一项就得打电话问人。

可以显示但要留痕的：完整号码（点击查看，落日志）、身份证后四位、进件材料的缩略图。这类字段的共同点是「偶尔需要」，所以给入口，但每次打开都记账。

手机端一律不显示的：其他坐席负责的客户、客户的历史成交金额与佣金、其他渠道的名单、内部备注里的风控意见。前两项是权限问题，后两项是「看到了会出事」的问题——比如风控意见被客户看到，比泄露一个号码严重得多。

只在服务端保留的：完整身份证号、合同与流水原件、录音原文件、操作日志。这些不是「不给看」，是「用时下载、带水印、不留本地」。这也是移动端和 PC 端最本质的差别：PC 有固定的办公环境，手机没有。

配置的时候有个顺序建议：先配「藏什么」，再配「显示什么」。因为「显示什么」是业务部门提需求，会一直加；「藏什么」是底线，一旦漏了就补不回来。这一层的整体设计可以对照贷款中介客户管理系统怎么搭里的模块清单，先划清哪些是移动端必须、哪些是服务端专属。若是多租户 SaaS 形态，还要多一层租户隔离的考虑，见SaaS客户管理系统有哪些。

八、电销APP常见问题

电销APP和客户管理系统是一套还是两套？理想的形态是一套，两个入口：手机端做采集与呈现，服务端是唯一的数据源。判断是不是一套，只需看一件事——在手机上写的跟进，PC 上打开同一个客户能不能立刻看到；反过来，PC 上改了归属，手机上的名单会不会跟着变。两边要是一致，就是一套；要各看各的，那就是两套系统共用一个登录。打通的五个环节见电销助手和客户管理系统怎么打通。

录音一定要存在手机上吗？不要。手机只是中转站，录完尽快上传，本地副本在上传成功并校验通过后立即删除。把录音长期留在手机上会遇到三个问题：占空间导致用户清理、换机丢失、离职后无法回收。本库 678 通有录音、722 通停在待上传，这个比例本身就说明「以手机为准」的做法很难持续。

离线可用和号码脱敏冲突吗？不冲突，但要分清楚缓存什么。脱敏号码可以缓存（它本身就是脱敏的），完整号码不要缓存。这样离线时坐席能看到「138****5678」并直接用中间号或回拨通道打出去，既不影响业务，也不会在手机上留下明文。

怎么判断这套电销APP值不值得上线？做四项验证，每项都能当场做：①断网 30 秒后录音是否只剩一条且能播完；②飞行模式下能不能打开客户详情并写一条跟进，恢复网络后是否自动提交；③两台手机登录同一账号是否互斥；④在陌生地点签到，精度是否落库。四项过三项就可以上；四项里有两项过不去，说明底座没打好，先别急着加功能。要按坐席数与线路数估一下成本，可以查看价格与版本说明。

员工用私人手机装 APP，公司能管到什么程度？能管到「业务数据不留在他手机上」，管不到「他手机上装了什么」。所以边界要写清楚：只采集业务相关的四类数据（名单、跟进、录音、材料照片），不读通讯录、不读短信、不做持续定位。这个边界既是合规要求，也是能不能推得动的关键——坐席一旦怀疑 APP 在偷看别的，就会用各种办法绕过它，那时候你拿到的数据反而更假。想把边界写成制度，可以参考电销智能质检怎么做里的权限与留痕思路，把「能做什么」和「留什么痕」分开写。

回到开头那三个数字：18 条设备绑定、0 条在线、1400 个客户端标识。它们说的不是「这套 APP 差」，而是「这套 APP 只做了一半」——能拨号、能通话，但认不出设备、算不准在线、留不住录音。补的顺序也很清楚：先把设备与心跳补上（有了身份，才谈得上追责），再把录音回传的状态拆开（有了状态，才谈得上催办），最后才做脱敏与离线（这两项是体验与安全的平衡）。四件事做完，功能表上那些「看起来很全」的项才有意义。