Open, pending, resolved: conversation status that means something

Three statuses — open, pending and resolved — are enough to run a WhatsApp inbox, provided everybody agrees what they mean. Where teams get into trouble is not the number of statuses but the absence of a shared definition.

Get it right and your inbox becomes a to-do list. Get it wrong and it becomes a list of things somebody once looked at.

Definitions worth writing down

Status	Means	Does not mean
Open	Needs action from us	"Recent"
Pending	Waiting on the customer or a third party	"We are busy"
Resolved	Nothing further is needed	"We replied"

The right-hand column is where most of the value is. A team that uses pending to mean "I do not want to deal with this" has lost the only signal that told them what was genuinely blocked.

Who sets it

Both people and flows. An automation can set the status as a step, which is what makes the whole thing sustainable — relying on people to mark things consistently works for a fortnight.

The useful automatic rules are simple:

A flow that fully answered marks the conversation resolved.
A flow that asked a question and is waiting marks it pending.
A customer replying to a resolved conversation puts it back to open.

The third is the one that keeps the whole system honest. Without it, "resolved" slowly comes to mean "we stopped looking".

Status and the bot

Two cautions when automations are involved.

First, resolve deliberately rather than optimistically. A flow that marks everything resolved because it sent something hides work from your team, and the customer who was not actually helped is now invisible.

Second, if your flow is waiting inside a delay, the conversation should not look abandoned. Setting it pending signals to a colleague that something is in progress — otherwise they may reply by hand and end up talking over the automation. The fix for that specific collision is described in stopping a flow cleanly.

What status makes possible

A real backlog number, which is open conversations rather than total conversations.
Filtered views so each person sees their work rather than everything.
An honest resolution count, which is the basis of almost every other measure.
A way to spot the stuck ones — anything pending for days is usually a customer who never came back.

None of that is possible if status is applied inconsistently, which is the argument for automating as much of it as you can.

A convention that works

Write the three definitions down where the team can see them.
Automate the obvious transitions in your flows.
Review anything pending for more than a few days once a week.
Do not add a fourth status until the three are being used properly.

The fourth point is a real temptation and almost always a mistake. Extra statuses divide the same information more finely without making anybody more likely to apply it accurately.

Status and cost

An indirect but real connection. A conversation that goes stale past the 24-hour customer service window — which opens when the customer messages you and resets each time, per Meta's sending messages documentation — can only be reopened by you with an approved template.

So a pending conversation nobody revisits for two days is one where your next message costs money, where it would have been free the day before under Meta's pricing documentation. That is a decent argument for the weekly review of stale conversations.

Frequently asked

Can the customer see the status?

No. It is internal, like notes and tags.

Should the bot resolve conversations?

Only when it genuinely finished the job. If in doubt, leave it open.

What if we disagree about a definition?

Then write down whichever one you agree on and apply it consistently. A consistent imperfect definition beats two correct ones used by different people.

Do statuses affect assignment?

Open conversations are the work; capacity limits count what an agent is holding. The mechanics are in assigning chats to the right agent.

The failure modes, and what each one looks like

Symptom	What is really happening	Fix
Hundreds of open conversations	Nothing is ever resolved	Automate the resolve step where a flow finished the job
Everything resolved, customers complaining	Resolved is being used to mean "replied"	Write the definition down; reopen on customer reply
Large pending pile, nobody looks at it	Pending means "later"	A weekly review of anything pending more than a few days
Two people reply to one chat	Status is fine; assignment is missing	Assign, do not restatus

The last row is worth separating out, because status and assignment solve different problems and teams often reach for the wrong one. Status says what state the work is in. Assignment says whose it is.

Automating the transitions

Three rules cover almost everything, and all three are a single block in a flow:

Set pending when a flow asks a question and waits, so the chat does not look abandoned to a colleague.
Set resolved only on paths where the flow genuinely completed the job — an order confirmed, a question answered from the knowledge base.
Set open whenever a customer replies to something previously resolved.

The third is the one that keeps the other two honest. Without it, a resolved conversation stays resolved even when the customer has come back with a follow-up, and it drops out of everyone's view.

A weekly ritual worth 10 minutes

Open the pending list, sorted oldest first, and deal with the top of it. Most of what you find falls into 3 categories: customers who never came back, things waiting on a supplier who has since replied, and conversations somebody parked and forgot.

All three are cheap to clear and expensive to leave. It is also the fastest way to discover which of your flows leaves conversations in a state nobody expected — the same diagnostic instinct as in the ten mistakes that cost stores sales.

Status as the first reporting you will have

Before any dashboard, status gives you 3 numbers worth knowing daily: how many conversations are open, how many are pending, and how old the oldest of each is.

Those three describe your entire service operation in a way anybody in the business can read. A backlog of 12 with nothing older than a day is healthy. A backlog of 12 with something from last week in it is a different situation entirely, and the count alone would not have told you.

What to do when the backlog is genuinely too big

Do not bulk resolve. It hides the problem and destroys the measure that would have told you whether the fix worked.
Sort by age and work from the oldest, because the oldest are the ones doing reputational damage.
Look for the pattern. Backlogs usually cluster around one question your automation could answer.
Build that flow, then clear the rest.

Step three is where a backlog stops being a staffing problem and becomes an automation opportunity — the same reasoning as in measuring response time and agent workload.

The short version

Open means we owe them something, pending means we are waiting on someone else, resolved means finished. Automate the transitions inside your flows, reopen on a customer reply, review the pending pile weekly, and resist adding a fourth status.

Done consistently, those 3 words give you a backlog number you can trust, filtered views your team will actually use, and the basis for every other measure you might want later.

Getting a team to use it consistently

Consistency is the whole value, and it does not come from asking nicely. Three things that work:

Automate every transition you can, so people only set status in the cases software cannot judge.
Put the definitions somewhere visible — not in a document nobody opens, but in whatever the team actually reads.
Review the pending pile together, weekly, for 10 minutes. Nothing teaches a definition faster than looking at examples of it being applied.

What does not work is a policy announcement. Status conventions decay unless somebody looks at them regularly, and the weekly review is that look.

One thing not to automate

Resolving a complaint. A flow can tag it, note it, assign it and alert somebody, and it should do all four — but the decision that a complaint is finished belongs to the person who handled it, because the customer's view of "finished" and the flow's view are frequently different.

Where to start if you use none of this today

Agree the three definitions in one short conversation.
Add a resolve step to the one flow that genuinely finishes a job.
Add the reopen-on-reply rule.
Look at the pending list on Friday.

Four steps, none of them longer than a coffee, and after a fortnight your inbox starts telling you the truth about what is outstanding rather than showing you everything that ever happened.

The order matters slightly: agree the words before touching any flow, because a resolve step built on a definition nobody shares just produces a different kind of wrong number.