How to handle "cross-departmental buck-passing"? — The art of "ticket routing" in banks.

In the complex ecosystem of commercial banks, cross-departmental "buck-passing" is often viewed as an intractable management issue, typically blamed on a lack of employee responsibility or inter-departmental friction. However, a deeper look at system architecture and operational processes reveals this inefficiency is a structural quagmire caused by the specific "Three Lines of Defense" risk framework and fragmented Legacy Systems. When front-office marketing, middle-office approval, and back-office operations are severed by functional silos and heterogeneous systems, "information black holes" at workflow boundaries create a perfect vacuum for evading responsibility. Therefore, breaking this deadlock requires not administrative coordination or personal favors, but a unified workflow architecture based on technical rationality. Banks must transcend traditional departmental views to establish standardized collaboration protocols featuring end-to-end visibility, mandatory SLA warnings, and data-driven closed-loop management. By technically exposing hidden process breakpoints, banks can eliminate excuses like "missed notifications" or "system incompatibility," transforming subjective collaboration into non-repudiable digital rules. This shift from "rule by man" to "rule by data" is essential for operational efficiency and crucial for reshaping agility and execution during deep digital transformation, ultimately letting data speak and forcing every business link to return to its root: serving the customer.

Why is "Passing the Buck" Prone to Occur Within Banks?

In the actual flow of banking business, "cross-departmental shirking" is often simply blamed on employees' lack of responsibility or bureaucracy. However, analyzing from the perspective of system architecture and operational processes, you will find that this is more of a structural and technical inevitability, rather than simple human negligence. The bank's unique "Three Lines of Defense" risk control system and complex Legacy Systems architecture jointly create a perfect "responsibility vacuum."

1. Structural Fragmentation: Segregation of Duties and "Zero Risk" Culture

The original intention of bank organizational design is for risk checks and balances, not flow efficiency. There is a natural physical isolation and functional opposition between the Front Office (Marketing/Acquisition), Middle Office (Risk Control/Approval), and Back Office (Operations/Lending).

• Rigid boundaries of responsibility: For compliance, the front office cannot interfere with risk control, and operations must act according to instructions. This rigidity leads to a situation where, when a work order encounters a "non-standard situation" (such as a missing non-mandatory but critical attachment), no party has the authority or incentive to "take an extra step."
• Side effects of "Zero Risk" culture: Within the banking system, ambiguous areas mean risk. If a work order is not explicitly assigned to a specific person at the system level, taking the initiative means actively assuming potential operational risks. Therefore, "passing the buck" is, to some extent, a self-protection mechanism for employees under ambiguous regulations.

2. Technical Black Box: "Information Silos" Among Legacy Systems

A more core reason lies in the fault lines of the technical architecture. As mentioned in Everbright Bank's FinTech Department's exploration of distributed core system construction, traditional banking systems often face the status quo of "system silos" and "data islands."

The vast majority of "buck-passing" occurs at the boundaries of system switching. Imagine a typical corporate credit process:

1. CRM System (Front Office): The relationship manager enters the requirements, and the process is clearly visible.
2. "Black Box" Transmission: Since the CRM and the core system are not fully connected, application materials may be transmitted via email, Excel ledgers, or even paper documents to the middle and back offices.
3. Core System (Back Office): Operations personnel perform data entry on traditional "green screens" or outdated Web terminals.

In this process, there is a huge "process black hole" between the export from CRM and the entry into the core system. Once a work order enters this black hole, the front office cannot see the progress, and the back office cannot see the full picture.

• Front Office thinks: "I have already sent the email; the process is with you."
• Back Office thinks: "The email attachment cannot be opened/the format is incorrect, I haven't accepted it yet, so the process doesn't count as mine."
• Result: The work order gets "lost" in the crack between the two systems, both sides wait for the other, eventually evolving into mutual accusations.

This state of "invisibility" is the breeding ground for shirking. When business flow lacks a full-link unique identifier (Trace ID), anyone can claim "I didn't receive it" or "It's not with me," and the other party cannot disprove it.

The Three Core Pillars to Break Buck-Passing: Visualization, SLA, and Closed Loop

To solve the persistent problem of "buck-passing" between internal bank departments (such as risk control, operations, and branches), relying solely on "strengthening communication" often yields little effect. Structural problems require mechanistic solutions. An efficient ticket workflow system should not just be a recording tool, but a mandatory collaboration contract.

This contract consists of three core pillars, aiming to eliminate areas of human ambiguity through technical means:

