AWS Builder Center

Builder Center

Call Center Insights Without the Pipeline: Amazon Connect, Lake Formation, Athena, and QuickSight

Call Center Insights Without the Pipeline: Amazon Connect, Lake Formation, Athena, and QuickSight

We connected a card-servicing contact center's Amazon Connect data to a central analytics account using Lake Formation and Athena, then built governed QuickSight dashboards for AHT, CSAT, and sentiment — with zero custom ETL pipelines to maintain.

Santhosh P

Senior Data & AI Engineer

Call Center Insights Without the Pipeline: Amazon Connect, Lake Formation, Athena, and QuickSight

Every contact center team eventually asks the same question: why did average handle time spike last Tuesday, or which call reasons are driving the most repeat contacts? The built-in Amazon Connect dashboards answer the standard metrics, but the moment you need a custom cut — handle time by call reason and agent tenure, say, or sentiment trends segmented by product line — you're usually looking at standing up a CTR export pipeline: Kinesis stream, Lambda transform, S3 landing zone, a Glue crawler, and a lot of IAM policy to keep the agent-level PII locked down.
We wanted to see how far we could get for a card-servicing support line without writing any of that, using the Amazon Connect analytics data lake feature — a zero-ETL data share — paired with AWS Lake Formation, Amazon Athena, and Amazon QuickSight. Here's what we built and what we learned.

Why we split this across two accounts

Our contact center runs in its own AWS account (standard practice for isolating PCI-scoped workloads), but the people who need to analyze the data — workforce management, QA, product analytics — live in a separate analytics account. Rather than replicate data between them, Amazon Connect's analytics data lake lets you share the underlying tables (contact trace records, agent event data, Contact Lens conversational analytics) directly, with AWS Resource Access Manager (RAM) handling the cross-account grant and Lake Formation handling exactly who can see what once it lands.
No data actually moves. The analytics account queries the same underlying tables in place.

Step 1 — Turn on the data share in Amazon Connect

In the Amazon Connect console, we opened our instance, went to Analytics tools, and chose Add data share. From there:
  1. We entered the target AWS account ID — our central analytics account.
  2. Under Data types, we selected the sets we needed: contact trace records, agent event data, and Contact Lens conversational analytics (call transcripts and sentiment scores).
  3. We confirmed the share.
The same thing is scriptable for repeatable environments:
1
2
aws connect batch-associate-analytics-data-set \
--cli-input-json file://input_batch_association.json
1
2
3
4
5
{
"InstanceId": "YOUR_CONNECT_INSTANCE_ID",
"DataSetIds": ["<DATA_SET_ID>"],
"TargetAccountId": "YOUR_ANALYTICS_ACCOUNT_ID"
}

Step 2 — Accept the share in AWS RAM

Over in the analytics account, we opened AWS Resource Access Manager → Resource shares → Shared with me and accepted the incoming share from the contact center account. This is the handoff point between the two accounts — nothing is queryable yet until the next step.

Step 3 — Create governed resource links in Lake Formation

This is the part that made us comfortable putting PCI-adjacent data in front of more than one team. In AWS Lake Formation, under Tables, we chose Create → Resource link, pointed it at the shared database and table, and selected the source region.
From there, Lake Formation permissions did the actual gatekeeping:
  • QA and workforce management got row- and column-level access to full contact trace records and Contact Lens sentiment — they need to see everything to coach agents effectively.
  • Broader analytics and product teams got the same tables with sensitive columns (customer phone number, account identifiers) masked out via Lake Formation's column-level permissions, so they can analyze trends without touching anything PCI-scoped.
That split — one shared table, two permission sets — replaced what would otherwise have been two separate pipelines with two separate masking jobs.

Step 4 — Query it in Athena

With the resource links in place, the data showed up in Athena like any other Glue Catalog table. A few of the queries we ran early on:
1
2
3
4
5
6
7
8
9
10
-- Average handle time by call reason, last 7 days
SELECT
queue_name,
disconnect_reason,
AVG(agent_interaction_duration) AS avg_handle_time_seconds,
COUNT(*) AS contact_count
FROM contact_trace_records
WHERE initiation_timestamp >= date_add('day', -7, current_date)
GROUP BY queue_name, disconnect_reason
ORDER BY avg_handle_time_seconds DESC;
1
2
3
4
5
6
7
8
9
10
11
-- Negative-sentiment calls by product queue, joined to Contact Lens
SELECT
ctr.queue_name,
COUNT(*) AS negative_sentiment_calls
FROM contact_trace_records ctr
JOIN contact_lens_conversational_analytics cla
ON ctr.contact_id = cla.contact_id
WHERE cla.overall_sentiment_score < 0
AND ctr.initiation_timestamp >= date_add('day', -1, current_date)
GROUP BY ctr.queue_name
ORDER BY negative_sentiment_calls DESC;
Both ran directly against the shared tables — no intermediate copy, no crawler to schedule, no schema drift to chase down because the table definitions are managed by the Connect data lake itself.

Step 5 — Build the QuickSight dashboards

From QuickSight, we created a new dataset using the Athena connector, pointed at the same resource-linked tables, and built three views that mattered most to our ops leads:
  • Handle time and queue health — AHT and abandon rate by queue, broken out by hour of day, to spot staffing gaps.
  • Sentiment and escalation trends — Contact Lens sentiment scores overlaid with escalation rate by product line, refreshed daily, so QA can flag scripts or products generating friction.
  • Repeat contact analysis — contacts from the same customer within a 7-day window, grouped by original call reason, to find the issues that aren't getting resolved on first contact.
Because the underlying permissions were already enforced at the Lake Formation layer, the same QuickSight dataset could be shared with both the QA team (full detail) and the broader analytics org (masked columns) without building two separate data models.

What we'd flag before you build on this

  • This is a read path, not a transformation layer. If you need heavier reshaping — sessionizing multi-channel journeys, joining against your CRM — you'll still want Athena CTAS queries or a downstream job; the data lake itself doesn't transform anything for you.
  • Schema is owned by Connect. You consume the tables as Connect defines them; you can't alter the shared table's structure, only build views or CTAS tables on top.
  • Cross-region shares need the target region specified when creating the resource link — easy to miss on the first pass.
  • RAM acceptance is a one-time manual (or scripted) step per target account — budget for it in any new-environment runbook.
  • Up to two years of history is included in the Connect data lake at no extra charge; older data needs its own archival strategy if you need it.

What it cost us

The Amazon Connect analytics data lake itself carries no additional charge for up to two years of data — you pay only for the services you use to query and visualize it. For us that meant standard Athena per-query scanning costs (kept low since we were querying governed, already-structured tables rather than raw JSON), QuickSight per-author and per-reader costs for the ops and QA teams using the dashboards, and no incremental Glue, Lambda, or Kinesis spend at all, since there was no custom pipeline to run.

Wrapping up

The biggest shift for us wasn't a specific feature — it was not building a pipeline. Sharing the Connect data lake through RAM, wiring it up with Lake Formation resource links, and pointing Athena and QuickSight at the result gave two different teams two different, correctly-governed views of the same contact center data, without a single Lambda function or crawler schedule between the call ending and the dashboard updating.

AWS Reference Documentation

# amazon-connect# aws-lake-formation# amazon-athena# amazon-quicksight# big-data
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article