易歪歪成员工作量怎么统计？

易歪歪电脑版的成员工作量统计，核心在于把“谁做了什么、什么时候做的”和“这些动作如何计分”三件事结合起来：先从系统会话与消息日志抓取原始数据（会话ID、坐席、时间戳、动作类型、渠道、标签等），再按明确的业务规则把动作归类为“接待/回复/解决/转接/闲置”等维度，最后用直接计数或加权公式汇总出每位成员的数量指标与加权工作量，并通过时间段、团队或渠道过滤及导出或对接BI做可视化与归档。接下来我按步骤、举例和实际操作细节把方法讲清楚，方便你立刻上手。

先弄清楚：工作量到底指什么？

这个问题看似简单，实际是所有统计的起点。不同团队、不同业务场景，对“工作量”的定义往往不一样。为了好用且可比，我们通常把工作量拆成两类：

数量型指标：容易计数、便于统计，比如会话数、回复次数、完成工单数、转接次数等。
质量/时间型指标：反映效率与质量，比如首次响应时长、平均处理时长、解决率、客户满意度等。这类指标常常与数量指标一起用来打分。

常见的具体维度（可以直接用来建表）

会话数（session_count）：按会话ID去重的会话量。
有效回复数（reply_count）：排除系统提示或重复模板后的人工回复。
首次响应时长（FRT, first_response_time）：顾客发起会话到坐席首次响应的时间。
平均处理时长（AHT, average_handle_time）：从坐席开始处理到结束的总时长。
解决率（resolve_rate）：会话被标记为“已解决”的比例。
转接率、溢出率、重开率等：反映流程或技能匹配问题。
快捷键/话术使用率：衡量坐席利用效率以及话术覆盖度。
在线工时/活跃时长：坐席实际在线或有操作的时长。

易歪歪电脑版中数据的典型来源

虽然我没有你们具体后台的表结构，但大多数客服软件都会保存以下类型的日志，统计就靠这些字段：

会话ID（session_id）——把所有消息和操作串起来的主键。
坐席ID（agent_id）和坐席姓名。
消息/动作类型（message_type / action_type）：比如用户消息、坐席回复、工单关闭、转接、标签更新等。
时间戳（timestamp）：所有动作的精确时间，用于计算时长。
渠道信息（channel）：电商平台、微信、QQ、站内信等。
标签/话术ID（tags / script_id）：判定问题类型或是否使用了快捷话术。
会话状态（status）：未处理、处理中、已解决、无需处理等。

三条可行的统计路径（从简单到完整）

遇到统计需求，通常我按投入与准确度分三种做法，你可以按团队能力和工具选其一或组合使用：

方法一：直接用客户端/后台自带的“统计/报表”模块（最快）

进入“报表”或“统计”界面，选择时间范围、团队/成员、渠道等过滤条件。
选择需要的指标（会话数、回复数、首次响应时长等），系统会展示表格或图表。
可导出CSV或Excel，做存档或进一步处理。

优点：快、不需要技术支持；缺点：灵活度受限，若想做自定义加权或复杂过滤可能不够用。

方法二：导出日志用Excel/透视表处理（中等灵活度）

如果自带报表不满足需求，可以导出原始CSV，然后用Excel做透视、指标计算和可视化。

导出时至少包含：session_id、agent_id、message_type、timestamp、status、tag、channel。
在Excel里做透视：按agent_id与时间分组，统计不同message_type的计数，计算首次响应时长（需要用到MIN/差值函数）。
可在Excel里加入加权公式，生成“工作量得分”列，方便排名和KPI考核。

方法三：用API/数据库+BI工具（最高自由度）

对数据透视、自动化报表、历史追溯要求高时，建议把日志接入数据库或BI工具（如Power BI、Tableau、Metabase）。优点是自动化、可重复、支持复杂计算与可视化。

把CSV/日志表导入数据仓库或直接通过API写入数据库。
在数据仓库里写SQL，按业务规则去重、聚合和计算。
BI工具做图表、仪表盘和权限分发。

如何把动作变成可计算的“工作量”？——实用公式与示例

光数数不够，我们通常需要把不同动作赋予权重，合成一个可比较的“工作量得分”。下面是常用做法与示例公式。

一、常见简单公式（直接计数）

如果你只要数量统计，可以直接用：

会话数 = COUNT(DISTINCT session_id)
回复数 = SUM(CASE WHEN action_type=’reply’ THEN 1 ELSE 0 END)

二、加权得分（既看数量又看质量）

给每类动作分配权重，按业务重要性调整。示例：

工作量得分 = 1×会话数 + 0.6×有效回复数 + 2×已解决数 − 0.5×超时会话数 + 0.2×满意度分

举个数值化例子：

指标	数量	权重	加权分
会话数	40	1	40
有效回复数	90	0.6	54
已解决数	35	2	70
超时会话数	5	-0.5	-2.5
满意度（平均分，满分5）	4.2	0.2	0.84
总得分			162.34

