Ticket Auto Assign Process

Owned by Kanij Fatema (Unlicensed)
Last updated: Dec 24, 2019
6 min read

This document is intended to describe the technical implementation of ticket auto-assign process that has been developed by the following story:  https://commengine.atlassian.net/browse/CE-1093  

As a Host Admin I want to run a crone job for a specific Tenant.

System will automatically assigned ticket to available operator based on settings of time period.

Time period (x) must not be less than 1 min (60) sec. Job will run periodically after 10 min and assign (10/x) tickets to an operator.

Tenant Admin can specify user for stream and inbox ticket.

Summary of Process:  a periodic timer will be triggered from client browser to auto-assign. 2 types of user permission will be checked i.e. inbox and feed. If permission allowed, only active users will get assigned tickets.

Configuration:

  1. Periodic timer can be configurable. Tenant admin can configure it.

  2. User ticket handling capacity can be configurable by the tenant admin

  3. There should be a Pause button to stop auto assign by the operator

Test Scope:

  1. HostAdmin can enable/disable the auto-assign feature

  2. Admin can set auto assign permission for inbox/feed or both to individual operators

  3. Admin can set Handling capacity and interval from User settings (user settings permission need to be enabled)

  4. Once the operator logins, the system runs the process according to the permission.

  5. once the system starts the process it will run periodically according to the user settings

  6. Users can pause auto-assign from the right sidebar. It will stop the auto-assign process for that user until re-login.

  7. the auto-assign process will follow basic thumb rule as below

    1. all assignable tickets will be distributed equally to the logged in users

    2. all assignable tickets will be distributed according to the individual’s handling capacity per interval

 

Details of Auto Assign Process:

UI validation:

Whenever a user logged in to the system, it automatically set a timer that will check and validate the auto-assign process is to be started or not. The system will retrieve the auto-assign interval from the settings and check the difference between the current time and last assign time. If the current time reached the interval, the system will send a request to the server and the auto-assign process will start.

Back-end API process:

The entire auto-assign process workflow as below:

  1. While UI sends requests to the server, system checks logged in users and validate interval time with last assign time. If the difference between the current time and the last assign time>= interval, it returns true otherwise, it stops the process. Last assign time is stored on global cache for the validation of the next interval 

  2. If the system passes the validation, it calculates the total handling capacity for all active users for the current interval only.

  3. After that, the system invokes Facebook graph API for retrieving inbox conversations and feed (regular posts, visitor posts, recommendations, and ad posts) comments and filter according to the input criteria to search assignable ticket data.

  4. After generating ticket data according to the calculated total handling capacity, the system distributes the tickets to all logged-in users with the round-robin method.

  5. Then, the system invoked the stored Procedure ‘CreateBulkTickets’ to insert all the generated data at a time.

  6. After inserting, system notifies users about the new assignment and

  7. Finally, the system refreshes the inbox and feed streams.

 

Generating Ticket Data for Inbox and Feed

Ticket data generation process divided by two steps:

  1. Generating Inbox Ticket Data

  2. Generating Feed Ticket Data

 Generating Inbox Ticket Data

Inbox ticket data are generated by the following steps:

  1. Inbox conversations are retrieves by invoking Facebook conversations API with the given time frame.

  2. After retrieving conversations data, it checks the conversations are already ticket or not.

  3. If any item found as a ticket, remove it from the data list.

  4. After preparing the filtered data, system checks the handling capacity again. If ticket data is less then total handing capacity, system again revokes the method recursively followed by the step 1 to 4.

  5. Once ticket data count is equal to total handling capacity or reaches the date filter criteria, it stops invoking API calling and prepare the object for ticket input DTO. 

Generating Feed Ticket Data

Feed ticket data are generated by the following steps:

  1. The system runs an iteration over an array of 4 feed types such as [NewsFeed, AdPost, VisitorPost, Rating]

  2. For each type, system invokes Facebook graph API with the given time frame and fetch comments and replies of page posts.

  3. After retrieving posts data, it checks the comments and replies are already ticket or not.

  4. If any item found as a ticket, remove it from the data list.

  5. After preparing the filtered data, system checks the total feed handling capacity again. If ticket data is less then total feed handing capacity, system again revokes the method recursively followed by the step 1 to 4.

  6. Once ticket data count is equal to total handling capacity or reaches the date filter criteria, it stops invoking API calling and prepare an object for ticket input DTO.

 

Distribution of tickets to logged-in users

Tickets will be distributed with the following thumb rule:

  1. The ticket should be distributed equally

  2. The ticket should be distributed as per individual handling capacity

Distribution mechanism can be understood by the following case studies:

Case Study 01:

For example: Logged-in users: 2

User 1: Handling capacity: 80

User 2: Handling capacity: 20

If total handling capacity is 100 and ticket count is 50, then average capacity will be 25 per each user.

  1. User 1 will get the 25 tickets and User 2 will get 20 tickets at the first iteration.
  1. Remaining 5 tickets will be distributed to the user 1 at the second iteration.

 Case Study 02:

For example: Logged-in users: 2

User 1: Handling capacity: 20

User 2: Handling capacity: 80

 If total handling capacity is 100 and ticket count is 50, then average capacity will be 25 per each user.

  1. User 1 will get the 20 tickets and User 2 will get 25 tickets at the first iteration.
  1. Remaining 5 tickets will be distributed to the user 2 at the second iteration.

 Case Study 03:

For example: Logged-in users: 2

User 1: Handling capacity: 50

User 2: Handling capacity: 50

 If total handling capacity is 100 and ticket count is 50, then average capacity is 25 per each user.

  1. User 1 will get the 25 tickets and User 2 will get 25 tickets at the first iteration.

Case Study 04:

For example: Logged-in users: 3

User 1: Handling capacity: 20

User 2: Handling capacity: 30

User 3: Handling capacity: 50

If total handling capacity is 100 and ticket count is 100, then average capacity is 33 per user.

  1. User 1 will get the 20 tickets, User 2 will get 30 tickets and User 3 will get 33 tickets at the first iteration.
  1. Remaining 17 tickets will be distributed to the user 3 at the second iteration. 

Above case studies have been covered by the following validations: 

  1. Run an iteration over the logged in users, and

  2. Calculate average distribution capacity per logged-in user (say: AvgCapacityPerUser)

  3. Calculate current distributed ticket per user (say: currentDistributedTickets)

  4. Calculate ticket handling capacity per user/interval (say: handlingCapacity)

  5. If currentDistributedTickets>= handlingCapacity , set handlingCapacity value to ‘0’

handlingCapacity value ‘0’ means stop distribution for the user

6. If AvgCapacityPerUser>0 and AvgCapacityPerUser<handlingCapacity, then distribute tickets as per AvgCapacityPerUser

7. If AvgCapacityPerUser>0 and AvgCapacityPerUser>handlingCapacity, then distribute tickets as per handlingCapacity

8. After ending the iteration, if any ticket remains to be distributed, run recursive iteration from step 1 to 8 again.

These validation conditions are applied for both inbox and feed tickets distribution.

Note:

  • Equal distribution may differ according to the handling capacity per individual user and if assignable tickets count is odd.

  • The client browser sets a 5 min timer that checks and validates auto-assign interval. This timer will be reset and will start from the beginning of the user refreshes the browser. This means that if the user refreshes the browser just before the auto-assign process getting ready to start, it may delay max 5 min to start the process again.