Most teams that use Help Scout treat it like a very nice shared inbox. Tickets come in, agents reply, tickets close. The workflow engine sitting under Settings → Workflows is the most powerful thing on the page, and in most accounts I've seen, it has never been opened.
Before you add Zapier, before you build an n8n flow, before you call your developer to wire up a webhook, spend two hours in Help Scout's native workflows. They run in-context with your conversations, they cost nothing extra, and they eliminate most of the manual triage work that slows teams down every single morning.
These are the five I enable first, in the order I enable them, and why the order matters.
Why Native Workflows First
External automation tools are powerful, but they add complexity: new credentials to manage, new failure points, new things to debug at 8 a.m. on a Monday. Help Scout's native workflow engine runs in the same place your support team already works. When a workflow misfires, you can see exactly why inside the conversation timeline. No webhook logs, no external dashboard to open.
The other reason to start here: tagging, routing, and nudge workflows built natively are the foundation everything else depends on. If your tags are inconsistent, your Zapier triage automation will produce garbage. Get the foundation right first.
Workflow 1: Auto-Tag by Keyword
This is always the first one I build. The trigger is simple: conversation subject or body contains one of a defined list of keywords. The action is: apply a tag.
My starting keyword groups look roughly like this:
- Urgency tags: words like "urgent," "ASAP," "immediately," "escalate" apply a tag called
urgent - Billing tags: words like "invoice," "refund," "charge," "payment," "billing" apply
billing - Cancellation tags: words like "cancel," "cancellation," "unsubscribe," "leaving" apply
churn-risk - Onboarding tags: words like "getting started," "how do I," "setup," "first time" apply
onboarding
The keywords are directional, not exhaustive. You will miss some on day one. That is fine. Watch the tag coverage for two weeks and add the keywords you notice slipping through. Within a month, you will have tagged roughly 60 to 80 percent of incoming volume automatically. That percentage is what makes every other workflow reliable.
Clean tags are not the goal. Clean tags are the prerequisite for every goal that comes after.
Workflow 2: Route by Tag
Once your tags are running, routing becomes mechanical. Build one workflow per specialization your team has.
If you have a billing team or a billing queue: trigger is "tag is billing," action is "assign to [billing team]." Same pattern for technical support, onboarding, cancellations. The churn-risk tag I assign directly to the account manager or to whoever owns retention, not to the general queue.
One thing I always add to the churn-risk workflow: a note action. Help Scout lets you add an internal note automatically. I set mine to say something like "This conversation contains a cancellation signal. Prioritize a personal reply." The agent sees it before they open the thread. That 10-word note changes the tone of the reply that follows.
Workflow 3: The Stale Conversation Nudge
This is the one that catches the ticket everyone forgot. The trigger is a time condition: conversation is open, has an assignee, and has had no outbound reply for 48 hours (or whatever your SLA window is, I usually set this at about 80% of the reply target).
The actions are two things: apply a tag called needs-followup, and send the assigned agent an email notification. If you have a manager or team lead, I also add them as a secondary notification recipient.
The important thing about this workflow is what it is NOT doing: it is not auto-replying to the customer on behalf of the agent. The human is still in the loop. All the workflow does is tap the agent on the shoulder. They write the reply. That distinction matters because a premature automated reply to a complex or sensitive ticket can make things significantly worse. The nudge workflow surfaces the gap; the agent closes it.
Workflow 4: After-Hours Smart Reply
The worst version of an after-hours auto-reply is the one that says nothing except "we are closed, we will be in touch." It answers no question, solves nothing, and leaves the customer staring at a blank wall until morning.
The better version tells the customer three specific things: when they will hear back (give an actual time window, not just "soon"), where they can find answers right now (link to your knowledge base or your most common FAQ topics), and optionally, what to do if the issue is genuinely urgent (an emergency contact or escalation path, if one exists).
Set this up as a time-condition workflow: conversation created between [your close time] and [your open time], action is send a reply using a saved template. Write the template once, carefully, then leave it. Revisit it quarterly to update the knowledge base links.
Workflow 5: The Pre-SLA Alert
This is the most underused one. Most teams track SLA breaches after they happen. This workflow catches them before.
The trigger is a time condition again: conversation is open, has no outbound reply, and is approaching your first-reply SLA threshold. I typically set this to fire about 90 minutes before the deadline. The action is two things: apply a tag called sla-risk, and send the assigned agent a direct notification.
The practical effect: your SLA breach rate drops because agents are not surprised by deadlines. They know, with 90 minutes of runway, that they need to reply now. This is especially useful in higher-volume environments where tickets are easy to lose in the queue during a busy stretch.
Pair this with a report filter on the sla-risk tag and you get a useful weekly view: how many conversations were flagged pre-SLA, and of those, how many still breached. If that second number is consistently above zero, the issue is usually staffing or queue depth, not process. That data is valuable to have when you make the case for headcount.
The Setup Order (and One Thing to Skip)
I enable these in exactly this sequence, and the sequence matters:
- Keyword auto-tagging (Workflow 1) first. Everything else depends on clean tags.
- Route by tag (Workflow 2) second, once you have a day or two of tag data to check coverage.
- After-hours reply (Workflow 4) third, because it has no dependencies and is customer-facing. Get it live early.
- Pre-SLA alert (Workflow 5) fourth, once you know your actual SLA targets for the account.
- Stale conversation nudge (Workflow 3) last, after agents are used to the routing patterns, so the nudges land in the right place.
The one thing I skip on first setup: auto-close workflows. Help Scout lets you automatically close conversations after a period of silence. I have seen this cause more problems than it solves. A customer who sent a follow-up two days later suddenly finds their ticket closed, reopens it, and now feels dismissed. Leave the auto-close decision to your agents. They have the context; the workflow does not.
What You Have After Two Hours
When these five workflows are running, the queue your team sees each morning is fundamentally different from a raw, unsorted inbox. Billing tickets are in the billing queue. Churn-risk conversations have a note already flagging the priority. After-hours customers have already been told when to expect a reply. Nothing older than 48 hours sits unnoticed. And the SLA clock is visible to everyone it needs to be visible to.
None of this required a developer, an API key, or a paid integration. It took two hours in Settings. That is a good trade before you write a single line of external automation.
Once the native layer is solid, you can layer in external tools where they actually add something new, routing based on CRM data, AI-drafted replies, escalation logic tied to subscription tier. But those tools should be extending a clean foundation, not compensating for one that was never built.
Want to compare notes on your current Help Scout setup, or figure out which workflow to tackle first? Drop me a line.
Comments