Call center intelligent telephone traffic distribution scheduling method, device, equipment and medium

Abstract

The invention relates to a call center intelligent telephone traffic distribution scheduling method and device, equipment and a medium. The method comprises the following steps: acquiring session metadata collected by a local call center system, performing standardized desensitization processing on the session metadata, and standardizing the session metadata into an inbound event in combination with meta-information of each call center system; performing session intention extraction, service complexity scoring and customer value estimation on the inbound event to obtain an enhanced interaction file; generating a candidate micro-queue list according to the enhanced interaction file and each system state snapshot, and performing expected cost estimation on each candidate micro-queue in the candidate micro-queue list to obtain an expected cost score corresponding to each candidate micro-queue; and based on the service constraint, solving according to the candidate microqueue list and the expected cost score thereof to obtain a scheduling decision, and initiating a resource reservation request to a target call center system pointed by the scheduling decision to obtain a resource reservation token and a transfer token. By adopting the method, the scheduling waiting time and the switching failure rate can be reduced.

Description

Technical Field

[0001] This invention belongs to the field of call dispatching technology, and in particular relates to a method, device, equipment and medium for intelligent call dispatching in call centers. Background Technology

[0002] With the development of call center technology, call center system scheduling technology has emerged, which improves call response efficiency and service quality to a certain extent by evaluating and allocating the session load within a single system.

[0003] In traditional technologies, call centers typically employ a single-system internal scheduling strategy based on queue length, business matching, or rule-driven approaches to manage queuing and assign customer service representatives to incoming calls or sessions. When an enterprise has multiple heterogeneous call center systems serving different business lines and channels, each system often operates independently, building its own business queues, customer service resource pools, and scheduling strategies. Even when some enterprises connect multiple systems to a unified communications platform, scheduling between these systems usually still relies on static routing, fixed priorities, or manually set conditional transfer rules to achieve call flow between systems.

[0004] However, the aforementioned methods fail to uniformly model the real-time status, load levels, business context, session behavior, and customer service capabilities of different systems. This results in cross-system scheduling relying solely on fixed rules, hindering dynamic and intelligent session allocation. Traditional cross-system scheduling transfers are based solely on business type or simple latency thresholds, lacking comprehensive consideration of multi-dimensional data such as interaction context, user behavior characteristics, session complexity, and system resource constraints. Consequently, scheduling results are unstable and resource utilization is low. Summary of the Invention

[0005] Based on this, it is necessary to provide a method, device, equipment, and medium for intelligent call distribution and scheduling in call centers that can fully utilize the overall optimization space brought about by cross-system resource collaboration to address the aforementioned technical problems.

[0006] Firstly, this application provides a method for intelligent call distribution and scheduling in a call center, including:

[0007] Acquire session metadata collected by the local call center system, and perform standardized and anonymized processing on the session metadata. Combine it with the metadata of each call center system to standardize it into inbound events. Inbound events include session identifier, interactive language response text, and customer identifier. Call center system metadata includes system identifier, transfer mode, and system status snapshot. System status snapshot includes transfer delay estimate, cost, queue length, and customer pool summary.

[0008] The process of extracting session intent, scoring business complexity, and estimating customer value from inbound events yields an enhanced interaction profile. This enhanced interaction profile includes an intent vector, a complexity score, and a customer value vector.

[0009] A candidate microqueue list is generated based on the enhanced interactive archive and snapshots of each system state. The expected cost of each candidate microqueue in the candidate microqueue list is estimated to obtain the expected cost score corresponding to each candidate microqueue.

[0010] Based on business constraints, a scheduling decision is obtained by solving the candidate micro-queue list and its expected cost score, and a resource reservation request is initiated to the target call center system indicated by the scheduling decision to obtain a resource reservation token and a transfer token. The scheduling decision includes a session identifier, a local call center system identifier, and a target call center system identifier. The transfer token is used to transfer the session to the target call center system according to the transfer protocol of the corresponding target call center system's transfer mode.

[0011] In one embodiment, the inbound event is subjected to session intent extraction, business complexity scoring, and customer value estimation to obtain an enhanced interaction profile, including:

[0012] Semantic recognition and intent extraction are performed on interactive language response text to obtain intent vectors and their corresponding confidence scores;

[0013] The complexity score is obtained by scoring the business complexity based on the number of intents corresponding to the intent vector.

[0014] The customer value vector is obtained by calculating the customer value score and the customer's historical customer service hash value based on the historical customer data corresponding to the customer identifier.

[0015] An enhanced interaction profile is generated based on the intent vector and its corresponding confidence and complexity scores, along with the customer value vector.

[0016] In one embodiment, a candidate microqueue list is generated based on the enhanced interaction archive and snapshots of each system state, and the expected cost is estimated for each candidate microqueue in the candidate microqueue list to obtain the expected cost score corresponding to each candidate microqueue, including:

[0017] Based on the enhanced interaction profile, the request business tags, preferred language, and priority tags are determined. Combined with the customer's historical customer service hash value, the corresponding call center system is filtered in each system status snapshot according to the preset matching rules to obtain a candidate micro-queue list. The candidate micro-queue includes system identifier, queue identifier, business tag set, and transfer mode.

[0018] Feature extraction is performed on each candidate micro-queue to obtain the feature vector of each candidate micro-queue; the feature vector includes, but is not limited to, business matching score, queue load, transfer delay estimation, historical transfer success rate, complexity score, and customer value score.

[0019] The expected cost score is obtained by scoring the feature vector using a pre-trained transmission cost predictor; the transmission cost predictor is obtained through federated training.

[0020] In one embodiment, based on business constraints, a scheduling decision is obtained by solving the candidate micro-queue list and its expected cost score, and a resource reservation request is initiated to the target call center system indicated by the scheduling decision, obtaining a resource reservation token and a transfer token, including:

[0021] Based on business constraints, a preset sorting strategy is used to select the call center system with the lowest expected cost score as the primary scheduling target for each candidate micro-queue according to the expected cost score, thus obtaining a real-time scheduling decision; business constraints include the service level agreement expiration time.

