Call Triage Pipeline

Adapted from a real job posting brief into a working portfolio build, to demonstrate translating a business automation problem into a production-shaped AWS architecture.

User Story

As a property management office, we're manually downloading call recordings, uploading them to a transcription tool, pasting the transcript into an AI chatbot to summarize, and pasting that summary into tenant notes - every single call. We want that whole chain automated, with urgent issues (maintenance emergencies, legal threats, angry tenants) flagged immediately, and a weekly rollup so management can see what came in without reading every note.

What It Does

1. A call recording lands in S3 (from GoTo Connect, as it already does today).
2. Amazon Transcribe converts it to text.
3. Claude (Anthropic) reads the transcript and produces a structured summary: category, urgency flags, tenant-note-ready paragraph + bullets, and action items.
4. The transcript and summary are archived in S3; the call is logged in DynamoDB.
5. A per-call email goes out immediately, urgent calls marked [URGENT] in the subject line.
6. Every Monday, a weekly digest email summarizes the week for management.
7. Any call's summary can be resent or regenerated on demand.

Architecture

Transcription and summarization run as separate Lambdas; DynamoDB (not S3 listing) drives the weekly digest; and the existing recordings bucket stays under GoTo Connect's / the client's own management rather than being absorbed into this stack.

├── template.yaml              SAM template - all AWS resources
├── src/
│   ├── start_transcription/   Lambda 1: S3 trigger → starts Transcribe job
│   ├── process_transcript/    Lambda 2: Transcribe done → Claude summary → email
│   ├── weekly_summary/        Lambda 3: scheduled weekly digest
│   └── resend_summary/        Lambda 4: on-demand resend/regenerate
├── layer/python/               Shared code (Claude client, parsing, email templates)
├── scripts/                   Bucket-notification wiring + CSV export helpers
├── tests/                     Regression tests for parsing + email rendering
└── docs/
    ├── ARCHITECTURE.md
    ├── SETUP.md                Deployment walkthrough
    └── HANDOFF.md              Plain-language guide for the client's team

Deploy It

sam build && sam deploy --guided

Plus a couple of one-time steps: SES verification, a Parameter Store secret, and wiring the existing bucket's event notification.

Run the Tests

python3 -m unittest discover -s tests -v

Pure-logic tests for filename/phone parsing and email rendering - no AWS credentials needed. These specifically guard against the brief's stated concern: a naming-convention change should degrade gracefully, never break the pipeline.

Security Notes

• The Anthropic API key lives in SSM Parameter Store as a SecureString, never in code, CloudFormation parameters, or logs.
• All IAM roles are scoped per-function to only the bucket/table/parameter they need (SAM Policies: blocks, not *-on-everything).
• Email links use short-lived presigned S3 URLs rather than making the archive bucket public.