AI-Powered Technical Help Desk for Energy Utility Field Operations

infosys_topaz · Energy · 2025 · source Agentic: no · promotional bias: high · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Energy utility technical support

A large energy supplier needed to reduce technical-help-desk handling time for meter technicians in the field by reusing historical call knowledge, automating repetitive support, and preserving secure role-based access to transcripts and answers.

Constraints:

• meter technicians call support agents from customer locations when they cannot fix issues themselves
• call volume is roughly 5,000 per week and 20,000 per month
• the top 10 issue categories represent over 60% of calls and exceed five minutes average handling time
• 60-70% of issues are repetitive, but 30-40% still require human intervention
• the system must protect PII, credentials, API keys, transcripts, and role-specific access

Architecture

Infosys Topaz and AWS built a production RAG help-desk assistant around Amazon Bedrock. Recorded call transcripts land in S3 as JSON/CSV. Lambda triggers a Step Functions ingestion workflow that parses contact ID, participant, and content, then uses Claude Sonnet to summarize calls, classify relevant versus irrelevant transcripts, and extract summary/problem/resolution steps. Relevant summaries are chunked, embedded with Titan Text Embeddings, and stored in OpenSearch Serverless. A Streamlit UI with role-based access control queries the vector store, generates responses through Bedrock, persists feedback/metrics/FAQ counters in DynamoDB, and uses caching for faster FAQ retrieval.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  call-transcript-s3-bucket["call-transcript-s3-bucket"] --> lambda-trigger["lambda-trigger"]
  call-transcript-s3-bucket["call-transcript-s3-bucket"] --> irrelevant-transcript-archive["irrelevant-transcript-archive"]
  lambda-trigger["lambda-trigger"] --> step-functions-ingestion["step-functions-ingestion"]
  step-functions-ingestion["step-functions-ingestion"] --> claude-classifier-summarizer["claude-classifier-summarizer"]
  step-functions-ingestion["step-functions-ingestion"] --> irrelevant-transcript-archive["irrelevant-transcript-archive"]
  step-functions-ingestion["step-functions-ingestion"] --> knowledge-base-schema["knowledge-base-schema"]
  claude-classifier-summarizer["claude-classifier-summarizer"] --> knowledge-base-schema["knowledge-base-schema"]
  knowledge-base-schema["knowledge-base-schema"] --> titan-embedding-pipeline["titan-embedding-pipeline"]
  knowledge-base-schema["knowledge-base-schema"] --> opensearch-vector-store["opensearch-vector-store"]
  titan-embedding-pipeline["titan-embedding-pipeline"] --> opensearch-vector-store["opensearch-vector-store"]
  opensearch-vector-store["opensearch-vector-store"] --> streamlit-help-desk-ui["streamlit-help-desk-ui"]
  rbac-dynamodb-acl["rbac-dynamodb-acl"] --> streamlit-help-desk-ui["streamlit-help-desk-ui"]
  rbac-dynamodb-acl["rbac-dynamodb-acl"] --> opensearch-vector-store["opensearch-vector-store"]
  streamlit-help-desk-ui["streamlit-help-desk-ui"] --> bedrock-response-generator["bedrock-response-generator"]
  streamlit-help-desk-ui["streamlit-help-desk-ui"] --> faq-cache["faq-cache"]
  streamlit-help-desk-ui["streamlit-help-desk-ui"] --> feedback-metrics-store["feedback-metrics-store"]
  faq-cache["faq-cache"] --> feedback-metrics-store["feedback-metrics-store"]

Components

Data flow

A new transcript upload to S3 triggers Lambda and a Step Functions workflow. The parser extracts call ID, speaker role, and conversation content, concatenating rows by contact ID. A map-state classification step runs Claude Sonnet with zero-shot chain-of-thought prompting to summarize and classify each conversation as relevant or irrelevant. Irrelevant conversations are logged to S3; relevant conversations are summarized into structured problem and resolution fields, chunked, embedded with Titan, and indexed in OpenSearch Serverless. At query time, the Streamlit help desk enforces the user's role, retrieves similar knowledge-base items, generates an answer, updates FAQ counters and user metrics, and records feedback in DynamoDB.

Why this architecture

The system uses a RAG pipeline because repetitive field-support questions can be answered from past calls, but the knowledge base must ingest fresh transcripts near real time. Bedrock fits the AWS-native workflow with Step Functions, DynamoDB, and OpenSearch. Claude classification keeps low-quality calls out of the knowledge base, Titan embeddings and OpenSearch support scalable retrieval, and role-based collections/DynamoDB ACLs enforce different access levels for administrators, analysts, and technical agents. Streamlit caching and FAQ counters improve repeated-query performance.

Models used: Amazon Bedrock · Anthropic Claude Sonnet · Amazon Titan Text Embeddings · Amazon OpenSearch Serverless · AWS Step Functions · AWS Lambda · Amazon DynamoDB · Streamlit

