tickets
sidebar_position: 37 title: "Tickets" description: "Help desk and issue tracking with lifecycle state machine, SLA tracking, priority management, and internal/public commenting."
Tickets
The Tickets module is ProBeya's built-in help desk and issue tracker. It provides a structured workflow for reporting, triaging, assigning, and resolving operational issues — keeping them in the same platform as your boards, KPIs, and action items rather than in a separate tool.
Every ticket carries an auto-generated number, a typed priority, a full lifecycle state machine, SLA response tracking, and threaded commenting with separate public and internal visibility.
Overview
Operational teams encounter issues that are not action items or Kaizen ideas: equipment failures, quality deviations, IT requests, facility problems, regulatory observations. These need a dedicated workflow with priority, assignment, SLA awareness, and audit history. Handling them in email threads or chat channels loses traceability and makes it impossible to measure response performance.
The Tickets module solves this by bringing issue management directly into the ProBeya workspace, where it can link to the boards, actions, and people already present.
Getting Started
- Navigate to the Tickets tab within your project.
- Click New Ticket.
- Fill in the subject, type, priority, source, and description.
- Optionally assign the ticket to a team member and set a due date.
- The ticket is created in New status with an auto-generated sequential number.
- Move the ticket through the lifecycle as work progresses.
- Add comments to communicate with stakeholders — marking sensitive notes as Internal to keep them visible to your team only.
Key Concepts
Ticket number — A sequential integer unique within the organization (e.g., #42). Provides a stable human-readable reference for email subject lines and verbal communication.
Type — The category of issue (e.g., incident, request, bug, improvement). You define the taxonomy that fits your team.
Priority — Urgency level used for triage ordering. Drives sorting and filtering in the ticket list.
Source — Where the issue originated (email, walk-in, monitoring alert, system event). Helps identify the most common entry points.
Assignee / Reporter — The assignee is responsible for resolution; the reporter submitted the issue. Both are tracked for accountability.
SLA first response — The timestamp of the first non-internal comment from staff, captured automatically. Used to measure response-time compliance against internal targets.
Internal comment — A comment visible only to the support team, not to the broader organization. Use for triage notes, escalation discussions, and workaround coordination.
How It Works
Lifecycle State Machine
Tickets follow a strict state machine. Invalid transitions are rejected with a descriptive error message, preventing accidental status changes.
| From Status | Valid Next Statuses |
|---|---|
| New | Open, In Progress, Closed |
| Open | In Progress, Waiting, Resolved, Closed |
| In Progress | Waiting, Resolved, Open |
| Waiting | In Progress, Resolved, Open |
| Resolved | Closed, Open (reopen) |
| Closed | Open (reopen only) |
The typical flow is New → Open → In Progress → Resolved → Closed. The Waiting state signals that the assignee is blocked, waiting for information or a third party. Closed tickets can be reopened if the issue recurs.
When a ticket transitions to Resolved, the resolvedAt timestamp is set automatically. When it transitions to Closed, closedAt is set. These timestamps enable resolution-time analytics without requiring manual data entry.
Ticket Properties
| Field | Description |
|---|---|
| Subject | Short summary of the issue |
| Description | Full detail of the problem, steps to reproduce, or context |
| Type | Classification (incident, request, bug, improvement, etc.) |
| Priority | Urgency level for triage ordering |
| Source | Where the ticket originated |
| Assignee | Person responsible for resolution |
| Reporter | Person who submitted the issue |
| Tags | Flexible labels for filtering and grouping |
| Due Date | Target resolution date |
| Board Link | Optional link to the project board for context |
| Action Link | Optional link to a related action item |
SLA Response Tracking
The first time a staff member adds a non-internal comment to a ticket, ProBeya automatically records the firstRespondedAt timestamp in the SLA metadata. This happens without any manual step, providing an objective, audit-ready measure of initial response time against your internal SLA targets.
Search and Filtering
The ticket list supports filtering by status, type, priority, assignee, board, and linked action simultaneously. Free-text search matches against both subject and description using case-insensitive pattern matching. Results can be sorted by creation date, update date, ticket number, priority, or due date in either direction.
Statistics Dashboard
The statistics view provides organization-wide counts grouped by status, type, and priority. Use this to spot backlogs (too many tickets in "Waiting"), identify the most common issue types, and track queue health over time.
Configuration
Tickets are scoped to the organization. Auto-generated ticket numbers are unique per organization. Tickets can optionally be linked to a specific board or action item for additional context. No per-project configuration is required — the module is available organization-wide.
Permissions
| Action | Required Role |
|---|---|
| View tickets and stats | Any organization member |
| Create a ticket | Any organization member |
| Add public comments | Any organization member |
| Add internal comments | Support team member or admin |
| Update / assign | Ticket assignee, creator, or admin |
| Delete a ticket | Organization admin |
All create, update, and delete operations are logged to the audit trail with actor identity and a list of changed fields.
Tips & Best Practices
Establish a clear, agreed set of ticket types before your team starts using the module — "incident", "service_request", "quality_deviation", "access_request" for a pharma site, for example. Consistent typing enables meaningful analytics and helps the queue avoid becoming a catch-all.
Internal comments are not visible to the broader organization — they are the place for the support team to debate root cause, share workarounds, and coordinate with external vendors without cluttering the public comment thread that stakeholders read.
When a ticket requires follow-up work beyond the immediate fix, create an action item and link it to the ticket. This creates a traceable chain: issue reported → immediate resolution → systemic corrective action, all visible in one place.
Resolved means the fix has been applied and is pending verification. Closed means the issue is confirmed resolved and no further action is needed. Collapsing the two statuses makes it impossible to distinguish "we think we fixed it" from "we verified the fix held."
Related Features
- Action Log — link tickets to action items for follow-up corrective work
- KPI Boards — track ticket resolution rates and SLA compliance as board KPIs
- Escalation — escalate unresolved or overdue tickets through the TIER hierarchy
- TIER Meetings — review the open ticket queue during daily stand-ups
- Problem Solving — for systemic issues that require structured root cause analysis beyond a ticket