[0022] After the real-time scheduling decision determines the target call center system, a soft reservation request is initiated to the target call center system and a resource reservation token is received; the resource reservation token is used to reserve resources for a set time period for the session;

[0023] After obtaining the resource reservation token, a transfer token is generated based on the enhanced interaction profile; the transfer token contains an encrypted session context digest.

[0024] In one embodiment, the method further includes:

[0025] When the target call center system's transfer mode supports session initiation protocol transfer or computer telephony integration bridging, the corresponding transfer is executed to establish a session connection;

[0026] When the target call center system does not support Session Initiation Protocol (SIP) transfer or Computer Telephony Integration (CTI) bridging, initiate proxy bridging or API proxy to inject a transfer token and establish a session connection.

[0027] In one embodiment, the method further includes:

[0028] The transmission latency, media interruption time, and number of transfers during the switching process are obtained to generate real-time monitoring metrics.

[0029] If a real-time monitoring indicator is abnormal, a correction mechanism is triggered to select the next candidate micro-queue from the candidate micro-queue list as the alternative resource reservation token.

[0030] In one embodiment, the method further includes:

[0031] Standardized results are collected from the end of each call center system to obtain a standardized result set; the standardized result set includes processing time, resolution status, number of transfers, customer satisfaction score, and cost.

[0032] After performing local aggregation and de-identification on each standardized result, the local gradient corresponding to each standardized result is obtained;

[0033] The local gradients are merged using a federated aggregator to obtain global model parameters; these global model parameters are used to update the transport cost predictor.

[0034] Secondly, this application also provides a call center intelligent call distribution and scheduling device, comprising:

[0035] The session connection module is used to acquire session metadata collected by the local call center system, and to perform normalized and de-identified processing on the session metadata. It is then combined with the metadata of each call center system and standardized into inbound events. Inbound events include session identifier, interactive language response text, and customer identifier. Call center system metadata includes system identifier, transfer mode, and system status snapshot. The system status snapshot includes transfer delay estimate, cost, queue length, and customer pool summary.

[0036] The conversation evaluation module is used to extract conversation intent, score business complexity, and estimate customer value from inbound events, resulting in an enhanced interaction profile. The enhanced interaction profile includes an intent vector, a complexity score, and a customer value vector.

[0037] The business matching module is used to generate a candidate micro-queue list based on the enhanced interaction profile and snapshots of each system status, and to estimate the expected cost of each candidate micro-queue in the candidate micro-queue list to obtain the expected cost score corresponding to each candidate micro-queue.

[0038] The scheduling decision module is used to obtain a scheduling decision based on business constraints, the candidate micro-queue list and its expected cost score, and to initiate a resource reservation request to the target call center system indicated by the scheduling decision, and obtain a resource reservation token and a transfer token. The scheduling decision includes a session identifier, a local call center system identifier and a target call center system identifier. The transfer token is used to transfer the session to the target call center system according to the transfer protocol of the corresponding target call center system's transfer mode.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above-described intelligent call center dispatching methods.

[0040] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the above-described intelligent call center dispatching methods.

[0041] The aforementioned intelligent call distribution and scheduling method, device, equipment, and media for call centers reduce data parsing and interface adaptation overhead caused by inconsistent fields through a unified inbound event format. This facilitates the scheduling engine to process sessions from different systems in the same way. Anonymization protects customer privacy and reduces compliance risks when sharing data across systems, making centralized or collaborative scheduling feasible and compliant in multi-system environments. By extracting session intent, scoring business complexity, and estimating customer value from inbound events, an enhanced interaction profile is created. This incorporates the semantics of customer needs, expected processing difficulty, and customer business value into scheduling considerations, achieving more accurate business matching, differentiated priority allocation, and more reasonable resource allocation. By subdividing scheduling objects into candidate micro-queues and estimating the expected cost for each candidate, the comparability of different systems and queues shifts from fuzzy rule-based judgments to quantitative score comparisons. This allows for comparison of the allocation effects of multiple call center systems on the same metric, supporting optimal selection based on the goal of minimizing numerical values. Under business constraints, scheduling decisions are obtained by quantifying candidate solutions. Resource reservation tokens and transfer tokens are used as execution credentials. Resource reservation reduces the risk of the selected target being concurrently occupied, improves the transfer success rate and system robustness. Transfer tokens are used to minimize the encapsulation, encryption and signature of the session context, ensuring the integrity and privacy of cross-system context transmission, thereby achieving secure and controllable cross-system session migration. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a flowchart illustrating the intelligent call distribution and scheduling method for call centers according to the present invention.

[0044] Figure 2 This is a flowchart illustrating the steps of step S103.

[0045] Figure 3 This is a flowchart illustrating the steps of step S104.

[0046] Figure 4 This is a structural diagram of the intelligent call distribution and scheduling device for call centers according to the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0048] In one embodiment, such as Figure 1 As shown, a method for intelligent call distribution and scheduling in a call center is provided. This embodiment illustrates the method by applying it to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0049] S101. Obtain the session metadata collected by the local call center system, and perform standardized and desensitized processing on the session metadata. Combine it with the metadata of each call center system to standardize it into inbound events. Inbound events include session identifier, interactive language response text and customer identifier. Call center system metadata includes system identifier, transfer mode and system status snapshot. System status snapshot includes transfer delay estimate, cost, queue length and customer pool summary.