Scale

• The technical help desk receives approximately 5,000 calls per week and 20,000 per month.
  “The approximate volume of these calls is 5,000 per week, approximately 20,000 per month.”article, stated
• Top 10 issue categories account for over 60% of calls and exceed five minutes handling time.
  “calls in the top 10 categories, which represent over 60% of calls, are over 5 minutes.”article, stated
• 60-70% of issues are repetitive.
  “60–70% issues are repetitive, and the rest are new issues.”article, stated
• The RAG chunking strategy uses 1,000-token chunks with 150-200 token overlap.
  “We used a chunk size of 1,000 with an overlapping window of 150–200 for best results.”article, stated
• The AI assistant handles 70% of previously human-managed calls.
  “now handles 70% of the previously human-managed calls.”article, stated
• Average handling time for top categories dropped from over five minutes to under two minutes, a 60% improvement.
  “average handling time has decreased from over 5 minutes to under 2 minutes, a 60% improvement.”article, stated
• Human intervention fell from 30-40% to 20% within six months.
  “reduced the percentage of issues requiring human intervention from 30–40% to 20% within the first 6 months after deployment.”article, stated
• Customer satisfaction scores related to technical support rose 30%.
  “Post-implementation surveys show a 30% increase in customer satisfaction scores related to technical support interactions.”article, stated
• Role-based access control has three personas: administrator, technical desk analyst, and technical agent.
  “We used three different personas to implement role-based access control: an administrator with full access, a technical desk analyst”article, stated

Alternatives considered (roads not taken)

Hiring and training more support agents

Rejected because: The article says staffing is costly and not scalable for repetitive support volume.

Processing massive documents at once

Rejected because: The RAG design uses chunking and overlap to improve retrieval instead.

Simple narrow user prompts

Rejected because: Expanded prompts with synonyms, procedures, regulations, best practices, and agent experiences retrieve better results.

Single unrestricted transcript corpus

Rejected because: Different roles need different access levels, so transcripts are ingested into separate OpenSearch collections.

Patterns

rag-retrieval (retrieval)

Past support transcripts are summarized, embedded, retrieved, and used to answer new technical help desk questions.

structured-output-contract (knowledge extraction)

Claude turns raw conversations into structured knowledge-base fields: summary, problem, resolution steps, and embeddings.

guardrails-io-filtering (data quality)

The ingestion workflow filters disconnected or meaningless conversations before they enter the knowledge base.

semantic-caching (performance)

The Streamlit cache and FAQ counter reuse frequent valid results and surface top questions for faster support.

privacy-preserving-processing (security)

The architecture encrypts buckets, PII, OpenSearch traffic/storage, DynamoDB ACL data, credentials, and service transmissions.

Tradeoffs

Automate repetitive support with an AI assistant.

Chose RAG-backed assistant over more staffing over Hiring and training more support agents.

Rationale: Most issues are repetitive and staffing enough agents is costly and not scalable.

Filter transcript data before embedding.

Chose Relevant-conversation shortlist over Embedding every recorded call.

Rationale: Disconnected calls and unresolved conversations would produce noisy retrieval, so the workflow keeps only useful context in the vector store.

Use role-separated vector collections.

Chose Multiple OpenSearch collections controlled by DynamoDB ACLs over A single shared vector index.

Rationale: Role-specific transcript access is required for least-privilege knowledge retrieval.

Gotchas (what bit them)

Raw transcripts include irrelevant or low-context calls.

Root cause: Signal disturbances, disconnected conversations, and calls without meaningful resolution can pollute the knowledge base.

Resolution: Use Claude with zero-shot chain-of-thought summarization and relevance classification, archiving irrelevant calls separately.

Production RAG needs a vector store that can update without hurting query performance.

Root cause: The knowledge base expands continuously with new call transcripts and updated embeddings.

Resolution: Use OpenSearch Serverless vector engine to add, update, and delete embeddings in near real time.

Help desk knowledge access has to be role-scoped.

Root cause: Administrators, analysts, and technical agents should not all see the same transcript collections.

Resolution: Store role/access metadata in DynamoDB and separate OpenSearch Serverless collections by access level.

Evaluation

The system measures operational outcomes, user feedback, answer helpfulness, misses, FAQ frequency, satisfaction, response time, and support-call handling metrics after deployment.

Metrics: average handling time · percentage of calls handled by the assistant · human intervention rate · customer satisfaction score · number of weekly queries · helpful responses generated · dislikes and misses · FAQ query counts

Outcomes

• The AI assistant handles 70% of previously human-managed calls.
• Average handling time for top issue categories dropped from over five minutes to under two minutes.
• Human intervention fell from 30-40% to 20% in the first six months.
• Post-implementation surveys showed a 30% increase in technical-support satisfaction.

The deployment serves a 5,000-call-per-week, 20,000-call-per-month field-support operation with top 10 issue categories making up more than 60% of calls.