Abstract:
Omni-channel routing broker technology is usable to improve the experience for customers and for workers using service channels, especially for very large enterprise service operation centers that have large pools of agents, helping businesses determine the relative priority for handling a variety of service channels, and to efficiently route issues accordingly. Omni-channel routing broker includes intelligent routing of service requests in a large, distributed service center operation, efficiently prioritizing the routing of work across organizations to agents based on availability, capacity and priority—in a multi-tenant environment. The disclosed methods are usable for managing digital data for many tenants to software instances, including groups of users who share common access with a specific set of privileges to a software instance of at least one application. The disclosed technology makes possible the delivery of an improved performance from routing 3-4 requests per second to routing 100 requests per second.

Description:
RELATED 
     The present application is a continuation of and claims priority to U.S. patent application Ser. No. 14/829,347 for SYSTEMS AND METHODS FOR AN OMNI-CHANNEL ROUTING BROKER, by Andrew Lintner, filed 18 Aug. 2015, which is incorporated herein by reference for all purposes. 
    
    
     FIELD OF DISCLOSURE 
     The technology disclosed describes systems and methods for intelligent routing of service requests in a large, distributed service center operation—efficiently prioritizing the routing of work across organizations to agents based on availability, capacity and priority, in a multi-tenant environment. The methods disclosed include managing digital data for a plurality of tenants to software instances, each tenant of the plurality of tenants comprising a group of users who share a common access with a specific set of privileges to a software instance of at least one application. 
     The technology discloses systems and methods for an omni-channel routing broker. 
     INTRODUCTION 
     Customer service is moving toward a more personalized 1:1 communication with consumers, through the many channels and on the many devices they use. Omni-channel is a multichannel approach for providing customers with a seamless experience, whether the customer is interacting online via email, web, short message service (SMS), chat, or live agent video support on a desktop or mobile device, by telephone, or in a brick and mortar store. 
     Historically, a series of requests for services have been stored in a database, as an event sequence—a queue of available work. Common techniques for routing work from the queue to agents include the following options: either agents pull work from the queue and assign it to themselves, or a supervisor assigns work to agents. Given that companies have extensive information about their agents—their capabilities, the amount of work that is waiting, and how much work the agents already have in their queues—one goal is to intelligently route work to the agents. Methods of prioritizing include either ‘most available agent’: determining which agent is most available, based on a difference between their capacity and the amount of work already in the agent&#39;s queue; and ‘least active agent’: prioritizing routing of work to an agent based purely on how much work an agent already has. Note that two agents can have different capacity amplitudes, based on various factors, such as number of work hours per week, amount of work experience, or level of training. 
     Service channels for contact centers are evolving significantly for organizations. In this era of omni-channel, it is important for a business to determine the relative priority for handling a variety of service channels, and to efficiently route issues accordingly. 
     In a multi-tenant environment, agents are potentially connected to different app servers, generating a need for keeping work queues synchronized. In order to select a preferred agent to receive any given piece of work, the system needs to evaluate the availability of the agents in the org, their queue membership, their current workload, and the priority of the work. Making these selections in a multi-tenant environment with a high load of incoming work is difficult due to the concurrent nature of the updates made to the variables used to perform agent selection and the distributed system that handles these requests. For example, for a routing system that searches to identify the agent with the least amount of current work, if two work request cases are pushed into a queue simultaneously, and we make routing decisions on two different app servers, then we could potentially push both pieces of work to the same agent, leaving that agent over-burdened. 
     Increasing bandwidth issues accompany routing requests across app servers, and synchronizing access to shared resources is a challenging problem that has relatively slow solutions, with limitations on throughput. Existing technology solves the limitation by segmenting contact centers, but a new approach is needed to allow very large scale service organizations to utilize a very large pool of agents. Some approaches break up distributed systems entirely, but with traffic served by a single app server with agents in an org connected to it, the size of the app server becomes a limiting factor. 
     Speed and efficiency are two of the biggest drivers for customer service departments. The disclosed technology delivers an improved performance from routing 3-4 requests per second to routing 100 requests per second. 
     An opportunity arises to improve the experience for customers and for workers using disclosed omni-channel routing broker technology, including making it feasible for very large enterprise service operation centers to have very large pools of agents. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The included drawings are for illustrative purposes and serve only to provide examples of possible structures and process operations for one or more implementations of this disclosure. These drawings in no way limit any changes in form and detail that may be made by one skilled in the art without departing from the spirit and scope of this disclosure. A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures. 
         FIG. 1  illustrates one example implementation of an omni-channel routing broker environment. 
         FIG. 2  shows a brokered routing example. 
         FIG. 3  illustrates a user interface for an open lead interface, with an agent status window. 
         FIG. 4  shows an example user interface that displays agents&#39; work history. 
         FIG. 5  shows an example omni-channel routing broker workflow. 
         FIG. 6  is a block diagram of an example computer system for implementing an omni-channel routing broker. 
     
    
    
     DETAILED DESCRIPTION 
     The following detailed description is made with reference to the figures. Sample implementations are described to illustrate the technology disclosed, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a variety of equivalent variations on the description that follows. 
     In one implementation, an omni-channel routing broker system includes selecting an app server among the cluster of app servers (pod) to perform routing for a given org. Event handling results are stored in a database, to fulfill a requirement of many large organizations for recording permanent and highly available event logs that enable event tracking, agent activity tracking, and performance analysis. 
     A cascading series of queues is used to avoid the reduction in throughput that would occur if the orgs were routed via a single thread in a single app server. The disclosed system separates routing decisions from the work required to commit routing decisions, delivering improved routing performance and service for customers. 
     Routing Broker Environment 
       FIG. 1  illustrates an example omni-channel routing broker environment  100  that includes a request receiver  162  for handling service requests from a plurality of organizations, via multiple sources: for example—email, web, SMS, chat, or live agent video support on a desktop or mobile device, or by telephone. Each organization has an agent pool disjoint from the agent pools of other organizations. Agents 1-N  164 , at service center one, complete work requests received at service centers 1-N  168 . Clusters of app servers  148  serve org clusters 1-N  128 , storing event information and other log data in cluster/app support data store  116 . In some implementations, organizations operate on a single pod. Clusters of servers that handle traffic exist as a logical unit sometimes referred to as a “superpod” which is a group of pods. 
     An app server among the cluster of app servers  148  is elected to perform routing for a given org. That app server will make the routing decisions for the org. A system could have a single app server for a hundred different orgs. That is, a given app server can serve many orgs. Each org has one or more work queues for their organization&#39;s agent pool. Cluster/app support data store  116  gets updated when agents complete tasks (i.e. close work) for their organizations. 
     Omni-channel routing broker environment  100  makes use of multithreading to manage requests from more than one user at a time, and to manage multiple requests by the same user-tracking the presence and status of agents for multiple orgs. Current presence and status for each agent is stored in master agents&#39; presence and status data store  118 , and presence and status update events are published to event queue  113 . 
     Omni-channel routing broker environment  100  in  FIG. 1  also includes eventually consistent, in-memory node-based databases  142 , which get updated based on the results of receiving agent presence and status events from event queue  113 . For eventually consistent databases, changes to a replicated piece of data eventually reach the affected replicas. The master presence and status data store  118  can store agent presence and status data across agent pools serving multiple nodes; and the eventually consistent in memory node-based databases  142 —are subsets of the master presence and status database that is eventually consistent with the master presence and status data store  118 , as a result of processing events from the event queue. 
     Per org routers 1-N  122  publish incoming service request events from the event queue  113  to at least one of the node-based routing queues 1-N  112 . Additionally, routing broker environment  100  includes a master database of service requests  114  that provides a permanent record of events, enabling long-term event tracking and agent performance analysis. 
     In other implementations, environment  100  may not have the same elements as those listed above and/or may have other/different elements instead of, or in addition to, those listed above. 
     The disclosed omni-channel routing broker technology, described in detail below, evaluates presence and status for agents, and makes routing selections in a multi-tenant environment that handles a high volume of incoming work. 
       FIG. 2  shows an example brokered routing system. Master presence and status data store  118  includes data that specifies the availability and capabilities of each agent. In one example in which agents service sales leads for an organization, an agent&#39;s status can include a list of cases in the agent&#39;s queue, an indicator showing availability for a live chat, and a list of leads being pursued by the agent. Availability can be disabled or dimmed when the agent selects a lunch or offline setting. Agent interactions  222  can include logging in, logging out, completing a task, changing their status such as ‘lunch’ or ‘available for work’, accepting work or closing work, new work coming in, or a new case created. Request log  232  stores the service requests generated via multi-node request logging  234 . 
     When an event comes from one of multiple threads on an app server, the event gets passed to a pool of listeners that processes the event and determines relevance, makes decisions, and adds a routing request to request log  232 , as appropriate. Some events do not cause the addition of a routing request—such as events for orgs not of interest to the stream—because they require no routing decision. Events of interest include an agent doing something that changes their availability for work such as logging in; changing an agent&#39;s capacity for work such as closing work, etc.; or the addition of a new work request. 
     A service request event for an org can be stimulated by an agent requesting work, or by a service request being routed to push work to an agent. An example class for routing work from a pull request is shown below. The code identifies which queue has the most eligible piece of work to route for an agent based on priority and time in queue, and routes the pulled work to the agent. 
     
       
         
               
             
           
               
                   
               
             
             
               
                 class PullRouter extends AbstractRunner { 
               
               
                  &lt;...&gt; 
               
               
                  public void route(PullRequest request) { 
               
               
                   RoutableBrokeredAgent agent = request.getAgent( ); 
               
               
                   while (agent.hasCapacity( )) { 
               
               
                    //Evaluate queue priorities and other business rules to identify the  
               
               
                 highest priority work 
               
               
                    RoutingResult work = queueRouter.findBestWorkForAgent(agent); 
               
               
                    if (work != null) { 
               
               
                     //Attempt to route the work and make changes to our local state. 
               
               
                     // Note: The actual changes to the data store will be committed 
               
               
                      asynchronously. Success here only indicates success 
               
               
                     // of the initial attempt. 
               
               
                     if (routeToAgent(agent, work, request, routeRequestHandler)) { 
               
               
                      logSuccessfulRoute(agent, work); 
               
               
                     } 
               
               
                    } else { 
               
               
                     //There was no work to route, exit the loop 
               
               
                     break; 
               
               
                    } 
               
               
                   } 
               
               
                  } 
               
               
                  private boolean routeToAgent(RoutableBrokeredAgent agent,  
               
               
                 RoutingResult work, RoutingRequest request, RouteRequestHandler  
               
               
                 routeRequestHandler) { 
               
               
                   //Remove the pendingServiceRouting object from our local state 
               
               
                   QueuedPsr psr = 
               
               
                 routeRequestHandler.getQueuesState( ).take(work.getWinningItem( )); 
               
               
                   if (psr != null) { //If there was concurrent modification and we lost  
               
               
                 this, it&#39;s okay - we&#39;ll come through on the next loop 
               
               
                    QueueId queueId = work.getWinningQueue( ).getQueueId( ); 
               
               
                    long capacityImpact = agent.getQueueManager( ).getIm- 
               
               
                 pact(queueId); 
               
               
                    // Update the local agent state to remove capacity for this pending  
               
               
                 work. We&#39;ll later commit this or roll it back. 
               
               
                    agent.getWorkManager( ).consumePending(capacityImpact); 
               
               
                    try { 
               
               
                     // Enqueue the routing result to be processed asynchronously 
               
               
                     routeRequestHandler.addRoutingResult(agent, queueId, psr, 
               
               
                 capacityImpact); 
               
               
                     return true; 
               
               
                    } catch (Exception e) { 
               
               
                     logException(e); 
               
               
                     agent.getWorkManager( ).restorePending(capacityImpact); 
               
               
                 //Rollback the capacity impact 
               
               
                     routeRequestHandler.addAll(Collections.singleton(request)); 
               
               
                 //Add the routing request back to the queue to be retried later 
               
               
                    } 
               
               
                   } 
               
               
                   return false; 
               
               
                  } 
               
               
                 } 
               
               
                   
               
             
          
         
       
     
     An implementation of handling a routing result from the org&#39;s router is shown in the code snippet listed below. If a problem is encountered during the routing, then the work gets restored to the queue, and the pending agent&#39;s capacity gets restored. In one case, if the work is unavailable due to a concurrent modification, the agent&#39;s capacity gets restored. In another case, if the agent concurrently modifies their status to one that should not receive this work, the agent&#39;s capacity gets restored. In both cases, the routing request gets added back to the queue to be retried later. Alternatively, if the routing conditions are successfully met, then the route success marker gets activated. 
     
       
         
               
             
           
               
                   
               
             
             
               
                 public class RoutingResultHandler { 
               
               
                  &lt;...&gt; 
               
               
                  public void handleRoutingResult(RoutingRequest request,  
               
               
                 RoutingResult result) { 
               
               
                   CompletableFuture&lt;WorkRoutedResponse&gt; responseFuture = 
               
               
                 executeCustomerValidation(result) 
               
               
                    .exceptionally((exception) -&gt; 
               
               
                 WorkRoutedResponse.failedExceution(exception)) 
               
               
                    .thenApplyAsync(commitToDataStore( )) 
               
               
                    .exceptionally((exception) -&gt; 
               
               
                 WorkRoutedResponse.failedExceution(exception)) 
               
               
                    .thenApplyAsync(commitToSharedState( )) 
               
               
                    .exceptionally((exception) -&gt; rollbackDataStoreChange(excep- 
               
               
                 tion)) 
               
               
                    .thenAcceptAsync((response) -&gt; { 
               
               
                     if (response.failedExceptionally( )) { 
               
               
                      resyncLocalState( ); //Something has become out of sync in an 
               
               
                 unexpected way. Re-sync the local state from the shared state. 
               
               
                      return; 
               
               
                     } 
               
               
                     if (response.result == WORK_UNAVAILABLE) { 
               
               
                      //The work was unavailable due to a concurrent modification.  
               
               
                 Restore the agent&#39;s capacity and move on 
               
               
                 result.getAgent( ).getWorkManager( ).restorePending(result.getCapacityIm- 
               
               
                 pact( )); 
               
               
                     } else if (response.result == WRONG_AGENT_STATUS) { 
               
               
                      //The agent concurrently modified their status to one that  
               
               
                 should not receive this work. 
               
               
                      // Restore the agent&#39;s capacity and put the work back in the  
               
               
                 queue result.getAgent( ).getWorkManager( ).restorePending(result.getCa- 
               
               
                 pacityImpact( )); //Rollback the capacity impact 
               
               
                      routeRequestHandler.addAll(Collections.singleton(request));  
               
               
                 //Add the routing request back to the queue to be retried later 
               
               
                     } else { 
               
               
                      publish WorkRoutedEvent( ); 
               
               
                     } 
               
               
                   }); 
               
               
                 } 
               
               
                   
               
             
          
         
       
     
     Routers may not be constantly running. If a routing request is the first one in the queue for the particular organization, a router spin-up request event is generated, which causes spin-up of a router for a particular org. Per org routing requests are handled in a non-blocking fashion using the in-memory state snapshot, in order to quickly return the thread for further processing. 
     Multi-node presence and status updating  224  captures changes in agents&#39; states, such as the completion of a task, and provides the changes to the event queue  113 . 
     In one implementation of the disclosed system, a single router per org runs at any snapshot in time. An advantage of this single-router-per-org approach is the ability to route events serially. Single node presence and status updating and request queuing  228  updates an eventually consistent, in-memory subset of the master agent presence and status database  218  and at least one in-memory node-based routing queue  236 . Single thread per org routing decision making  238  includes receiving incoming service requests from the node-based routing queue  236 ; and making routing decisions on the incoming service requests using the in-memory subset of the master agent presence and status database  218 . The eventually consistent, in-memory subset of the master agent presence and status database  218  gets updated to reflect the routing decisions; and the routing decisions get published to the event queue  113 . 
     Implementing the routing decisions applicable to the agent pools across the multiple nodes includes receiving routing decisions from the event queue  113 , and testing the routing decisions for consistency with the master agent presence and status data store  118 . Confirming consistency includes looking at the in-memory node-based routing queue  236  and in-memory presence and status database  218 , and determining whether to roll back the route or to commit the route, based on whether the master presence and status data store  118  is consistent with in-memory node-based routing queue  236 . Consistency-qualified updates are made to the master agent presence and status data store  118  and updated status events are published to event queue  113 . 
     For some implementations, validation rules provided by an organization affect which of the decisions made during single node presence and status updating and request queuing  228  get applied to routing work, via service requests, to agents. Customer code can include Apex triggers or validation rules that affect the ultimate routing decision. For example, some organizations implement rules for fulfillment of customer orders and for processing claims made relative to customers&#39; orders: ‘manager’ level permissions may be required for an agent who approves service requests that include refunds for customers. 
     Once the routing decision has been made; results are stored in the master presence and status data store  118 ; customer code has been executed successfully; and consistency has been confirmed, then the route is considered committed. The service request routing the work to that agent is posted to the event stream, and the agent receives notification that they have work. The agent ‘listening’ to the event stream learns that they have work. 
     In the case of lack of consistency between a particular routing decision and the master presence and status data store  118 , a routing decision rollback event is published to the event queue  113 , and the particular routing decision is not applied to the master presence and status data store  118 . The node-based database—the in-memory presence and status database  218 —gets updated to roll back the routing decision. That is, if unsuccessful, the state changes are rolled back and the work is made available for another routing attempt. For example, if an agent has gone offline during the routing of the request, then we learn that the agent is not available when we try to commit the route to the database, so the route will be rolled back as though it never happened and a new routing request will be generated. 
     App servers within a cluster keep a connection open to each other and ping periodically to be sure they are “up”. In one implementation, if an app server drops out of the pool, the remaining distributed processes coordinate with each other and elect a new app server to serve that org as router. That is, app server selection can be updated if cluster members change over time. A new leader can be elected if the app server that runs the routing decision maker goes offline. 
     A distributed commit log can handle hundreds of megabytes of reads and writes per second from thousands of clients. In one example implementation, a single Apache Kafka broker can allow a single cluster to serve as the central data backbone for a large enterprise organization. The commit log can be elastically and transparently expanded without downtime. Data streams can be partitioned and spread over a cluster of machines to allow data streams larger than the capability of any single machine and to allow clusters of coordinated consumers. 
     An example user interface for a multi-tenant, multi-threaded omni-channel routing broker system is shown in  FIG. 3 . The screenshot shows a webpage that an agent accepting work might view, of Leads known to the organization. In this case, open leads  321  are listed. Also, a zoom in of an agent options popup, located in the bottom right corner of the page, shows agent options  333 . As discussed earlier in this application, cases, chat leads, SOS (for mobile device support), lunch, training and offline are options available to the agent. When a service request has been successfully pushed to the agent, the requests count will show the addition of a new request  336 . Agents can also set their availability to receive work and view incoming requests; and can choose to accept or decline work based on setup for the org, when the widget flashes or rings. 
       FIG. 4  shows an example user interface, for data reporting and analysis, that displays the results of an agent&#39;s work over time. Data can be gleaned from the master agents&#39; presence and status data store  118 , and from the request log  232  and productivity can be displayed. In this example UI, online versus away breakdown  422  displays the agent&#39;s data: the agent was away 4% of the time (based on a sum of status durations in thousands). Average speed of answer (ASA) by queue  446  shows average speed to answer for a cases queue, mobile cases, open leads and sev 1 cases. 
     While the technology disclosed is disclosed by reference to the preferred embodiments and examples detailed above, it is to be understood that these examples are intended in an illustrative rather than in a limiting sense. It is contemplated that modifications and combinations will readily occur to those skilled in the art, which modifications and combinations will be within the spirit of the invention and the scope of the following claims. 
     OMNI-Channel Routing Broker Workflow 
       FIG. 5  shows an example workflow  500  of one implementation of an omni-channel routing broker—routing service requests in a large, distributed service center, across multiple nodes having disjoint memory spaces. Workflow  500  can be implemented at least partially with a database system, e.g., by one or more processors configured to receive or retrieve information, process the information, store results, and transmit the results. Other implementations may perform the steps in different orders and/or with different, fewer or additional steps than the ones illustrated in  FIG. 5 . Multiple steps can be combined in some implementations. 
     At action  510 , track the presence and status of agents in a plurality of disjoint agent pools. At action  515 , publish update events to at least one event queue. 
     At action  520 , process selected update and request events, as described in actions  525  through  550 . 
     At action  525 , update the node-based database from the selected update events; and at action  530 , publish the selected request events to at least one node-based routing queue. 
     At action  535 , on a single thread per organization running on a processor having memory-bus access to the node-based database: make routing decisions on the requests events using the node-based database and at action  540 , update the node-based database accordingly. At action  545 , publish routing decision events to the event queue. 
     At action  552 , implement the routing decision events: at action  555 , test the routing decision events for consistency with a master agent presence and status database; and at action  555 , make consistency-qualified updates to the master agent presence and status database. At action  570 , publish the consistency-qualified update events. 
     Computer System 
       FIG. 6  is a block diagram of an example computer system  600  for implementing an omni-channel broker.  FIG. 6  is a block diagram of an example computer system, according to one implementation. The processor can be an ASIC or RISC processor. It can be an FPGA or other logic or gate array. It can include graphic processing unit (GPU) resources. Computer system  610  typically includes at least one processor  672  that communicates with a number of peripheral devices via bus subsystem  650 . These peripheral devices may include a storage subsystem  624  including, for example, memory devices and a file storage subsystem, user interface input devices  638 , user interface output devices  676 , and a network interface subsystem  674 . The input and output devices allow user interaction with computer system  610 . Network interface subsystem  674  provides an interface to outside networks, including an interface to corresponding interface devices in other computer systems. 
     User interface input devices  638  may include a keyboard; pointing devices such as a mouse, trackball, touchpad, or graphics tablet; a scanner; a touch screen incorporated into the display; audio input devices such as voice recognition systems and microphones; and other types of input devices. In general, use of the term “input device” is intended to include the possible types of devices and ways to input information into computer system  610 . 
     User interface output devices  676  may include a display subsystem, a printer, a fax machine, or non-visual displays such as audio output devices. The display subsystem may include a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), a projection device, or some other mechanism for creating a visible image. The display subsystem may also provide a non-visual display such as audio output devices. In general, use of the term “output device” is intended to include the possible types of devices and ways to output information from computer system  610  to the user or to another machine or computer system. 
     Storage subsystem  624  stores programming and data constructs that provide the functionality of some or all of the methods described herein. This software is generally executed by processor  672  alone or in combination with other processors. 
     Memory  622  used in the storage subsystem can include a number of memories including a main random access memory (RAM)  634  for storage of instructions and data during program execution and a read only memory (ROM)  632  in which fixed instructions are stored. A file storage subsystem  636  can provide persistent storage for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a CD-ROM drive, an optical drive, or removable media cartridges. The software used to implement the functionality of certain systems may be stored by file storage subsystem  636  in the storage subsystem  624 , or in other machines accessible by the processor. 
     Bus subsystem  650  provides a mechanism for letting the various components and subsystems of computer system  610  communicate with each other as intended. Although bus subsystem  650  is shown schematically as a single bus, alternative implementations of the bus subsystem may use multiple busses. 
     Computer system  610  can be of varying types including a workstation, server, computing cluster, blade server, server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, the description of computer system  610  depicted in  FIG. 6  is intended only as one example. Many other configurations of computer system  610  are possible having more or fewer components than the computer system depicted in  FIG. 6 . 
     Particular Implementations 
     In one implementation, a method of routing service requests in a large, distributed service center includes, across multiple nodes having disjoint memory spaces, tracking presence and status of agents in a plurality of disjoint agent pools and publishing update events to at least one event queue. The method also includes processing selected update and request events, including updating the node-based database from the selected update events, and publishing the selected request events to at least one node-based routing queue, across one or more processors that have access to a node-based database used to track agent presence and status in one or more disjoint agent pools. The method further includes making routing decisions on the requests events using the node-based database and updating the node-based database accordingly; and publishing routing decision events to the event queue—on a single thread per organization running on a processor having memory-bus access to the node-based database. The method additionally includes implementing the routing decision events, including testing the routing decision events for consistency with a master agent presence and status database; and making consistency-qualified updates to the master agent presence and status database and publishing update events accordingly. 
     In some implementations of the method of routing service requests in a large distributed service center, the master presence and status database stores agent presence and status data across agent pools serving the multiple nodes; and the node-based database is a subset of the master presence and status database that is eventually consistent with the master presence and status database as a result of processing events from the event queue. The method further includes processing the selected update and request events from the event queue; and on the single thread per organization, reading service request events from the node-based routing queue. 
     In one implementation, a method of routing service requests in a large, distributed service center applies to managing digital data for a plurality of tenants to software instances, each tenant of the plurality of tenants comprising a group of users who share a common access with a specific set of privileges to a software instance of at least one application, wherein each tenant includes one or more of the organizations. 
     In some implementations, the method is enhanced by further including the distributed service center handling service requests for a plurality of organizations, each organization having an agent pool disjoint from agent pools of other organizations, and having one or more work queues for the organization&#39;s disjoint agent pool. 
     The method further includes tracking the presence and status of agents in the master presence and status database using multiple threads per node on the multiple nodes; and updating the node-based database and publishing to the node-based routing queue using multiple threads. 
     The method additionally includes, in case of lack of consistency between a particular routing decision and the master presence and status database: publishing a routing decision rollback event to the event queue and not applying the particular routing decision to the master presence and status database; and updating the node-based database to roll back the routing decision. 
     In some implementations of the method of routing service requests in a large distributed service center, the agent pool serving the organization includes agents working on a plurality of app servers, the method further including: operating a single thread for routing service requests to the agent pool serving the organization across the plurality of app servers used by the agent pool. 
     In some implementations, the method is enhanced by further including an agent pool serving the organization that includes agents working on a plurality of app servers, geographically disbursed across pods operating in different data centers, the method further including: operating a single thread for routing service requests to the agent pool serving the organization across the plurality of app servers, geographically disbursed across pods operating in different data centers, used by the agent pool. 
     Other implementations may include a computer implemented system to perform any of the methods described above, the system including a processor, memory coupled to the processor, and computer instructions loaded into the memory. 
     Yet another implementation may include a tangible computer readable storage medium including computer program instructions that cause a computer to implement any of the methods described above. The tangible computer readable storage medium does not include transitory signals. 
     While the technology disclosed is disclosed by reference to the preferred embodiments and examples detailed above, it is to be understood that these examples are intended in an illustrative rather than in a limiting sense. It is contemplated that modifications and combinations will readily occur to those skilled in the art, which modifications and combinations will be within the spirit of the innovation and the scope of the following claims.