01 — The problem
Where request intake goes wrong today
Requests arrive by chat, hallway conversation and email to whoever helped last time. Someone copies them into a spreadsheet and forwards them. Urgent items wait behind trivial ones, and nobody knows whether a laptop swap or a broken door is overdue.
Generic ticketing system software fixes the inbox but not your routing logic, which depends on site, department, asset type and approver.
02 — What to build
Core building blocks of a ticketing workflow
Request form with category, location, affected asset, impact and urgency
Routing rules that assign tickets to a queue or person by category and site
SLA targets per priority, with a due date and an overdue flag
Approval steps for requests that cost money or change access
Status trail
new, assigned, waiting on requester, resolved, closed
Roles
requester, resolver, queue manager and approver
Queue dashboard with open tickets, breached SLAs and workload
03 — How to build it
Building the ticketing system step by step in Henosia
Open a private project as a sandbox. Nothing goes live until you publish.
Upload mock data
a CSV of past requests, your category list, sites and resolver teams.
Connect a database so tickets, queues and SLA rules are stored as structured data.
Plan in Plan mode
The agent asks about edge cases and proposes a plan. You decide when to build.
Build the first version and run sample tickets through it.
Refine with prompts
adjust routing, add an approval step, tune the dashboard.
Publish with access limited to your company domain and the right roles.
Example Plan-mode prompt:
Build an internal ticketing system for IT and facilities across three offices.
Employees submit a request with category, location and urgency.
Route tickets to a queue by category and site, and set SLA due dates by priority.
Requests for new software or building access need manager approval first.
Queue managers need a view of overdue tickets per resolver.Paste it into a private Henosia project in Plan mode. The agent asks questions and proposes a plan first.
04 — Before you go live
Rules, AI and governance before go-live
In a Henosia webinar, Danish e-commerce company 4tal described a useful split: deterministic rules for stable steps, AI for interpretation. For ticketing, SLA timers and routing should be rules, while AI can suggest a category for a vague request.
Before real requests go in, decide:
- Who owns the ticket data and the routing rules
- Read or write access for any connected system, such as an asset list or directory
- Which roles see sensitive categories like HR or security incidents
- Who approves publishing and later changes
- How each integration is scoped, per system, data direction and access level
Henosia can work with data connections and API-based data; more point-and-click connector interfaces are on its roadmap. If approvals grow complex, add a separate approval workflow.
Start a private Henosia project and plan a ticketing system your resolvers actually want to use.
Start a private project05 — FAQ
Frequently asked questions
What is an internal ticketing system?
An internal ticketing system lets employees submit requests to teams like IT, facilities, HR or operations. Each request becomes a ticket with a category, owner, priority and due date, so nothing gets lost in chat or email and managers can see workload, overdue items and recurring problems.
Do I need developers to build a ticketing system?
Not for a first version. A process owner can describe the workflow in Plan mode, review the plan and build in Henosia without writing code themselves. Involve IT for access rules, integrations with directories or asset systems, and the decision to publish.
How do SLAs work in a custom ticketing system?
You define a target response or resolution time per priority or category. The app calculates a due date when the ticket is created, flags it when it is close to or past due, and shows breaches on the queue dashboard. These are fixed rules you decide.
Who can see tickets in a Henosia-built ticketing system?
You decide. Henosia describes access tied to your company email domain, more granular app-level permissions and optional IP restriction. Within the app you define roles, so sensitive categories like HR cases are visible only to the right resolvers. Confirm details with IT before using real data.
Can one ticketing system serve IT, HR and facilities?
Yes, if each team gets its own categories, queues and visibility rules. Start with one team to prove the routing and SLA logic, then extend the same app with new prompts for the next department instead of building separate tools.