[0050] A call center system (Automatic Call Distribution, ACD) refers to a hardware and software platform deployed internally or by an outsourcing party for receiving, initiating, and managing customer interactions. Examples include voice platforms based on CTI (Computer Telephony Integration) / SIP (Session Initiation Protocol), online chat platforms, IVR (Interactive Voice Response) / ASR (Automatic Speech Recognition) nodes, and CRM (Customer Relationship Management) systems. During operation, the ACD continuously generates session metadata, such as session identifiers, interactive voice response text, customer identifiers, arrival timestamps, and initial IVR paths. The call center system that a user first enters after initiating a call or inquiry is defined as the nearest or corresponding entry point. Each call center system should report its metadata, including system identifier, supported transfer modes, and a system status snapshot. The system status snapshot reflects the estimated transfer latency, unit time cost, current queue length, and customer service pool summary. The customer service pool summary includes the number of available customer service representatives, average occupancy rate, and estimated idle capacity, categorized by business capacity. Optionally, standardization maps fields from different systems to a unified inbound event schema. Anonymization is achieved by hashing or partially masking customer-identified information, such as contact numbers, to avoid transmitting or centrally storing original identifiable information, thus meeting compliance requirements. As an example, metadata is extracted using lightweight DoH (JSON over HTTPS) / WebSocket (full-duplex communication network protocol) and pushed into the event-driven intelligent call allocation and scheduling of the call center as inbound events.

[0051] S102. Extract session intent, score business complexity, and estimate customer value from inbound events to obtain an enhanced interaction profile. The enhanced interaction profile includes an intent vector, a complexity score, and a customer value vector.

[0052] Specifically, the interactive language response text obtained from inbound events is analyzed through semantic recognition and intent extraction modules to identify the customer's current need type and possible processing path, providing an intent vector that reflects single or multiple intents and their confidence distribution. Business complexity scoring quantifies the expected processing difficulty based on signals such as the number and type of intents, processing time and failure rate of similar historical sessions, generating a complexity score. Customer value estimation calculates the customer's value or priority over their lifecycle by associating the customer identifier with local or authorized CRM historical data, such as based on historical transaction volume, retention importance, or contract level, outputting a customer value vector. Optionally, to balance privacy and real-time performance, intent extraction or value estimation can be performed on local edge nodes, reporting only necessary abstract features, thus providing a basis for global scheduling decisions without revealing the original text.

[0053] S103. Generate a candidate micro-queue list based on the enhanced interactive archive and snapshots of each system state, and estimate the expected cost of each candidate micro-queue in the candidate micro-queue list to obtain the expected cost score corresponding to each candidate micro-queue.

[0054] Candidate micro-queues are collections of queues or customer service representatives with specific service capabilities and transfer modes within the target system. They include information such as target system identifier, queue identifier, supported service tags, and transfer methods. Specifically, the process of generating a candidate micro-queue list is based on the intent, complexity, and value in the enhanced interaction profile, while also referencing system status snapshots reported by various call center systems, such as queue congestion levels, expected transfer latency, and costs. Several candidates meeting business, language, and policy requirements are selected according to preset matching and priority rules, limited to a certain top-K number to control the scale of real-time computation. Further, an expected cost estimate is performed for each candidate micro-queue. The expected cost quantifies the overall cost of allocating a session to that candidate and can be generated by weighting factors such as waiting time, transmission latency, expected processing time, monetary cost, and potential penalties for SLA violations. For example, the expected cost can be estimated using a scoring function or a prediction model based on historical data. Input features include the candidate's service matching degree, current or predicted queue load, inter-system round-trip latency and historical transfer success rate, as well as the complexity and customer value reflected in the enhanced interaction profile.

[0055] S104. Based on business constraints, a scheduling decision is obtained by solving the candidate micro-queue list and its expected cost score, and a resource reservation request is initiated to the target call center system pointed to by the scheduling decision to obtain a resource reservation token and a transfer token. The scheduling decision includes a session identifier, a local call center system identifier, and a target call center system identifier. The transfer token is used to transfer the session to the target call center system according to the transfer protocol of the corresponding target call center system's transfer mode.

[0056] As an illustration, business constraints include, but are not limited to, Service Level Agreement (SLA) deadlines, necessary business or language requirements, cost or priority strategies, etc., which together constitute the hard or soft constraints when selecting candidates. Optionally, to balance real-time performance and overall optimization, a two-layer scheduling architecture can be adopted. The real-time layer uses low-latency heuristics or approximate algorithms, such as a greedy sorting based on expected cost scores, selecting the candidate micro-queue with the smallest score, while simultaneously performing soft resource reservation to prevent concurrent occupation of selected items. The periodic layer performs a higher-dimensional global rebalancing to correct long-term decision biases and capacity allocation. The result of the scheduling solution is a decision record for each arriving session, which includes at least the session identifier, the identifier of the local call center system initiating the scheduling, and the identifier of the selected target call center system.

[0057] Furthermore, after making the decision, a resource reservation request needs to be sent to the target system to ensure that the selected target allocates the necessary processing resources for the session within a short period. Upon successful response from the target system, a resource reservation token is returned. This token indicates that the target has reserved the corresponding resources for the session within a predetermined timeframe, thereby reducing the failure rate and contention risk of the transfer. Simultaneously, to achieve seamless or controlled context migration, the system needs to construct a transfer token. This token encapsulates the necessary context summary of the session, such as the interaction intent vector, complexity hints, allowed transfer operations, and validity period, and protects data integrity and privacy through encryption and signature. The existence of the transfer token allows for the secure transmission of a minimized and verifiable context to the target system during specific transfers, supporting access processes under different transfer modes.

[0058] The aforementioned intelligent call center dispatching method transforms natural language interactions into intent vectors and calculates complexity scores and value vectors. During dispatching, semantic-level features and value trade-offs can replace simple business label matching, reducing incorrect allocation, decreasing the possibility of irrelevant customer service calls, and increasing the probability of first-contact resolution. The expected cost score incorporates waiting time and SLA risk into a unified score, and prioritizes candidates with the lowest expected cost that meet the SLA based on business constraints. It tends to allocate sessions to targets that can meet the SLA the fastest, or select targets with higher costs but better quality in high-value customer scenarios, thereby reducing average queuing time and the probability of SLA violation. This results in lower call processing costs, more balanced resource utilization, and more efficient resource dispatching during peak periods. The resource reservation token mechanism reserves resources before transfer and obtains confirmation from the target end. The transfer token carries compressed context for verification by the target system, reducing failures caused by resource contention or context mismatch during the transfer process.

