Freshdesk and CodeWords: automating against the clock

Freshdesk organizes support around time more explicitly than most helpdesks. SLA policies set targets for first response and resolution, business hours determine what counts as elapsed, and Supervisor rules exist specifically to act on things that have been waiting.

That makes the time dimension the most useful place to automate, and it is also where the native tooling has a particular gap: everything it does about time is reactive. A Supervisor rule fires after a ticket has already been waiting too long. By then the target is at risk or already missed.

What we'll cover

• Three rule types and what each is for
• The gap: reacting against predicting
• What the Freshdesk API reaches
• Connecting it to CodeWords
• Seven automations worth building
• Business hours, which break most calculations
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Three rule types and what each is for

Worth separating, because people frequently build in the wrong one and then wonder why it did not fire.

Dispatch rules run once, at creation. They see the ticket as submitted and nothing after. Right for initial routing, group assignment, and priority from the form.

Observer rules run on change. They see the transition — priority raised, status moved, agent reassigned — and act on it. Right for escalation when something changes.

Supervisor rules run on a schedule. They are the only native mechanism that acts on the passage of time, and they are how "no response for four hours" gets handled.

The limitation all three share: each evaluates one ticket against conditions on that ticket. None can consult your billing system, and none can reason about the queue as a whole.

The gap: reacting against predicting

A Supervisor rule fires when something has already waited too long. Useful for escalation, useless for prevention.

Predicting is a different question. Given how many tickets are open, who is actually working, what is already at risk, and how long this category usually takes, which of today's targets will be missed unless something changes? That needs a view across the queue rather than of one ticket, and it needs facts Freshdesk does not hold, such as who is at their desk this afternoon.

That prediction is the highest-value thing to build here, and it is genuinely beyond what the native rules can express.

What the Freshdesk API reaches

Tickets can be created, read, updated, searched, and filtered, including the SLA timestamps that matter here: due by, first response due by, and whether each has been breached.

Conversations — public replies and private notes — can be read and created, with the distinction between them being the field it is most consequential to get wrong.

Contacts and companies carry custom fields, which is where data from your own systems belongs so Dispatch rules can route on it.

Agents and groups can be read, including availability, which is what makes capacity reasoning possible at all.

SLA policies can be read, so an automation knows which target applies to a given ticket rather than assuming one.

Business hours calendars can be read, including holidays, which is essential for any calculation involving elapsed time.

Time entries can be recorded, which matters for anyone billing support.

Webhooks and rule actions can call an external URL, letting Freshdesk's own rules hand specific cases outward rather than having an automation poll everything.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which tickets, which target, and who should hear about the risk.
3. Authorize the connection with an API key scoped appropriately rather than an administrator's own.
4. Describe the exceptions: a ticket with no SLA policy attached, a category with too little history to predict from, a public holiday.
5. Run it in report-only mode for a week and compare its predictions against what actually breached.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Breach prediction. Each morning and again at midday, identify the tickets most likely to miss their target given queue depth, agent availability, and how long this category usually takes. A short ranked list, not an alert per ticket.

Capacity-aware reassignment. Dispatch rules assign by rule. They cannot see that one agent has fourteen open tickets and another has two. Rebalancing within a group by actual load evens out a queue that native routing distributes without regard to it.

Stale pause detection. Tickets marked as waiting on the customer where the customer replied two days ago. The clock is stopped, nobody is looking, and it is invisible in every standard view.

Category timing baselines. How long each ticket type actually takes, computed from history rather than set once by guesswork. This is what makes prediction possible, and it usually reveals that at least one target was set optimistically.

External data onto contacts. Plan, spend, renewal date, and open issues elsewhere written as custom fields, so Dispatch rules can route on what matters rather than only on what the form captured.

Outcome capture. On resolution, create the record elsewhere — a bug with the conversation attached, a credit request, a note against the account — so nothing depends on somebody remembering.

Honest attainment reporting. SLA performance in business hours, alongside reopen rate and time spent paused. Attainment alone is the easiest support metric to improve without improving service.

Business hours, which break most calculations

Almost every wrong number in support reporting starts here.

Elapsed time is not working time. A ticket raised at five on Friday and answered at nine on Monday took three days of wall clock and about an hour of business time. Reporting the first makes a responsive team look negligent.

Read the calendar rather than assuming. Freshdesk holds business hours including holidays. An automation calculating against a hard-coded working day will be wrong on every holiday and for every team in another timezone.

Multiple calendars are common. Different groups frequently have different hours, and applying one to all of them produces predictions that are confidently wrong for whichever group it was not built for.

