40、计算机电话信息请求相关内容解析

原创于 2025-07-28 12:18:32 发布 · 746 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#计算机电话信息 # ACD呼叫处理 # 客户服务系统

计算机电话信息请求相关内容解析

1. 系统环境概述

在整个系统环境中，涉及到多个软件版本和硬件配置。软件版本方面，MVS/ESA 为 4.3 版本，IMS 是 3.3 版本，CICS 为 3.3 版本，DB2 是 3.1 版本，VTAM 为 3.4 版本，TCP/IP 是 3.1 版本。
硬件配置上，Tandem 环境有用于 ATM/POS 处理的 6 个 Cyclone 处理器和用于电汇的 8 个处理器，ACI Base24 为 4.0 版本。前端网络处理器包括 4 个 IBM 3725（NCP 版本 4.2）和 2 个 IBM 3745（NCP 版本 7.1）。
企业处理量方面，每天有 1500000 个 IMS 事务支持分行在线、ATM/POS、CIS 和 Hogan 应用；每天有 1200000 个 CICS 事务支持电子邮件、信用卡和零售贷款；每天处理 3000000 个纸质项目，其中 60% 是本行事务。

2. 客户服务部门环境

客户服务部门在物理上分为两个站点，一个在 Xzzum，另一个在 Axxum。Axxum 站点每周 7 天、每天 24 小时开放，Xzzum 站点从上午 7:00 到晚上 9:00 开放，周日关闭。
在电话处理方面，43% 的来电由 Axxum 的语音响应单元（VRUs）处理，32% 由 Xzzum 的 VRUs 处理，16% 由 Axxum 的客户服务代表（CSRs）处理，9% 由 Xzzum 的 CSRs 处理。800 号码主要路由到 Xzzum 站点，Axxum 站点处理华盛顿西部的所有本地电话。12 月，客户服务部门的 VRUs 处理了 75% 的来电。CSR、培训和管理人员的工作站分布为：Xzzum 有 120 个，Axxum 有 173 个。
多队列呼叫处理中，代理分为三个组：
- 主要队列：负责回答和响应 90% 的一般信息和账户请求。
- 特殊队列：处理所有需要研究或额外客户协助的客户请求，并接收来自其他代表转接的电话。在业务量较大时，还处理队列溢出。
- 业务队列：响应商业客户的电话，如支票验证。
此外，还有一个参考中心为整个客户服务部门提供支持，执行柜员功能（如非本行信用卡预支）、总账功能（如费用反转）、写信、研究、缩微胶片请求等支持活动。

3. 电话系统

有两个 Aspect 自动呼叫分配器（ACD），一个位于 Xzzum 地区，另一个位于 Axxum。目前运行的软件版本是 8.0，正在提议升级到 9.0 版本。
这两个 ACD 通过 T - 1 线路连接（T - 1 等于 24 条线路），以便在两个客户服务部门站点之间平衡呼叫。由于两个位置的 ACD 相互连接，它们可以在计划内或计划外停机期间相互支持。
每个 ACD 都有独立可编程的“路由”来控制呼叫处理方式，例如：
1. 呼叫进入 Axxum ACD。
2. ACD 检查 Axxum 中是否有可用的 VRU。
3. 在指定时间（可能是 3 秒）后，ACD 将查看 Axxum 中是否有主要队列代表可用。
4. ACD 继续检查是否有可用的 VRU 或主要队列客户服务代表，直到另一个指定时间段过去。
5. 接下来，交换机将开始寻找可用的特殊队列代表（同时继续检查 VRU 或主要队列 CSR）。
6. 如果 VRU、主要 CSR 和特殊队列 CSR 都不可用，则开始搜索业务队列代表。
7. 此时，路由可能会指示 Axxum ACD 联系 Xzzum ACD 并在其队列中进行预订。
8. 最后（可能在 12 秒后），ACD 在 Xzzum 地区找到一个可用的特殊队列代表。
9. 呼叫通过 T - 1 线路从 Axxum 路由到 Xzzum 的 ACD，然后到可用的特殊队列代表。