[0059] In one embodiment, the inbound event is subjected to session intent extraction, business complexity scoring, and customer value estimation to obtain an enhanced interaction profile, including:

[0060] S11. Perform semantic recognition and intent extraction on the interactive language response text to obtain the intent vector and its corresponding confidence level.

[0061] Indicatively, the interactive language response text can originate from the recognition results of IVR / ASR or the text message of the first round of the conversation. Specifically, the interactive language response text is preprocessed, including text normalization, noise filtering, and segmentation, to remove filler words or meaningless fragments in the recognition and improve the robustness of subsequent semantic analysis. Furthermore, the preprocessed interactive language response text is input into the semantic recognition and intent extraction module for processing. This module can identify one or more intent categories based on a trained semantic model or classifier and give a confidence value for each intent, thereby generating an intent vector and its confidence distribution.

[0062] S12. Based on the number of intents corresponding to the intent vector, score the business complexity to obtain a complexity score.

[0063] After obtaining the intent vector and its confidence level, the business complexity is assessed based on statistical signals including the number of intents, intent type, intent confidence level, and processing time and transfer rate of similar historical sessions. For example, a single intent typically has lower complexity, while multiple or concurrent intents indicate higher complexity. Intents related to complaints, compensation, or technical malfunctions are expected to have higher processing complexity, and low confidence levels may require longer clarification processes. Optionally, a rule-based weighted or learned regression model can be used to aggregate the statistical signal features and output a numerical complexity score. This score is used to reflect the expected workload and uncertainty during candidate evaluation and resource scheduling.

[0064] S13. Calculate the customer value score and the customer's historical customer service hash value based on the historical customer data corresponding to the customer identifier to obtain the customer value vector.

[0065] This example illustrates how, using customer identifiers as indexes, a customer value score reflecting business priority or customer importance is calculated by combining local / authorized access to historical customer data. A related historical customer service hash value is then generated to maintain traceability of customer contact history without revealing the identity of specific individuals. Specifically, customer transaction history, contract level, historical satisfaction, or churn risk indicators are retrieved from local CRM or authorized data storage using customer identifiers. These indicators are then synthesized into a single or vectorized customer value score or customer value vector according to preset weighting rules or a trained scoring model. This is used to achieve business objectives during scheduling, such as prioritizing high-value customers or providing differentiated services. Simultaneously, customer service identifiers or conversation records from the customer's history are anonymized to generate a historical customer service hash value. This involves irreversibly transforming the customer service identifier or conversation identifier using a hash function. This hash value is used to maintain the affinity or priority for follow-up visits between the customer and previous customer service representatives, while preventing the direct exposure of the customer service representative's true identity to meet compliance requirements. By calculating customer value and generating historical customer service hashes, business-level trade-offs are introduced into candidate selection and cost estimation, so that scheduling is not only based on time or cost, but also takes into account customer business value and continuous service experience.

[0066] S14. Generate an enhanced interaction profile based on the intent vector and its corresponding confidence, complexity score, and customer value vector.

[0067] The intent vector and its corresponding confidence score, complexity score, and customer value vector, among other features, are fused into an enhanced interaction profile that can be directly used for subsequent candidate generation and cost estimation. Optionally, the features are standardized and validated during the fusion process to ensure that the dimensions of the intent vector, the confidence score, the complexity score, and the customer value vector can be compared or combined within the same processing framework. Further, according to a predetermined fusion strategy, the intent vector, complexity score, customer value vector, and other necessary metadata, such as inbound timestamp, channel type, and IVR path summary, are aggregated into a structured record, which constitutes the enhanced interaction profile.

[0068] In one embodiment, such as Figure 2 As shown, a candidate micro-queue list is generated based on the enhanced interaction archive and snapshots of each system state. The expected cost of each candidate micro-queue in the list is estimated to obtain the expected cost score for each candidate micro-queue, including:

[0069] S201. Based on the enhanced interaction profile, determine the request business tag, preferred language, and priority tag, and combine the customer's historical customer service hash value to filter the corresponding call center system in each system status snapshot according to the preset matching rules to obtain a candidate micro-queue list; the candidate micro-queue includes system identifier, queue identifier, business tag set, and transfer mode.

[0070] The business tags, preferred languages, priority identifiers, and customer historical customer service hashes for enhanced interactive profile read requests constitute the initial constraints for matching. Further, real-time capability signals are extracted from system status snapshots submitted by each local call center system, such as queue length for each system and queue, the number and utilization of customer service representatives by business (i.e., customer service pool summary), inter-system transfer latency estimates (interconnect_latency_estimate_ms), and unit time cost (cost_per_minute). For example, based on the above constraints and capability signals, according to a preset matching rule chain, such as requiring language and necessary business compliance, prioritizing historical customer service affinity, and prioritizing low-cost or low-latency items within cost or latency thresholds, all system snapshots are screened, and candidates that meet stability and policy constraints are selected and represented as candidate micro-queue records. Each candidate micro-queue record contains at least the target system identifier, target queue identifier, a set of compatible business tags, and the transfer mode supported by the candidate, so that it can point to specific resources during subsequent transfer implementation.

[0071] S202. Extract features from each candidate micro-queue to obtain the feature vector of each candidate micro-queue; the feature vector includes, but is not limited to, business matching score, queue load, transfer delay estimation, historical transfer success rate, complexity score, and customer value score.

[0072] Schematic, the business matching score can be calculated by the intersection of the request business tags in the enhanced interaction profile and the set of business tags in the candidate micro-queues, along with weighted matching rules, reflecting the degree of matching between business / language / priority; queue load is synthesized from on-site indicators such as the current queue length, average waiting time, and customer service occupancy rate of the target queue; transfer latency estimation is directly taken from the interconnection latency in the system state snapshot, i.e., transfer latency estimation, or the historically measured transfer time distribution; historical transfer success rate is calculated by statistically analyzing the ratio of transfer attempts and successful access between the same or similar systems in the past, characterizing the reliability of cross-system transfers; furthermore, the interaction complexity score and customer value score are also included in the vector so that the final score can reflect the balance between service costs and business value. Optionally, the above indicators are normalized and missing value handled during construction, such as using default estimates or substitute values ​​based on similar systems for unavailable indicators, thereby ensuring the integrity and consistency of the feature vector in the model input.