1. End-to-End Visualization (Visualized Process Tracking): Eliminate information asymmetry and make processes transparent.
2. Automated SLA Warnings (Automated SLA Warnings): Replace manual urging with system rules.
3. Data-Driven Closed Loop (Data-Driven Closed Loop): Ensure every matter has a response and every case has a final state.

The following is how these three pillars directly break through common excuses for shirking responsibility and management pain points:

This framework transforms cross-departmental collaboration, which originally relied on "personal relationships," into a digital process relying on "rules," enabling managers to free themselves from arguments over "who is shirking responsibility" and instead focus on the data fact of "which link has the lowest efficiency."

Pillar One: Full-link Visualization—Breaking "Information Silos"

In the complex IT architecture of banks, the phenomenon of buck-passing often stems not from the subjective slack of employees, but from objective "system fragmentation." Credit systems, core systems (Core Banking System), treasury systems, and CRM are usually built by different vendors at different times, with inconsistent data standards and frequent process breaks. To solve this problem, one cannot count on tearing everything down and starting over, but needs to build a "Unified Ticket Platform" located above all business systems.

Architecture Strategy: Building a "Non-intrusive" Process Orchestration Layer

Traditional solution approaches often attempt to modify the core system to adapt to new process requirements, but this is extremely risky and costly in a banking environment. A more pragmatic technical path is to adopt an Overlay Architecture.

In this architecture, the unified ticket platform does not replace the original specialized systems, but exists as a "connector" and "commander":

• Downward Integration: Connect with underlying legacy systems through an API Gateway or ESB (Enterprise Service Bus). As described in the Primeton System Integration Solution, utilizing custom APIs and adapter technologies allows for the seamless integration of new and old systems without requiring high-risk modifications to the core accounting system.
• Horizontal Alignment: Utilize a Process Engine to cross departmental boundaries, stringing together marketing actions scattered in CRM, approval actions in risk systems, and accounting actions in operation systems into a complete "full link."

Practical Scenario: "Express Delivery Style" Tracking of Corporate Credit Processes

Taking typical Corporate Credit business as an example, the traditional "black box" process is often a hotbed for buck-passing: after submitting an application at a branch, a relationship manager can often only inquire about the head office's approval progress via phone or email, while the risk control department often shelves processing on the grounds of "materials not received" or "system did not push."

After the implementation of full-link visualization, ticket circulation will present a clear view similar to "express logistics tracking":

1. Initiation Stage (Marketing Side): The relationship manager enters enterprise data into the CRM and initiates a credit application. The unified platform automatically generates a unique "global ticket number" and captures key metadata.
2. Approval Stage (Middle Office): The ticket flows to the risk management system. At this point, the platform not only displays "Pending Approval" but also shows the specific duration of stagnation at the node (e.g., has remained at the 'Risk Preliminary Review' node for 4 hours).
3. Disbursement Stage (Back Office): After approval, instructions are automatically sent to the core system for limit control and fund transfer.

Eliminating the "I Sent the Email" Gray Area

The core value of visualization lies in accountability. Once the process is connected, the flow of every node is accompanied by a system-level "timestamp" and "operator signature."

• Farewell to Verbal Reconciliation: There are no more arguments like "I sent you an email yesterday." System logs show that the ticket was accurately pushed to the risk control post's to-do queue at "October 24, 14:30"; if unprocessed, responsibility is immediately locked in.
• Making Breakpoints Visible: If data is lost during transmission from the credit system to the core system (technical ticket loss), the visualization dashboard will immediately show the ticket in an "abnormally suspended" state. The operations team can intervene quickly based on modern core system operations and monitoring capabilities, rather than letting business personnel blame each other during endless waiting.

Through this "God's eye view" process mapping, banks can make the "information silos" originally hidden behind departmental walls completely transparent, leaving no place for buck-passing to hide.

Process Breakpoint Identification: Where Are the Real Bottlenecks?

In the complex cross-departmental collaboration within banks, "passing the buck" often stems from the black-box state of information. When a credit approval or compliance review task remains in a "Processing" state for more than three days, the initiating department can usually only anxiously urge for progress, while the back-office processing department may be unable to proceed due to missing materials or system failures. At this point, the core value of visualization lies not in drawing pretty charts, but in precisely identifying Process Breakpoints, reducing vague "delays" to specific technical or business obstacles.

1. Deconstructing "Status" into "Breakpoint Types"