三、时间类指标如何纳入得分

时间类指标（如FRT、AHT）常用“阈值分段”或“反向权重”：

FRT：0-1分钟得1分，1-5分钟得0.6分，>5分钟得0.2分。
AHT越短越好，可以用基准时间除以实际AHT作为系数。

示例SQL片段（思路类、需根据你数据库调整）

下面是常见的按坐席统计会话数与首次响应时长的SQL示例思路：

-- 统计每个坐席当天会话数与首次响应平均时长
SELECT
  agent_id,
  COUNT(DISTINCT session_id) as session_count,
  AVG(first_response_seconds) as avg_first_response
FROM (
  SELECT
    session_id,
    agent_id,
    MIN(CASE WHEN action_type='reply' THEN timestamp END) - MIN(CASE WHEN source='user' THEN timestamp END) as first_response_seconds
  FROM messages
  GROUP BY session_id, agent_id
) t
GROUP BY agent_id;

说明：这里假定messages表里包含session_id、agent_id、action_type、source、timestamp字段。实际表结构不同需要调整。

避免常见陷阱（这些坑容易让统计结果“膨胀”或“不准确”）

重复统计：多窗口、多设备导致同一会话的操作被重复计数——解决办法是以session_id去重。
机器人与系统消息：自动回复或机器人干预应剔除或单独统计。
转接与协同：一个会话跨坐席处理时，如何分配工作量？常见处理是按“主要处理坐席”计数，或把该会话的工作量在参与坐席间按规则拆分。
定义不清：什么算“有效回复”、什么算“已解决”要事先用文档固化。
时区与时间戳：跨时区团队要统一时间基准。

把统计做成可复用的报表：字段与样式建议

下面是一份推荐的“坐席日报/周报”字段清单。把它作为CSV/数据库列头，你会方便很多。

字段名	说明
date	统计日期
agent_id	坐席ID
agent_name	坐席姓名
session_count	会话数（去重）
reply_count	有效回复数
resolved_count	已解决会话数
avg_first_response	平均首次响应时长（秒）
avg_handle_time	平均处理时长（秒）
csat	客户满意度（如有）
weighted_score	加权工作量得分（可选）

落地步骤（一步步操作示范）

先和团队约定“度量定义”：什么是会话、什么是有效回复、谁是主要处理人、如何处理转接。
查看易歪歪是否有“导出原始日志”功能，导出包含上文字段的CSV样本。
用Excel做一次试算（透视表 + 自定义列），确认指标口径与数值合理。
如果需要长期自动化，准备把数据导入数据库并用BI建仪表盘；或用脚本定时处理CSV并发报表。
上线前做一次抽样核对：随机抽10-20个会话，手工比对系统统计是否一致，修正规则。

质量控制与持续改进的几点建议

建立口径手册：把所有指标定义写在文档里，谁都能查。
定期抽查：每周随机抽查若干会话，检查自动统计的准确性。
监控异常：设置阈值告警（例如某坐席的AHT突然翻倍），触发人工复核。
迭代权重：加权得分不是一成不变，按业务优先级和绩效反馈调整权重。

关于多窗口协同与快捷键带来的特殊处理

易歪歪电脑版支持多窗口协作与快捷键，这会对统计产生两类影响：

多窗口：可能会有同一坐席在不同窗口同时处理多个会话，这本身没问题，但同一会话被多个窗口重复写入操作的情况要去重。
快捷键与话术：如果要统计话术使用率，需要在日志里保存话术ID或快捷键触发记录，否则无法区分纯文本回复与模板回复。

若没有内置报表，如何快速做出一个自动化日报（实操提示）

我习惯的做法是：把导出的CSV上传到一个共享的数据库（甚至是Google Sheets也可以），然后写一个每天定时跑的脚本（Python/SQL）计算指标并把结果写成表格或推送邮件。示例流程：

每天凌晨自动导出上一日日志（或接入API自动拉取）。
脚本清洗数据：去重、转换时间戳、识别首次响应等。
汇总指标并生成CSV，保存归档。
把结果发送给主管并更新BI仪表盘。

最后，关于考核的几条实用建议（经验之谈）

数量与质量并重：只看会话数容易让人只追数量，忽视客户体验；只看满意度则可能抑制效率。
小步试错：先做简单可执行的统计，再逐步增加复杂度与自动化。
透明与沟通：把统计方法透明给坐席，避免因为口径不同引发信任问题。
结合业务节奏调整权重：比如促销期可能要更重视响应速度而非解决率。

嗯……写到这里，我想你应该有比较清晰的路线了：先明确口径、拿到日志、先做一次Excel透视确认思路，再决定是用内置报表还是上数据库+BI。如果你愿意把导出的样表或截图发来，我可以帮你把SQL或Excel公式具体写好，或者直接把报表模板做成可以复用的格式，省你不少时间。