Helpdesk Ticketing Planner

The problem

You open your coding agent and say "build me a helpdesk." It produces something: a ticket list, a submit form, maybe a status page. What it does not produce is a system that holds up in real use:

• Inbound email quietly drops messages when the OAuth token rotates.
• A public portal fills with spam within 72 hours.
• SLA timers exist in the schema but are never shown to the agent who is about to miss one.
• The data export gives you a CSV with metadata only when you decide to leave.

Each of these is a documented failure in real products. People leave Zendesk and Freshdesk because prices are hard to predict and features are locked to higher plans. Missing capabilities are rarely the reason. People who self-host have trouble with email setup, spam, and screens their organization is embarrassed to show to clients. The two groups have different problems and the same need: a system that works.

What it is built from

The planner was built from an audit of 18 real help desk products: 8 open-source (Zammad, FreeScout, osTicket, UVdesk, Frappe Helpdesk, Znuny, RT, OTOBO), 6 SaaS (Zendesk, Freshdesk, Help Scout, Zoho Desk, Front, Intercom) and 4 marketplace scripts. They were checked against a 58-item feature inventory, with counts out of those 18 products.

So when the planner says collision detection appears in 10 of 18 products, and is free in three of the cheapest OSS tools but locked to higher plans at Zendesk and Freshdesk, that is a checked fact about the market. When it says SLA policies appear in all six SaaS products and seven of eight OSS tools but in zero marketplace scripts, that is the documented gap that decides where your product stands. A coding agent cannot state "found in 13/18 reviewed products, zero of four scripts" unless it repeats the same 18-product review.

The research also found patterns that shape the spec:

• Frappe Helpdesk's status-category model, where every ticket status sets the SLA timer to run, pause or stop, is the cleanest design across all 18 products.
• Zendesk closes tickets by system only, with a hard limit of 28 days. The planner treats this as a pattern to avoid.
• No product in the set ships a dedicated home screen for supervisors. Everywhere, the supervisor role is put together from views and notifications.

These are build decisions based on what the market does.

What you get

The planner runs a structured discovery in your coding agent: delivery mode, depth, roles, SLA yes/no, email intake path, knowledge-base deflection, CSAT, and your current seat count and price per seat. It then writes a complete build spec your agent can work from: a CLAUDE.md for Claude Code, an AGENTS.md for ChatGPT Codex, or the rules file your tool expects. The spec comes with a confirmed decision receipt that includes an honest ROI calculation for your own numbers.

The generated spec covers:

• A customer portal that accepts tickets from guests. The research identifies forced registration as a reason people stop using a portal.
• A modern three-pane agent workbench with canned responses, internal notes, rich-text replies, collision detection and SLA countdown chips shown in the ticket list.
• Email ingestion that forwards mail to a webhook and fetches it in a way that is safe to repeat, so a failed delivery never quietly marks mail as read.
• A setup wizard that blocks go-live until SPF/DKIM/DMARC are verified and a test message makes the full round trip.
• Spam filtering as a required default. It is not optional, because self-hosted portals without it are a documented failure.
• A full export of tickets, conversations, attachments and users. Every major existing product either leaves out attachment files, limits exports to metadata, or makes you raise a support ticket to unlock the feature.

The decision receipt is honest. Below roughly 8-16 agents on low-cost plans, self-hosting does not save money. The savings are real above about 10 agents on mid-tier plans, where SaaS cost grows with every seat and infrastructure cost stays flat.

Tested in a build-off

Four coding models built four working support desks from this planner: Claude Fable 5, Grok 4.5, GPT-5.6 Sol and Gemini 3.6 Flash. All four run as live demos you can log into from this page, and the full audited ranking is published as a PlanSmith benchmark. They were scored on what a helpdesk must get right: an internal note must never reach the customer's page, and one customer must never see another customer's ticket.

What it covers

The planner goes through 12 structured phases:

• delivery mode selection
• depth selection (Basic, Moderate, Advanced)
• role selection (Customer, Agent, Supervisor, Admin)
• SLA configuration with targets per priority and actions on breach
• email intake path selection
• knowledge-base and deflection setup
• CSAT
• channel lock (portal and email only in v1; live chat and phone are excluded in writing)
• ROI receipt, with the break-even warning written out in full
• confirmation of the visual layout (the three-pane workbench, and no generic admin dashboard)
• build execution mode (Guided Step, Batch or Autopilot)
• a forbidden-family scan before the spec is written, which keeps chat stubs, AI suggestion widgets and phone widgets out of the generated UI

The build sequence has seven steps. Step 1 produces a real working shell: agent ticket-list home, three-pane ticket detail, customer portal, admin settings hub and setup wizard. It is no placeholder. Screenshots at desktop width and at 375px are required before you are asked to test.