您的贷款发起数据模板
您的贷款发起数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
贷款发放属性
| 名称 | 描述 | ||
|---|---|---|---|
| 事件timestamp EventTimestamp | 特定活动或事件发生的日期和时间。 | ||
| 描述 Event Timestamp 记录了活动发生的精确时刻。此时间序列数据对于正确排列事件顺序以及进行所有基于时间的流程分析至关重要。 此属性支持计算关键绩效指标(KPI),如周期时间、处理时间和活动间的等待时间。它用于识别延迟、衡量相对于服务水平协议(SLA)的绩效,并了解贷款发放流程的时间动态。没有准确的 timestamp,流程挖掘就无法实现。 为何重要 此 timestamp 对于正确排序事件以及计算所有基于时长的指标(如周期时间和瓶颈)至关重要。 获取方式 通常在 Temenos 的事件日志或审计追踪表中与活动或状态字段并列。请查找名为 'TIMESTAMP'、'EVENT_DATE' 或类似的字段。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z | |||
| 活动名称 ActivityName | 贷款发放流程中发生的特定业务事件或步骤的名称。 | ||
| 描述 Activity Name 描述了贷款发放过程中的具体步骤或里程碑,例如“Application Submitted”或“Credit Check Completed”。这些活动构成了流程图的骨干,展示了每笔贷款申请的事件序列。 分析这些活动有助于实现流程流向的可视化,识别常用路径,发现偏离情况并精准定位瓶颈。活动的顺序和频率是理解流程实际运行情况(与设计情况相比)的基础。 为何重要 它定义了流程中的步骤,支持流程图的可视化以及对流程流、瓶颈和偏差的分析。 获取方式 此信息通常源自 Temenos 内的事件日志、状态变更记录或审计追踪表。可能需要将技术状态代码或事件类型映射为用户友好的活动名称。 示例 已提交申请已完成信用审核核保开始贷款决策已下达资金已拨付 | |||
| 贷款申请 ID LoanApplicationId | 每个贷款申请的唯一标识符,作为追踪整个发放流程的主键。 | ||
| 描述 Loan Application ID 在贷款请求的整个生命周期内(从提交到最终决策和放款)唯一标识每一笔请求。它是关联所有活动和数据的核心实体,支持对特定贷款的发放过程进行完整追踪。 在流程挖掘中,此属性对于构建案例(case)视图必不可少,其中每个 Loan Application ID 代表一个完整的端到端流程实例。通过此标识符分析数据可以计算案例级指标,如总周期时间、返工环路和最终结果,从而全面了解贷款发放流程。 为何重要 这是必不可少的 case 标识符,它将所有相关事件连接成一个完整的端到端流程,使流程分析成为可能。 获取方式 这通常是 Temenos 中主贷款申请或交易实体的初级键。请咨询 Temenos 文档以获取具体的表名和字段名,例如与 AA.ARRANGEMENT 模块相关的名称。 示例 LA-2023-001234LA-2023-001235LA-2023-001236 | |||
| 最后数据更新 LastDataUpdate | 指示此 event 的 data 上次刷新或提取时间的 timestamp。 | ||
| 描述 此元数据属性记录了从源系统进行最近一次数据提取或更新的日期和时间。它不代表业务事件,而是代表被分析数据的新鲜度。 这些信息对于了解流程挖掘分析的时效性以及数据治理至关重要。它帮助用户了解他们查看的是实时数据、每日数据还是每周数据,从而为他们的发现和决策提供背景信息。 为何重要 指示数据的新鲜度,这对于数据治理以及用户了解其分析的时效性至关重要。 获取方式 这是在数据提取、转换和加载 (ETL) 过程中添加的元数据属性。它通常设置为 ETL 运行时的 timestamp。 示例 2023-11-20T04:00:00Z2023-11-21T04:00:00Z2023-11-22T04:00:00Z | |||
| 源系统 SourceSystem | 提取事件数据的记录系统。 | ||
| 描述 此属性标识了活动数据起源的信息系统。在复杂的 IT 环境中,贷款发放事件可能记录在多个系统中,例如前端门户、核心银行平台和文档管理系统。 指定源系统对于数据治理、故障排除以及了解流程中的技术触点非常重要。它有助于验证数据准确性,并能揭示跨不同平台的流程碎片化情况。 为何重要 识别数据来源,这对于数据验证、故障排除和理解流程集成至关重要。 获取方式 这是通常在数据提取和转换过程中添加的元数据属性。对于来自该系统的所有记录,它可以是一个静态值,例如 'Temenos Transact'。 示例 Temenos Transact T24Temenos Infinity外部征信服务 | |||
| 信用评分 CreditScore | 申请人在申请时的信用评分。 | ||
| 描述 信用评分是申请人信用状况的数字化表示,从征信机构获取。它是核保和决策过程中的关键因素。 在流程挖掘中,信用评分是一个关键的上下文属性。通过将评分与最终结果关联,它有助于分析贷款决策的一致性。它还可以用于细分申请,以查看评分较低的申请是否需要更长的处理时间或更多的人工干预。 为何重要 为决策提供关键背景,支持分析信用度如何影响流程路径、时长和结果。 获取方式 这些数据通常从外部征信机构服务获取,并存储在 Temenos 内的客户或申请特定表中。 示例 720650810 | |||
| 决策结果 DecisionOutcome | 贷款申请审查的最终结果,如已批准、已拒绝或已撤回。 | ||
| 描述 “决策结果”捕获了核保和审批阶段完成后贷款申请的最终状态。这是整个流程的关键结果指标。 此属性对于分析流程有效性至关重要。它用于计算批准率和拒绝率,当与“信用评分”或“申请人类型”等其他属性结合使用时,有助于评估贷款决策的一致性。了解申请被拒绝的原因是流程改进的关键。 为何重要 代表流程的最终业务结果,支持对审批率、拒绝原因和决策一致性进行分析。 获取方式 通常存储在 Temenos 主贷款申请记录的状态字段中。该字段通常在“Loan Decision Rendered”活动中更新。 示例 已批准已驳回申请人撤回报价已过期 | |||
| 指定的信贷员 AssignedLoanOfficer | 负责执行该活动的信贷员或用户的名称或 ID。 | ||
| 描述 此属性标识了在贷款发放流程中执行特定任务的员工或团队成员。在流程挖掘中,这通常被称为“资源”(resource)。 按信贷员分析绩效有助于了解工作负载分布、识别表现优秀的员工并发现培训或流程标准化的机会。它是资源绩效和工作负载管理相关仪表板的基础,支持管理人员优化团队效率并平衡任务分配。 为何重要 将用户操作归因于特定个人或团队,从而实现工作量分析、绩效比较和资源优化。 获取方式 此信息通常存在于审计追踪表中,通常与用户 ID 关联。请在 Temenos 的事件或交易记录中查找如 'USER_ID'、'PROCESSED_BY' 或 'OWNER' 等字段。 示例 Alice SmithBob Johnson核保团队 B | |||
| 申请渠道 ApplicationChannel | 贷款申请的提交渠道,例如在线、分行或移动端。 | ||
| 描述 Application Channel 指示了客户使用的提交方式。不同渠道可能具有不同的数据质量、客户预期和处理要求,从而影响整体流程绩效。 按渠道分析流程有助于识别哪些渠道效率最高,哪些渠道可能需要流程改进。例如,来自在线门户的申请平均处理速度可能快于在分行提交的申请。这一洞察对于优化渠道策略和资源配置非常有价值。 为何重要 支持不同客户互动渠道的绩效分析,有助于优化特定渠道的流程和用户体验。 获取方式 此信息通常在流程开始时捕捉,并存储在主贷款申请记录中。请在 Temenos 中查找 'SOURCE' 或 'CHANNEL' 字段。 示例 在线门户Branch移动应用经纪人 | |||
| 结束时间 EndTime | 指示活动完成时的时间戳。 | ||
| 描述 End Time 标记了特定活动的完成。Start Time 指示事件何时开始,而 End Time 对于了解其持续时间必不可少。对于瞬时事件,End Time 可以与 Start Time 相同。 在流程分析中,同时具备开始和结束时间对于准确计算活动的执行时间(processing time)至关重要。这有助于区分申请正在被处理的时间与等待下一步的时间(wait time),而这正是识别真实效率瓶颈的关键。 为何重要 支持精确计算活动处理时间,这对于在瓶颈分析中区分“实际工作时间”和“空闲等待时间”至关重要。 获取方式 这可能在审计日志中作为一个单独的 'END_TIME' 字段提供,或者可能需要通过使用序列中后续活动的 Start Time 来推导。请咨询 Temenos 文档以了解事件记录详情。 示例 2023-10-26T10:15:00Z2023-10-26T18:00:10Z2023-10-27T11:30:00Z | |||
| 贷款产品类型 LoanProductType | 申请的贷款产品类型,如按揭贷款、个人贷款或汽车贷款。 | ||
| 描述 此属性根据所申请的金融产品对每个贷款申请进行分类。不同的贷款产品通常具有不同的流程流向、SLA 和风险概况。 按 Loan Product Type 对流程分析进行细分对于进行有意义的对比至关重要。它有助于解释周期时间、审批率和流程路径的差异。例如,抵押贷款申请流程本质上比个人贷款流程更复杂、更长。此属性支持“同类比较”并实现针对性改进。 为何重要 支持流程细分,以便比较不同业务线的绩效并识别差异,因为这些业务线通常具有独特的流程要求。 获取方式 这是贷款申请的核心属性,通常存在于 Temenos 的主申请表中。请查找与 'PRODUCT_ID' 或 'PRODUCT_CATEGORY' 相关的字段。 示例 抵押贷款个人贷款汽车贷款房屋净值贷款 | |||
| 贷款金额 LoanAmount | 申请人申请的贷款总金额。 | ||
| 描述 此属性代表所申请的贷款本金金额。贷款金额会显著影响流程路径、审查级别和所需的审批权限。 基于贷款金额分析流程支持按维度细分,以了解高额贷款是否遵循不同且更严格的流程。这有助于解释周期时间和核保投入的差异。例如,超过一定阈值的贷款可能需要额外的审批步骤,这些可以通过流程挖掘进行可视化和验证。 为何重要 支持基于价值的分析,以观察贷款金额如何影响流程复杂性、周期时间以及所需的审批级别。 获取方式 这是 Temenos 贷款申请记录中的基本字段。请查找如 'AMOUNT' 或 'REQUESTED_AMOUNT' 等字段。 示例 250000.0015000.00500000.00 | |||
| 决策原因 ReasonForDecision | 解释最终贷款决策原因的代码或描述,特别是针对拒绝决策。 | ||
| 描述 此属性为“Decision Outcome”提供上下文。对于被拒绝的申请,它指定了根本原因,如“收入不足”、“债务收入比过高”或“信用记录不良”。 这些信息对于拒绝原因的根因分析极具价值。通过分析最常见的拒绝原因,机构可以识别预审阶段的问题、改善客户沟通或调整放贷标准。它直接支持减少返工并提高进入审批环节申请的整体质量。 为何重要 为被拒绝的申请提供关键背景,支持根因分析以提高申请质量并减少不必要的处理。 获取方式 通常存储在 Temenos 中与最终决策状态关联的相关备注或原因代码字段中。 示例 负债收入比过高申请材料不全信用评分低 | |||
| 处理时间 ProcessingTime | 在一项活动上实际投入工作的时间长度。 | ||
| 描述 “处理时间”是一个计算指标,代表活动的实际工作时间,计算方式为结束时间与开始时间之差。它与“等待时间”(即活动之间花费的时间)形成对比。 此指标是瓶颈分析的基础。通过将处理时间与等待时间分开,分析人员可以确定延迟是由低效活动(处理时间长)还是由队列和交接延迟(等待时间长)引起的。这对于正确确定改进重点至关重要。 为何重要 测量活动的实际工作时长,有助于在瓶颈分析中区分流程效率低下和等待时间。 获取方式 此属性不在源系统中。它是在数据转换期间通过从每项活动的“EndTime”中减去“EventTimestamp”(StartTime)计算得出的。 示例 15 minutes2小时3天 | |||
| 客户地区 CustomerRegion | 申请人的地理区域。 | ||
| 描述 Customer Region 提供了申请人的地理位置,例如“北美”、“欧洲”或特定省份。这支持对流程进行地理维度细分。 按区域分析绩效可以发现流程效率、审批率或产品普及度的地域差异。这些洞察可用于精准营销、资源分配,以及识别区域最佳实践或面临的挑战。 为何重要 支持地理位置分析,以比较不同地区的流程绩效,识别区域瓶颈并了解市场差异。 获取方式 此信息是存储在 Temenos 的客户信息文件 (CIF) 或等效客户主数据中的客户概况或地址详情的一部分。 示例 北美欧洲、中东和非洲亚太加利福尼亚州 | |||
| 是否已自动化 IsAutomated | 指示该活动是由系统自动执行还是由用户手动执行的标志。 | ||
| 描述 此布尔属性区分由人工执行的活动与由自动化系统(如自动信用检查或初始验证规则)执行的活动。 了解自动化程度是识别进一步提升效率机会的关键。它支持对自动化步骤与人工步骤的速度和一致性进行比较。此分析有助于确定未来自动化方案的优先级并衡量其影响。 为何重要 区分系统驱动和人工驱动的活动,这对于识别自动化机会和衡量现有自动化的影响至关重要。 获取方式 这通常基于与活动关联的用户来推断。如果用户是系统或服务帐户,则该活动被标记为自动化。也可以基于事件类型本身进行判断。 示例 truefalse | |||
| 是否返工 IsRework | 一个计算标志,如果某项活动属于返工循环的一部分,则为 true。 | ||
| 描述 此布尔标记识别代表返工的活动,即某个步骤或一系列步骤必须重复执行。例如,如果在“Underwriting Commenced”之后发生了“Supporting Documents Requested”,则表示流程出现了回流。 检测并标记返工是流程挖掘的核心优势。此属性支持轻松量化“Application Rework Rate” KPI。分析返工的驱动因素(如初始提交不完整)是提高流程效率、降低成本并缩短周期时间的突破口。 为何重要 突出显示属于低效流程循环一部分的活动,从而可以轻松对返工进行量化和根因分析。 获取方式 此属性不在源系统中。它是流程挖掘引擎通过检测单个 case 内重复出现的活动序列计算得出的。 示例 truefalse | |||
| 核保 SLA 是否违规 IsUnderwritingSlaBreached | 一个计算标志,如果核保时长超过了定义的 SLA 目标,则为 true。 | ||
| 描述 此布尔属性是一个计算出的标记,指示贷款申请的核保阶段是否违反了其服务水平协议(SLA)。它是通过将核保流程的实际持续时间与“Underwriting SLA Target”进行对比来确定的。 此标记通过提供清晰、二元的 SLA 合规指标来简化分析和报告。它直接用于仪表板和 KPI,按时间、产品或信贷员追踪 SLA 违约率,从而帮助前瞻性地管理绩效和合规风险。 为何重要 为 SLA 合规性提供简单的“是/否”指标,便于过滤、汇总和分析 SLA 违规的频率及根本原因。 获取方式 此属性不在源系统中。它是通过衡量“Underwriting Commenced”和“Underwriting Completed”活动之间的持续时间,并将其与“UnderwritingSlaTarget”属性进行比较计算得出的。 示例 truefalse | |||
| 核保 SLA 目标 UnderwritingSlaTarget | 贷款核保流程应完成的目标时长。 | ||
| 描述 Underwriting SLA Target 定义了核保阶段预期的服务水平协议,通常以营业小时或天数衡量。此目标可能根据贷款产品类型或金额等因素而有所不同。 此属性作为衡量实际绩效的基准。它直接用于“Underwriting SLA & Compliance Status”仪表板,并用于计算“SLA Breach Rate” KPI。分析违约情况有助于识别延迟原因,并管理运营与合规风险。 为何重要 提供清晰的绩效基准,支持衡量 SLA 遵守情况并识别有违规风险的申请。 获取方式 这可能根据业务规则存储为静态值,或者可能是贷款申请上的一个字段,可能源自 Temenos 中的产品主数据。 示例 48 小时72 小时24 小时 | |||
| 申请人类型 ApplicantType | 对申请人进行分类,例如新客户或老客户。 | ||
| 描述 此属性将申请人划分为有意义的群体,如“新客户”、“老客户”或“企业”。流程可能会因申请人类型而异;例如,由于已有数据,老客户的处理速度可能更快。 按申请人类型分析流程有助于了解不同客户群体的流程体验。它可以发现简化老客户办理旅程的机会,或为新客户提供更多支持。这种细分是“Loan Decision Outcome Consistency”分析的关键。 为何重要 支持细分分析,以查看流程在针对新老客户时是否存在差异,从而帮助定制和改进客户旅程。 获取方式 此信息通常通过在申请时检查申请人在 Temenos 中是否已有现成的客户概况或 ID 来获取。 示例 新客户老客户企业客户 | |||
| 部门 Department | 负责该活动的组织部门。 | ||
| 描述 此属性指示了执行给定活动的业务单元或部门,如“Origination”(发起)、“Underwriting”(核保)或“Closing”(结案)。它有助于了解组织不同部分之间的交接情况。 按部门分析流程对于识别交接期间的跨职能低效和延迟至关重要。它可以突出显示特定部门内的沟通鸿沟或资源限制,从而清晰地展示组织瓶颈。 为何重要 有助于可视化不同团队之间的工作流,从而能够分析交接时间并识别组织瓶颈。 获取方式 这通常不是事件日志中的直接字段,但可以通过使用 HR 主数据源将用户('AssignedLoanOfficer' 属性)映射到其各自部门来推导。 示例 发放核保信用风险结案 | |||
贷款发放活动
| 活动 | 描述 | ||
|---|---|---|---|
| 已完成信用审核 | 当从征信机构收到征信报告或评分并在申请记录中更新时发生。这是从信用相关字段的更新以及随后的状态更改中推断出来的。 | ||
| 为何重要 此活动标志着信用检查子流程的结束。从启动到完成的时长是衡量流程效率的关键绩效指标。 获取方式 从申请记录中填充信用评分字段的时间戳,或申请状态更改为“信用检查完成”时推断得出。 捕获 源自信用评分字段更新的时间戳或相关的状态更改。 事件类型 inferred | |||
| 已提交申请 | 标志着在 Temenos 系统中创建了新的贷款申请。这是贷款发放流程的正式开始,通常在用户首次保存新申请记录时捕获。 | ||
| 为何重要 此活动是整个流程的主要启动事件。分析从此时点到完成的时间可得出总周期时间(cycle time),这是衡量效率的关键 KPI。 获取方式 记录在申请创建日志中,或源自相关 Temenos 模块(如 AA.ARRANGEMENT)中主贷款申请记录的创建时间戳。 捕获 通过“贷款申请 ID”的创建事件或初始时间戳来识别。 事件类型 explicit | |||
| 核保完成 | 标志着核保员审核流程的结束,处于最终贷款决策之前。此事件由申请的状态更改(如“核保完成”或“待决策”)推断得出。 | ||
| 为何重要 此里程碑结束了核保 SLA 的衡量。分析从“Underwriting Commenced”到此时点的时间是评估核保人员绩效的关键。 获取方式 从申请状态历史日志中状态更改为“核保完成”或“准备最终决策”的时间戳推断得出。 捕获 通过标志核保审核结束的状态更改的时间戳来识别。 事件类型 inferred | |||
| 核保开始 | 表示已分配贷款核保人员并已开始审查申请。这通常在申请状态更新为“核保中”或类似状态时推断得出。 | ||
| 为何重要 这是关键核保阶段的开始。从此时点开始衡量有助于追踪核保人员的工作负载以及对服务水平协议 (SLA) 的遵守情况。 获取方式 从申请历史日志中状态更改为“核保中”的时间戳推断得出。它也可能与核保员的分配有关。 捕获 通过申请状态更改为“核保中”状态来识别。 事件类型 inferred | |||
| 贷款决策已下达 | 代表贷款申请的最终决定,例如“已批准”或“已拒绝”。这是一个关键事件,通过申请决策状态字段的最终确定来捕捉。 | ||
| 为何重要 这是一个主要的业务结果。它对于计算审批率、分析拒绝原因以及衡量整体决策时间至关重要。 获取方式 从主申请记录中对“决策结果”或等效状态字段进行的最终、不可更改的更新中推断得出。使用此更新的时间戳。 捕获 源自记录最终决策状态(如“已批准”或“已拒绝”)的时间戳。 事件类型 inferred | |||
| 贷款协议已签署 | 标志着已收到已签署的贷款协议并在系统中注册。用户更新申请状态以反映此情况,将流程移至最后的放款阶段。 | ||
| 为何重要 这是资金发放前的最后法律先决条件。追踪此项有助于衡量最终行政程序所需的时间。 获取方式 从申请审计日志中申请状态更改为“协议已签署”或“准备放款”推断得出。 捕获 通过指示已收到并验证已签署合同的状态更改来识别。 事件类型 inferred | |||
| 资金已拨付 | 成功的贷款发放中的最后一项活动,代表向申请人转账。这是一项核心金融交易,在 Temenos T24 核心银行引擎中会有明确记录。 | ||
| 为何重要 此活动标志着流程的成功完成。放款时间(time to disbursement)是关键的客户体验指标,也是衡量流程吞吐量的最终标准。 获取方式 从核心银行模块捕获为明确的财务交易日志条目。放款的交易记录将具有特定的交易代码和时间戳。 捕获 通过执行资金发放的财务交易来识别。 事件类型 explicit | |||
| 信用检查已启动 | 代表向外部征信机构或内部信用系统发送请求以评估申请人信用状况的时刻。这是一个明确的系统操作,通常记录为发出的 API 调用。 | ||
| 为何重要 这是衡量信用检查处理时间的起点,信用检查是一个可能成为重大瓶颈的关键子流程。它有助于隔离征信机构导致的延迟。 获取方式 从记录信贷机构 API 调用的系统日志中捕获,或从特定 Temenos 子模块内创建的信用检查请求记录中捕获。 捕获 记录启动信用检查交易或 API 调用的事件。 事件类型 explicit | |||
| 初始验证已完成 | 代表自动或人工检查的完成,以确保申请表完整并符合基本准入标准。此事件通常以申请记录上的状态变更形式进行捕捉。 | ||
| 为何重要 追踪此里程碑有助于识别流程最开始阶段的数据质量问题和延迟。它将数据录入阶段与实质性审查阶段区分开来。 获取方式 从申请状态历史日志中申请状态字段的更改推断得出,例如从“新建”更改为“待审核”或“已验证”。 捕获 源自申请状态字段更改为“已验证”或等效状态。 事件类型 inferred | |||
| 已执行风险评估 | 代表正式风险评估的完成,这可能是主核保(underwriting)审查过程中或之后的一个独立步骤。当风险评估环节或任务标记为完成时,即会记录此事件。 | ||
| 为何重要 此活动对于合规追踪必不可少。它确保为所有相关申请一致地执行强制性风险评估步骤。 获取方式 从与风险相关的状态更改(如“已评估风险”)或工作流中特定风险评估任务的完成时间戳推断得出。 捕获 源自风险评估任务的完成时间戳或特定的状态更改。 事件类型 inferred | |||
| 已请求补充材料 | 指示信贷员已要求申请人提供补充材料。这通常是记录在与申请相关的系统通信或备注模块中的明确操作。 | ||
| 为何重要 此活动对于识别返工环路至关重要。单笔申请中出现多次此类活动标志着效率低下、沟通脱节或初始需求不明确。 获取方式 通常在执行“Request Documents”交易时作为记录事件捕捉,或者源自与申请 ID 关联的案例备注或沟通日志中的特定条目。 捕获 当用户触发文档请求操作或通信模板时记录。 事件类型 explicit | |||
| 所有文档已收齐 | 此事件标志着已收到并上传申请人提供的所有必需补充材料。这通常根据申请状态的变更推断得出,表明其已准备好进入下一阶段。 | ||
| 为何重要 此里程碑是核保和信用评估的关键前提。此时点之前的延迟通常取决于申请人,而此时点之后的延迟则是内部原因。 获取方式 从申请审计追踪中记录的状态更改推断得出,例如状态变为“文档已齐全”或“准备核保”。 捕获 通过申请状态更改为指示所有文档已收到的时间戳来识别。 事件类型 inferred | |||
| 申请已撤回 | 一个可选的结束事件,即申请人在最终决策做出前撤回申请。这通过用户将申请状态更新为“已撤回”来捕获。 | ||
| 为何重要 追踪撤回申请有助于识别客户流失率高的流程阶段。这可能预示着处理时间过长或沟通不畅等问题。 获取方式 从申请历史日志中申请状态更改为“客户已撤回”或“已取消”推断得出。 捕获 通过状态更改为最终的“已撤回”状态来识别。 事件类型 inferred | |||
| 贷款已拒绝 | 一个可选的结束活动,即贷款申请在审核后被正式拒绝。当申请的最终决策状态设为“已拒绝”时,将捕获此活动。 | ||
| 为何重要 此活动标志着不成功的结果。分析在此结束的案例以及拒绝原因,对于提高申请质量和优化决策政策至关重要。 获取方式 从最终申请状态设置为“已拒绝”或类似的终结状态推断得出。这与“贷款决策已下达”的来源相同,但针对特定结果进行了过滤。 捕获 源自最终决策状态设置为“已拒绝”的时间戳。 事件类型 inferred | |||
| 贷款报价已接受 | 指示申请人已正式接受贷款报价。这通常由信贷员在收到申请人确认后更新申请状态来记录。 | ||
| 为何重要 这是一个关键的客户驱动里程碑。它确认申请人希望继续办理,并触发合同生成和资金发放的最后步骤。 获取方式 从申请历史日志中状态更改为“已接受报价”或类似状态推断得出。使用此状态更新的时间戳。 捕获 源自状态更改为“已接受报价”的时间戳。 事件类型 inferred | |||
| 贷款报价已生成 | 对于已批准的贷款,这是生成发送给申请人的正式贷款报价文档的明确操作。当触发文档生成服务时,通常会记录此事件。 | ||
| 为何重要 此活动标志着从内部处理转向客户操作。此步骤与客户接受之间的延迟可能预示着报价或沟通存在问题。 获取方式 当用户执行“生成报价”功能时从应用程序事件日志中捕获,或从文档管理系统中报价文档的创建时间戳捕获。 捕获 在执行文档生成交易时记录。 事件类型 explicit | |||
提取指南
该流程的提取方法正在验证中。请稍后回来查看或 联系我们 寻求帮助。