Service Operations · B2B SaaS
Bi-directional ticket sync between HubSpot and ClickUp using Zapier
How a fast-growing B2B SaaS company replaced manual email support with a two-way HubSpot ↔ ClickUp ticket sync, built as eight coordinated Zapier automations with an SLA engine on top — HubSpot the customer system of record, ClickUp the engineering execution layer.
- 8 live automations
- Coordinated Zaps forming the two-way HubSpot ⇄ ClickUp sync
- 200+ tickets in Q1
- Synced, organised and resolved within SLA in the first quarter — the company's first SLAs
- 3-tier SLA
- P1/P2/P3 with automated due dates (8h · 2 days · 10 days), synced both ways
- Context: Fast-growing B2B SaaS (AI product)
- Systems: HubSpot · ClickUp · Zapier
- Focus: Service desk, escalation, cross-system sync
The problem
A system built before the wave, not after it
Customer issues arrived by email — around 20 a week, growing by roughly three more for every customer onboarded — triaged by hand by a two-person support team. No categories, no SLAs, no structured escalation. And underneath it, the two systems that mattered didn't talk: engineering worked in ClickUp, the customer relationship lived in HubSpot, and every handoff depended on a person remembering to carry information across the gap.
What makes this project unusual is when it was built. The Customer Success team didn't wait for the process to break. They could see the shape of what was coming — more customers meant more tickets, and a small team triaging a rising tide by hand was a wall they would hit, not a matter of if but when. So the system was commissioned deliberately, ahead of the volume, while there was still room to design it properly instead of firefighting it later.
The best time to build the system is before you desperately need it. This one was built at exactly that moment — at the CS team's request, ahead of the curve.
The architecture
Two tools, one truth
The core decision was not to force everyone into one system. Customer Success should own the relationship in the tool built for it; engineering should keep working in the tool they already use. So the design gave each system one clear job — and made them mirror each other.
HubSpot — customer system of record
- →The customer-facing ticket and its history
- →Classification, ownership and priority
- →SLA definitions and status
- →Reporting and customer communication
ClickUp — technical execution layer
- →The actual engineering work
- →Assignment and technical priority
- →Execution status and progress
- →Developer notes and context
HubSpot holds what the customer sees. ClickUp holds how the work gets done. The integration keeps them honest with each other.
The key decision
The escalation gate
The obvious mistake would have been to pipe every customer ticket straight into engineering's board. That doesn't remove chaos — it just moves it from HubSpot into ClickUp.
Instead, a ticket stays in HubSpot unless it's explicitly marked as requiring escalation. Only then does it create a ClickUp task. Product questions get answered as questions; bugs and real engineering work get escalated as work. Support sets the flag; support never sets engineering's urgency — so priorities can't be quietly inflated.
Don't automate the transfer of noise. Automate the transfer of qualified work.
The engine room
Why eight Zaps, not one
The obvious way to build a two-way sync is one giant automation that does everything. It's also the wrong way. This system is deliberately eight separate Zapier Zaps — and the split is the engineering.
The first reason is structural. A Zap has exactly one trigger, and this system has to react to seven different events: a ticket flagged for escalation, a priority change and a new note on the HubSpot side; a status change, a property change, a new comment and a new task on the ClickUp side. Seven triggers cannot live in one Zap. Each event gets its own automation, listening for its own signal.
The deeper reason is control. Each Zap does one job, so each can be tested, versioned and debugged on its own — and if one fails, the other seven keep running. A monolith fails whole; eight small automations fail one at a time. It's the difference between a fuse box and a single wire.
And a two-way sync has one signature danger the split exists to defeat: the infinite loop. A note copied from HubSpot into ClickUp looks, to ClickUp, like a brand-new comment — which would copy back to HubSpot, which would look new again, forever. Splitting the two directions into separate Zaps, each stamping its output with its origin and filtering the other's out, is what breaks the cycle.
Every one of the eight follows the same anatomy: a trigger fires, a filter decides whether this event should act at all, a lookup in a shared mapping table finds the record's counterpart in the other system, an optional code step runs custom logic, paths branch on category or status or priority, and a final action writes the change into the other tool. Zapier is the orchestration, the mapping table is the memory, and the code steps are the intelligence.
The sophistication isn't one clever automation. It's eight simple ones engineered never to step on each other.
The build
The eight automations
Each Zap is small, single-purpose and independently live. Together they are the two-way sync.
HubSpot → ClickUp · escalation
Fires when a ticket is flagged Escalation Required. Enriches the owner via the HubSpot API, decides the assignee by time of day, routes by category into the right engineering lane, and creates the ClickUp task carrying the HubSpot Ticket ID.
ClickUp → HubSpot · status
Fires on a task status change and mirrors it to the HubSpot ticket — pipeline stage, internal status and assigned engineer — across seven states from To-Do to Deployed-in-Production.
HubSpot → ClickUp · SLA priority
When a ticket's SLA priority changes, updates the matching ClickUp task's priority field. Priority is set once and reflected everywhere.
ClickUp → HubSpot · severity
When engineering adjusts a task's impact, scope or urgency, recomputes the resulting P1/P2/P3 and writes it back to the HubSpot ticket.
SLA due dates
On a new task, a code step computes the deadline from its priority — 8 hours, 2 business days or 10, skipping weekends — sets the due date, and DMs the assignee the clock and who to contact.
HubSpot notes → ClickUp comments
New ticket notes flow into the linked task as comments, stamped “From HubSpot” and filtered so they never loop back.
ClickUp comments → HubSpot notes
The reverse direction: task comments become ticket notes, stamped “From Clickup”, with the same loop guard.
The mapping table
On every new task, writes a row linking the HubSpot Ticket ID to the ClickUp Task ID — the shared memory every other Zap looks up to know which record belongs to which.
The hard parts
The three problems that actually make this hard
Identity — which task is this ticket? Ticket names aren't unique, so matching on them eventually updates the wrong record. Everything keys on the HubSpot Ticket ID instead, written once into a Zapier mapping table when the task is created and looked up by every sync afterwards. That table is the system's database.
Loops — the two directions must not chase each other. Every synced note and comment is stamped with its origin and filtered on the way in, so a message that came from HubSpot is never sent back to HubSpot. Without that guard, the first note would ping-pong between the systems forever.
Real SLA logic — “urgent” can't be a feeling. Severity is computed from a 27-row Impact × Scope × Urgency matrix into P1/P2/P3, synced both ways; due dates are calculated in code that counts business days and skips weekends; and the assignee is chosen by category and time of day. The rules live in the system, not in someone's head.
This is where a ticket form ends and an operating system begins.
The operating model
From customer to resolution — and back
CUSTOMER (email · form · chat)
│
▼
HUBSPOT SERVICE DESK
classify · own · prioritise · SLA
│
Escalation required?
│
┌─────────┴──────────┐
NO YES
│ │
answer & resolve CLICKUP TASK
in HubSpot assign · execute · status · notes
│ │
│ ▼
│ resolution / progress
│ │
└─────────┬───────────┘
▼
HUBSPOT TICKET UPDATED
(status back · creator notified)
│
┌───────────┼───────────┐
▼ ▼ ▼
SLA reporting & customer
tracking recurring comms (CS)
issuesOne loop: the customer never leaves HubSpot's view, engineering never leaves ClickUp, and the two stay synchronised in both directions.
What changed
Before and after
Before
- Issues arrived as email and Teams messages
- Manual triage; no categories, no SLAs
- Engineering work invisible to Customer Success
- Escalation depended on someone remembering
- No reporting on volume, priority or recurring issues
- Every new customer added load the process couldn't absorb
After
- Every issue becomes a structured, owned ticket
- Classification, priority and SLA from the start
- Status and notes sync both ways, automatically
- Escalation is a deliberate, gated decision
- Support is measurable — categories, SLAs, recurring issues, per-customer volume
- A system built to add agents and customers without rebuilding it
The outcome
Live before the wave it was built for
In its first quarter live, more than 200 tickets were synced, organised and resolved within their SLA windows — the first time the company had SLAs at all.
Because this was the company's first SLA implementation, there is no “before” number to compare against, and we won't invent one. The honest result is simpler, and arguably stronger: a two-person Customer Success team was handed a system that let it absorb rising ticket volume without adding headcount or dropping issues — put in place at the moment it was cheap to build, and before it became expensive not to have.
Not a rescue after the fire. A system installed while the building was still calm.
The takeaway
Integrate the systems; don't force one on everyone
The instinct in a growing company is to make everyone work in one tool. But Customer Success and engineering have genuinely different jobs and genuinely different tools — and fighting that just creates duplicate work or shadow systems.
The better move is to let each system do what it's best at and build the connective tissue between them: one system of record, one execution layer, a deliberate gate deciding what crosses over, and a two-way sync so neither side is ever in the dark. That's diagnosis-first, system-over-tool RevOps — applied to service.