“路由”还包括在客户等待时播放的公告或音乐的类型和时间信息。目前，两个 ACD 共有 190 个编程“路由”，每个“路由”最多可以有 256 个步骤。
所有代表通过用户 ID 定义到 ACD，这些 ID 与定义的组相关联。每个组有一个服务级别，服务级别决定了该组执行的功能（如主要或特殊队列）。代表可以在任何站点登录，登录会告诉 ACD 该 CSR 所属的组，从而确定允许该 CSR 在该站点执行的服务级别。
每个 ACD 提供有关处理呼叫的详细报告，每天报告的信息包括但不限于：提供的呼叫、处理的呼叫、放弃的呼叫、转接的呼叫、平均延迟时间、代理的最小、最大和平均呼叫时间以及结束信息。这些报告以半小时增量和每日摘要的形式生成。

4. 语音响应单元（VRUs）

Aspect 与 9 个专门用于客户服务部门电话服务功能的 VRUs 通信（7 个用于客户服务部门，2 个用于电话支付，这也是客户服务部门的功能），其中 55% 位于 Axxum，45% 位于 Xzzum。
VRUs 由三台奔腾 III 服务器运行，服务器在 Microsoft NT 软件下运行，服务器和 VRUs 运行 Intervoice IFORM 软件。客户服务部门的 VRUs 每天大约处理 60000 个呼叫。

5. 主机网络

客户服务部门通过令牌环局域网（Token Ring Local Area Network）上的 IBM 服务器连接到 IBM 主机。令牌环控制器连接到 IBM 3745 数据通信控制器，该控制器与 IBM 大型机上的 VTAM 接口。客户服务部门共有 300 个 IBM 3270 类型的终端，每个终端具有四个会话能力。

6. 应用程序

Access 系统 ：由 Stairs/VS Release 4 Level 3 应用程序支持，包含分行位置、营业时间、电话号码等杂项信息、ATM 位置以及自动清算所（ACH）交易活动。每月执行超过 50000 个 Access 应用程序事务。
Bill Payer（PBP） ：由 FNAX 开发的应用程序，允许客户通过 VRU 会话直接支付账单。它是一个使用 Telon 代码生成器开发的 IMS DB/DC 应用程序，每天大约有 1000 个 Bill Payer 会话，产生约 6000 个支付事务。
Branch On - line（BOL） ：是分行在线系统的 IBM 主机部分，支持柜员和管理（平台）事务，是当前大多数备忘录过账活动的存储库。有 11 个 BOL 条带文件作为柜员、管理和客户服务部门区域的客户账户信息的主要来源。BOL 是一个使用 IMS DB/DC（Fastpath）Release 3.1 的 FNAX 开发的 COBOL II 应用程序，支持 157 个事务（62 个柜员事务、70 个管理事务（包括客户服务部门事务）和 25 个支持功能）。它有 11 个应用程序条带文件和 29 个其他数据库，与 25 个其他生产应用程序接口。每月有 1000 万个 BOL 柜员事务和 400 万个 BOL 管理事务（客户服务部门事务是这些 BOL 事务的子集），并与 62 天的在线货币交易电子日志存档链接。
- Accounts in Jeopardy（AIJ） ：是 BOL 系统的一个子集，作为账户关闭警告系统，是一个内部开发的 IMS DB/DC、COBOL 在线和批处理应用程序，记录账户关闭信息并传递给个人银行家进行跟进，有 2 个在线事务。
- Inbound Telemarketing（ITM） ：也是 BOL 的一个子系统，包含产品信息，是一个内部开发的 IMS DC 应用程序，产品数据存储在 DB2 表中，包含可更新的产品信息和简单脚本以支持销售工作。
Customer Information System（CIS） ：是 Hogan Release 8306 IMS DB/DC，包含客户信息文件（CIF，有 480 万条记录）、账户信息文件（AIF，有 790 万条记录）和地址信息文件（ADF，有 350 万条记录）。客户服务部门每天执行约 20000 个 IMS 事务来检索 CIS。
Automated Teller Machine（ATM）/Point of Sale（POS） ：切换和驱动程序位于 Tandem 大型机上，主机授权、日志记录、网络结算和 ATM 平衡都位于 IBM 大型机上，这些应用程序是 FNAX 开发的 IMS DB/DC 应用程序。目前，ATM/POS 交易细节通过批处理过程到达大型机，细节存储在多个平面文件中进行每日处理，每月处理超过 1100 万个事务。客户服务部门目前不直接访问这些应用程序，有限的 ATM/POS 信息通过 BOL 应用程序查看。
Credit Card/Merchant System ：Cardpac Release 5.0 CICS/VSAM 应用程序，个人账户数量为 110 万，其他账户数量超过 15 万。客户服务部门不直接访问 Cardpac 应用程序，信用卡交易通过 BOL 应用程序处理。
Host Electronic Journal（Host EJ，HEJ） ：包含所有 BOL 货币交易的在线记录，是一个 FNAX 开发的 COBOL II、DB2 应用程序。应用程序加载在 IMS 环境中执行，在线查询功能通过 CICS/ESA 实现。每天通过 IMS 处理约 400000 个传入事务，目前 CICS 事务每天约 20000 个，HEJ 应用程序使用约 70 个不同的屏幕。
Demand Deposit Accounts Application（DMS） ：Hogan 应用程序 Release 8603 IMS DB/DC，有 967000 个活期存款账户。该应用程序的信息存储在 BOL 条带文件中，查询由 BOL 系统处理，客户服务部门的更新每天晚上通过 BOL 以批处理方式发送到记录系统。每天批处理后，BOL 条带文件按账户更新，BOL 在条带文件中保留活期存款账户的备忘录过账信息。
Savings Application（SAV） ：Hogan 应用程序 Release 8603 IMS DB/DC，有 910000 个开放关联储蓄账户和 364000 个开放非关联储蓄账户。信息存储在 BOL 条带文件中，查询由 BOL 系统处理，客户服务部门的更新每天晚上通过 BOL 以批处理方式发送到记录系统。每天批处理后，BOL 条带文件按账户更新，BOL 在条带文件中保留储蓄账户的备忘录过账信息。
Microfilm Services Automation（MSA） ：FNAX 开发的 IMS DB/DC（Telon 生成）COBOL 应用程序，与基于 PC 的缩微胶片应用程序 Procars 接口。MSA 每天使用批处理过程三次将请求传递给 Procars 应用程序，保留请求记录但不保留请求细节。Procars 在独立的 DOS 环境中运行，不连接到局域网，通过 3270 仿真与主机通信，将请求分组、创建拉取列表和详细挑选列表，包含每个请求的状态信息和三个月的详细历史记录。
Clarke American check vendor information ：FNAX 目前正在开发对 Clarke American 支票订单在线应用程序的直通访问。
Electronic Mail（eMail） ：CA eMail 版本 3.2，在 CICS 环境中运行，支持 X.400 协议（但在 FNAX 安装的产品不支持该协议）。
TCS Telecenter workload projection and scheduling system ：用 FoxPro 编写的 Windows 应用程序，运行在客户服务部门的 PC 上，为 500 多名员工进行排班，与 Aspect ACD 接口，使用呼叫量来预测未来的人员需求。

