Freshdesk Ticket Statuses & Lifecycle Explained

The four default statuses

Every Freshdesk account, right down to the Free plan, ships with the same four statuses, and you cannot delete them. They map to the four states a support conversation can realistically be in:

• Open — the default status the moment a ticket is created. It means the ball is in your court: the ticket is new, or an agent needs to take an action. This is the working state where most of your queue lives.
• Pending — the agent has replied and is now waiting on the customer (or a third party) for more information. The conversation is alive but blocked on someone outside your team.
• Resolved — an agent is reasonably sure they have provided the right answer and is waiting for the customer to confirm. It is a "probably done, pending sign-off" state, not a final one.
• Closed — the issue is finished and the solution has been accepted. This is the terminal state.

Under the hood these are more than labels. Freshdesk's API represents them as numeric status codes — Open is 2, Pending is 3, Resolved is 4, and Closed is 5 — which is exactly what you pass when you update a ticket programmatically. If you ever script status changes or read the Freshdesk API, those integers are the values you will see.

How a customer reply reshuffles everything

The rule that trips up the most people: any time a customer replies, the ticket moves back to Open, no matter what status it was in. Reply to a Resolved ticket with "still broken" and it reopens. Reply to a Pending ticket and it goes back to Open so an agent takes another look. Even a Closed ticket can be reopened by a fresh customer reply, depending on your reopen settings.

This is by design, per Freshworks' Understanding Ticket Statuses guide, and it is the mechanism that keeps conversations from silently dying. It is also why "Resolved" and "Closed" are two distinct states rather than one: Resolved parks a ticket while leaving the door open for the customer to push back, and Closed is the point at which you consider it genuinely finished.

Statuses and SLA timers: the part everyone gets wrong

Here is where status stops being cosmetic. An SLA timer starts ticking the moment a ticket is created, counting down to your first-response and resolution targets as defined in your Freshdesk SLA policies. Status is one of the main things that pauses or resumes that clock.

The clearest example is Pending. By default, SLA timers are turned off for Pending tickets — because you should not eat an SLA violation for time you spent waiting on the customer. Move a ticket to Pending and the resolution clock freezes; move it back to Open (or the customer replies) and it resumes. That single behaviour is why disciplined use of Pending is the difference between honest SLA reporting and a dashboard full of violations you never actually caused.

For custom statuses, this on/off behaviour becomes an explicit choice. Every status carries an SLA timer toggle, and any ticket sitting in a status with the timer switched off is flagged as On Hold — a state you can see and filter on from your dashboard. On Hold is not a status of its own; it is a derived label for "the SLA clock is currently frozen here." That is exactly how teams model realities like "waiting on engineering" or "escalated to a vendor" without punishing their metrics.

Custom statuses: when the default four aren't enough

The four defaults describe a conversation's state, but they don't describe your process. If your workflow has stages — waiting on a third party, pending a code fix, queued for a callback — you'll want custom statuses. These are available on the Growth plan and up; the Free plan is limited to the four defaults.

You create them in one place. Here is the path and the flow:

1. Go to Admin → Ticket Fields and click the Status field.
2. Click Add new choice to add a status.
3. Type the agent-facing label and, separately, the customer-facing label. These can differ — agents might see "Waiting on Customer" while the customer, checking the portal, sees "Awaiting your Reply."
4. Set the SLA timer on or off for that status, depending on whether the clock should keep running while a ticket sits there.
5. Save. The new status now appears in the ticket status dropdown and in your automation and ticket-field logic.

That separate agent/customer labelling is genuinely useful: it lets you run an internal vocabulary ("Waiting on Eng", "Escalated — Tier 3") while showing customers something plainer. The mechanics are documented in Freshworks' guide to creating and editing custom ticket statuses.

The ticket lifecycle, start to finish

Put the pieces together and a ticket's journey looks like this:

