Tickets

Every organization that works with customers or on more complex projects needs a place where every suggestion, task, and error report is recorded — and where it will be visible who is handling it, what stage it is in, and how it was ultimately closed. The /issue module is a full-fledged issue tracker that fulfills this role: it records incoming tickets (whether from an internal team or from contact forms on the website), assigns them to responsible persons, monitors progress, and — a key difference from traditional trackers — automatically processes routine inquiries using AI. The AI workflow can classify spam, suggest answers to recurring questions, and recommend who to assign the ticket to. The support team, project managers, and technical resolvers thus gain a unified environment where every initiative is captured and nothing falls through the cracks.

Ticket Overview

The main table displays a list of all tickets belonging to the current organization that are not marked as spam. The default order is optimized for an operator inbox: active work first (tickets in New and In Progress, grouped together), then tickets Waiting for an external response, and finally Done at the very bottom. Within each of those buckets the list is further sorted by priority (highest first), then by issue type (incidents and bugs float above questions and feature requests), and finally by last activity so freshly touched tickets rise to the top. The result is that the tickets an operator can act on this morning are always at the top of the page — nothing important is buried by low-priority "done" chatter. In the top bar, there is full-text search across all columns for quick retrieval of a specific case. Each row indicates:

• Ticket Key — an internal identifier in the format PROJ-123 (project abbreviation and sequence number), which is permanent and used in communication.
• Subject — a concise name describing the essence of the ticket.
• Priority — a colored label ranging from 1 to 5, indicating urgency.
• Status — the current processing phase.
• Assignee — the person currently responsible for progress.
• Reporter — the person who created the ticket.
• Creation Date — the moment the ticket was created.
• Last Update — when the last change was made.

The list automatically refreshes every 15 seconds.

ℹ️ The default order is smart — active work at the top, waiting tickets in the middle, done at the bottom. If you need a different order (e.g. sort by creation date or by priority alone) click any column header.

Classification: types, priorities and statuses

Every ticket carries three independent labels — an issue type (what kind of work it is), a priority (how urgent it is), and a status (where in the flow it sits). The system uses ten issue types (Story, Task, Bug, Incident, Question, Feature request and a few others), five priority levels (Low, Normal, High, Critical, Blocker), and four status categories (New, In progress, Waiting, Done). New tickets default to Normal priority and Story type so intake is never blocked on a required field.

Every project-specific status label (for example "For analysis", "In testing", "Ready for deployment") maps to one of the four system categories. Automations, statistics and the default inbox order look only at the category — the specific label helps the team orient itself but does not change platform behaviour. When the reporter replies to a Waiting ticket, it auto-reopens to In progress; a substantive reply on a Done ticket does the same, while a short thank-you keeps the closed state. Customer-facing comment e-mails surface the priority only when it is Critical or Blocker.

See Ticket classification model for the full definitions of every label, the signals used by the AI classifier, and the rules driving the smart inbox order.

ℹ️ Transitions between statuses are performed using a switch in the ticket detail. Allowed transitions are determined by the project workflow — not every status is accessible from everywhere, which prevents skipping steps.

Assignment

Each ticket has two participants with distinct roles. Reporter is the person who created the ticket — typically a customer for external inquiries or a colleague for internal tasks. The reporter remains permanently on the ticket, even if they have moved to another department in the meantime, as they are the source of the issue and the recipient of the final response. Assignee, on the other hand, is the person currently responsible for progress and can be changed at any time — handing over a ticket between colleagues is a common part of the workflow, and previous assignments remain visible in the activity history. If no one is assigned, the ticket awaits triage. Such tickets are visually distinguishable in the filter, so the team knows what needs to be distributed.

💡 The reporter is typically an external contact (customer), while the assignee is always an internal team member. In the detail view, both roles are displayed side-by-side with clear labeling to avoid confusion in communication.

Creating a New Ticket

The Add button opens a form with a mandatory subject and an optional description (supporting formatting — bold text, bullet points, links). You can pre-fill the reporter and assignee, enter a parent key to create a sub-task, and insert internal notes visible only to the team. After submission, the system assigns a key within the project (e.g., PROJ-124) and initiates an AI workflow (see below), which can enrich the ticket proposal with classification, a suggested response, or a recommended resolver.