Traditional ticketing systems often only display coarse-grained statuses (such as "Pending Approval"), which masks the real bottlenecks. To eliminate blame-shifting, breakpoints must be subdivided into the following three categories during the visualization process:

• System Breakpoints: These issues are usually caused by integration failures of Legacy Systems. For example, a relationship manager submits an application in the CRM, but due to an interface timeout in the Core Banking System, the data does not actually reach the Risk Control Department's queue. Through digital breakpoint bridging, the system should be able to automatically flag "API Handshake Failure" or "Data Sync Exception," directly proving that the delay is not due to the negligence of risk control personnel, but an IT operations issue.
• Operational Breakpoints: This is the most common human bottleneck, usually manifesting as the "dwell time" of a ticket at a specific approval post exceeding the standard. By monitoring the time consumed at nodes, one can clearly see whether the ticket is stuck at the "Branch Manager Approval" node or the "Compliance Dept Preliminary Review" node.
• Input Breakpoints: Often, back-office departments do not process tasks because the materials submitted by the front office are incomplete (e.g., missing stamped documents or blurry images). If the system cannot explicitly display "Suspended: Awaiting Supplementary Documents," the back office will be misunderstood as being inefficient.

2. The "Granularity" Trap of Visualization

When implementing process visualization, a common pitfall is attempting to record every minute action, resulting in excessive data noise. Efficient breakpoint identification should focus on Key Handoff Nodes.

It is recommended to adopt the principle of "Input/Output" standardization: every key node must clearly define its input content and output content. For example, at the "Personal Loan Approval" node, the visualization interface should not display how many times the approver opened the page, but should focus on:

• Entry Time: When did the task accurately arrive at this node?
• Cause of Stagnation: If the SLA (Service Level Agreement) time limit is exceeded, does the system force the entry of a reason (such as "Awaiting Credit Report Return")?
• Routing Action: Is the task "Approved," "Rejected," or "Reassigned"?

In this way, visualization dashboards or reports are no longer just showing "who is working," but become X-rays for diagnosing process health. When departments face objective breakpoint data—"Currently 30% of tickets are stuck in the image supplementation stage"—rather than subjective accusations, the focus of cross-departmental communication naturally shifts from "mutual blame-shifting" to "jointly clearing bottlenecks."

Pillar 2: Rigid SLA and Smart Dispatch—Replacing Personal Favors with Rules

In complex cross-departmental collaboration within banks, "buck-passing" often wears the cloak of "insufficient resources" or "unclear responsibilities." To break this deadlock, relying solely on meeting coordination or verbal promises is ineffective; rigid SLAs (Service Level Agreements) and smart dispatch mechanisms must be introduced to transform a "relationship-based society" into a "rule-based society."

Traditional SLAs are often narrowly understood as IT system availability metrics (such as the 99.999% availability required by bank core systems), but in business workflows, an SLA represents a rigid turnaround time commitment. For example, stipulating that "the Retail Credit Department's preliminary review must be completed within 4 hours" or "the Compliance Department's AML investigation assistance must provide feedback within T+1 days." This is no longer a vague "handle as soon as possible," but a hard metric measurable by the system.

At the same time, Smart Ticket Dispatch (Smart Dispatch) resolves the dispute of "who does the work." The traditional "supervisor assignment" model easily triggers complaints like "why do I always handle the hard tickets" and breeds favoritism. By introducing rule engines or AI algorithms, the system can automatically dispatch based on the following logic:

• Load Balancing: Automatically assign to the specialist with the fewest current pending tasks.
• Skill Matching: Match personnel with corresponding qualification certificates based on ticket tags (such as "Cross-border Business," "Large Credit Line").
• Recusal Principle: Automatically avoid approval paths involving conflicts of interest.

This mechanism strips away human intervention, making "rules" the sole baton, and eliminates excuses for buck-passing at the source.

Early Warning Mechanism: Solving Problems Before They Become "Overdue"

The core value of an SLA lies not in post-event accountability, but in in-process intervention. Many bank assessment reports are "rearview mirrors"—counting how many tickets were overdue at the end of the month, by which time customer experience has already been damaged. An efficient ticket workflow system must possess a real-time early warning mechanism, moving management actions forward to the critical point where risks occur.

A mature early warning system typically includes the logical design of the following three levels:

1. Red/Yellow Light Threshold Setting (The 80% Rule)
   The system should set dynamic thresholds based on the total SLA duration. For example, for an "Urgent" ticket promised to be completed within 4 hours, when the elapsed time reaches 3 hours (75%-80%) and it is still unfinished, the system automatically triggers a "Yellow Light Warning." At this point, the focus of processing is no longer simple workflow, but "rescue."