7. 应用程序处理截止时间

支持客户服务部门的主要应用程序 BOL 是每周 7 天、每天 24 小时运行的应用程序。大多数应用程序的批处理在周一至周五进行。为了支持及时的批处理，应用程序有标准的截止时间来结束当天的工作。截止后，应用程序的事务将记录为下一天的事务。例如，信用卡应用程序可能在下午 5:00 左右截止工作，而 BOL 事务可能直到晚上 10:00 后才截止当天的工作。这意味着在 24 小时内，应用程序可能会处理不同工作日的工作，由于工作日截止标准，应用程序信息的数据源可能会在一天中发生变化。
此外，账户刷新是按应用程序、按账户进行的。可能会出现查询到已从批处理中刷新或更新的支票账户，但查询到该客户未更新的储蓄账户的情况。因此，刷新日期存储在账户级别。在向客户提供账户活动和状态信息时，跟踪每个应用程序的工作日日期非常重要。

8. 会话概念

3270 会话 ：每个 3270 类型的终端（基本的客户服务部门工作站）有能力处理四个基于主机的会话或登录。配置上，第一个会话（会话 A）是唯一定义到 IMS 的会话，因此是唯一可以访问分行在线（BOL）应用程序的会话。这意味着要访问任何其他 IMS 应用程序，CSR 必须从 BOL 注销并登录到其他 IMS 应用程序。CICS 应用程序可以在任何会话中访问，但不能通过已经登录到 IMS 的会话访问。四个会话都会被使用，最常用的应用程序包括：
- BOL - 分行在线，客户服务部门在此应用程序下运行。
- eMail - 电子邮件系统，是一个 CICS 应用程序，最初是 ADR eMail，现在是 CA 产品，用于银行内的书面通信。
- Access - FNAX 应用程序，允许 CSR 查找银行内员工、部门和分行的信息。
- Host EJ - 记录分行执行的事务和客户服务部门执行的备忘录过账事务。
客户事件会话 ：客户会话从 TS07 客户服务部门识别屏幕开始。为识别目的输入的账户号码在会话中适当的地方被携带和预填充（整个会话中只携带一个账户号码）。会话可以包含多个单独的应用程序事务。只要 CSR 处理的是同一个主账户的活动，会话就会继续。如果要为不同的账户号码执行事务，则必须开始新的会话。在会话结束时，决定是否向客户收取所请求活动的费用，无论哪种收费选择都会结束会话。在大多数情况下，是否收费由 CSR 决定（一些缩微胶片请求会自动收费，一些项目如报表则手动收费），CSR 会得到决策指导，通过按“收费”或“不收费”功能键来处理决策。

