您的 KYC 客户开户数据模板
您的 KYC 客户开户数据模板
- 建议的事件日志属性
- 整个流程中需要追踪的关键活动
- 实用的数据提取指南
KYC 客户入职属性
| 名称 | 描述 | ||
|---|---|---|---|
|
客户申请
CustomerApplication
|
每个客户开户申请 Case 的唯一标识符。 | ||
|
描述
客户申请 (Customer Application) 是主要的 Case 标识符,它将单个客户开户旅程中的所有相关活动和事件分组。每份申请都遵循从提交到批准激活或拒绝的路径。 在流程挖掘中,此属性对于重构每份申请的端到端旅程至关重要。它允许分析师查看完整的事件序列,跟踪每份申请的状态,并比较不同的路径。根据此 ID 分析 Case 有助于识别常见的流程变体、瓶颈以及偏离标准程序的情况。
为何重要
此 ID 是流程挖掘的基础,因为它将所有单个事件连接成连贯的、端到端的流程实例以供分析。
获取方式
这通常是 Pega 中的主要 Case ID,通常可以通过 pzInsKey 或主 Case 类型工作对象中业务友好的等效项访问。
示例
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
开始时间
EventTime
|
指示某项活动或事件开始的时间戳。 | ||
|
描述
此属性记录活动开始的精确日期和时间。它为单个客户申请 Case 内的所有事件提供按时间顺序排列的顺序。 时间戳是性能相关流程分析的基础。它们用于计算活动持续时间、步骤之间的等待时间以及开户流程的端到端总周期。这些数据对于识别瓶颈、衡量 SLA 达成情况以及了解流程效率至关重要。
为何重要
时间戳提供了计算持续时间、分析流程绩效和识别延迟所需的时序背景。
获取方式
这是 Pega 审计轨迹的标准部分,通常在历史表中作为每个事件的 pxTimeCreated。
示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
|
|||
|
活动
ActivityName
|
开户流程中发生的特定事件或任务的名称。 | ||
|
描述
此属性记录业务活动或系统事件的名称,例如“提交申请”、“启动合规审核”或“申请被拒绝”。它代表整个客户开户流程中的一个步骤。 分析活动是流程挖掘的核心。此属性用于构建流程图,显示不同步骤之间的流向。它有助于识别事件序列,衡量每个活动的频率,并精准定位哪些任务最常见或最耗时。
为何重要
此属性定义了流程图中的步骤,从而使可视化、分析和理解流程流向成为可能。
获取方式
此信息通常记录在 Pega 的审计轨迹(历史表)中,或者可以从 Case 的状态变化中得出。
示例
初次筛选已执行合规审查已完成申请已批准
|
|||
|
SLA 目标日期
SlaTargetDate
|
预计完成客户开户 Case 的日期。 | ||
|
描述
此属性存储申请的目标完成日期,该日期由服务水平协议 (SLA) 定义。SLA 可能会根据客户类型、风险等级或产品等因素而有所不同。 此日期对于“SLA 达成跟踪”仪表板和相关 KPI 至关重要。它作为衡量实际完成日期的基准。分析未达到 SLA 目标的 Case 有助于识别系统性延迟,并优先进行流程改进,以确保履行服务承诺。
为何重要
它为衡量准时率提供了基准,这对于客户满意度和运营控制至关重要。
获取方式
Pega 内置了 SLA 管理框架。该日期通常存储在 pySLAGoal 等属性中,或者存储在 Case 的自定义 SLA 属性中。
示例
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
拒绝原因
RejectionReason
|
说明申请被拒绝的原因。 | ||
|
描述
当申请的最终状态为“已拒绝”时,此属性提供具体原因,例如“背景调查失败”、“文件不全”或“高风险概况”。 此属性是“申请拒绝分析”仪表板的主要驱动因素。通过按原因细分拒绝 Case,企业可以识别开户流程中最常见的失败点。这一见解对于实施有针对性的改进以降低拒绝率、改善客户体验并提高运营效率至关重要。
为何重要
深入分析申请失败的原因,提供可落地的建议,从而有针对性地改进流程,提高成功率。
获取方式
这很可能是当 Case 转换为“已拒绝”状态时在 Case 上设置的特定属性。请参阅 Pega KYC 文档以获取标准拒绝原因字段。
示例
命中制裁名单文件不匹配政治敏感人物 (PEP) 识别信息不足
|
|||
|
用户
OperatorId
|
执行该活动的用户的唯一标识符。 | ||
|
描述
此属性存储负责完成 KYC 流程中特定任务的员工或系统用户的 ID,例如合规官或自动化筛查机器人。对于自动化步骤,这可能是系统或服务账号 ID。 按用户分析有助于了解工作量分布、个人绩效和培训需求。它还可以通过识别参与非标准流程流向的用户或团队来调查流程偏离情况。
为何重要
此属性将流程活动链接到特定的个人或团队,从而实现工作量分析、绩效评估和合规性检查。
获取方式
这是 Pega 审计轨迹中的一个标准字段,通常在历史表中存储为 pxUpdateOperator 或类似的属性。
示例
j.doe@acmebank.comkyc_analyst_04system_auto_agent
|
|||
|
申请状态
ApplicationStatus
|
客户申请的最终结果或当前状态。 | ||
|
描述
此属性表示流程结束时申请的整体状态,如“已批准”、“已拒绝”或“已撤回”。它也可以反映进行中 Case 的最新状态。 这是结果分析的一个关键维度。它直接用于“申请拒绝分析”仪表板,以细分 Case 并了解特定结果发生的原因。分析导致不同状态的流程流向有助于识别已批准 Case 的最佳实践以及已拒绝 Case 的根本原因。
为何重要
它定义了案例的业务结果,从而支持对成功路径与失败路径进行强大的对比分析。
获取方式
这通常是 Pega 中 Case 工作对象的最终状态 (pyStatusWork)。
示例
已批准已驳回等待合规审核客户已撤回
|
|||
|
结束时间
EndTime
|
指示活动或事件完成的时间戳。 | ||
|
描述
此属性记录活动结束的精确日期和时间。它与“开始时间”配合使用,以计算单个活动的处理时间。 拥有明确的“结束时间”可以进行更准确的性能分析。它有助于区分主动处理时间(开始时间和结束时间之间的时间段)和等待时间(一个活动的结束时间与下一个活动的开始时间之间的时间段)。这对于精准定位真正的瓶颈并将其与排队情况区分开来至关重要。
为何重要
能够精确计算活动处理时间,这对于详细的性能分析和瓶颈识别至关重要。
获取方式
这可能在 Pega 的审计轨迹中可用,或者可能需要通过将后续事件的“开始时间”作为当前事件的“结束时间”来得出。
示例
2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
|
|||
|
部门
WorkGroup
|
负责该活动的部门或职能团队。 | ||
|
描述
此属性识别执行用户的组织单位或团队,例如“筛查团队”、“合规部”或“开户运营部”。 按部门分析流程对于“按部门划分的工作量分布”仪表板至关重要。它帮助经理了解工作在不同团队之间的流转情况,识别跨职能瓶颈,并评估整个开户流程的资源分配。它是优化交接和平衡工作量的关键。
为何重要
它支持对不同业务单元之间的流程流向和瓶颈进行分析,从而助力资源管理和组织优化。
获取方式
此信息通常与 Pega 中的用户配置文件(Operator ID 记录)相关联,并可与事件数据合并。该属性可能是 pyWorkGroup。
示例
初次筛选合规审查账户激活
|
|||
|
风险等级
RiskLevel
|
客户申请的计算风险等级。 | ||
|
描述
此属性表示与客户相关的评估风险,通常分为“低”、“中”或“高”。风险等级通常由自动化评分引擎根据客户数据和筛查结果确定。 风险等级是流程变体的主要驱动因素。高风险申请通常需要额外的尽职调查步骤(如增强的合规审核),从而导致更长的周期。按风险等级分析流程有助于证明这些变体的合理性,并确保风险控制在不造成过度延迟的情况下有效运行。
为何重要
解释流程路径和持续时间的变化,因为风险等级通常决定了所需的尽职调查水平。
获取方式
这将是 Case 上的一个计算属性,由 Pega 决策规则或评分模型填充。请参阅 Pega KYC 文档。
示例
低中高
|
|||
|
SLA 状态
SlaStatus
|
指示案例是否在 SLA 目标内完成。 | ||
|
描述
此属性根据实际完成时间戳与“SLA 目标日期”的比较,将每个已完成的 Case 分类为“准时”或“逾期”。 这是“SLA 达成跟踪”仪表板和“SLA 达成率”KPI 的核心指标。它能让人一目了然地查看服务水平承诺的履行情况。分析逾期 Case 的特征有助于识别延迟的根本原因并降低未来 SLA 违约的风险。
为何重要
直接衡量相对于承诺的绩效,这对于运营管理、合规性和客户满意度至关重要。
获取方式
这是通过将最终 Case 活动的时间戳与 SlaTargetDate 字段进行比较得出的。如果完成时间晚于目标时间,则状态为“逾期”。
示例
准时逾期存在风险
|
|||
|
最后数据更新
LastDataUpdate
|
上次数据刷新或提取的时间戳。 | ||
|
描述
此属性表示从源系统提取数据的最近时间。通常,单次数据加载中的所有记录都是相同的。 此时间戳对于了解所分析数据的时效性非常重要。它让用户知道流程分析的最新程度以及下一次数据更新的时间,这对于运营监控仪表板至关重要。
为何重要
告知用户数据的及时性,确保他们了解分析反映的是当前状态还是过去某段时期。
获取方式
此值在数据提取、转换和加载 (ETL) 过程中生成并标记到数据集中。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
单据状态
DocumentStatus
|
客户所提供文件的当前状态。 | ||
|
描述
此属性跟踪 KYC 流程所需文件的状态,其值包括“待处理客户”、“已收到”、“已验证”或“已拒绝”。在单个 Case 中,此状态可能会多次更改。 这是“开户吞吐量和状态”仪表板以及“文件验证速度”分析的关键属性。它允许对最常见的瓶颈区域之一进行粒度视图。By 跟踪文件在每个状态下保留的时间,企业可以识别客户提交或内部审核中的延迟。
为何重要
提供文件处理子流程的可见性,帮助识别并解决文件验证中的常见延迟。
获取方式
这很可能是与主 Case 关联的相关数据对象或页面列表 (Page List) 上的属性,用于跟踪每份所需文件。请参阅 Pega KYC 文档。
示例
等待上传已收到 - 待审核已批准已拒绝 - 需要更多信息
|
|||
|
周期时间
CycleTime
|
从提交申请到最终解决所经过的总时间。 | ||
|
描述
此计算指标衡量每个客户申请从第一个事件到最后一个事件的端到端持续时间。通常计算为给定 Case 的最终活动与初始活动的时间戳之差。 周期 (Cycle Time) 是衡量流程效率和客户体验的主要关键绩效指标 (KPI)。它用于“整体开户周期分析”仪表板,以监控平均处理时间,识别运行时间较长的 Case,并跟踪流程改进计划随时间产生的影响。
为何重要
这是一个关键 KPI,直接从客户的角度衡量开户流程的整体速度和效率。
获取方式
该指标在流程挖掘工具中通过计算每个 Case ID 的最大和最小时间戳之差得出。
示例
5 天 4 小时12 天 1 小时2 天 8 小时
|
|||
|
处理时间
ProcessingTime
|
单个活动的持续时间,不包括等待时间。 | ||
|
描述
此指标计算事件的主动工作时间,即其“结束时间”与“开始时间”之差。它代表资源主动从事某项任务的时间。 处理时间 (Processing Time),也称为活动的周期,对于详细的性能分析至关重要。它有助于区分耗时较长的任务(处理时间长)和排队时间较长(等待时间长)的情况。这可以实现更有针对性的改进工作,例如提供更好的工具来加快任务速度,或者重新分配资源以减少排队。
为何重要
衡量活动的实际工作时长,有助于区分低效任务与资源或排队问题。
获取方式
该指标计算为每个事件的 (EndTime - StartTime)。它要求两个时间戳字段都可用。
示例
15 minutes4 小时 30 分钟2 天
|
|||
|
客户ID
CustomerId
|
正在开户的客户的唯一标识符。 | ||
|
描述
此属性是唯一的 ID,将申请链接到主数据系统中的客户记录。它代表了作为 KYC 流程对象的实体,无论是个人还是组织。 虽然申请 ID 跟踪流程,但客户 ID (Customer ID) 允许跨同一客户的多个申请进行分析,或者使用客户特定属性(如细分市场或历史记录)来丰富流程数据。这实现了以客户为中心的开户流程视图。
为何重要
将流程数据连接到客户主数据,从而能够基于客户属性和历史记录进行更丰富的分析。
获取方式
这将是 KYC Case 上的一个核心属性,将其链接到 Pega 内部或外部 CRM 中的客户数据模型。
示例
CUST-98765CUST-98766CUST-98767
|
|||
|
客户国家/地区
CustomerCountry
|
客户的居住国或注册国。 | ||
|
描述
此属性存储与开户客户关联的国家。此信息是风险评估和确定所需尽职调查水平的关键输入。 在分析中,客户所在国家可以揭示重要的模式。某些司法管辖区可能与更高的风险相关联,导致更长且更复杂的开户流程。这一维度允许基于地理位置进行绩效分析,并有助于确保有效地满足区域合规要求。
为何重要
支持对流程进行地理分析,这通常与监管复杂性和风险水平相关联。
获取方式
这将是与 Case 关联的客户数据对象上的一个属性。
示例
美国DEUSGPGBR
|
|||
|
已入职产品
OnboardedProduct
|
客户申请的金融产品。 | ||
|
描述
此属性指定客户开户所属的产品或服务,例如“零售银行账户”、“企业贷款”或“投资服务”。 产品会影响开户流程,因为不同的产品可能有不同的监管要求和复杂性。按产品分析流程有助于识别特定产品线是否具有更长的周期或更高的拒绝率,为特定产品的流程优化提供见解。
为何重要
允许按产品线细分流程分析,揭示性能差异和优化机会。
获取方式
这将是 Case 上的一个属性,在申请流程开始时选择。
示例
支票账户财富管理商业信用额度
|
|||
|
是否已自动化
IsAutomated
|
指示活动是由系统还是人工执行的标识。 | ||
|
描述
如果活动由自动化代理(如筛查引擎或系统规则)执行,则此布尔属性为 true;如果是由于人工用户执行,则为 false。 区分自动化和人工活动对于自动化分析至关重要。它有助于衡量现有自动化的有效性,识别适合未来自动化的手工任务,并了解流程中人工和系统参与者之间的交互。
为何重要
它将人工驱动的活动与系统驱动的活动分开,这是任何自动化计划或分析的基础。
获取方式
这可以从与事件关联的用户 ID 中推断出来。如果 OperatorId 对应于已知的系统或代理账号,则此标志设置为 true。
示例
truefalse
|
|||
|
是否返工
IsRework
|
指示活动是否属于返工循环一部分的标识。 | ||
|
描述
如果特定活动(如“文件审核”)在同一个 Case 中发生多次,则此布尔属性为 true。这通常由“请求补充信息”等事件触发。 识别返工对于发现流程效率低下和客户摩擦点至关重要。“流程返工和循环”仪表板使用此属性来量化返工的频率和影响。减少返工通常是一个关键目标,因为这可以加快处理速度、降低运营成本并改善客户体验。
为何重要
突出流程中的低效环节、冗余任务和循环,这些都是流程改进的主要目标。
获取方式
此标志在数据分析期间通过检查同一个 Case ID 内重复的活动名称得出。例如,如果“文件审核完成”出现了第二次。
示例
truefalse
|
|||
|
案例类型
CaseType
|
KYC 开户 Case 的具体类型。 | ||
|
描述
此属性对开户申请进行分类,例如“个人客户”、“企业客户”或“高净值个人”。不同的 Case 类型通常遵循不同的流程变体,具有不同的步骤、SLA 和风险概况。 按 Case 类型分析流程可以实现更有意义的绩效比较。它有助于了解某些类型的开户是否更容易出现延迟或拒绝。这种细分对于针对不同客户旅程的特定需求定制流程改进至关重要。
为何重要
允许将流程数据细分为不同的类别,从而实现更准确、更相关的性能分析。
获取方式
这通常是 Pega 中 Case 实例的类名,或者是 Case 上定义其类型的专用属性。
示例
个人入职/准入企业入职/准入简化尽职调查
|
|||
|
源系统
SourceSystem
|
用于标识数据来源的系统。 | ||
|
描述
此属性指定记录事件的源应用程序。对于此流程,该值始终为 'Pega KYC'。 虽然如果所有数据都来自一个系统,这似乎是多余的,但此属性对于数据治理至关重要,并且在集成来自多个系统的数据时变得非常重要。它确保了数据来源的清晰度,并有助于排查数据集成问题。
为何重要
它提供了有关数据来源的关键上下文,确保了数据治理并支持跨多个源系统的分析。
获取方式
这通常是在 data 提取和 transformation 过程中添加的静态值,用于标记 dataset 的来源。
示例
Pega KYCPega CLM
|
|||
KYC 客户入职活动
| 活动 | 描述 | ||
|---|---|---|---|
|
入职办理完成
|
此活动标志着整个 KYC 开户流程的成功结束。当 Pega Case 达到表示成功完成的最终解决状态且所有下游操作均已结束时,将记录此活动。 | ||
|
为何重要
这是该流程的主要成功结束事件。它对于计算所有成功开户客户的端到端周期至关重要。
获取方式
从案例解决状态 (pyStatusWork) 设置为其最终成功值(如“Resolved-Completed”)时的时间戳推断得出。
捕获
识别 History-Work 表中最终“Resolved-Completed”状态的时间戳。
事件类型
inferred
|
|||
|
合规审查已启动
|
此活动标志着合规团队正式审核的开始,这是流程中关键且通常耗时较长的部分。当 Case 被分配到合规工作队列或其状态相应更新时,将记录此活动。 | ||
|
为何重要
这是“合规审核周期”KPI 的开始事件。它有助于衡量并识别这个关键(通常是手动的)审核阶段中的瓶颈。
获取方式
从案例状态 (pyStatusWork) 更改为“Pending-Compliance”或从合规工作篮中的分配创建事件推断得出。
捕获
识别案例被分配到合规工作篮的时间戳,或状态更改以指示审查开始的时间戳。
事件类型
inferred
|
|||
|
合规审查已完成
|
此活动表示合规团队已完成审核并提出了建议。它通过 Case 的状态更改来捕获,将其移出合规阶段。 | ||
|
为何重要
这是“合规审核周期”KPI 的结束事件。分析直到此时间点的时间对于提高合规效率至关重要。
获取方式
从案例状态 (pyStatusWork) 从“Pending-Compliance”更改为“Pending-Final-Decision”或“Resolved-Approved”等状态推断得出。
捕获
识别案例历史中合规审查阶段或分配完成的时间戳。
事件类型
inferred
|
|||
|
已执行风险评估
|
此活动标志着根据申请和验证数据完成客户风险评估和评分。这是一个关键里程碑,通常在 Pega Case 中的风险评估阶段或步骤解决时记录。 | ||
|
为何重要
这是一个关键的合规里程碑。分析此活动的持续时间和结果是了解风险管理效率及其对流程路径影响的关键。
获取方式
从 Pega 案例模型中特定阶段或流程的完成推断得出,这会导致审计轨迹中记录状态更改。
捕获
从风险评估阶段后 pyStatusWork 的更改推断得出,例如,变为“Pending-Compliance-Review”。
事件类型
inferred
|
|||
|
已提交申请
|
此活动标志着在 Pega 系统中创建了新的客户开户 Case。当通过客户门户、内部用户或自动数据馈送正式发起客户申请的新 Case 实例时,将记录此活动。 | ||
|
为何重要
这是整个开户流程的主要开始事件。它对于衡量端到端周期以及分析申请提交量和模式至关重要。
获取方式
这是创建新工作对象 (Case) 时在 Pega 审计轨迹中捕获的显式事件。在 pc_history_work 表中查找 Case ID 的初始条目。
捕获
从 pc_work 表中的案例创建时间戳或审计轨迹中的第一条记录捕获。
事件类型
explicit
|
|||
|
已收到文件
|
标志着客户已将所有要求的文档上传或提供给系统的时刻。当新附件链接到 Pega 案例时,通常会将其捕获为明确的事件。 | ||
|
为何重要
这是一个关键里程碑,开启了文件审核和验证 SLA 的计时。此时间点之前的延迟取决于客户,而此后的延迟则是内部原因。
获取方式
当新文档与案例关联时,会明确记录在 Pega 的附件表(pc_link_attachment 或 pc_data_workattach)中。
捕获
事件是与案例链接的相关附件对象的创建时间戳。
事件类型
explicit
|
|||
|
申请已批准
|
代表批准客户开户申请的最终决定。这是一个关键的业务里程碑,可通过 Case 状态更新为最终成功的解决状态来推断。 | ||
|
为何重要
这是区分成功 Case 与失败 Case 的关键里程碑。它是最终账户激活步骤的前奏,也是衡量决策时间的常见节点。
获取方式
从案例解决状态 (pyStatusWork) 设置为最终成功值(如“Resolved-Completed”或“Resolved-Approved”)时的时间戳推断得出。
捕获
识别案例审计轨迹中反映成功解决的 pyStatusWork 的最终更新。
事件类型
inferred
|
|||
|
申请被拒绝
|
代表拒绝客户申请的最终决定,从而终止开户流程。该事件可通过 Case 进入最终未成功的解决状态来推断。 | ||
|
为何重要
这是主要的失败结束事件。它对于分析“申请拒绝率”以及通过“拒绝原因”等属性了解失败原因至关重要。
获取方式
从案例解决状态 (pyStatusWork) 设置为最终失败值(如“Resolved-Rejected”)时的时间戳推断得出。
捕获
识别案例审计轨迹中反映拒绝状态的 pyStatusWork 的最终更新。
事件类型
inferred
|
|||
|
初次筛选已执行
|
代表对申请数据完整性和基本资格的初始(通常是自动化的)审核完成。该事件通常根据 Case 状态的变化推断得出,例如从“新建”变为“待处理文件”。 | ||
|
为何重要
分析这一初始阶段花费的时间,有助于识别数据验证或自动规则执行中的早期瓶颈,这些瓶颈可能会延迟整个流程。
获取方式
从 Pega 审计轨迹(History-Work 表)中记录的案例状态属性 (pyStatusWork) 更改推断得出。
捕获
识别 pyStatusWork 从“New”或“Submitted”状态更改为“ScreeningComplete”或类似状态的时间戳。
事件类型
inferred
|
|||
|
已发起背景调查
|
代表开始对客户进行外部或内部背景调查,这可能涉及第三方服务集成。通常根据指示 Case 正在等待这些核查结果的状态变化来推断。 | ||
|
为何重要
此活动有助于分离等待外部依赖项所花费的时间。它可以分析第三方服务的绩效及其对整体开户时间的影响。
获取方式
从 Pega 的 History-Work 表中记录的案例状态 (pyStatusWork) 更改为“Pending-Background-Check”或类似状态推断得出。
捕获
识别 pyStatusWork 更新为反映背景调查流程已启动的时间戳。
事件类型
inferred
|
|||
|
已请求文件
|
当系统或代理确定需要客户提供特定文件才能继续时,会发生此活动。它通过识别信函的创建或 Case 状态更改为“待处理客户文件”等状态来捕获。 | ||
|
为何重要
跟踪此项有助于衡量客户响应所需的时间,并确定流程是否因等待文件而频繁停滞。它是“文件验证时长”KPI 的前置指标。
获取方式
可以是明确的信函事件 (pc_link_attachment),也可以是从审计轨迹中记录的案例状态更改 (pyStatusWork) 推断得出。
捕获
从 pyStatusWork 更改为“Pending-Documents”或类似状态推断得出。也可以与明确的“发送信函”事件关联。
事件类型
inferred
|
|||
|
文件审查已完成
|
此活动表示合规官或自动化流程已完成对客户提交文件的审核。该事件根据 Case 或文件状态的变化推断得出,表示审核步骤已完成。 | ||
|
为何重要
完成文件验证时长 KPI。分析完成此步骤的时间可以突出人工或自动审查流程中的效率低下。
获取方式
从审计轨迹中案例状态 (pyStatusWork) 从“Pending-Review”状态变为“Review-Complete”或“Pending-Checks”状态推断得出。
捕获
识别案例状态 (pyStatusWork) 发生更改的时间戳,这标志着文件验证子流程已解决。
事件类型
inferred
|
|||
|
请求补充信息
|
当审查人员(通常是合规部门)需要客户提供更多信息或澄清时发生。此事件通常是明确的,在用户从案例发送特定信函时记录。 | ||
|
为何重要
此活动是流程返工和循环的主要指标。跟踪其频率对于衡量一次处理通过率和识别不明确的需求至关重要。
获取方式
可以是审计轨迹中记录的明确“发送信函”事件。或者,也可以从状态更改为“等待客户信息”推断得出。
捕获
从创建特定信函对象或由案例工作人员发起的流程操作中捕获。
事件类型
explicit
|
|||
|
账户已激活
|
此活动表示客户账户已在核心银行或相关下游系统中成功创建并激活。这通常是在成功批准后,根据 Pega Case 中的最终状态更新推断出来的。 | ||
|
为何重要
代表了客户和企业的“价值”时刻。“申请批准”与此事件之间的时间反映了系统交接的效率。
获取方式
从审计轨迹中记录的特定案例状态 (pyStatusWork)(如“Resolved-AccountActive”)或通过集成设置在案例上的标志推断得出。
捕获
识别指示下游账户已激活的案例属性更新时间戳。
事件类型
inferred
|
|||