Post-migration queue statistics reconciliation between platforms

After migrating from PureConnect, our queue statistics don’t match. GC shows 15% fewer answered calls for the same time period.

We ran both systems in parallel for 2 weeks. PureConnect reported 10,000 answered calls. GC reported 8,500. The calls were identical - routed to both systems. What’s causing the discrepancy?

The discrepancy is likely caused by different definitions of ‘answered’.

PureConnect counted a call as ‘answered’ when the agent’s phone went off-hook. GC counts a call as ‘answered’ when the agent clicks ‘Accept’ in the UI AND the media stream is established. If the agent’s WebRTC session takes 2 seconds to establish, some calls that PureConnect counted as answered may be classified as ‘alerting’ in GC.

We reconciled the statistics by aligning the metric definitions.

# GC 'connected' timestamp vs IC 'answered' timestamp
for conv in gc_conversations:
    gc_answer_time = conv.connected_time
    ic_answer_time = ic_records[conv.ani].answer_time
    delta = abs(gc_answer_time - ic_answer_time)
    if delta > timedelta(seconds=5):
        print(f'DISCREPANCY: {conv.id} delta={delta.seconds}s')

Most discrepancies were under 3 seconds - within the WebRTC setup window.

From an executive perspective, this 15% discrepancy will undermine confidence in the new platform.

If the board was told ‘we answer 10,000 calls per day’ and the new system reports 8,500, they’ll question the migration’s success. Proactively explain the metric definition change BEFORE presenting the first GC dashboard.

We created a ‘metric translation guide’ for the migration.

Distribute this to every stakeholder who reads reports.