Conversation Reassignment Thresholds When an Agent Is Absent: Trigger Table, Owner and Evidence

When an operator steps away, the conversation doesn't just drop on its own: it stays open, the customer keeps writing, and no one answers. The operational problem isn't the absence itself, it's not having defined from what point that conversation stops belonging to that person and becomes someone else's. Without a written threshold, every supervisor improvises: some conversations get reassigned too early (the operator comes back and finds their inbox in disarray) and others too late (the customer has already left).

The typical case: in a rotisserie with two people on the midday shift, one goes out to make a delivery and comes back forty minutes later. In the meantime, six orders and two schedule inquiries came in. If no one defined that after 10 minutes of operator silence the conversation gets reassigned, those six orders get answered when the operator returns, with the customer already ordering somewhere else. This page is the missing table: what signal triggers reassignment, with what number, who executes it, and what gets recorded. It's not a product recommendation or a tool comparison: these are thresholds for the team to adopt and adjust with their own data. The logic is always the same: first you measure, then you decide with a number, and only at the end do you automate what already works by hand.

How to read this table

Each row is an absence scenario with its threshold. The "signal" column is what to look at. The "threshold" column is the number from which action is taken, expressed in the unit in which the signal is measured (minutes of silence, minutes since the operator's last activity, number of open conversations). The "trigger rule" column says what exactly happens when that threshold is crossed. The "responsible" column says who executes it: the operator themselves, the on-duty supervisor, or the system. The "evidence" column is what must be recorded so that later it can be audited whether the reassignment was done correctly.

Two warnings before using the table. The first: the thresholds are starting points, not definitive. They are calibrated with the business's own data, and the reasonable starting point is the first response time the team already sustains during normal hours. The second: the absence isn't always the operator's. A customer who writes and gets no response is also a conversation that is cooling down, and sometimes the operator is present but the conversation got stuck waiting for a piece of data from the customer. The table separates the two cases because they are resolved differently.

Why the threshold can't be just one

A team that uses a single threshold for everything ends up with two opposite problems. If the threshold is short, conversations move before the operator can answer and the customer gets replies from two different people about the same topic. If the threshold is long, the customer waits too long and the operator who comes back finds an inbox they no longer recognize. The table solves this by separating three dimensions: who stopped responding (the operator or the customer), why (declared absence, undeclared absence or simple delay) and what is being waited for (a simple answer or a piece of information that depends on another area).

The most underestimated dimension is the last one. A conversation where the operator promised to look something up and still does not have the answer is not fixed by reassigning it to another operator who also does not have the information. It is fixed by reassigning it to whoever can resolve the information, which often is not in the inbox. That is why that row of the table has a different owner and a threshold that depends on what the operator told the customer.

How each team's threshold is calculated

The numbers in the table are starting points. To calibrate them with your own data, you first need to measure the team's actual first response time during normal hours and peak hours, and use that value as a reference. The formula is simple:

• Step 1: measure the first response time of the last two weeks, separating peak hours from off-peak hours.
• Step 2: take the 75th percentile of each group, not the average. The average hides the conversations that sank to the bottom of the inbox.
• Step 3: the reassignment threshold for customer silence is set at that 75th percentile, rounded up.
• Step 4: the absent operator threshold is set at half the first response time during peak hours. If during peak hours the team responds in 12 minutes, the absence threshold is 6.
• Step 5: review the thresholds every time the shift's staffing or message volume changes.

A concrete example to see how it applies. A clinic with two secretaries measures that in the morning 75% of first responses go out in 8 minutes or less, and in the afternoon in 14 minutes or less. With that data, the customer silence threshold is 8 minutes in the morning and 14 in the afternoon. The absent operator threshold, half of peak, is 4 and 7 minutes. If the following week a new secretary joins and the first response time rises to 20 minutes, the threshold also rises: the team is not forced into a number it cannot sustain.

What is NOT reassigned (and why)

The temptation when an operator is absent is to move everything. That breaks the continuity of conversations that were already on track and forces the customer to explain the same thing twice. There are three cases where the correct rule is not to reassign:

• Conversations where the customer did not reply to the operator's last message. There is no urgency: the customer is in control. They are marked for follow-up and closed or rescheduled according to the defined deadline.
• Conversations that are waiting for information from the customer themselves (documentation, a photo, a receipt). Reassigning them does not speed anything up because the bottleneck is not on the business side.
• Conversations that already have a previous reassignment in the last 24 hours. Moving them again creates more confusion than waiting. In that case, escalate to a supervisor, who decides whether to take them.

The general criterion: reassign the conversation where the customer is waiting for something from the business. Leave alone the conversation where the business is waiting for something from the customer.

What gets recorded and what it is for

The evidence column in the table is not bureaucracy: it is what allows you to answer three questions later that always come up. The first, whether the reassignment was done on time or late, by comparing the trigger time with the reassignment time. The second, whether the absent operator had a reasonable conversation load or was overwhelmed, which changes whether the problem is the person or the shift's staffing. The third, whether the customer received a response within the threshold after the reassignment, which is the only measure that matters from the outside.

For that evidence to be useful, the timestamps must be those of the message, not those of the system's internal record. A message can be inserted into the database at a very different time from when it was sent or received, especially if there was a migration or a history import. If the analysis is done with the insertion date, any distribution of times will give a false result. The rule is to always use the message's timestamp and not the record's.

How to automate it without breaking anything

Automating reassignment is done in three stages, and none is skipped. In the first, the supervisor performs the reassignment by hand following the table, and notes each case. In the second, when the criterion is clear and the noted cases match the table, only the "unattended" mark is automated and the reassignment remains manual. In the third, full reassignment is automated for the most predictable scenarios (operator who did not log in, declared absence) and everything involving judgment is left manual, such as the conversation waiting for internal information.

The most common mistake is automating reassignment before having the criteria written down. When that happens, the system moves conversations with logic that nobody defined, operators distrust the inbox and end up working outside the system. The table exists precisely so that automation has a rule that the team has already tested by hand.

Common mistakes when setting thresholds

• Using a single threshold for the whole day. Peak hours and off-peak hours have different response times and need different thresholds.
• Setting the threshold based on how long the fastest operator takes. The threshold is set based on what the team consistently sustains, not on the best case.
• Not distinguishing declared absence from undeclared absence. The first is planned, the second is detected.
• Reassigning without notifying the original operator. When they return, they find their inbox changed and waste time reconstructing what happened.
• Measuring reassignment by number of conversations moved and not by subsequent response time. Moving a lot is not better.
• Leaving the reassigned conversation without a clear owner. A conversation that passed through three hands without an owner ends up unanswered.
• Not reviewing thresholds when shift staffing changes. A threshold calibrated for five operators does not work for three.

How to know the thresholds are set correctly

A set of thresholds is well calibrated when three things happen at the same time. First, the number of reassignments per shift is low and stable: if it rises every day, the threshold is too short or staffing is insufficient. Second, the first response time after a reassignment is equal to or better than the normal first response time: if it is worse, the conversation is falling into an inbox that does not attend to it. Third, operators do not complain about conversations that were taken from them before they could answer them: that indicates the threshold is cutting off conversations that were going to resolve themselves.

When any of the three signals fails, adjust only one threshold at a time and measure for a week before touching the next one. Changing several thresholds together makes it impossible to know which one improved or worsened the result. If after two adjustments the signal remains the same, the problem is probably not the threshold but the number of people on the shift, and there the table does not help: staffing must be reviewed.

If the team handles WhatsApp with a tool that suggests replies and allows reassigning conversations between operators, the table applies the same way: thresholds belong to the business, not to the tool. Wando, for example, has a multi-agent inbox and AI suggestions that the team approves, but the numbers in this table are defined by each business with its own data.