[0073] S203. Use a pre-trained transmission cost predictor to score the feature vectors and obtain the expected cost score; the transmission cost predictor is obtained through federated training.

[0074] The transmission cost predictor is constructed using federated training or de-identified statistical aggregation methods based on LightGBM (Light Gradient Boosting Machine) or small neural ranking networks. The predictor takes candidate feature vectors as input and outputs an expected cost score (expected_cost_score). This score is obtained by weighting several sub-items, such as waiting time, transfer delay, expected processing time, monetary cost, and potential SLA penalties, or by direct regression from the model. It also returns a confidence score or interval estimate calculated based on model uncertainty or historical error distribution. This expected cost score is used for candidate comparison and ranking in the higher-level global optimization, while the confidence interval information assists the real-time layer in robust selection, such as favoring candidates with narrower confidence intervals to reduce risk.

[0075] In one embodiment, such as Figure 3 As shown, based on business constraints, a scheduling decision is obtained by solving the candidate micro-queue list and its expected cost score. A resource reservation request is then initiated to the target call center system indicated by the scheduling decision, obtaining a resource reservation token and a transfer token, including:

[0076] S301. Based on business constraints, the call center system with the lowest expected cost score is selected as the preferred scheduling target by using a preset sorting strategy for each candidate micro-queue according to the expected cost score, thus obtaining a real-time scheduling decision; the business constraints include the expiration time of the service level agreement.

[0077] Optionally, the set of business constraints includes, but is not limited to, service level agreement (SLA) deadlines, necessary business or language requirements, priority strategies, and cost or compliance thresholds. Illustratively, a feasibility screening is performed on candidate micro-queues, eliminating those that clearly violate hard constraints, such as exceeding SLA deadlines, lacking necessary business, or exceeding preset cost limits. The remaining candidates are then sorted according to expected cost scores. A heuristic approach combining expected cost as the primary sorting criterion with priority weights can be adopted to ensure millisecond-level or low-latency decision-making capabilities. To reduce the risk of resource contention caused by concurrent competition, the real-time scheduling decision initiates a soft reservation step simultaneously when selecting the preferred candidate, ensuring that the selected target can reserve resources for the session for a short period. The final output is a real-time scheduling decision record, which includes at least the session identifier, the system identifier of the selected target, and the queue identifier.

[0078] S302. After the real-time scheduling decision determines the target call center system, a soft reservation request is initiated to the target call center system and a resource reservation token is received; the resource reservation token is used to reserve resources for a set time length for the session.

[0079] Triggered by real-time scheduling decisions, a resource reservation request is initiated to the selected target call center system to ensure that the target reserves the necessary processing capacity for the session within a short time window. The resource reservation request encapsulates the candidate context, such as session identifier, estimated arrival time, required service set, and reservation duration requirements, in a standardized API (Application Programming Interface) or CTI protocol message, and is transmitted to the target system through a secure channel. Upon receiving the request, the target system performs a partial evaluation based on its current resource snapshot and local policies. If the request can be satisfied, a resource reservation token (reservation_token) is returned. This token identifies the resources reserved by the target system for the session within the specified reservation period and contains specific metadata about the reservation, such as the reserved queue identifier, pre-assigned customer service or ticket number, and reservation validity period. If the target cannot commit, a rejection or non-commitment indication is returned. The resource reservation token supports timeout and conflict handling mechanisms; that is, the reservation is a soft reservation. When the reservation period expires or a higher-priority request conflict occurs after reservation confirmation, the target system can reclaim resources according to local priority rules and notify the scheduling system to migrate the session to alternative resources. Optionally, to improve robustness, the caller can issue parallel reservation requests to several high-priority candidates in parallel and compare the priorities of the returned reservation_token, or trigger fallback logic to select the next item in the candidate micro-queue list when resource reservation fails.

[0080] S303. After obtaining the resource reservation token, generate a transfer token based on the enhanced interaction profile; the transfer token contains an encrypted session context digest.

[0081] This example illustrates the process of extracting necessary contextual summary information for subsequent processing from the enhanced interaction profile. This includes session identifiers, intent vector summaries, complexity hints, IVR path summaries, customer history service hashes, a list of permitted transfer operations (permitted_transfer_ops), and token expiry times (expiry_ts). Furthermore, the aforementioned contextual summary is encrypted to prevent unauthorized access during transmission or in the target system. The entire token is also digitally signed to ensure immutability and traceability. The payload of the transfer token (transfer_token) should also include a mapping to a resource-reserved token, allowing the target system to verify the matching of the reserved credentials and context upon access. Optionally, to mitigate risk, the transfer token should have a limited validity period and specify permitted use cases. Expired or expired tokens should be rejected by the target system.

[0082] In one embodiment, the method further includes:

[0083] S21. When the target call center system's transfer mode supports session initiation protocol transfer or computer telephony integration bridging, the corresponding transfer is executed to establish a session connection.

[0084] When the target call center system determined by the scheduling decision supports Session Initiation Protocol Transfer (SIP_transfer) or Computer Telephony Integration (CTI_bridge) in its transfer mode declaration, the reservation_token and transfer_token are used as key inputs to achieve seamless and low-latency session switching by leveraging the target system's native transfer mechanism. Specifically, upon receiving the reservation_token returned by the target system, the scheduling system or the source local call platform verifies the validity and matching of the reservation_token. Based on the target system's publicly disclosed transfer interface specifications, it constructs the corresponding transfer command or signaling message. For example, for targets supporting SIP_transfer, a transfer request conforming to the SIP protocol can be constructed, carrying the encrypted context digest or token reference field from the transfer_token. If necessary, the transfer information can be sent to the target end using relevant SIP header fields or through a protected signaling channel. For targets supporting CTI_bridge, a bridging instruction containing a transfer_token reference and session identifier can be submitted through the CTI control channel, allowing the target system to complete session access and customer service allocation locally.

