Ticket Management
Tickets are the main work record in SupportHub. A ticket is one customer or internal problem that must be owned, routed, answered, tracked against SLA, and eventually resolved.
Plain meaning: A ticket is like a job card. It says who needs help, what the problem is, who owns the work, how urgent it is, what promises apply, and what was done before closure.
SupportHub vs TicketPro: TicketPro is centered on this ticket layer. SupportHub keeps ticket management as the source-of-truth support record and adds CX entry points around it, including live chat conversion, Customer 360 case creation, automation workflows, customer health, feedback, status, and developer APIs.
Where Tickets Come From
- Internal tickets: staff create tickets from
/tickets/create. Example: an agent logs a phone complaint for a customer. - Public support: a visitor submits the public form at
/support. Example: a customer reports a login issue without logging in. - Requester portal: an authenticated requester creates a ticket from
/portal/tickets/create. Example: a company user opens a payroll support request. - Live chat: a visitor conversation can become a native SupportHub ticket while preserving the chat transcript and visitor link.
- Customer 360: a support or success user can create a follow-up case from the customer profile workspace.
- Email mailbox: an inbound mail parser posts to
/api/v1/mailboxes/{mailboxKey}/inbound. Example: an email sent tosupport@example.combecomes a ticket. - API: external systems create tickets through
/api/v1/ticketsor requester intake through/api/v1/tickets/requester-intake. Example: a monitoring system opens an outage ticket.
Create Ticket Fields
These are the fields on the internal create ticket screen. Required means the app will not save the ticket until the field is filled.
| Field | Required? | What It Means | Example |
|---|---|---|---|
| Subject | Yes | A short title for the problem. It should be clear enough to recognize in the queue. | Cannot access payroll dashboard |
| Description | Yes | The full story of what happened, what the customer tried, and what result they saw. | User gets "403 forbidden" after login. |
| Department | Yes | The team responsible for the work. This controls routing, filters, reports, and SLA matching. | Technical Support or Billing |
| Organization | No | The customer account the ticket belongs to. Use it when the ticket should follow that account's contract, support team, portal members, approvals, and routing rules. | Acme Pvt Ltd |
| Category | Yes | The type of issue. Categories help suggestions, reports, custom fields, FAQ matches, and automation rules. | Access Issue, Bug Report |
| Assigned Agent | No | The staff member currently responsible for the next action. Leave blank when routing should decide later. | Ayesha Khan |
| Preferred Language | No | The language the requester prefers for updates. This is a short text value. | en, ur, ar |
| Product Area | No | The product, module, or service area affected by the issue. | Payroll Suite, Mobile App |
| Routing Skills | No | Comma-separated skills needed to solve the ticket. The app normalizes these into a list and can use them for smarter assignment. | sql, payroll, api |
| Priority | Yes | How urgent or important the ticket is. Priority affects queue order, SLA policy matching, escalations, and reports. | High for a blocked payroll run |
| Status | Yes | The workflow stage of the ticket. New tickets usually start as Open, New, or similar depending on your setup. | Open |
| Linked Context Type | No | The kind of related record you want to connect to this ticket. This can be an order, asset, employee, organization, requester, user, or department record if those context providers exist. | Organization |
| Linked Context Record | No | The exact record inside the chosen context type. The app validates that the record matches the selected type. | Acme Pvt Ltd |
| Sensitive Case Flags | No | Marks a ticket as sensitive so leads or managers know it needs extra care. Available flags include HR, Finance, Legal, Executive, Harassment, Payroll, Termination, and Compliance. | Payroll plus Finance |
| Manual Tags | No | Labels added by staff. Manual tags stay beside automatic keyword tags. | vip, needs-evidence |
| Issue Group | No | Links the ticket to a known recurring problem or incident group. | May login outage |
| Custom Fields | Depends | Extra fields configured in Ticket Setup. Required custom fields must be completed when they match the department/category. | Affected Employee ID: EMP-1042 |
| Attachments | No | Files that support the ticket. The validation accepts common images, documents, spreadsheets, archives, videos, and audio files up to 50 MB each. | Screenshot, invoice PDF, call recording |
Create Ticket Example
| Field | Sample Value | Why This Is Good |
|---|---|---|
| Subject | Payroll export fails for March salaries | Short but specific. |
| Description | Customer clicks Export Payroll, waits 20 seconds, then receives error 500. Happened for March only. | Explains action, result, and scope. |
| Department | Technical Support | The issue needs a technical agent. |
| Organization | Acme Pvt Ltd | Contract, approval, and account team rules can apply. |
| Category | Bug Report | Fits reporting and suggestion logic. |
| Priority | High | Payroll work is time-sensitive. |
| Sensitive Case Flags | Payroll, Finance | Salary data needs controlled handling. |
| Attachments | error-screenshot.png | Gives evidence for the agent. |
Assignee Insights and Smart Suggestions
| Area | What It Does | Example |
|---|---|---|
| Assignee Insights | Shows account-team recommendations and live agent metrics after you select an organization or department. | If Acme has a dedicated lead, the panel helps you choose that lead or a suitable team member. |
| Smart Suggestions | Uses subject and description text to suggest category, priority, FAQ articles, reply templates, and similar resolved tickets. | Typing password reset link expired can suggest the Access category and a password reset FAQ. |
Queue and Saved Views
/tickets is the working list for support staff. Filters help users find the right tickets quickly.
| Filter or Button | What It Does | Example Use |
|---|---|---|
| Search | Searches ticket number, subject, requester, or description. | Type SH-1005 or login error. |
| Current Queue | Shows which queue preset is active. | All tickets, Lead Inbox, My Approvals. |
| Status | Shows tickets in one workflow stage. | Only Open tickets. |
| Priority | Shows tickets at one urgency level. | Only High priority tickets. |
| Department | Shows tickets owned by one team. | Only Billing tickets. |
| Assignee | Shows tickets assigned to one agent. | All tickets assigned to Bilal. |
| Category | Shows one type of work. | Only Bug Report tickets. |
| Organization | Shows one customer account's tickets. | All tickets for Acme Pvt Ltd. |
| Created By | Shows tickets created by a selected staff member. | Tickets created by the call center agent. |
| Issue Group | Shows tickets linked to one recurring problem or incident. | All tickets in the May login outage group. |
| Response SLA | Filters by first-response SLA state. | Show tickets where response SLA is overdue or warning. |
| Resolution SLA | Filters by resolution SLA state. | Show tickets close to breach. |
| Tag | Shows tickets with one manual or automatic tag. | vip or needs-evidence. |
| Duplicate State | Shows only tickets flagged as duplicates. | Find repeated reports of the same issue. |
| Context Type and Context Record | Finds tickets linked to a specific context record. | All tickets linked to one organization, requester, or department record. |
| Saved Views | Saves a filter combination with a name. A saved view can also be marked as default. | My High Priority Billing Tickets. |
| Reset | Clears the current filters and returns to the normal list. | Use when the list looks empty because filters are too narrow. |
Queue Presets
Lead Queue Presets
- Lead Inbox: tickets waiting for the organization lead.
- My Teams: tickets assigned inside teams led by the current user.
- Returned To Me: tickets sent back to the lead.
- Urgent Lead Review: important cases needing lead attention.
- My Approvals: public replies, evidence, or closure items waiting for the lead.
- Morning Review: tickets useful for a daily lead check.
- Enterprise At Risk: enterprise account tickets with risk signals.
- Payroll Sensitive: payroll-sensitive tickets.
- Closure Due Today: closure review work due today.
Workflow Queue Presets
- Team Inbox: shared team work that can be claimed.
- Claimed By Me: shared inbox tickets the current user has claimed.
- Closure Review: tickets waiting for close approval.
- Overdue Approvals: approval requests past the expected time.
- Escalated Review: tickets escalated above normal handling.
- Sensitive: tickets with sensitive flags.
- Inactive Cases: tickets with no recent movement.
Bulk Actions
Bulk actions update many selected tickets at once. They require the use ticket bulk actions permission.
| Field | What It Means | Example |
|---|---|---|
| Selected Tickets | The tickets that will be changed. At least one ticket must be selected. | Select 5 open Billing tickets. |
| Action | The type of change: assign, status, priority, or department. | priority |
| Assigned User | Required only when action is assign. | Assign all selected tickets to Sana. |
| Status | Required only when action is status. Closed status is blocked from queue bulk action; use the closure flow instead. | Move selected tickets to Waiting On Customer. |
| Priority | Required only when action is priority. | Change selected tickets to High. |
| Department | Required only when action is department. | Move selected tickets to Technical Support. |
Ticket Detail
The ticket detail page is where agents do the real work. It supports metadata updates, replies, internal notes, attachments, subtasks, watchers, time entries, status changes, dossier export, collaboration drafts, mentions, playbook steps, video consultation approvals, same-app rooms, consultation recordings, Case Files, and closed-ticket edit approvals.
Finalized Ticket Lock
Resolved, closed, and completed tickets are finalized records. Without an active admin-approved edit window, the ticket detail page is read-only for normal edits: replies, notes, status changes, routing updates, watcher changes, subtasks, playbook actions, time entries, attachment metadata, Case Files updates, video consultation changes, recording writes, AI apply actions, and collaboration AJAX are blocked.
When a finalized ticket genuinely needs correction, a user with ticket access submits a reason from the closed-edit approval panel. An admin approves or rejects the request. Approval opens a limited edit window for that requester; after the window expires, the ticket returns to read-only behavior.
Files Tab
The Files tab shows the Case Files manager scoped to the current ticket. It combines ticket attachments and consultation recordings, shows visibility/redaction/evidence metadata, records downloads and previews, and links to the global /case-files manager for cross-ticket audits. The ticket-scoped metadata form uses the shared attachment metadata component from app/View/Components/UI/AttachmentMetadataForm.php and resources/views/components/ui/attachment-metadata-form.blade.php.
AI Copilot
The Intelligence tab includes AI draft actions when AI is enabled in Settings. Actions create editable summaries, reply drafts, classification hints, duplicate checks, sentiment/risk notes, and SLA escalation drafts. They do not post replies or change ticket data automatically.
Editable Ticket Fields
| Field | What It Does | Important Rule |
|---|---|---|
| Subject and Description | Clarify the issue after creation. | Only users with assignment authority can change core details. |
| Department, Organization, Category, Assignee | Control ownership, routing, account rules, and reporting. | Assignment permission is required for these routing fields. |
| Priority | Changes urgency and can affect SLA matching. | Requires update ticket priority. |
| Status | Moves the ticket through the workflow. | Requires update ticket status. Resolved, closed, and completed tickets are locked, and completed ticket status cannot be changed from the ticket index page. |
| Preferred Language, Product Area, Routing Skills | Add useful context for communication and assignment. | Assignment permission is required to change them after creation. |
| Linked Context Type and Record | Connects the ticket to a related app record. | The record must match the selected context type. |
| Manual Tags and Issue Group | Improve filtering, reporting, duplicate handling, and incident tracking. | Assignment permission is required to change them. |
| Watchers | Internal users who follow ticket activity. | Usually managed by users with assignment permission or by watch/unwatch actions. |
| Sensitive Case Flags | Mark special oversight needs such as legal, finance, payroll, or compliance. | Assignment permission is required to change them. |
| Custom Fields | Store extra structured details configured in Ticket Setup. | Required fields must follow the matching custom field rules. |
| Resolution Summary | Explains how the issue was fixed before resolving or closing. | Required before moving a ticket to Resolved or Closed. |
| SLA Pause Reason | Explains why SLA time is paused or waiting. | Only status-update permission can change it. |
Assignment and Ownership
- Assigned user: the agent responsible for the next normal action.
- Accountable owner: the lead-level owner responsible for enterprise routing and closure review.
- Claim owner: the person who claimed the ticket from a shared team inbox.
- Claim: take a shared team ticket for yourself.
- Unclaim: put the ticket back into the shared team inbox.
- Takeover: move ownership to yourself when allowed.
- Assign down: a lead sends work to a selected team member. Field:
team_user_id. Optional field:note. - Return to lead: an assigned team member sends the ticket back to the lead. Optional field:
note.
Replies, Notes, and Approvals
| Action | Fields | Plain Meaning | Example |
|---|---|---|---|
| Public or Internal Reply | body, is_public, attachments | A message in the conversation. Public replies are customer-facing. Internal replies are staff-only. | We have identified the export failure and are applying a fix. |
| Internal Note | body, attachments | A staff-only note that requesters should not see. | Check payroll export logs before next update. |
| Communication Approval Decision | status, note, edited_body, watermark_label | A lead approves or rejects a public reply/evidence item. The approver can optionally edit text or add a watermark label. | Approve after removing private salary data. |
| Resubmit Communication | body, note | The agent resubmits a rejected public communication after changes. | Rewrite the customer update and add a note to the lead. |
| Closure Review Request | target_status_id, resolution_summary, note, closure_qa_state | Asks the lead to approve closing the ticket when the organization requires closure review. | Request close after root cause, evidence, and public reply are done. |
| Closure Review Decision | status, note | The lead approves or rejects closure. | Reject if evidence is missing. |
| Closed Ticket Edit Request | reason | Asks an admin to open a temporary edit window on a resolved, closed, or completed ticket. | Request approval before correcting a finalized ticket typo, file flag, subtask, reply, or routing field. |
| Closed Ticket Edit Decision | status, note | An admin approves or rejects the edit window. Approval does not change the ticket by itself; it only allows the requester to edit within the time limit. | Approve a correction window after confirming the reason. |
| Video Consultation Request | audience, meeting_provider, meeting_url, title, scheduled_at, duration_minutes, agenda | Requests a team or client consultation. Same-app rooms use an internal room; external meetings require a meeting link. | Request a client screen-share after documenting the agenda. |
| Video Consultation Decision | status, meeting_provider, meeting_url, note | The lead or fallback admin approves or rejects the consultation. External approvals require a URL; internal approvals create the app room link. | Approve an in-app room for a payroll troubleshooting call. |
| Playbook Approval Decision | status, note | Approves or rejects a playbook step that needs review. | Approve a refund step after checking policy. |
Video Consultations
Video consultations are ticket-scoped sessions for team discussion or customer-facing consultation. Non-admin users request approval from the ticket detail page before a meeting link or same-app room can be used. Admin users create the consultation as approved immediately.
| Field or Control | What It Means | Important Rule |
|---|---|---|
| Audience | Choose team for internal staff sessions or client for requester/customer sessions. | Client consultations require the ticket to have a requester. |
| Meeting Type | internal creates an in-app room after approval. external uses a third-party meeting link. | The external link field is shown and enabled only when External Link is selected. |
| External Meeting Link | The URL for Zoom, Meet, Teams, or another provider. | The browser validates it before submit, and the backend validates it again before saving or approving. |
| Agenda | Short notes explaining what the session should cover. | Use it to keep approval and recording context clear. |
| Request Approval / Create Approved Session | Non-admin users send the consultation to the configured approver. Admins create an approved consultation immediately. | A ticket cannot have two pending consultations for the same audience. |
Approval Rules
- Team lead approval is required before a non-admin user's consultation can be used.
- Admin role users do not need separate approval. Their consultation is created with approved status, the approver is the admin, and the room or external link becomes usable immediately.
- The approver is selected from the organization lead, backup lead, or account manager when those users exist.
- If no organization lead path is configured, the app falls back to an active Admin. The panel shows an admin fallback notice so users know who will approve it.
- Non-admin requesters cannot approve their own consultation request. Admins may approve existing pending requests even if they originally created them.
- Approving an internal consultation creates or keeps a private room token and shows an Open in-app room link on the ticket.
- Approving an external consultation requires a meeting URL. If the user switches the dropdown away from External Link, the URL field is hidden, disabled, and cleared before submit.
Same-App Video Rooms
Same-app rooms use browser WebRTC with Laravel-backed presence and signaling routes. The room page includes Join, Mute, Camera, Record, Stop Recording, Complete, Leave, participant tiles, agenda, and a recording manager panel.
| Route Name | Purpose |
|---|---|
tickets.video-consultations.room | Opens the approved in-app room. |
tickets.video-consultations.room.presence | Updates active participant presence. |
tickets.video-consultations.room.signals.index | Polls for WebRTC offer, answer, candidate, and leave signals. |
tickets.video-consultations.room.signals.store | Stores a signaling message for another participant. |
Room access is limited to users who can access the sensitive ticket. For client consultations, the ticket requester can also enter the approved room. Camera and microphone permissions are controlled by the browser. Leave returns the user to the page that opened the conference when the previous URL is inside the same app; otherwise it returns to the source ticket.
Consultation Completion
Completing an approved consultation asks for confirmation. After confirmation, the consultation status becomes completed, the active request is removed from the Video tab, and the completed consultation remains visible in the Conversation tab with an explicit history note. This is intentional so the Video tab stays focused on active requests while the conversation remains the audit timeline.
Consultation Recordings and File Manager
Approved in-app rooms can be recorded by users with recording access. The browser composes the visible local and remote video tiles with mixed audio, then uploads the finished file to private storage when recording stops.
| Area | Behavior |
|---|---|
| Private storage | Files are saved on the local disk under ticket-video-recordings/{ticket}/{consultation}; they are not public attachments. |
| Recording manager | The ticket panel and room side panel list saved recordings with media preview, download count, recorded by, timestamp, duration, and size. |
| Download and stream | The recording route can download a file or stream media inline for playback after server-side authorization. |
| Delete | Deleting a recording removes the private file and its database row. |
| Access | Admin users, users with assignment authority, organization lead paths, accountable owners, and the consultation approver can access recordings when they can also access the sensitive ticket. |
Production note: Browser recording depends on WebRTC and MediaRecorder support. Use HTTPS in production and test long recordings against the server upload limit before enabling this for large customer calls.
Attachments and Evidence Fields
| Field | What It Means | Example |
|---|---|---|
| Visibility Scope | Who can see the file: internal, customer-visible, lead-only, or manager-only. | Use lead_only for a salary screenshot. |
| Needs Redaction | Marks that the file contains information that should be reviewed or hidden before customer sharing. | Turn on for a document containing ID numbers. |
| Redaction Status | Tracks review state: not required, pending review, approved, or rejected. | pending_review |
| Evidence Tags | Short tags that describe what the file proves. | screenshot, invoice, call-recording |
| Expires At | Date after which the evidence should no longer be used or shown. | 2026-06-30 |
| Watermark Label | Text shown on protected evidence. | Confidential - Acme Payroll |
Subtasks and Time Entries
| Area | Field | Plain Meaning | Example |
|---|---|---|---|
| Subtask | Title | Small piece of work inside the ticket. | Check export job logs |
| Subtask | Description | Extra instructions for the subtask. | Check logs for March payroll export only. |
| Subtask | Assigned User | Person responsible for the subtask. | Database engineer |
| Subtask | Depends On Subtask | Another subtask that must be done first. | Do not test fix until logs are checked. |
| Subtask | Priority | Low, normal, high, or critical. | high |
| Subtask | Status | Open, in progress, blocked, or completed. | in_progress |
| Subtask | Blocking | If on, this subtask blocks progress. | Cannot close ticket until this is done. |
| Subtask | Required For Close | If on, closure is not clean until the subtask is completed. | Require customer confirmation before close. |
| Subtask | Due At | Deadline for the subtask. | 2026-05-08 17:00 |
| Time Entry | Minutes | Work time spent. Must be 1 to 1440 minutes. | 45 |
| Time Entry | Billable | Whether the time should count for billing or contract use. | On for contract support work. |
| Time Entry | Billing Type | Billable, non-billable, overage, or shadow. | overage when contract limit is exceeded. |
| Time Entry | Hourly Rate and Cost Rate | Optional money values for billing and cost reporting. | 75.00 hourly rate. |
| Time Entry | Entry Date | Date the work happened. | 2026-05-06 |
| Time Entry | Description | Short note explaining the work. | Reviewed logs and tested export. |
Merge, Split, and Linked Cases
| Action | Fields | Plain Meaning | Example |
|---|---|---|---|
| Merge Tickets | primary_ticket_id or primary_ticket_number, plus ticket_ids | Combines duplicate tickets into one main ticket. | Merge three duplicate login outage tickets into SH-1001. |
| Split Ticket | Subject, description, optional department, category, priority, status, assignee, attachments | Creates a new ticket from part of an existing case. | Split a billing complaint from a technical support case. |
| Issue Group | Selected from the ticket form or detail page. | Groups related or recurring tickets together. | All customer reports for one outage. |
SLA State
SLA means the service promise for response and resolution. SLA policy assignment and timers are recalculated by ticket services and the tickets:check-sla scheduled command. Statuses can pause SLA timers when configured with wait reasons such as waiting on customer, waiting on vendor, or on hold.
- Response SLA: how fast the customer should receive the first meaningful response.
- Resolution SLA: how fast the issue should be solved or moved to a valid resolved state.
- Warning: the ticket is close to missing the promise.
- Breach: the promise was missed.
- Paused: the clock is stopped because the ticket is waiting for customer, vendor, or another valid reason.
Collaboration
The collaboration tools record agent presence, autosave reply/note drafts, provide mention suggestions, and clear drafts. Plain example: if two agents open the same ticket, the app can show activity and reduce the chance that one agent overwrites another agent's draft.