Turn support escalations into tracked issues
Complaints that need an engineering fix become prioritised, customer-labelled issues in your Support team.
New submission on your "Contact support" form
Create an issue in your Support team with the customer's message, priority mapped from the complaint type, and a "customer" label
One-directional. A submission triggers the action — nothing is written back into your form.
A help desk can answer most of what arrives. The rest needs a code change, and that is where things stall: the agent knows, the engineer does not, and the customer waits on both. Sending the escalation into Linear puts it on a board engineers already look at every morning.
Support leads set this up when the handover keeps happening by direct message. Each issue carries the account number and what the customer actually asked for, so an engineer can pick it up without going back to the agent for context.
Setting it up
- 1
Publish the complaint form your agents use for escalations, and add a customer label to your Linear Support team before you build anything in Zapier.
- 2
Submit one escalation yourself with an account number filled in, so the trigger has a complete sample rather than a half-empty one.
- 3
In Zapier, pick formformform's New Submission trigger and choose that form.
- 4
Add Linear's Create Issue action and select your Support team.
- 5
Build the issue title from Complaint Type and Order or Account Number, so the board reads as a list of affected accounts rather than a column of the word "Complaint".
- 6
Map Complaint Details into the description word for word. Do not summarise it in the Zap — engineers need the customer's own phrasing, not an agent's paraphrase of it.
- 7
Add the desired resolution and the incident date underneath, then set Labels to customer and choose the Linear priority that matches the complaint type.
- 8
Run a test escalation, confirm the issue lands in the Support team at the priority you expected, then turn the Zap on.
What maps where
Using the Customer Complaint Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Linear |
|---|---|
| Complaint Type | Issue title prefix, and the priority you set |
| Order or Account Number | Issue title, so the account is visible on the board |
| Complaint Details | Issue description, the customer's own words |
| Desired Resolution | Issue description, what closing this actually means |
| Is this the first time you are reporting this issue? | Issue description, flags a repeat report |
| Date of Incident | Issue description, when it happened |
Variations worth knowing
Add a Zapier filter that lets a submission through only when the customer says this is not the first time they have reported it. First contacts stay with the help desk; anything raised twice becomes a Linear issue without an agent having to decide.
If account numbers are sensitive in your workspace, drop that field from the mapping and title the issue from the complaint type and date instead. Search your formformform responses for the account when an engineer genuinely needs to identify the customer.
If something isn't arriving
Each submission creates its own issue and the Zap cannot see the earlier one. Ask agents to search the Support team by account number before escalating, then use Linear's duplicate action to fold the second issue into the first.
Mapping Complaint Details into the title produces a paragraph where a title should be. Use the complaint type and account number for the title instead and keep the full text in the description, where Linear renders line breaks properly.
Frequently asked questions
Does the customer see the Linear issue?
No. They see the form and whatever your agent sends them afterwards. The issue lives inside your workspace, and its state, comments and assignee are never written back to the form or shown to the person who submitted it.
Can an agent update the issue by submitting the form again?
No. The connection runs one way, so a second submission creates a second issue rather than editing the first. Once an escalation exists, agents should comment on the Linear issue directly, or the conversation drifts back outside the tracker.
What about complaints that don't need engineering?
Only escalate what needs code. Use conditional logic so the escalation questions appear only when an agent marks the complaint as a product fault, and everything else stays in the help desk queue where an agent can simply answer it.
Related automations
- Create design tasks from a campaign brief
Each brief becomes a Design team issue in the right project, with the campaign context already in the description.
- File feature requests into a product project
Requests land in your Product team's project as labelled low-priority issues, grouped and ready to weigh at planning.
- Route customer feedback into a triage view
Feedback arrives in Triage as a labelled issue the team can accept, decline, or move into a project.
- Send bug reports to your engineering backlog
Each report arrives in the Engineering backlog as a bug-labelled issue with reproduction steps already written.
- Send internal IT requests to your operations team
Hardware, access and tooling requests become assigned Operations issues with a priority, so the queue stays visible.
- Add every RSVP to your confirmed guest list
Each RSVP creates a card on the "Confirmed guests" list with the ticket type as a label and dietary notes in the description.
Build the form first
The automation needs somewhere to fire from. Publish a form, connect it once, and every submission from then on runs this flow.
Start free