[0085] Prioritize the switching methods supported by the target system itself, which has lower media interruption time, fewer proxy paths and lower risk of context loss, thereby improving user experience and reducing middleware burden.

[0086] S22. When the target call center system does not support Session Initiation Protocol (SIP) transfer or Computer Telephony Integration (CTI) bridging, initiate proxy bridging or API proxy to inject a transfer token and establish a session connection.

[0087] When the target call center system does not support session initiation protocol transfer or CTI bridging, or when the target cannot access the system natively at the current moment, the system uses the scheduling system to initiate proxy bridging or API proxy to achieve session access and context injection, ensuring session continuity and the transmission of business context. The inputs are still reservation_token and transfer_token, but the execution path changes from direct signaling transfer to the scheduling system layer acting as an intermediate endpoint. For example, proxy bridging can adopt a media trunking or B2BUA (Back-to-Back User Agent) style connection method, that is, the scheduling system acts as an intermediate media and signaling terminal during session transfer, maintaining a media / signaling channel with the source end on one end, and initiating a new session establishment request to the target system on the other end. At the same time, the transfer_token is injected in the establishment request through a protected management channel or the API exposed by the target system. The target system verifies and extracts the session context summary and reservation information for local queuing or dispatch. The API_proxy mode is more geared towards control layer adaptation. That is, the scheduling system calls the target system's open API to create a pending session record or work order with a protected parameter with transfer_token. The target system then pulls the media under its local mechanism or the scheduling system proxies the media stream to the target's assigned customer service.

[0088] The reason for using proxy bridging or API_proxy is that direct protocol-level switching is not feasible when facing heterogeneous or restricted target systems. The proxy method provides a compatibility layer to maintain business context and customer experience.

[0089] In one embodiment, the method further includes:

[0090] S31. Obtain the transmission delay, media interruption time, and number of transfers during the switching process to obtain real-time monitoring indicators.

[0091] To illustrate, during the session transfer execution phase, the scheduling system continuously collects real-time events and metrics related to the transfer process from all participating parties and the underlying media / signaling layer. These include, but are not limited to, timestamps of transfer start and end, media stream interruption and recovery events, network quality indicators such as media packet loss or jitter, error codes and response statuses from the signaling layer, and the transfer count (transfer_count). Furthermore, the scheduling system performs real-time data processing and aggregation within its streaming module. This includes calculating the end-to-end transmission latency (transfer_latency), media interruption time (media_interruption_time), and the cumulative transfer count for the current session. Based on predefined indicator semantics, it generates real-time monitoring indicator vectors to promptly identify anomalies that may affect service continuity and quality, thereby supporting immediate correction and subsequent performance evaluation.

[0092] S32. If the real-time monitoring indicators are abnormal, the correction mechanism is triggered to select the candidate resource reservation token of the next candidate micro-queue in the candidate micro-queue list.

[0093] Based on real-time monitoring metrics, the scheduling system evaluates these metrics in the error correction judgment module according to preset rules or a lightweight anomaly detector to identify any abnormal situations requiring immediate corrective action. Optionally, the judgment logic includes hard comparison of key metrics with thresholds, such as transfer response timeouts, media interruptions exceeding preset limits, and a sharp increase in transfer failure rates, as well as behavioral deviation detection based on statistics / sliding windows, such as multiple consecutive transfer failures within a short period or latency significantly higher than the historical distribution. When any judgment condition is met, the scheduling system considers it an anomaly and triggers the error correction process. Specifically, it attempts to use the next available reservation token from the candidate micro-queue in the candidate micro-queue list (i.e., selects the next available reservation_token in the candidate list in its original order) to initiate a parallel or sequential resource reservation request. If successful, the new reservation_token / transfer_token is immediately used to execute the transfer to avoid the fault path. If the backup reservation also fails or is temporarily unavailable, predefined fallback measures are executed, such as rolling back the session to the source local queue, initiating local manual intervention, or downgrading the service level. Optionally, during the correction process, the scheduling system records the timestamps of all attempts, the reasons for failure, and the alternatives selected. At the same time, it submits the abnormal events and their context to the subsequent model training and policy calibration pipeline to update the transmission cost predictor, candidate ranking policy, and reserved duration parameters, so as to reduce the probability of similar anomalies occurring in the future.

[0094] In one embodiment, the method further includes:

[0095] S41. Collect standardized results from each call center system at the end of the session to obtain a standardized result set; the standardized result set includes processing time, resolution status, number of transfers, customer satisfaction score, and cost.

[0096] At the end of the session, each local call center system extracts key result data from the session lifecycle according to a predefined standardized format. The standardized results include, but are not limited to, handling time, resolution flag, transfer count, customer satisfaction score, and monetary cost generated in this session.

[0097] S42. After performing local aggregation and de-identification processing on each standardized result, the local gradient corresponding to each standardized result is obtained.

[0098] Specifically, the standardized results are aggregated and de-identified locally within each local call center system. Local aggregation includes summarizing and statistically analyzing the standardized results by time window or batch, such as calculating average processing time, average number of transfers, access success rate, and actual processing cost distribution by complexity. These standardized records can also be used locally to perform batch gradient calculations for model fine-tuning samples. That is, using the current transmission cost predictor model parameters as initial values, the local standardized results are used as training samples to calculate the loss function and back-calculate the gradient to obtain the local gradient.

[0099] S43. The local gradients are merged using a federated aggregator with secure aggregation to obtain the global model parameters; the global model parameters are used to update the transport cost predictor.

