Internal operations
An internal IT help desk
Employees raise a ticket for an IT problem, it is routed to the right team by category, and they can see its status. Tickets breach a response target after a set time and appear on a manager's dashboard. Common problems link to a written answer instead.
Automatically generated draft
Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.
Section 01 · What has to work
Employees must be able to raise an IT ticket and instantly see it reach the correct team queue without manual triage.
Section 03 · Screens
Every screen, and what it is for.
- ›Dashboard — Employee views personal ticket statuses; list load must be instant.
- ›New Ticket Form — Employee submits IT issue details; form submission must be instant.
- ›Queue Manager — IT agent views routed category tickets; column sorting must be instant.
- ›Ticket Detail — Agent updates status and links knowledge base; save action must be instant.
- ›Manager Dashboard — Supervisor views breached response SLA items; metric cards must be instant.
Anything not on this list is not in version one. That is what keeps a fixed price fixed.
Section 04 · The data model
What it stores, and who can read a row.
ticket
id uuid, employee_id uuid, category_id uuid, status enum(submitted, routed, breached, resolved), description text, created_at timestamptz
Access · Employee reads own rows; IT agents read category rows; managers read all.
category
id uuid, name text, default_team_id uuid, response_sla_minutes int, active boolean
Access · All authenticated employees can read active categories.
knowledge_article
id uuid, category_id uuid, title text, body text, published boolean
Access · All authenticated employees can read published articles.
audit_log
id uuid, ticket_id uuid, actor_id uuid, event_type text, created_at timestamptz
Access · Managers and assigned agents can read ticket logs.
Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.
Section 05 · States
submitted → routed → breached | resolved
Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.
Section 06 · Where this breaks
What bites products like this one.
Background jobs calculating SLA breaches fail silently, leaving tickets off the manager dashboard.
Database triggers evaluate breach status on row read, removing reliance on cron workers.
Employees submit duplicate tickets for identical issues during outages, overwhelming queues.
Force inline search of knowledge base articles before the submit button unlocks.
Section 08 · Deliberately left out
What version one does not do.
- ×Automated ticket routing via machine learning classification — Rules-based category selection covers v1 at zero model maintenance cost; add ML at v2.
- ×Real-time WebSocket chat threads on tickets — Polling state changes every thirty seconds suffices for v1, avoiding persistent connection overhead.
This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.
Still open
What we would ask before quoting.
- What exact duration in minutes constitutes a breached response target per category?
- Should agents be able to manually override the category-based routing after submission?
Your product, not this one
Get this written for what you are actually building.
Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.
Next step
Find out if your idea fits in 10 working days.
Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.