2. Multi-channel Reach and "Strong Reminders"
   Warnings cannot just be a red dot within the system. Referring to general ticket product design, effective warning actions should include:

• • Level 1 (About to Overdue): Send a pop-up reminder to the current handler via Enterprise WeChat or internal IM, informing them of the remaining time.
  • Level 2 (Already Overdue): Immediately trigger an SMS or phone notification, and simultaneously copy their direct supervisor.
  • Level 3 (Severely Overdue): If the overdue duration reaches a specific multiple (e.g., 200%), the ticket automatically escalates to the department head or a higher level for intervention.

1. From "Hiding" to "Swarm" Culture
   In an environment lacking early warnings, the instinct of operators is to "hide the backlog"; however, under an early warning mechanism, once a red light is triggered, the team supervisor can immediately perceive the bottleneck (e.g., a queue blockage caused by someone's sudden leave) and quickly manually allocate resources for "Swarming" support.

Through this mechanism, the bank's operating model transforms from passive "Complaint-Driven" to active "SLA-Driven," ensuring that the vast majority of potential buck-passing and delays are "corrected" by system rules before affecting the final delivery.

Early Warning Mechanism: Solving Problems Before They Become "Overdue"

Traditional banking operations management often falls into the "rearview mirror" trap: managers usually only discover that the SLA (Service Level Agreement) compliance rate for a certain type of ticket is only 70% when reviewing compliance reports at the end of the month. By then, customer complaints have already arisen, and cross-departmental buck-passing is a foregone conclusion. To solve this pain point, the core of the ticket workflow system must shift from "post-event reporting" (Reporting) to "real-time warning" (Warning).

Trigger Logic Based on Time Thresholds

An efficient early warning mechanism is similar to the "alert strategy" in system monitoring; it does not rely on manual monitoring but triggers automatically based on preset rules. A mature banking ticket system should support multi-level warning configurations, rather than a single "overdue notification."

Taking an "emergency risk investigation" ticket with a 4-hour SLA timeframe as an example, the system should execute the following logic:

• T + 3.2 hours (80% time used): Trigger a "yellow light" warning. Detecting that the ticket is not yet completed, the system automatically sends a strong reminder to the current handler via WeCom or internal IM: "Your ticket is about to become overdue, please prioritize processing."
• T + 4 hours (100% time used): Trigger a "red light" escalation. Once the SLA red line is breached, the system automatically changes the ticket status to "Overdue" and immediately copies the direct supervisor or department head.

From "Concealment" to "Swarming Tactics"

The essence of this mechanism is to expose problems within a "recoverable" window. In the design of Basic Configuration of Ticket Systems and SLA Monitoring Systems, the key lies in configuring flexible "execution actions"—that is, automatically triggering SMS, app push notifications, or voice messages at specific time points (such as before/after the first response time).

Through this transparent escalation mechanism, the internal collaboration culture of the bank will undergo a fundamental shift:

1. Eliminate information asymmetry: Employees can no longer cover up low processing efficiency by "sitting on tickets," because the system will automatically broadcast the risk before the red line is reached.
2. Dynamic resource allocation: When a supervisor receives a warning at 90% or 100% time usage, their intervention is no longer simple accountability, but adopting "Swarming tactics"—immediately coordinating other available personnel to intervene, assisting the original handler in quickly overcoming bottlenecks, and ensuring that commitments to customers are not broken.

This ability to "solve problems before they become overdue" is the key watershed distinguishing a passive recording tool from a proactive operational platform.

Pillar 3: Data-Driven Performance Closed-Loop

If "visualization" solves the problem of being "invisible," then "data-driven" addresses the chronic illness of being "unclear." In cross-departmental collaboration within banks, buck-passing ("kicking the ball") often occurs in gray areas: business departments accuse risk control of being too slow, while risk control departments complain about incomplete materials submitted by business. Building a performance closed-loop means no longer relying on verbal defenses, but letting the data left by ticket workflows speak for itself.

Farewell to "Free Text," Embrace Structured Attribution

Many early banking ticket systems were merely digitized emails; closing a ticket required only a phrase like "Processed." Such unstructured data is worthless for management. To achieve a true closed-loop, structured Resolution & Return Codes must be enforced.

When a ticket ends or is returned, the handler must select a clear reason category instead of writing arbitrary notes.

• Return Scenarios: Should not just be "Returned for revision," but subdivided into "Missing documents," "Does not meet access policy," "Not this department's responsibility," etc.
• Resolution Scenarios: Distinguish between "Completed normally," "Abnormal termination," or "Transferred to offline processing."

As described in practical sharing on ticket systems in the Product Manager community, a robust ticket system can only transform complex business operations into an orderly management closed-loop through standardized structured information collection. Only when "return reason" becomes a statistical field can management precisely identify which link is creating friction.

Generating "Buck-Passing Profiles": Quantifying Inter-Departmental Friction Coefficients

Based on structured data, the bank's operations management department (or IT department) can generate periodic "Collaboration Efficiency Reports," focusing on the following counter-intuitive metrics rather than just "processed volume":

1. Inter-Departmental Rejection Rate Matrix:
   If 30% of tickets submitted by the Credit Department to the Compliance Department are returned, and the reason is mostly "incomplete documents," the problem may not lie in the Compliance Department's efficiency, but in the Credit Department's submission quality or a lack of frontend system validation.
2. Ping-Pong Count:
   Monitor the number of times a single ticket bounces back and forth between two departments. If a certain type of ticket circulates more than 3 times on average, it indicates that the responsibility boundaries for that process are blurred (unclear SOP) or that a necessary "pre-review" mechanism is missing.
3. Pending Time Attribution:
   For a ticket with a total duration of 5 days, was it actually processed for 5 days, or did it sit silently in someone's "inbox" for 4.5 days? By automatically recording the Mean Time To Respond (MTTR) at each node, bottlenecks can be precisely pinpointed.

Beware of Weaponizing Data: From "Accountability" to "Resource Optimization"

When implementing a data closed-loop, management must maintain strategic focus: The primary purpose of data is not punishment, but resource optimization.

In actual banking scenarios, data often reveals unexpected truths. For example, data might show that the Legal & Compliance Department has the longest "average stagnation time," but this does not necessarily mean employees are slacking off. Combined with an analysis of total ticket volume, it might reveal that the per capita ticket processing volume in that department is 5 times that of other departments.

In this case, data becomes strong evidence for the department to apply for increased headcount or to procure automated review tools, rather than a basis for punishment. Through cost constraints and input-output analysis, banks can more scientifically assess the actual load of each department in the process.

Therefore, a healthy performance closed-loop should follow the principle of "optimize first, assess later":

1. Identify Bottlenecks: Discover congestion at a specific node through data.
2. Analyze Causes: Is it insufficient manpower, difficult-to-use systems, or unreasonable process design?
3. Allocate Resources: Optimize the system or increase manpower.
4. Final Assessment: If efficiency still does not improve after resources are in place, then initiate performance accountability.

Through this approach, the ticket system is no longer an "electronic shackle" in the eyes of employees, but a powerful tool to help them clarify responsibilities and fight for resources, thereby fundamentally reducing the motivation to pass the buck.

Case Study: The "Slimming Down" of a Bank's Credit Process

To verify the theoretical effectiveness of "Unified Tickets" and "Data Closed-loops," we selected the Corporate Trade Finance business of a joint-stock bank as a sample for review. Due to its involvement in document verification, risk assessment, legal compliance, and credit limit usage, this business has traditionally been a hotspot for cross-departmental buck-passing.

Pain Point Analysis: A "Relay Race" Amidst Information Silos

Before implementing the unified ticket system, the workflow for a complex Letter of Credit (L/C) issuance application at the bank was in a typical "black box" state.

• Nodes Involved: 5 independent departments (Relationship Manager, Branch Risk Control, Head Office Document Center, Compliance Department, Disbursement Center).
• System Fragmentation: Used 3 heterogeneous systems (initiated in CRM, limit checked in Credit Approval System, booked in Core Banking System), interspersed with extensive email communication and offline paper signatures.
• Efficiency Bottleneck: Average processing time was 3 working days.
• High Buck-passing Frequency: When Relationship Managers asked about progress, the Risk Department claimed to be "waiting for compliance opinion," while the Compliance Department claimed "documents are being reviewed at the Document Center." Due to the lack of a unified view, the business side could not determine exactly where the ball was dropped, causing the process to fall into an unaccountable "vacuum period."

As pointed out by industry research, this phenomenon is a typical management failure caused by data silos and process breakpoints.

Transformation Solution: From "Serial Handoff" to "Parallel Collaboration"

The bank introduced a unified Process Orchestration Engine to thoroughly restructure the existing process. The core of the reform was not to replace the core system, but to establish a unified ticket layer covering the entire process.

1. Unified Ticket ID
All cross-system operations are mapped to a single "Ticket ID." Whether data flows through the CRM or the credit system, the Ticket ID remains constant. This solved the problem of "unable to find data across systems" and achieved full-link visual tracking.

2. Parallel Processing
This broke traditional serial dependencies. Once the Relationship Manager submits an application, the ticket system automatically splits it into sub-tasks:

• Risk Control Sub-ticket: Pushed to the risk control system to verify limits and trade background.
• Compliance Sub-ticket: Pushed to the legal/compliance system for anti-money laundering (AML) and sanctions list screening.
  These two actions occur simultaneously. The system sets a "Join" point; only when both sub-tasks return a "Pass" status code will the ticket automatically flow to the Disbursement Center.

3. SLA Countdown
On the ticket dashboard, every node is equipped with a visible countdown timer. For example, if the SLA for compliance review is set to 2 hours, and it remains unprocessed after 1.5 hours, the system automatically triggers a yellow light warning and sends an instant notification to the department supervisor.

Implementation Results and Compliance Benefits

After three months of trial operation and tuning, the efficiency and governance level of this credit process achieved a qualitative leap:

The Unexpected Bonus of Regulatory Compliance
Beyond efficiency gains, the unified ticket system brought significant compliance advantages to the bank. Since every operation (approval, rejection, countersigning) is automatically recorded and timestamped by the system, the bank can export complete audit logs with one click when facing regulatory inspections regarding the "flow of credit funds" or "AML review trails." This not only reduces operational risk but also responds to the banking industry's transformation trend regarding process automation and bridging digital gaps.

This case demonstrates that the key to solving cross-departmental buck-passing lies in replacing vague manual coordination with deterministic system logic, transforming "expediting via relationships" into "flowing via rules."

Conclusion: Tools Are the Means, Governance Is the Core

Many bank managers hold a misconception when implementing "ticket routing systems" or similar digital tools: they believe that as long as an advanced IT system is launched, the chronic illness of cross-departmental buck-passing will automatically disappear. However, reality is often cruel—without matching managerial will, the system not only fails to eliminate "kicking the ball," but may instead become a tool for departments to "shift blame" more precisely (for example, using loopholes in system rules to refuse accepting tickets).

Technology Solves the Problem of "Seeing"; Management Solves the Problem of "Caring"

A unified ticket system essentially provides a set of "transparency infrastructure" for internal bank collaboration. Through digital footprints, it solves the long-standing problem of "Can we see it?". Through process visualization, managers can clearly see how many days a credit approval has been stuck in the Risk Management Department, or how many times a customer complaint has bounced back and forth between a branch and the Head Office Personal Banking Department.

However, technology cannot solve the problem of "Do we care?" (willingness to take responsibility). This belongs to the realm of governance. If internal performance appraisals still encourage the mindset of "the more you do, the more mistakes you make; the less you do, the fewer mistakes you make," or if the boundaries of responsibility (SLA) between departments are vaguely defined, then even the best ticket system will only be reduced to an electronic ledger recording evidence of buck-passing.

As pointed out in research regarding the Construction and Practice of Bank Risk Governance Systems, building an efficient "process-oriented bank" is not just about reducing management hierarchy, but also requires achieving effective collaboration and separation among the front, middle, and back offices. The true core of governance lies in this: Leadership must define clear rules of the game. This includes:

• Establishing an arbitration mechanism: When two departments dispute the ownership of a ticket, there must be a clear "first-inquiry responsibility system" or a high-level arbitration process, rather than letting the ticket hang indefinitely in the system.
• Reshaping collaboration culture: Incorporating "on-time ticket completion rate" and "cross-departmental satisfaction mutual evaluation" into assessments, allowing departments that assist others to gain tangible benefits.

From "Internal Routing" to "Customer Experience"

Ultimately, our goal in governing "cross-departmental buck-passing" is by no means just to make the internal flowcharts look smoother, or to produce a pretty operational report.

The efficiency of internal routing directly defines the upper limit of the external customer experience.

In the digital age, customers expect instant responses from banking services. While we argue internally for three days over the ownership of a complex business matter, the customer is already considering transferring their assets to a competitor bank that responds faster. By achieving transparency through tools and parity of authority and responsibility through governance, banks can truly break down departmental "silos" and transform the energy originally consumed in internal friction into efficiency for serving customers.

This is not only a technological upgrade but also a profound transformation regarding organizational agility.