Project Management for Zendesk
The definitive guide to running projects inside Zendesk, without bolting on another tool.
Why projects belong in Zendesk
Most project management tools assume the project starts with a plan. In the real world, a huge class of project work starts with a request: a new customer, a new hire, a change request, an audit, an escalation. That work already lives in Zendesk. Graduating it to a separate PM tool means losing the requester, the SLA, the conversation, the CSAT, and the help-centre history. Keeping it in Zendesk, done well, avoids all of that.
Work that begins with someone asking for something. Onboardings, changes, procurement, facilities requests, legal reviews, escalations.
Work where losing the requester, organisation, or conversation thread would break the outcome. The project has a name on it.
Work with commitments, pauses for approvals, and response-time accountability. The Zendesk SLA engine already knows how to track this.
Work that hops between support, HR, IT, legal, finance, engineering. Zendesk light agents make cross-team collaboration free for up to 1,000 contributors on Enterprise.
What Zendesk gives you out of the box, and where it stops
Before layering on apps, know the floor. A vanilla Zendesk Suite instance is already a surprisingly capable project substrate. It is also missing a small set of primitives that stops real projects from running well.
What already works
- Tickets as work items with requester, assignee, group, priority, form, fields, attachments, and a full audit trail.
- Problem and Incident linking collapses many tickets to one root cause and notifies every affected customer on resolution.
- Custom ticket statuses within Open, Pending, On-hold, Solved, Closed for phases like "Awaiting CAB" or "In QA", usable in triggers and SLAs.
- Triggers, automations, and SLA policies to move work along without a human.
- Side conversations to Slack, Teams, or email without polluting the customer thread.
- Light agents (50 to 1,000 seats included) for SMEs and stakeholders to contribute without a paid seat.
- Ticket forms to capture structured intake for each project type.
- Zendesk Explore for reporting, including parent to child ticket relationships.
- Native approvals (Suite Professional+) for single-step yes or no sign-off.
Where vanilla Zendesk stops
- No in-ticket checklists. The native "Task" ticket type is a single ticket with a due date, not a subtask of anything.
- No hierarchical, field-synced subtickets. Side conversation child tickets copy fields once at creation and drift after that.
- No way to block solve until child tickets or tasks are complete.
- No phased or sequential work. Step 2 cannot be gated on step 1.
- No rollup reporting on a parent ticket. The parent does not know "3 of 7 deliverables done, 2 overdue".
- No multi-step approval chains, sequential or parallel, out of the box.
- No kanban board. Views are lists.
- No recurring tickets. Audits, renewals, and check-ins have to be re-created by hand.
- No calendar of upcoming ticket milestones.
- Closed tickets cannot be re-opened or edited, which breaks long-horizon project records.
Tasks and subtickets: the whole project model in two objects
A project is a directed graph of work with owners, deadlines, and a completion criterion. In Zendesk, two primitives express almost every real project: the atomic task (a checklist item on the parent ticket) and the subticket (a full, independently routable ticket linked to that parent). The discipline is knowing when each is the right upgrade.
A task is enough when…
- The work is atomic to the current owner.
- It completes in one sitting.
- It needs no separate conversation with anyone else.
- A checkbox and a timestamp are the right amount of metadata.
Promote to a subticket when any of these appear…
- It needs its own SLA clock.
- The assignee is in a different group or has different permissions.
- It needs a different form, or different custom fields.
- It requires a distinct conversation, often with a different party (engineering, a vendor, the customer's procurement contact).
"This will take a while" is not a reason to promote. Duration alone is not a signal. If none of the four conditions ever appear, keep it as a task. If a project's parent ever exceeds about 7 to 12 subtickets, group them into phases rather than listing flat: every subticket costs a notification, a status, and a place for work to get stuck.
Why not just use side conversations, tags, or a separate Kanban?
- Internal notes and side conversations work for ad-hoc coordination but cannot be reported on, cannot carry SLAs, and never block solve.
- Zendesk side conversation child tickets create real tickets but cannot auto-create on triggers, cannot be created by light agents, and cannot map parent fields into specific templates.
- Tags plus views rot fast. Tags do not enforce ordering, cannot carry owners or dates, and multiplying tags to model phases is a well-known anti-pattern.
- A separate Kanban in Trello or Jira breaks the most important property: the customer thread, CSAT, attachments, and help-centre history stay in Zendesk while status lives elsewhere. You now have two sources of truth.
- Native problem and incident linking is purpose-built for many-incidents-one-cause and is great at that. It cannot express "one ticket with ten deliverables".
Four ways to manage projects in or around Zendesk
There are broadly four postures teams take. Each has a legitimate reason to exist. The mistake is picking the wrong one for the shape of your work.
| Criterion | Vanilla Zendesk | Zendesk + SweetHawk | Zendesk + external PM tool | Project work only in the PM tool |
|---|---|---|---|---|
| Where work lives | One tool, one ticket | One tool, with parent / subticket / task structure | Two tools, synced best-effort | PM tool only; customer context is lost |
| Licensing | Zendesk agent seat; light agents free | Zendesk seat + app fee per agent; light agents can contribute to subtickets | Zendesk seat + PM tool seat, often for the same people | PM tool seat only; support ops still need Zendesk elsewhere |
| Customer context | Fully present | Fully present on parent and subtickets | Partial; copied once at integration time, can drift | Absent |
| Reporting | Explore, custom parent-ID builds | Explore plus app-specific fields (total, complete, remaining, phase) | Two dashboards; unifying needs a BI layer | PM reporting only; no SLA or CSAT story |
| Time to implement | Days | Days to a few weeks | Weeks to months (field mapping, permissions) | Months (rebuild intake and support) |
| Cross-team friction | High | Low; subtickets route to groups, light agents collaborate free | Medium; context lives in two heads | High; support requests never cleanly reach the PM tool |
| Best for | Simple linear work, few handoffs | Request-driven, customer-context-bound, multi-team projects | Engineering-heavy escalations; projects that need Jira-style sprints | Pure internal project work with no customer signal |
Project shapes that thrive inside Zendesk
Every one of these starts from a request, carries a customer or employee name, and benefits from being inside the same tool as the rest of the conversation.
Client onboarding & implementation
Parent ticket is the implementation. Subtickets cover kickoff, SSO setup, data import, training, go-live. Auto-applied on form = Onboarding.
Employee onboarding
New hire spawns subtickets to IT (laptop, SSO, accounts), HR (contract, benefits), facilities (desk, pass), manager (90-day plan). Light agents in each team contribute free.
Employee offboarding
Parallel checklist of account revokes, hardware return, knowledge transfer, final payroll, exit interview. SLAs enforce same-day revoke for compliance.
ITSM change management
RFC moves through Requested, CAB review, Approved, Scheduled, Implemented, PIR. Approve runs the CAB vote. Calendar shows the change window. A lean alternative to ServiceNow or BMC.
Incident to problem remediation
Native incident-to-problem link aggregates the blast radius. A task list on the problem drives root cause, hotfix, comms, post-mortem. Resolving the problem notifies every affected customer in one action.
Product escalations to engineering
Customer ticket stays in Zendesk. Subtickets route to engineering or a linked Jira issue via the official integration. The agent closes the loop with the customer when the fix ships.
Professional services delivery
Each engagement is a parent ticket with phases: Discover, Build, Test, Go-live, Hypercare. Timers track burndown against fixed-fee delivery; Time Tracking logs billable seconds.
Facilities projects
Office move or fit-out as a parent, subtickets per vendor and per inspection. Recurring Tickets regenerates weekly walkthroughs.
Request intake & campaign delivery
Ticket form captures brief. Subtickets split copy, design, dev, review, publish. Kanban shows the pipeline by phase.
Contract & legal review
Form captures counterparty, value, jurisdiction. Approve runs a sequential sign-off chain through Legal, Finance, Exec. The closed ticket is the audit record.
Procurement & vendor onboarding
Subtickets for security review, financial diligence, MSA signature, provisioning. Recurring Tickets schedules annual vendor re-reviews automatically.
Quality, audits, compliance checks
Recurring Tickets spins up quarterly SOC2 evidence collection with the checklist pre-attached and subtickets routed to evidence owners.
Renewal & QBR cadence
Every renewal becomes a templated parent ticket 60 days out. Subtickets gather usage report, success plan, commercial proposal.
Event planning
Parent = event. Subtickets = venue, catering, speakers, registration, comms, run-of-show. Calendar syncs to Google or Office 365 for company-wide visibility.
Product launches
Parent = Launch vX. Subtickets own docs, support enablement, sales enablement, CS comms. Approvals gate go-live.
Security incidents & DSAR
Structured intake, time-bound SLAs, subtickets to legal, security, engineering, comms. Full evidence trail for regulators lives in one tool.
Recruiting & applicant tracking
Each candidate is a ticket moving across Applied, Phone Screen, Onsite, Offer, Hired. Kanban makes stage bottlenecks obvious; cycle time per stage becomes a hiring KPI.
Tier escalation pipeline
Cards move across Tier 1, Tier 2, Engineering, Resolved. A board surfaces where handoffs stall in a way a list cannot.
Add a Kanban board when flow matters
Zendesk views are lists. For most work, that's fine. When stage-based flow, WIP visibility, and cycle-time-per-stage are the point of the job, a board earns its place. Here is how to decide, and how to build one that does not drift.
When a board beats a list
Strong fits
- Professional services delivery (Discover, Build, Test, Go-live, Hypercare).
- ITSM change management (Requested, CAB Review, Approved, Scheduled, Implemented, PIR).
- Marketing campaign intake (Brief, Design, Review, Scheduled, Live).
- Recruiting and applicant tracking.
- Support tier escalation, sales-to-onboarding handoff.
Weaker fits (a filtered list is just as useful)
- Priority-sorted triage and bug intake.
- Low-cadence facilities or procurement work.
- Checklist-shaped work (tasks on a parent ticket already does this).
The test: if you cannot remember what was "In Review" yesterday without scrolling, you need a board.
Three rules for Kanban on Zendesk
Two paths to a Zendesk Kanban board
Keep the board inside Zendesk
The ticket is the card. Drag-and-drop updates the underlying field. Unified reporting, no sync layer to maintain.
- SweetHawk Kanban: unlimited boards, WIP limits, cards without tickets, works with Tasks & Subtickets.
- Kanban Pro by GrowthDot: converts any saved view into a board; handles sales and support workflows in one tool.
- Kabana (open source): zero-cost starting point; one board per group, no vendor lock-in.
Best when Zendesk is the system of record and the board is the primary workflow UI.
Sync to an external board
Tickets link or mirror to a board in the other tool. Right when the card, not the ticket, is the unit of work for that team.
- Jira (Cloud): deepest sync, real-time bidirectional field mapping. The standard for support to engineering handoff.
- Trello Power-Up: lightest and cheapest, attachment-style link; good when you need board context on the Trello side only.
- Monday, ClickUp, Linear, Asana: varying sync fidelity; Monday and ClickUp are closest to two-way.
Best when engineering, product, or creative teams already work elsewhere and Zendesk is one input of many.
Twelve patterns practitioners actually use
Collected from a decade of watching 1,000+ SweetHawk customers run projects in Zendesk, plus Zendesk's own community guidance. Adopt as a baseline; deviate when you need to.
project=true tag. Columns for Phase, Open Subtickets, Days Since Update. This is the PM's single pane.What goes wrong, and when to graduate
An honest section. Not every project belongs in Zendesk. And even projects that do get wrecked by a handful of repeated mistakes.
Patterns that quietly wreck a project
- Tag sprawl in place of a custom field. Phases become
phase_discovery,phase_build… A drop-down field is the right structure. - Hijacking ticket status to model stage. Pending and On-hold are SLA-bearing. Using them for project stage distorts your first-response and resolution numbers.
- No block on solve. Agents close parents with open children every time. Required task lists stop this at the source.
- Copy-paste recurring projects. A step gets dropped. A new requirement never reaches older copies. Use a recurring generator with a required task list.
- Pending-forever projects. Parked parents drift with no cockpit view. Report on open subtickets per parent in Explore.
- Over-promoting to subtickets. Forty subtickets per parent becomes a notification storm. Group into phases; keep most items as tasks.
- Faking Gantt with SLA due dates. Due dates do not model dependencies; treating them as a schedule misreports SLA health.
- Running two Kanban boards for the same work. A Trello board for the PM and a SweetHawk board for the agents guarantees drift. Pick one system of record; use read-only mirrors everywhere else.
When to graduate off Zendesk
If the work has any of these dominant characteristics, a dedicated PM tool will serve you better:
- Capital projects with Gantt dependencies, critical-path scheduling, and resource levelling across labour pools.
- Engineering sprints with story points, velocity, epic / story hierarchy, and backlog grooming. Jira or Linear is purpose-built.
- Creative review loops where proofing, annotation, and version control are the primary work.
- Product roadmap planning with swim lanes, quarter-aligned views, portfolio rollups.
- Multi-year matters with many-to-many links, for example M&A or complex legal matter management.
- Anything where the team lives in the board or the Gantt. "I want to work on the plan, not in tickets" is a legitimate signal to move.
The test: if you remove the customer conversation and the request-first shape, does the project still make sense in Zendesk? If not, graduate.
How to run projects in Zendesk with SweetHawk
Everything above distilled into the five moves you actually make. Each one is a few clicks inside Zendesk Admin, not a project of its own.
What teams are running this way in production
SweetHawk has 1,000+ customers using the Tasks & Subtickets app. A few of their public results:
Numbers from SweetHawk's published customer case studies. Click through for the full story.
Common questions
Can I really run projects in Zendesk without a separate PM tool?
What about Jira, Asana, Monday, or ClickUp?
How are SweetHawk subtickets different from Zendesk's native side conversation child tickets?
Can light agents contribute to projects?
How do I report on project progress?
What about recurring projects like audits or renewals?
Do I need a Kanban board? Zendesk does not ship one.
How long does this take to roll out?
Find out more about these apps
Add tasks to tickets, break work into linked subtickets, and track progress as each task is completed.
Add approval requests to tickets with multi-step workflows, Slack and email approvals, dynamic approvers, and full audit trails.
Schedule and manage events directly from tickets with two-way sync to Google and Microsoft calendars.
Visualize tickets on Kanban boards, move cards between workflow stages, and update tickets instantly.
Automatically create tickets on a recurring schedule with customizable timing, templates, and ticket fields.
Down-to-the-second timers to track any period on a ticket, for SLAs, OLAs, workflows and deadlines.
Teams running this in Zendesk right now
Real quotes from customers using SweetHawk apps for this exact workflow.
Task management was a big one, like using the platform to add business processes to a particular incoming support request. SweetHawk's ability to add tasks and subtasks was crucial for us.
Without SweetHawk apps we wouldn't have all of our processes that we have built around the apps.
The Tasks + Approve combination replaced multiple tools for us; it's a much cleaner solution.