[0100] The federated aggregator, acting as a coordination center, collects standardized result sets (i.e., all local gradients corresponding to each system node) according to predetermined periods or trigger conditions. It then merges these local gradients securely to obtain the global update direction. Secure aggregation can employ encrypted aggregation protocols, threshold encryption, or secret-sharing-based aggregation mechanisms to ensure that data submitted by a single node is unreadable before aggregation. The aggregated global update is used to adjust global model parameters, which are then distributed to each local node for the next round of transmission cost scoring and candidate ranking. Specifically, these global model parameters are used to update the transmission cost predictor, enabling it to achieve a more accurate expected_cost_score based on more comprehensive cross-system statistical learning during the expected cost scoring phase. To ensure the auditability and stability of model iterations, the federated aggregator should maintain model version control, change logs, and aggregation timestamps, and can perform rollbacks or filter out abnormal gradients according to policies when necessary. Optionally, the aggregator also distributes the aggregated model performance metrics and training loss to the policy calibration module to trigger batch layer rebalancing, such as adjusting cross-system overflow thresholds or reservation duration parameters.

[0101] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0102] Based on the same inventive concept, this application also provides a call center intelligent call distribution and scheduling device for implementing the call center intelligent call distribution and scheduling method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations of one or more call center intelligent call distribution and scheduling device embodiments provided below can be found in the limitations of the call center intelligent call distribution and scheduling method described above, and will not be repeated here.

[0103] In one exemplary embodiment, such as Figure 4 As shown, a call center intelligent call distribution and scheduling device is provided, comprising:

[0104] The session link module 401 is used to acquire session metadata collected by the local call center system, and to perform normalized and desensitized processing on the session metadata, and to standardize it into inbound events in combination with the metadata of each call center system; the inbound events include session identifier, interactive language response text and customer identifier; the call center system metadata includes system identifier, transfer mode and system status snapshot; the system status snapshot includes transfer delay estimate, cost, queue length and customer pool summary;

[0105] The conversation evaluation module 402 is used to extract conversation intent, score business complexity, and estimate customer value from inbound events to obtain an enhanced interaction profile; the enhanced interaction profile includes an intent vector, a complexity score, and a customer value vector.

[0106] The business matching module 403 is used to generate a candidate micro-queue list based on the enhanced interaction profile and snapshots of each system status, and to estimate the expected cost of each candidate micro-queue in the candidate micro-queue list to obtain the expected cost score corresponding to each candidate micro-queue.

[0107] The scheduling decision module 404 is used to obtain a scheduling decision based on business constraints, the candidate micro-queue list and its expected cost score, and initiate a resource reservation request to the target call center system indicated by the scheduling decision, and obtain a resource reservation token and a transfer token. The scheduling decision includes a session identifier, a local call center system identifier and a target call center system identifier. The transfer token is used to transfer the session to the target call center system according to the transfer protocol of the corresponding transfer mode of the target call center system.

[0108] In one embodiment, the session evaluation module 402 is further configured to:

[0109] Semantic recognition and intent extraction are performed on interactive language response text to obtain intent vectors and their corresponding confidence scores;

[0110] The complexity score is obtained by scoring the business complexity based on the number of intents corresponding to the intent vector.

[0111] The customer value vector is obtained by calculating the customer value score and the customer's historical customer service hash value based on the historical customer data corresponding to the customer identifier.

[0112] An enhanced interaction profile is generated based on the intent vector and its corresponding confidence and complexity scores, along with the customer value vector.

[0113] In one embodiment, the service matching module 403 is further configured to:

[0114] Based on the enhanced interaction profile, the request business tags, preferred language, and priority tags are determined. Combined with the customer's historical customer service hash value, the corresponding call center system is filtered in each system status snapshot according to the preset matching rules to obtain a candidate micro-queue list. The candidate micro-queue includes system identifier, queue identifier, business tag set, and transfer mode.

[0115] Feature extraction is performed on each candidate micro-queue to obtain the feature vector of each candidate micro-queue; the feature vector includes, but is not limited to, business matching score, queue load, transfer delay estimation, historical transfer success rate, complexity score, and customer value score.

[0116] The expected cost score is obtained by scoring the feature vector using a pre-trained transmission cost predictor; the transmission cost predictor is obtained through federated training.

[0117] In one embodiment, the scheduling decision module 404 is further configured to:

[0118] Based on business constraints, a preset sorting strategy is used to select the call center system with the lowest expected cost score as the primary scheduling target for each candidate micro-queue according to the expected cost score, thus obtaining a real-time scheduling decision; business constraints include the service level agreement expiration time.

[0119] After the real-time scheduling decision determines the target call center system, a soft reservation request is initiated to the target call center system and a resource reservation token is received; the resource reservation token is used to reserve resources for a set time period for the session;

[0120] After obtaining the resource reservation token, a transfer token is generated based on the enhanced interaction profile; the transfer token contains an encrypted session context digest.

[0121] In one embodiment, an adapter module is also included for:

[0122] When the target call center system's transfer mode supports session initiation protocol transfer or computer telephony integration bridging, the corresponding transfer is executed to establish a session connection;

[0123] When the target call center system does not support Session Initiation Protocol (SIP) transfer or Computer Telephony Integration (CTI) bridging, initiate proxy bridging or API proxy to inject a transfer token and establish a session connection.

[0124] In one embodiment, a filing module is also included, for:

[0125] The transmission latency, media interruption time, and number of transfers during the switching process are obtained to generate real-time monitoring metrics.

[0126] If a real-time monitoring indicator is abnormal, a correction mechanism is triggered to select the next candidate micro-queue from the candidate micro-queue list as the alternative resource reservation token.

[0127] In one embodiment, a feedback update module is also included, for:

[0128] Standardized results are collected from the end of each call center system to obtain a standardized result set; the standardized result set includes processing time, resolution status, number of transfers, customer satisfaction score, and cost.

[0129] After performing local aggregation and de-identification on each standardized result, the local gradient corresponding to each standardized result is obtained;

[0130] The local gradients are merged using a federated aggregator to obtain global model parameters; these global model parameters are used to update the transport cost predictor.

[0131] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps in the above method embodiments.

