Organizing Operational Work by Risk, Urgency, and Scale

My primary goal this month is to advance a new operating model for servicing and collections. The model will organize work by urgency, severity, and volume rather than primarily by whether an interaction happens live or through a back-office process.

This is not a new idea entering execution without preparation. During the last two months, teams have designed workflows, aligned on the direction, and piloted parts within the existing structure. September is an opportunity to turn those pieces into a systematic model—and to build a stronger knowledge foundation beneath it.

1. Context: The Original Structure No Longer Fits the Work

When the company was smaller, a division between synchronous and asynchronous work was practical. Agents handled live customer conversations using defined scripts and training, then recorded commitments and next steps. Back-office work arrived as case IDs, was assigned manually, and often operated under broader service targets.

Scale has exposed the limits of that structure. Cases differ not only by channel but also by potential customer harm, regulatory or compliance exposure, financial loss, and reputational risk. High-volume routine work should not be managed in the same way as a lower-volume case requiring specialist attention and rapid escalation.

The new model separates work across two related dimensions:

• Urgency and severity: How quickly a case needs action and how serious the consequences could be
• Volume: Whether the work needs standardized high-throughput processing or concentrated specialist expertise

This should allow us to direct capacity according to business need, form specialized pods for severe cases, and intervene before important service commitments are at risk.

2. Operating Model: Route the Work and Prepare the Decision

We have created a curated reference dataset of examples showing how work should be routed based on message content, source, and specific descriptors. This provides a testable definition of correct routing rather than relying only on written procedures.

We plan to use those examples to develop and evaluate a machine-learning routing layer. Depending on measured performance and operational needs, that may use a prompt-based language model, a dedicated natural-language classifier, or a combination of the two. The model will assign each item to the appropriate queue based on factors such as urgency and severity.

After routing, an AI agent will create the case and enrich it with relevant metadata and context. It can collect and summarize information, suggest the next action, and alert the team when a service threshold is at risk. Assigned agents, supervisors, and managers will remain responsible for reviewing the case and completing the work within the applicable service level.

3. Training Human and AI Agents Starts with the Same Discipline

One challenge has been helping the team see that training an AI agent and training a human agent begin with similar work. In both cases, we must:

1. Define the workflow.
2. Specify the intended outcome and success criteria.
3. Provide the context needed to make a sound decision.
4. Review performance and improve the instructions.

The analogy is useful, but the differences matter. A person can sometimes use experience and judgment to compensate for incomplete instructions. An AI agent can apply an unclear instruction repeatedly and at scale. We therefore need to be more diligent about what we write, which exceptions we document, and how specifically we define the desired outcome. Copying and pasting a generic prompt is not an operating design.

This discipline has forced us to surface tribal knowledge and reconsider earlier documentation. Assumptions that an experienced employee might infer must now be made explicit enough to teach, test, and improve.

4. Build Context Once, Use It Across Workflows

An AI agent becomes more useful when it can understand more than the immediate task. That requires structured context about the customer, merchant, complaint, prior interactions, applicable requirements, and relationships among them.

The objective is not simply to collect more text. It is to create a relational, multidimensional record from which a workflow agent can retrieve the relevant facts and form a coherent case narrative for human review.

graph LR
    I[Incoming work] --> R[ML-assisted routing]
    G[Reference examples] --> R
    R --> A[AI case preparation]
    C[Customer context] --> A
    M[Merchant context] --> A
    H[Interaction history] --> A
    A --> K[Enriched case record]
    K --> U[Human review]
    K --> V[Live operating view]

This shared knowledge layer is more important than any one task. Once the context is reliable and reusable, the organization can decide which process—or combination of people and software—is best suited to each action. The foundation supports many workflows instead of creating isolated automation for each one.

5. Visibility, Leadership, and Success

The new operating view should answer three questions:

1. What backlog exists now?
2. Where have service levels been breached within a rolling time window?
3. At what rate is new work arriving?

For complaint-related work, this means visibility into intake velocity, current inventory, and resolution performance. Leaders should be able to identify pressure, reset priorities, and add help before severe cases approach a breach.

This work spans servicing, collections, machine-learning operations, data and AI platforms, and Merchant Risk and Claims, with input from legal, compliance, and product teams. I will serve as executive sponsor and cross-functional project lead, resolving conflicts and resetting priorities when daily demands compete with the transformation.

Success will begin with full visibility into complaint intake and velocity, live tracking against service levels, and faster resolution over time. The main risk is that production issues or a sudden increase in complaints consumes the capacity required for proactive redesign.