Pause states stop the clock. Any calculation has to account for time spent waiting on the customer, or it over-reports how long your team took.

Do the arithmetic once, in the automation. Business-hours calculation is fiddly enough that doing it correctly in the thing that reports beats doing it repeatedly by hand in a spreadsheet afterwards.

Building it so it survives

Make it safe to run twice. Webhooks retry, and a prediction posted twice reads as two separate warnings.

Distinguish public reply from private note explicitly. One field, customer-visible, and it cannot be unsent.

Never let an automation pause a ticket or change an SLA policy. Pausing stops the clock, which improves reported attainment without improving anything real. That is a judgement for a person.

Score the prediction weekly. An automation predicting breaches should be checked against what actually breached. A predictor nobody scores becomes a predictor nobody believes.

Keep routing in Freshdesk. Write fields from outside; let Dispatch and Observer rules act on them, so support leads can change routing without waiting for you.

Limits worth knowing about

Rate limits are per account and vary by plan, and touching every arriving ticket reaches them sooner than expected. Response headers report the remaining quota.

Supervisor rules run on a schedule rather than continuously, so anything needing finer granularity has to come from outside.

Filter and search endpoints have result caps, so an automation reasoning about the whole queue must filter tightly and paginate.

Custom fields must exist before they can be written, which catches automations that work in one environment and fail in another.

Public conversations cannot be unsent, which is the argument for keeping customer-facing replies under human control.

What to build first

Category timing baselines, read-only: how long each ticket type actually takes, in business hours, from your own history. It needs no write access, it usually shows that a target was set by optimism rather than evidence, and everything else here depends on it.

Two habits make the difference. Run the prediction in report-only mode for a fortnight and score it against what actually breached, because an unscored predictor is an opinion. And have it report on quiet days too, because a silent predictor cannot be distinguished from a broken one.

Frequently asked questions

Why not just use Supervisor rules for this?

Use them for what they do well: acting on a ticket that has already waited. They cannot see across the queue, cannot see agent load, and cannot use your own history to estimate duration. Prediction needs all three.

How accurate can breach prediction be?

Accurate enough to prioritise a morning, which is all it needs. Score it weekly and adjust. The output that matters is a ranked list of what to look at first, not a confident number per ticket.

Should an automation pause tickets to protect the SLA?

No. Pausing improves attainment without improving service, which turns the metric into a measure of how well the automation games it. Whether you are genuinely waiting on the customer is a judgement.

How do I handle teams in different timezones?

Read the business hours calendar attached to each group rather than assuming one. This is the most common source of wrong support numbers, and the figures it produces are plausible enough that nobody questions them.

Can Freshdesk's rules call my automation?

Yes, through webhook actions, and it is the tidiest available pattern: let Freshdesk decide which tickets need external handling using its own rules, and hand only those outward.

What is the most consequential mistake?

Posting a public reply where a private note was intended. Customer-visible and permanent. Specify it explicitly rather than relying on a default.

How should I report SLA performance honestly?

In business hours, alongside reopen rate and time spent paused. A report showing attainment alone will eventually be improved by moving tickets into paused states, and everyone will be pleased with a number that means nothing.

How far ahead can it usefully predict?

A few hours, reliably. Beyond that, too much changes — tickets arrive, agents pick things up, priorities shift — for a morning prediction to say anything useful about tomorrow. Two runs a day, each looking at the rest of that day, is the shape that works.

What if a category has too little history to predict from?

Say so rather than guessing. A category with six tickets behind it produces a baseline that is noise, and a prediction presented with the same confidence as one drawn from six hundred will be wrong in a way nobody can see. Report those separately as unpredictable and let the volume build.

Should agents see the prediction?

Yes, and as a team list rather than as individual assignments. A ranked list of what is at risk lets a team decide together who takes what. The same information delivered as personal alerts reads as monitoring, and it produces defensiveness rather than a rebalanced queue.

Does this work if we have not configured SLA policies properly?

It works better than without, and the baselines will expose how loosely the targets were set, which some teams find uncomfortable. That discovery is worth having: most SLA policies are inherited from a default nobody revisited, and knowing what your team actually achieves is the input to setting one deliberately.

Can it help decide whether our SLA targets are realistic?

That is arguably its most useful side effect. Baselines computed from your own history tell you what your team actually achieves per category, in business hours, which is the only sound basis for setting a target. Most policies are inherited defaults, and comparing them against reality is a ten-minute conversation that saves a year of quietly missing them.

Related reading

• Zendesk and CodeWords
• Freshsales and CodeWords
• CodeWords integrations and templates