[0132] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0133] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0134] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A method for intelligent call distribution and scheduling in a call center, characterized in that, The method includes: Acquire session metadata collected by the local call center system, and perform standardized and anonymized processing on the session metadata. Combine the metadata with the metadata of each call center system to standardize it into inbound events. The inbound events include session identifier, interactive language response text, and customer identifier. The call center system metadata includes system identifier, transfer mode, and system status snapshot. The system status snapshot includes transfer delay estimate, cost, queue length, and customer pool summary. The inbound events are subjected to session intent extraction, business complexity scoring, and customer value estimation to obtain an enhanced interaction profile; the enhanced interaction profile includes an intent vector, a complexity score, and a customer value vector. A candidate microqueue list is generated based on the enhanced interactive archive and each of the system state snapshots, and the expected cost is estimated for each candidate microqueue in the candidate microqueue list to obtain the expected cost score corresponding to each candidate microqueue. Based on business constraints, a scheduling decision is obtained by solving the candidate micro-queue list and its expected cost score, and a resource reservation request is initiated to the target call center system indicated by the scheduling decision to obtain a resource reservation token and a transfer token. The scheduling decision includes a session identifier, a local call center system identifier, and a target call center system identifier. The transfer token is used to transfer the session to the target call center system according to the transfer protocol of the transfer mode of the corresponding target call center system.

2. The method according to claim 1, characterized in that, The process of extracting session intent, scoring business complexity, and estimating customer value from the inbound events yields an enhanced interaction profile, including: Semantic recognition and intent extraction are performed on the interactive language response text to obtain the intent vector and its corresponding confidence level; The complexity score is obtained by scoring the business complexity based on the number of intents corresponding to the intent vector. Based on the historical customer data corresponding to the customer identifier, calculate the customer value score and the customer's historical customer service hash value to obtain the customer value vector; The enhanced interaction profile is generated based on the intent vector and its corresponding confidence level, the complexity score, and the customer value vector.

3. The method according to claim 2, characterized in that, The process of generating a candidate micro-queue list based on the enhanced interaction archive and each of the system state snapshots, and estimating the expected cost of each candidate micro-queue in the candidate micro-queue list to obtain the expected cost score corresponding to each candidate micro-queue, includes: Based on the enhanced interaction profile, the requested service tags, preferred language, and priority tags are determined. Combined with the customer's historical customer service hash value, the corresponding call center system is filtered in each of the system status snapshots according to a preset matching rule to obtain a candidate micro-queue list. The candidate micro-queue includes a system identifier, a queue identifier, a set of service tags, and a transfer mode. Feature extraction is performed on each of the candidate micro-queues to obtain the feature vector of each candidate micro-queue; the feature vector includes, but is not limited to, business matching score, queue load, transfer delay estimation, historical transfer success rate, complexity score, and customer value score. The feature vector is scored using a pre-trained transmission cost predictor to obtain the expected cost score; the transmission cost predictor is obtained through federated training.

4. The method according to claim 1, characterized in that, The process involves calculating a scheduling decision based on business constraints, using the candidate micro-queue list and its expected cost score, and then initiating a resource reservation request to the target call center system indicated by the scheduling decision. This process yields a resource reservation token and a transfer token, including: Based on business constraints, a preset sorting strategy is used to select the call center system with the lowest expected cost score as the preferred scheduling target for each candidate micro-queue according to the expected cost score, thereby obtaining a real-time scheduling decision; the business constraints include the service level agreement expiration time. After the real-time scheduling decision determines the target call center system, a soft reservation request is initiated to the target call center system and a resource reservation token is received; the resource reservation token is used to reserve resources for a set time length for the session; After obtaining the resource reservation token, a transfer token is generated based on the enhanced interaction profile; the transfer token contains an encrypted session context digest.

5. The method according to claim 1, characterized in that, The method further includes: When the target call center system's transfer mode supports Session Initiation Protocol transfer or Computer Telephony Integration (CTI) bridging, the corresponding transfer is executed to establish a session connection. When the target call center system does not support Session Initiation Protocol (SIP) transfer or Computer Telephony Integration (CTI) bridging, initiate proxy bridging or API proxy to inject the transfer token and establish a session connection.

6. The method according to claim 5, characterized in that, The method further includes: The transmission latency, media interruption time, and number of transfers during the switching process are obtained to generate real-time monitoring metrics. If the real-time monitoring indicators are abnormal, a correction mechanism is triggered to select the next candidate micro-queue from the candidate micro-queue list as the alternative resource reservation token.

7. The method according to claim 3, characterized in that, The method further includes: A standardized result set is obtained by collecting standardized results at the end of a session from each of the call center systems; the standardized result set includes processing time, resolution status, number of transfers, customer satisfaction score, and cost. After performing local aggregation and de-identification processing on each of the standardized results, the local gradient corresponding to each of the standardized results is obtained; The local gradients are merged using a federated aggregator with secure aggregation to obtain global model parameters; these global model parameters are used to update the transport cost predictor.

8. A call center intelligent call distribution and scheduling device, characterized in that, The device includes: The session connection module is used to acquire session metadata collected by the local call center system, and to perform standardized and anonymized processing on the session metadata, combining it with the metadata of each call center system to standardize it into inbound events; the inbound events include session identifier, interactive language response text, and customer identifier; the call center system metadata includes system identifier, transfer mode, and system status snapshot; the system status snapshot includes transfer delay estimate, cost, queue length, and customer pool summary; The conversation evaluation module is used to extract conversation intent, score business complexity, and estimate customer value from the inbound events to obtain an enhanced interaction profile; the enhanced interaction profile includes an intent vector, a complexity score, and a customer value vector. The business matching module is used to generate a candidate micro-queue list based on the enhanced interaction profile and each of the system state snapshots, and to estimate the expected cost of each candidate micro-queue in the candidate micro-queue list to obtain the expected cost score corresponding to each candidate micro-queue. The scheduling decision module is used to obtain a scheduling decision based on business constraints, according to the candidate micro-queue list and its expected cost score, and to initiate a resource reservation request to the target call center system indicated by the scheduling decision, thereby obtaining a resource reservation token and a transfer token. The scheduling decision includes a session identifier, a local call center system identifier, and a target call center system identifier. The transfer token is used to transfer the session to the target call center system according to the transfer protocol of the transfer mode of the corresponding target call center system.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images