9. 主机应用程序和用户 ID

每个 CSR 都有一个主机定义的用户 ID，所有用于 IBM 大型机访问的用户 ID 通过 RACF 安全应用程序定义。该用户 ID 用于登录到具有预定义客户服务部门适当应用程序的网络总监屏幕。通过屏幕选择或使用适当的功能键可以进入 IMS 和 CICS 应用程序，不需要额外的用户 ID。访问电子邮件需要不同的用户 ID 和密码。同一个用户 ID 可以用于登录四个会话，但每个会话可以有不同的用户登录。CSRs 可以登录多个 CICS 应用程序，但由于只有一个会话定义到 IMS，所以只能登录一个 IMS 应用程序。

10. 需求

所有列出的需求都必须得到解决，供应商应按相同顺序和编号响应本节内容。当出现需求或问题列表时，供应商应按相同顺序响应。功能以描述或问题的形式列出，供应商应说明如何支持该功能，避免简单的“是”或“否”回答。
响应必须明确指出哪些功能需求是：
- 可交钥匙交付（无需开发或定制）。
- 可由最终用户定义交付（无需技术资源来适应 FNAX 需求），区分最终用户无需技术支持即可实现的功能和需要更正式程序或控制来实现的功能。
- 使用标准供应商提供的工具和预构建模块进行交付，列出将使用的工具或模块以及对预构建模块必须进行的修改，并描述将工具或模块适应 FNAX 需求所需的工作量。
- 仅通过新开发交付。
- 是计划发布但当前未投入生产的可交付成果。
- 不可交付。
本节中确定的工具和预构建模块应与第 4.2 节（通用软件包信息）中这些特定工具/模块的完整描述进行交叉引用。供应商必须具体说明某个需求是否可以支持但目前没有任何客户在生产中使用。供应商必须准备好为当前正在生产中使用任何功能的站点提供参考，包括联系人信息。如果供应商认为某个需求是未来的增强功能，当前产品无法交付，则必须指定提议的可用日期。供应商可以为满足任何需求提出各种替代解决方案，替代方案的适用性将由 FNBA 全权决定。

以下是 ACD 呼叫处理流程的 mermaid 流程图：

graph TD;
    A[呼叫进入 Axxum ACD] --> B[检查 Axxum 可用 VRU];
    B -->|无可用 VRU| C[等待 3 秒];
    C --> D[检查 Axxum 主要队列代表];
    D -->|无可用代表| E[继续检查 VRU 或主要队列 CSR];
    E -->|仍无可用| F[检查特殊队列代表];
    F -->|无可用| G[检查业务队列代表];
    G -->|无可用| H[联系 Xzzum ACD 预订];
    H --> I[Xzzum ACD 查找代表];
    I --> J[找到 Xzzum 特殊队列代表];
    J --> K[呼叫路由到 Xzzum 代表];
    B -->|有可用 VRU| L[VRU 处理呼叫];
    D -->|有可用代表| M[主要队列代表处理呼叫];
    F -->|有可用代表| N[特殊队列代表处理呼叫];
    G -->|有可用代表| O[业务队列代表处理呼叫];

计算机电话信息请求相关内容解析

11. 系统整体架构总结

