Workflow recipe

Send Google Forms support tickets to Slack

High-priority tickets page on-call; routine ones queue in the support channel. Setup, the subteam-mention syntax, and the SLA framing that makes routing actually pay off.

Start free →

Priority-based channel routing
Subteam mention for on-call
Delivery log + retry on failure

TL;DR

The short answer

Capture priority as a dropdown in your Google Form. Route Priority = "High" to #support-oncall with a subteam mention; route Medium and Low to the standard #support queue. Optionally bump priority for paid-plan customers via a second rule. Every ticket lands in the right channel within seconds; the delivery log records the destination for audit.

The fields a support form needs

Five fields that cover ~95% of tickets

From (email): required. Without it you can't reply.
Subject (short text): required. One-line description; surfaces in the Slack header.
Priority (dropdown: High / Medium / Low): required. The primary routing signal. Users routinely underestimate priority; the rule layer can re-classify based on keywords.
Plan (dropdown or auto-filled): optional but valuable for tiered customers. Routes Agency-plan tickets to a separate channel even at standard priority.
Details (paragraph): required. Two lines minimum so the on-call has context.

Setup

Five steps to a routed support pipeline

1
Build the Google Form with the five fields
Mark From / Subject / Priority / Details required. Plan can be a hidden auto-filled field (URL parameter) or a dropdown.
2
Create Slack webhooks for each channel
Typically two: #support-oncall for High, #support for Medium / Low. For tiered plans, add a third like #support-vip.
3
Find your on-call subteam's ID
Slack → Manage user groups → click your on-call group → copy the ID from the URL (starts with S). You'll embed it as <!subteam^S0123|support-oncall> in the message body.
4
Wire the form into RouteForms with routing rules
Sign up, add the form, paste #support as the default destination, install the Apps Script. Add the rule: Priority = "High" → #support-oncall. Optional second rule: Plan = "Agency" → #support-vip (above the High rule if you want plan to override priority).
5
Set the message template with the subteam mention
Use the “Support ticket” preset from the template generator and replace the placeholder subteam ID with your real one. Test by submitting a High-priority response; the on-call channel should ping.

What lands in the channel

The message shape that actually wakes the right people

:rotating_light: *New support ticket*
<!subteam^S0123|support-oncall>
*From:* alex@customer.com
*Subject:* Cannot log in
*Priority:* High
*Plan:* Solo
*Details:* Reset email never arrives

Channel: #support-oncall · Pick up in Helpdesk

The mention syntax pages the on-call subteam without spamming the whole channel. The siren icon makes the ticket scannable in a busy channel. The plan field signals customer tier without needing a separate lookup.

SLA discipline

Routing is necessary, not sufficient

The routing layer puts the ticket in the right place. The team still has to respond. Pair the routing with explicit per-channel SLAs:

#support-oncall— 15-minute response target. The subteam mention pings whoever's on rotation; first responder claims the ticket with an emoji or reply.
#support — 4-hour response target. Scanned periodically by the support team; ticket-claiming via a thread reply.
#support-low, next business day. Async-friendly for low-urgency questions or feature requests.

Surface response-time metrics monthly. If the data shows the on-call channel isn't hitting its target, the fix is more on-call coverage or a backup escalation, not a different routing rule.

FAQ

Frequently asked questions

What fields should a support form capture?▾

Five usually: From (email), Subject (short text), Priority (dropdown: High / Medium / Low), Plan (if you have tiered customers), and Details (paragraph). The priority dropdown is the primary routing signal. Plan tier optionally bumps priority. Agency-plan tickets might always go to on-call regardless of user-marked priority.

How do I make sure high-priority tickets actually get seen?▾

Two layers. First, route them to a separate channel from the default support queue — #support-oncall instead of #support. Second, use a Slack mention that pages the right subteam: <!subteam^S0123|support-oncall> (replace S0123 with your real subteam ID, found under Slack → Manage user groups). The combination of dedicated channel + targeted mention beats either alone.

How do I find my Slack user-group ID for the mention?▾

Slack → menu → Manage user groups. Click the group → URL contains the ID (it starts with S). Or via API: /admin.usergroups.list. The mention syntax is <!subteam^GROUP_ID|fallback> where fallback is shown if the group can't be resolved (e.g. for users not in the workspace).

What's the right SLA framing for routing?▾

Match the channel to the SLA. High → on-call channel with subteam mention → 15-minute response target. Medium → support queue → 4-hour response target. Low → low-urgency channel → next business day. The routing rules enforce the channel assignment; humans enforce the SLA. Surface response times monthly to verify the discipline holds.

Can the form auto-set priority based on content?▾

Partially. RouteForms's routing rules can re-evaluate priority: 'IF Subject contains "production" → #support-oncall' bumps urgency regardless of user-selected priority. Useful for customers who undermark their tickets. But this isn't AI classification, it's keyword matching. For real intent detection, you'd need a separate classifier layer.

How do I handle escalation if the on-call team misses a ticket?▾

Slack doesn't escalate on its own, the message just sits there until someone acts. The honest pattern is a second integration: a periodic check (e.g. another Apps Script trigger) that looks at recent #support-oncall posts and pages a backup on-call via a separate channel or PagerDuty integration. RouteForms handles the initial routing; escalation is a separate concern.

Should I expose the form URL publicly?▾

Yes, usually, public support forms are the standard. Google Forms's own spam protection (CAPTCHA, response limits) handles most of the abuse. Add an internal admin form for elevated tickets (employee-only access) and route those to a different channel without the same external-customer triage step.

What if Slack rejects the support post?▾

RouteForms records the delivery failure with the response code. For tickets specifically, you can configure a backup destination, if Slack rejects, RouteForms can also email the support address as fallback (on the roadmap; today the manual fallback is reading the delivery log and re-posting). Don't let webhook failures silently lose support tickets.