1. Created → Open. The ticket lands, SLA timers start, and it sits in the working queue.
2. Agent replies → Pending. The agent answers and moves it to Pending; the SLA clock freezes while the customer thinks.
3. Customer replies → Open. Any reply snaps it back to Open and restarts the clock — the agent picks it up again.
4. Agent solves it → Resolved. The agent marks it Resolved, waiting for confirmation. Custom statuses (On Hold, Waiting on Third Party) can slot in anywhere along this path.
5. Confirmed → Closed. The issue is accepted and the ticket reaches its terminal state — until a new reply reopens it.

The loop between Open, Pending, and Resolved is where the real life of a queue happens, and status is the field that governs every transition — including which of those transitions the SLA clock is allowed to count.

The honest limits — where native statuses stop

Freshdesk's status model is clean, well-designed, and does exactly what a status field should. But it is worth being clear about its edges, because status is a state marker, not a decision-maker.

Status changes are manual or rule-driven, never judgment-driven. A ticket only becomes Resolved because an agent clicks it or an automation rule fires on a keyword or field condition. Nothing in Freshdesk reads the actual conversation and concludes "this is genuinely solved" or "the customer is still frustrated, don't resolve this yet." That reading-and-deciding is precisely the part native statuses can't do.

Custom statuses are gated and finite. They start at Growth, and while they let you model process stages, they're still a static list an admin maintains — not something that adapts to what customers are actually asking about. And SLA freezing, while powerful, only reflects the status a human or rule already set; if an agent forgets to move a waiting ticket to Pending, the clock keeps running and the report lies.

This is the seam where an AI agent layer helps — and it's worth thinking through the build-versus-buy tradeoff before you reach for one. The broader category of AI agents for customer service exists to handle the judgment work that a status field structurally can't. Macha is one such layer: it runs on top of the Freshdesk you already use as a native connector — it does not replace your help desk, and it is not a Freshdesk alternative. You connect it with your subdomain and API key, and it reads and writes the same tickets your statuses already govern: drafting replies grounded in your help center, adding internal notes, and updating status, priority, and tags based on what the customer actually said rather than a keyword match. (Note: Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller.)

The practical division of labour is simple. Keep Freshdesk's statuses and SLA timers for what they're great at — structuring your process and reporting on it honestly. Layer an agent on top for the reasoning: deciding whether a ticket is truly resolvable now, moving it to the right status with the right internal note, or looking up an order or account state through a custom tool that turns a REST API into something the agent can call before it touches the status at all.

FAQ

What are the default ticket statuses in Freshdesk? There are four, available on every plan and non-deletable: Open (the default at creation), Pending (waiting on the customer), Resolved (agent believes it's solved, awaiting confirmation), and Closed (accepted and finished). In the API these map to status codes 2, 3, 4, and 5 respectively.

Does the SLA timer keep running on a Pending ticket? No. By default, SLA timers are turned off for Pending tickets so you don't get penalised for time spent waiting on the customer. When you move the ticket back to Open — or the customer replies — the clock resumes. For custom statuses you can toggle the SLA timer on or off per status; tickets with the timer off appear as "On Hold" on your dashboard.

How do I create a custom ticket status in Freshdesk? Go to Admin → Ticket Fields, click the Status field, then Add new choice. Give it an agent-facing label and a (possibly different) customer-facing label, and set its SLA timer on or off. Custom statuses require the Growth plan or higher; the Free plan is limited to the four defaults.

Why does my Resolved ticket keep reopening? Because any customer reply moves a ticket back to Open, regardless of its previous status — that's by design, so conversations don't die silently. Resolved deliberately leaves the door open for the customer to push back; Closed is the state you use once the issue is genuinely finished.

Can I add AI to Freshdesk statuses without replacing Freshdesk? Yes. An AI agent layer like Macha connects to Freshdesk as a native connector and runs on top of your existing help desk — it isn't a replacement or a competitor. It reads and writes the same tickets your statuses govern and can set the right status based on the meaning of a conversation rather than a keyword. You can review Macha's pricing and the Freshdesk connector for details, then start a trial when you're ready.