从上述内容可以看出，整个系统是一个复杂且相互关联的架构，涵盖了硬件、软件、网络和应用程序等多个方面。以下是对系统整体架构的总结：
- 硬件层面 ：包括 Tandem 环境中的处理器用于特定业务处理，前端网络处理器如 IBM 3725 和 IBM 3745 等，以及客户服务部门的 IBM 3270 类型终端。
- 软件层面 ：涉及多个软件版本，如 MVS/ESA、IMS、CICS、DB2 等，不同的应用程序基于这些软件平台运行。
- 网络层面 ：通过令牌环局域网连接到 IBM 主机，同时 ACD 通过 T - 1 线路连接实现呼叫平衡。
- 应用程序层面 ：有众多应用程序，如 Access、BOL、CIS 等，每个应用程序都有其特定的功能和处理量。

以下是系统架构的 mermaid 流程图：

graph LR;
    A[硬件] --> B[软件];
    B --> C[网络];
    C --> D[应用程序];
    A1[Tandem 处理器] --> A;
    A2[前端网络处理器] --> A;
    A3[IBM 3270 终端] --> A;
    B1[MVS/ESA] --> B;
    B2[IMS] --> B;
    B3[CICS] --> B;
    B4[DB2] --> B;
    C1[令牌环局域网] --> C;
    C2[T - 1 线路] --> C;
    D1[Access] --> D;
    D2[BOL] --> D;
    D3[CIS] --> D;
    D4[其他应用程序] --> D;

12. 系统优势分析

高可用性 ：两个 ACD 通过 T - 1 线路连接，在计划内或计划外停机期间可以相互支持，确保呼叫处理的连续性。同时，多个应用程序的分布式处理也提高了系统的整体可用性。
灵活的呼叫处理 ：ACD 具有独立可编程的“路由”，可以根据不同的条件和需求灵活处理呼叫，提高了客户服务的效率和质量。
丰富的应用功能 ：涵盖了多种业务相关的应用程序，如账户管理、交易处理、客户信息管理等，满足了不同业务场景的需求。
详细的报告功能 ：ACD 提供详细的呼叫处理报告，为管理决策提供了有力的数据支持。

13. 系统面临的挑战

数据一致性 ：由于不同应用程序的处理截止时间不同，以及账户刷新按应用程序和账户进行，可能会导致数据不一致的问题。例如，查询到的不同账户信息可能处于不同的更新状态。
技术更新换代 ：随着技术的不断发展，现有的软件版本和硬件配置可能需要不断更新和升级，以满足业务增长和客户需求的变化。
安全问题 ：涉及大量的客户信息和金融交易，系统的安全性至关重要。需要确保数据的保密性、完整性和可用性，防止数据泄露和恶意攻击。

14. 应对挑战的建议

数据管理策略 ：建立统一的数据管理策略，定期进行数据同步和一致性检查，确保各个应用程序之间的数据一致性。同时，记录账户的刷新日期，方便在提供信息时进行参考。
技术规划 ：制定技术更新计划，定期评估系统的性能和功能，及时进行软件升级和硬件更换，以保持系统的先进性和竞争力。
安全措施 ：加强安全防护措施，如采用加密技术、访问控制、入侵检测等，确保系统的安全性。同时，对员工进行安全培训，提高安全意识。

15. 未来发展趋势

智能化 ：随着人工智能和机器学习技术的发展，系统可能会引入智能客服、智能路由等功能，提高客户服务的效率和质量。
移动化 ：越来越多的客户通过移动设备进行业务操作，系统可能会提供移动应用程序，方便客户随时随地进行查询和交易。
大数据分析 ：利用系统产生的大量数据进行大数据分析，挖掘潜在的业务价值，为业务决策提供更准确的依据。

16. 总结

整个系统是一个复杂而庞大的体系，在客户服务和业务处理方面具有较高的效率和灵活性。但同时也面临着数据一致性、技术更新和安全等方面的挑战。通过合理的数据管理、技术规划和安全措施，可以有效应对这些挑战。未来，随着技术的发展，系统有望朝着智能化、移动化和大数据分析等方向发展，为客户提供更好的服务和体验。

以下是系统优势、挑战、建议和趋势的表格总结：
|类别|详情|
| ---- | ---- |
|系统优势|高可用性、灵活的呼叫处理、丰富的应用功能、详细的报告功能|
|系统挑战|数据一致性、技术更新换代、安全问题|
|应对建议|数据管理策略、技术规划、安全措施|
|未来趋势|智能化、移动化、大数据分析|