肿瘤患者的每一次来电都可能关乎治疗窗口的开启与关闭。New York Cancer and Blood Specialists（NYCBS）在患者量持续增长的压力下，发现原有的联络中心已经跟不上节奏——登记流程卡顿、排队时间长、座席调度僵化。与 AWS 及合作伙伴 Pronetx（现已并入 Caylent）合作后，NYCBS 将联络中心整体迁移到 Amazon Connect，患者登记效率提升了 54%。这背后不是简单的"换个云"，而是联络逻辑的重构。
旧系统的瓶颈在哪里
NYCBS 原有的联络中心基于传统架构，核心问题集中在三个层面：
- 扩容慢。患者来电高峰期（如新诊断后的咨询潮）无法弹性增加座席，导致排队溢出。
- 流程硬。登记、预约、随访等环节依赖人工转接和纸质流程，患者需要反复提供同一信息。
- 数据孤岛。联络记录与临床系统割裂，团队无法实时看到患者上下文，每次通话都像从零开始。
对于肿瘤专科机构而言，这些瓶颈不仅是效率问题——延迟登记可能意味着延迟治疗。
Amazon Connect 的架构选型与迁移路径
Amazon Connect 是 AWS 提供的全托管云联络中心服务，核心能力包括：
- 基于浏览器的软电话，座席无需专用硬件即可上线；
- 可视化 Contact Flow 编辑器，用拖拽方式定义呼叫路由、IVR 逻辑和排队策略；
- 与 AWS 生态原生集成——Lambda 做后端逻辑、Kinesis 做实时流分析、S3 做录音归档；
- 按需弹性扩容，无需预购许可证或端口。
Pronetx（Caylent）在迁移中扮演的角色不仅是部署实施，更关键的是流程重塑：把原来依赖人工判断的登记流程，拆解为 Contact Flow 中的自动路由与条件分支，让系统先完成信息采集和预筛选，再决定是否转人工座席。这一步直接贡献了 54% 的登记效率提升——更多患者在更短的等待时间内完成了入组。
实战示例：用 CloudFormation 部署 Amazon Connect 实例与基础 Contact Flow
以下是一个最小可运行的示例，展示如何用 AWS CloudFormation 创建 Amazon Connect 实例，并附上一个可导入的 Contact Flow JSON 模板。实际生产中你会在此基础上叠加 Lambda 集成、CRM 查询、排队策略等逻辑，但这个起点足以让你在 30 分钟内拥有一个可拨入的联络中心。
第一步：创建 Connect 实例
# connect-instance.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Minimal Amazon Connect instance for oncology patient support
Resources:
ConnectInstance:
Type: AWS::Connect::Instance
Properties:
InstanceAlias: nycbs-patient-support
IdentityManagementType: CONNECT_MANAGED # 使用 Connect 自带身份管理；生产环境可切换为 SAML
InboundCallsEnabled: true
OutboundCallsEnabled: true
ContactFlowLogsEnabled: true # 开启流日志，便于后续排查路由问题
Outputs:
ConnectInstanceId:
Value: !Ref ConnectInstance
ConnectInstanceArn:
Value: !GetAtt ConnectInstance.Arn
部署命令：
aws cloudformation deploy \
--template-file connect-instance.yaml \
--stack-name nycbs-connect-instance \
--region us-east-1 \
--capabilities CAPABILITY_IAM
部署完成后，获取实例 ID：
aws cloudformation describe-stacks \
--stack-name nycbs-connect-instance \
--query "Stacks[0].Outputs" \
--output table
第二步：创建基础 Contact Flow（患者登记入口）
{
"Name": "PatientEnrollmentEntry",
"Type": "CONTACT_FLOW",
"Content": "{\"Module\":\"0\",\"StartModule\":\"1\",\"Modules\":[{\"Id\":\"1\",\"Type\":\"PlayPrompt\",\"Properties\":{\"Text\":\"欢迎致电纽约肿瘤与血液专科中心。如果您是新患者，请按 1 进行登记；已有患者请按 2。\",\"VoiceId\":\"Joanna\"},\"NextModule\":\"2\"},{\"Id\":\"2\",\"Type\":\"GetUserInput\",\"Properties\":{\"Text\":\"请输入您的选择。\",\"VoiceId\":\"Joanna\",\"TimeoutSeconds\":5,\"Conditions\":[{\"Condition\":{\"Operation\":\"Equals\",\"Value\":\"1\",\"Type\":\"Numeric\"},\"NextModule\":\"3\"},{\"Condition\":{\"Operation\":\"Equals\",\"Value\":\"2\",\"Type\":\"Numeric\"},\"NextModule\":\"4\"}]},\"NextModule\":\"5\"},{\"Id\":\"3\",\"Type\":\"TransferToQueue\",\"Properties\":{\"QueueId\":\"REPLACE_WITH_ENROLLMENT_QUEUE_ID\",\"ContactFlowId\":\"REPLACE_WITH_ENROLLMENT_AGENT_FLOW_ID\"},\"NextModule\":\"end\"},{\"Id\":\"4\",\"Type\":\"TransferToQueue\",\"Properties\":{\"QueueId\":\"REPLACE_WITH_EXISTING_PATIENT_QUEUE_ID\",\"ContactFlowId\":\"REPLACE_WITH_AGENT_FLOW_ID\"},\"NextModule\":\"end\"},{\"Id\":\"5\",\"Type\":\"PlayPrompt\",\"Properties\":{\"Text\":\"输入无效，请重新选择。\",\"VoiceId\":\"Joanna\"},\"NextModule\":\"2\"},{\"Id\":\"end\",\"Type\":\"Disconnect\",\"Properties\":{}}]}"
}
将此 JSON 保存为 patient-enrollment-flow.json，替换其中的 REPLACE_WITH_* 占位符为你在 Connect 控制台中创建的 Queue 和 Agent Flow ID，然后导入：
# 先获取实例 ID
INSTANCE_ID=$(aws cloudformation describe-stacks \
--stack-name nycbs-connect-instance \
--query "Stacks[0].Outputs[0].OutputValue" \
--output text \
--region us-east-1)
# 导入 Contact Flow
aws connect create-contact-flow \
--instance-id "$INSTANCE_ID" \
--name "PatientEnrollmentEntry" \
--type CONTACT_FLOW \
--content file://patient-enrollment-flow.json \
--region us-east-1
运行前须知：
- Amazon Connect 实例别名全局唯一，如果
nycbs-patient-support已被占用，请更换InstanceAlias。 - Contact Flow 中的 Queue ID 和 Agent Flow ID 需在 Connect 控制台手动创建后填入——这是 Connect 当前 API 的限制，无法在 CloudFormation 中一步完成队列创建。
- 生产环境务必开启录音归档（S3）和 Contact Flow 日志，并配置 Kinesis Data Streams 用于实时分析。
从 NYCBS 的结果看迁移决策的取舍
54% 的登记效率提升是硬指标，但迁移到 Amazon Connect 并非零代价。几个值得权衡的点：
| 维度 | 优势 | 需要注意的边界 |
|---|---|---|
| 扩容 | 座席按需增减，无需硬件采购 | Connect 按分钟计费，高峰期成本需建模预估 |
| 流程 | Contact Flow 可视化编排，迭代快 | 复杂分支逻辑在 JSON 维护成本高，建议用版本控制管理 |
| 集成 | Lambda/Kinesis/S3 原生打通 | 与非 AWS 临床系统（如 Epic）对接需额外中间层 |
| 合规 | Connect 支持 HIPAA BAA | 录音存储、数据流转仍需自行审计，BBA 不等于自动合规 |
如果你正在评估类似的联络中心迁移，这份清单可以作为起步框架：
- 量化当前瓶颈——排队时长、放弃率、登记周期天数，这些数字是迁移 ROI 的锚点。
- 梳理流程地图——把每个来电场景拆成路由决策树，明确哪些环节可以自动化、哪些必须人工介入。
- 选择身份管理模式——小型机构用 CONNECT_MANAGED 足够；有 SSO 要求的走 SAML，但配置周期更长。
- 提前建模成本——Connect 按通话分钟 + 座席时长计费，用历史话务数据跑一遍月度估算。
- 合规先行——签署 HIPAA BAA，确认录音归档的加密与保留策略，再开第一路通话。
- 分阶段上线——先跑一个科室或一条热线，验证流程和集成，再全量切换。
NYCBS 的案例说明：联络中心的云化改造，收益不在"换了基础设施"，而在"重新设计了患者与机构之间的连接逻辑"。技术选型是手段，流程重塑才是那 54% 的真正来源。