Freshdesk Ticket Status, and Why It Decides Your Metrics
A Freshdesk ticket status isn't a label. It's the input to every metric you report, and one missing status makes your whole response time dishonest.
The four Freshdesk ticket statuses you start with
Freshdesk ships with Open, Pending, Resolved and Closed, and each one means something specific to the system rather than just to your team.
The important behaviour is that Resolved and Closed both stop SLA clocks, and Pending can be configured to stop them too. Whether a status stops the clock is a setting on the status itself, and it's the single most consequential thing about status design.
The waiting-on-customer status
This is the one change I would make to almost any default Freshdesk setup.
If a customer takes six days to send you their account number, that isn't six days of your response time. Unless your statuses say otherwise, it is.
Create a status that explicitly means waiting on the customer, and configure it so the SLA clock does not run while a ticket sits in it. Custom statuses are available on the paid tiers; on the free plan you use Pending for the same purpose, provided you're disciplined about only using Pending for that.
Two things happen when you do this. Your first response and resolution figures start reflecting work you control rather than delays you do not, which means the numbers become worth acting on. And you can build a reminder automation against a status that has a single unambiguous meaning: three days waiting gets one nudge, seven days auto-closes.
Without it, the ticket that has been waiting a fortnight for a customer to reply sits in your backlog looking exactly like the ticket nobody has touched. Those need different responses and your queue can't tell you which is which.
The variant worth adding next is waiting on third party, for tickets blocked on a supplier or another internal team. Same clock treatment, different follow-up owner, and it stops "pending" meaning three unrelated things at once.
Freshdesk ticket status: resolved versus closed
People treat these as the same thing and then wonder why their reporting is odd.
Resolved is your claim. You have answered, and you are waiting to see whether the customer agrees. The ticket can still come back to life, and when a customer replies to a resolved ticket it typically reopens, which is exactly the behaviour you want.
Closed is the end. It signals nobody is expecting further movement.
Use both, with an automation that closes resolved tickets after a set period of silence, commonly three to seven days. That gap is doing real work: it's the window in which a customer can say "actually that did not fix it" and land back in the same conversation instead of opening a new one.
Two practical consequences. Your reopen rate, resolved tickets that came back, is one of the most useful quality signals you have, and it only exists if you use Resolved as a distinct state. And satisfaction surveys are usually best triggered on resolution rather than closure, because that's when the interaction is fresh.
Check the setting that governs what happens when a customer replies to a closed ticket. Some configurations reopen it, others create a new ticket. The second is how one conversation becomes two records with a shared history nobody can see, and it's worth knowing which behaviour you have. If you already have pairs like that, merging puts them back together.
How many statuses is too many
Six is comfortable. Ten is a warning sign. Fifteen means agents are guessing.
The test for any proposed status is whether somebody would behave differently because of it. "Waiting on customer" passes: it changes who chases and stops the clock. "In progress" usually fails, because it means the same as Open in practice and just adds a decision to every ticket.
Be especially wary of statuses that encode a department or a reason. That's what fields and tags are for. Statuses should describe where the ticket is in its lifecycle and who owes the next action, nothing else.
One more thing that bites: deleting or renaming a status later affects historic reporting and any automation referencing it. Adding a status is cheap, removing one is not, so add them slowly.
A status audit worth twenty minutes
Take the last month of tickets and answer three questions.
Then check the numbers your reports produce against those answers. If they disagree, trust the tickets.
Frequently asked questions
Where does Pending sit in the Freshdesk ticket lifecycle?
Between Open and Resolved. The Freshdesk pending status means waiting on the customer, and it's the one that makes response metrics honest by stopping the clock during the Freshdesk ticket lifecycle.
What is the difference between Resolved and Closed in Freshdesk?
Resolved means you believe it's fixed and the customer has not confirmed. Closed means the ticket is finished. Most teams auto-close resolved tickets after a few days of silence, which leaves a window for the customer to come back in the same conversation.
Can I create a custom Freshdesk ticket status?
Yes, on the paid tiers, and you can choose whether each custom status pauses the SLA clock. On the free plan you work with the four defaults.
Does the Pending status stop the SLA clock?
It can, depending on how the status is configured in your account. Check it rather than assuming, because it directly changes every response time number you report.
What happens when a customer replies to a resolved ticket?
It normally reopens, which is the behaviour you want. Replies to closed tickets may reopen or create a new ticket depending on your settings, so confirm which one you have.
How many Freshdesk ticket statuses should we have?
Around six. Add one only when someone would genuinely act differently because of it. Otherwise use fields and tags.
One conversation, two tickets
Replies to closed tickets often start a second record. Ticket Merger spots the pair and merges it back into one thread.
Start free trial14-day free trial. No credit card required.