Ticket Detail

Clicking on a row opens the detail view with complete context. At the top is the ticket description in HTML format, which the reporter wrote, and below it are internal notes for the team — these are never seen by the customer and serve for internal communication within the organization. To the right are details (project, priority, reporter, assignee, parent ticket, deadline, activity), a status switcher for one-click phase change, any links to testing environments or documentation, and a comments section, which forms a chronological discussion among participants. For sub-tasks, a link to the parent ticket is also displayed, making it easy to navigate between the main task and its sub-tasks. When a comment is added, an email notification is sent to relevant parties — the reporter and the assignee — so no one waits unnecessarily long for missing information.

ℹ️ The comment author is automatically determined from the logged-in identity. If a user does not have their own profile (e.g., a technical account), the system uses the ticket reporter as the author to ensure attribution does not fail.

Deadline

A completion deadline can be set for a ticket, which is displayed in the detail view next to other metadata and is included in statistics for uncompleted tasks. For an approaching or overdue deadline, the deadline is visually highlighted to ensure it doesn't go unnoticed. It serves for capacity planning and for monitoring commitments to customers — "we promise a reply by Friday" can thus be retrospectively checked and evaluated in aggregate.

⚠️ An overdue deadline does not automatically change the ticket status — the resolver must close the ticket themselves. The system only provides a warning so that the delayed ticket is not forgotten.

SPAM Filter

Tickets originating from website contact forms are sometimes generated by bots or spammers, and it would be a problem if they overwhelmed the team. The system therefore automatically classifies new tickets, and if it identifies them as spam, it hides them from the main overview. Any ticket can be manually marked as spam from the context menu, and similarly, the tag can be removed — it will then be moved back to the normal list. Spam tickets remain stored in the system (they are not deleted) and can be viewed using a separate toggle in the top bar. The context menu on each row and in the detail view offers three key actions for routine work:

• Report SPAM — marks the ticket as spam and hides it from the overview.
• Unmark SPAM — unmarks the ticket and returns it to the regular list.
• Run AI workflow — manually initiates AI processing if automatic processing was insufficient.

💡 The SPAM filter protects the team from being overwhelmed by automatically generated messages. If you need to view the list of spam tickets, a separate toggle in the top bar serves this purpose.

AI Workflow

For each ticket, the system automatically runs a set of AI steps that handle the routine part of triage. First, SPAM classification occurs, which evaluates whether the issue is genuine. Then, atomic analysis assesses whether the ticket contains a single request or is a combination of multiple items — in the latter case, it suggests splitting it into separate tickets. For simple, recurring inquiries, AI prepares a quick response in the form of a suggestion that the resolver can simply review and send. Routing, based on content, recommends which team or specific person the ticket should be assigned to. Finally, the system sends an email notification to the reporter and assignee, so they know the ticket has started processing. The AI workflow starts automatically immediately after each new ticket is created and can also be run manually from the context menu — typically if the ticket has changed in the meantime and you want the AI to re-evaluate its content.

ℹ️ AI processing occurs in the background. The result will appear with a short delay — the ticket may change its SPAM classification, have a suggested response added, or a recommended resolver changed. The process is transparent and remains recorded in the activity history. ⚠️ In some organizations, AI processing is forbidden (in "disable experiments" mode). In such a case, only SPAM classification and email notification will occur — other AI steps are skipped, and triage remains entirely in the hands of the team.

Statistics and Filtering

Above the table, there can be summary counts by status categories — how many tickets are new, in progress, waiting for input, and done, plus the total number of open and SPAM tickets. Statistics serve for the team's morning overview: they show how much work is in the system and how much is waiting for an external response. Filtering then allows the list to be narrowed down by project, status category, assigned resolver (typically "my tickets"), reporter, or SPAM flag.

💡 For efficient work with tickets, we recommend adhering to a consistent convention in subjects (for example, "[Module] Brief Description"). This way, the team can easily navigate even hundreds of tickets and quickly find what they are looking for.