Provide End User estimated waiting time for the CSA to interact

[rasmusei]

AS AN End User I WANT TO see how much longer I have to wait and what is my queue number SO THAT I can decide if I want to wait or give my contact information and leave the chat

Acceptance Criteria

Scope

• [ ] In phase 1, just fixed estimation from the DB is used
• [ ] In phase 2, estimations will be based on proper calculations

Business requirements

• [ ] Calculated time is displayed when at least one CSA is available (green) or idle (yellow) - one possible logic (https://isssp.org/finding-the-average-wait-time-littles-law/)
• [x] #445
• [ ] Calculated time and queue number are displayed only when the End User wants to talk with CSA
• [ ] Waiting time and queue number are not displayed when all CSAs are away (red) and/or outside service hours

Endpoints

/estimated-waiting-time

• [ ] DSL-based service to provide an endpoint with a total estimated waiting time for response

/estimated-waiting-time?chatId=123

• [ ] DSL-based service to provide an endpoint with an estimated waiting time for a response for a specific chat

GUI

• [ ] According to Figma designs
• [ ] Request to /estimated-waiting-time is made when the chat is to be forwarded to a CSA
• [ ] No business logic on the GUI side, GUI only provides the information given by the endpoint defined above
• [ ] Provides estimated waiting time on the basis of the user story and business ACs

DSL

• [ ] ~Keep track of waiting list's participants in a database~
• [ ] ~Re-initiate waiting list's generation via a cronjob~
• [ ] Calculate the estimated waiting time based on existing data in chat database

[turnerrainer]

Poisson distribution is also an option in case of going more into details. Output would be better is we know that during some period there are more requests than usually - for instance when graduands from all over the country are waiting for their exam results.

Technical solutions would be different though as Poisson distribution would require using more date-specific input from the past.

@rasmusei - any preferences?

[turnerrainer]

ADR: FaaS -- https://github.com/buerokratt/Buerokratt-onboarding/blob/main/architecture-design-records.md#function-as-a-service-faas

[joonasroosalung]

@turnerrainer Is there a need for a separate waiting list table? It already exists in the sense that there is a chatlist, the queue is basically chats without assigned agents.

If there would a separate table, how would the cron update it and where would the cron run?

I'm halfway towards writing an sql query to calculate this. For example right now I can take timestamps from an active chat (that is a chat between customer and agent), between the last bot message and first agent message. This is the time the customer had to wait for the first reply from an agent.

So if you take those times, add them up for all customer-agent chats for example in the last 24h and divide them by the size of the queue, you get a waiting estimate. If you order the queue by created, the id is any chat's position in the queue.

What is easy:

• getting the queue from chats without assigned agents, size and postion in queue
• finding waiting time (flow time)

Unknown/difficult:

• can it be done in one query, or could it be divided into multiple queries
• accuracy/usefulness of the estimate

Would this be worth pursuing, instead of the current dsl ac's?

[turnerrainer]

@joonasroosalung I agree, there's no need for a separate DB table for this as we are making these calculations only for live chats, not for a historical overview.

I'll update the AC.

[joonasroosalung]

@ceirowe Pushed mock yml to main as a placeholder, /estimated-waiting-time and /estimated-waiting-time?chatId=any-value. Using query params instead of path params as described in the original AC https://github.com/buerokratt/Ruuter/blob/main/samples/general/params.md.

Will respond 100 if chatId parameter is filled, 300 if not. Switch step is currently bugged and will respond 100 every time, if chatId is filled once. Will be fixed with https://github.com/buerokratt/Ruuter/issues/121.

[joonasroosalung]

The duration time will be in seconds from the last message of the bot to the final message in the chat. Will account chats that a) have a response from a human, b) have ended within the last month (hard-coded).

The average waiting time will be sum of the above duration times divided by the amount. Returned when no chatId parameter present in the request. Equivalent to being 1st in postion.

{ "response": { "durationInSeconds": "100", "positionInUnassignedChats": "0" } }

When the request has the chatId parameter, will return the above average waiting time multiplied by the position, as well as the position itself.

{ "response": { "durationInSeconds": "300", "positionInUnassignedChats": "3" } }

[sergeirudz]

PR: https://github.com/buerokratt/Chat-Widget/pull/14

[ffrose]

BUG -

1. The problem: Waiting for response(calculated time and queue number) does not exist.

2. How it should be: When atleast one CSA is available or idle and End User wants to talk with CSA, it displays calculated time and queue number so End User can decide if they want to wait or give their contact information and leave the chat.

3. When End User want to talk with CSA, it says "directing to CSA" without "Waiting for response" information.

How it is:

How it should be:

[turnerrainer]

@rasmusei this one needs special attention. Help set the priorities.

[rasmusei]

Discussion with Rainer needed