This is the companion to the Amazon Connect Jira backlog — same project, same three workstreams, this time organised by who rather than what. AWS's own guidance recommends defining roles through a RASCI matrix (Responsible, Accountable, Supported, Consulted, Informed) so each team understands its remit and how it interacts with others[1] — not a procedural runbook, but a clear statement of who decides, who does, and who just needs to know.
Governance & Cross-Cutting Roles
These roles span all three workstreams rather than sitting inside one.
Project Manager / Programme Manager
Owns the overall plan, the three-workstream structure, dependency tracking between them, and the sprint cadence. Chairs or feeds the Change Approval Board (CAB) process for the go-live cutover.
Owns: project plan, risk/issue log, governance cadence, go-live change request, stakeholder reporting.
Executive Sponsor / Steering Committee
Provides "engaged governance" — empowered to make decisions or escalate quickly.[1] Approves the vision statement, guiding principles, and business outcomes that frame the whole project, and ultimately approves go-live.
Owns: vision & guiding principles, business outcome sign-off, budget, go-live approval.
Business Analyst
Pairs closely with the Connect developer to lead discovery — eliciting requirements from business and operational stakeholders, documenting current-state and future-state call flows.[2] A permanent fixture across discovery, design, and UAT.
Owns: as-is mapping, requirements, use case documentation, UAT script authorship (with the business).
Technical Foundation Workstream Roles
AWS names project managers, business/solutions/technical/security architects, and infrastructure platform owners as the core discovery and design attendees for this workstream.[2]
Solutions Architect
Owns the high-level and detailed technical design — the Connect instance configuration, how it fits the broader AWS landing zone, and the integration architecture. Often the single most senior technical voice on the project.
Owns: solution design document, integration architecture, multi-account strategy, technology choices.
Security & Compliance Architect
Reviews and signs off the security section of the design independently from the main solution design, since it typically has its own specialist stakeholder group.[2] Confirms the platform is ready for live traffic from a security perspective before deploy.
Owns: security design sign-off, compliance requirements, pre-go-live security confirmation.
Infrastructure / Platform Owner
Owns the underlying AWS landing zone — the development, test, and production accounts the project is built across — and the DevOps/IaC tooling that promotes changes between them.
Owns: AWS account structure, IaC pipeline, environment promotion process.
Amazon Connect Developer
Builds the technical components: Connect instance configuration, security/routing profiles, Lambda integrations, and the data pipeline. Performs unit and integration testing of what they build.[2]
Owns: IaC build, backend integrations, unit/integration tests, DevOps runbook.
Network / Telephony Engineer
Owns PSTN/SIP connectivity, carrier relationships, and the number cutover mechanics — toll-free number service (TFNS) repointing or number porting, which AWS flags as needing significant lead time.[3]
Owns: telephony design, number porting/TFNS process, cutover execution.
Functional Test Team
A distinct role from the developers who build the components — responsible for end-to-end product testing of functional journeys through the whole infrastructure (e.g. confirming agent events log correctly and recordings land in the right S3 bucket).[2]
Owns: product/functional test plan and execution, defect triage ahead of UAT.
User Journeys Workstream Roles
AWS names project managers, business and solutions architects, business analysts, and the service line owner/operator as this workstream's workshop attendees.[3]
Conversation / IVR Designer
Designs the actual customer experience — menus, prompts, routing logic, no-input/no-match handling, and (where in scope) the agentic AI experience. In AWS's recommended approach, this role often works directly in the contact flow designer over screen-share so the design is self-documenting.[3]
Owns: journey design, prompt wording and placeholders, escalation criteria, AI agent instructions/guardrails if applicable.
Service Line Owner / Operator
The business-side owner of a specific call reason or department (e.g. billing, claims, technical support). Confirms the journey reflects how that service line actually needs to operate, and signs off the design before build.
Owns: service-line requirements, design sign-off, UAT participation for their journeys.
Amazon Connect Developer (Journey Build)
Builds the contact flows themselves in Connect — often the same developer role as the technical foundation workstream, but focused on journey logic rather than infrastructure. Exports flows as JSON for version control.[3]
Owns: contact flow build, flow version control, dev-environment journey testing.
AI / Prompt Engineer (where agentic AI is in scope)
Owns the AI agent's instructions, tool contracts, knowledge sources, and guardrails for any agentic or generative AI journeys — a specialism that didn't exist in deterministic-only Connect projects.
Owns: AI agent configuration, eval set for AI journeys, guardrail specification.
Business Users (UAT Testers)
A dedicated team or users drawn from the service line business unit who perform UAT only after functional testing has passed — a distinct, business-owned gate from the technical test phases.[3]
Owns: UAT execution, defect acceptance/rejection decisions.
Operational Workstream Roles
The non-technical roles AWS describes as crucial to overall migration success — "if end-users feel ignored or under-valued during the project, they will be reluctant to move to the new platform."[4]
Service Introduction (SI) Lead
Often a dedicated team working independently from the core project team. Owns the go-live entry criteria and checklists the project must pass, and should be engaged from early in the project — not brought in at the end.[4]
Owns: go-live checklist/criteria, AWS support plan selection, CAB impact statements.
Operations / BAU Support Lead
Owns the business-as-usual support model the new platform must be incorporated into, and signs off that the operations team is ready to manage support tickets on the new platform before go-live.[5]
Owns: BAU support model, operating model RASCI, out-of-hours process flows.
Training Lead / Trainer
AWS recommends a "train the trainer" approach using the organisation's own in-house training staff, who understand the culture and format that suits their users best.[4] Project SMEs support with technical source material.
Owns: training plan and materials, trainer enablement, agent/supervisor/admin training delivery.
Post Go-Live Support (PGLS) Team
Works alongside BAU support during the first weeks after go-live, helping users get started and troubleshooting live issues — distinct from, but closely paired with, the ongoing BAU team.[2][3]
Owns: early-life support, floor-walking, documentation refinement from real feedback.
Supervisors / Team Leaders
Consume real-time Connect dashboards and reports to manage agent activity day-to-day, and are a key audience for both training and go-live-day monitoring.[5]
Owns: day-to-day floor management, real-time monitoring, first-line escalation.
A Starter RASCI Matrix
Adapted from AWS's own operating-model guidance.[4] R = Responsible, A = Accountable, S = Supported, C = Consulted, I = Informed.
| Activity | PM | Sol. Architect | Connect Dev | Business Analyst | SI Lead | Ops/BAU | Sponsor |
|---|---|---|---|---|---|---|---|
| Vision & guiding principles | C | C | I | C | I | I | A |
| Technical design | I | A/R | S | C | C | I | I |
| Journey design | I | C | R | A/R | I | C | I |
| Build (tech & flows) | I | C | A/R | S | I | I | I |
| UAT | I | I | S | A/R | C | C | I |
| Operating model | A | C | I | C | R | R | I |
| Training | I | I | S | I | C | A/R | I |
| Go-live CR & CAB | A/R | C | S | I | R | C | I |
| Cutover execution | A | S | R | I | S | R | I |
| Post go-live support | C | I | S | I | I | A/R | I |
This is a starting point, not a template to copy verbatim — AWS's own guidance stresses that the operating model should be built with your own stakeholders, using document conventions your organisation already recognises, so it's easier to review and sign off.[4]
Sizing the Team for Your Project
- Small / single service line: one PM wearing a bit of the SI/ops role too, one solutions architect doubling as security reviewer, one Connect developer covering both tech foundation and journey build, one business analyst, part-time training support. Expect several roles to combine.
- Mid-size / multi service line: dedicated roles per workstream as listed above, with the developer role split between a technical-foundation developer and a journey-build developer or two.
- Large / enterprise migration: each role above becomes a small team; add a dedicated change manager, a formal CAB, and workstream leads coordinating multiple parallel sprints across service lines.
Whatever the size, keep the three-workstream separation AWS recommends — "basing workstreams on specific teams and roles gives team members autonomy in prioritizing sprint backlog items... and provides clear accountability."[6] Collapsing everyone into one undifferentiated project team is the most common way these projects lose accountability.
The one-line summary: technical foundation needs architects and developers who get the design right once; user journeys need designers and business analysts who iterate fast; operations needs a dedicated SI lead and trainers who are engaged from day one, not week twelve.
Pair this with the step-by-step work itself in the Amazon Connect Jira backlog. And if you're mapping the journeys this team will design and build, the free IVR Design Tool is built for exactly that collaboration.
Sources
This guide is grounded in AWS's own published migration guidance, plus publicly posted Amazon Connect delivery role descriptions from AWS and its partners. Content was summarised and rephrased for compliance; see each source for full detail. This is independent guidance and is not affiliated with or endorsed by AWS.
- AWS Prescriptive Guidance — Operational workstream (RASCI, operating model)
- AWS Prescriptive Guidance — Technical foundation workstream
- AWS Prescriptive Guidance — User journeys workstream
- AWS Prescriptive Guidance — Operational workstream (training, SI)
- AWS Prescriptive Guidance — Migration checklists
- AWS Prescriptive Guidance — Project phases and workstreams
- Role framing cross-checked against publicly posted Amazon Connect delivery job postings (AWS Professional Services, systems integrator partners) for Delivery Consultant, Solutions Architect, and Technical Architect roles.