Working Tickets in the App

This page explains the day-to-day workflow for support agents inside the Bnder app.

Ticket list

The ticket list supports:

  • Search
  • Status filter
  • Assignee filter (guild member dropdown)
  • Label filter
  • Infinite scroll loading
  • Live updates when ticket documents change

Ticket search in this list is index-backed for fast results across title, description, and reporter fields. The toolbar keeps the search field in a dedicated top row. Secondary filters now sit behind a Filters toggle and expand with a short animation when needed, while the toggle icon also transitions between its collapsed and expanded states. Active filters still stay visible as compact summary chips. The overview no longer waits for ticket settings before the first page appears. Ticket rows render from ticket data first, while status metadata and other settings-backed labels hydrate shortly afterwards in the background.

Ticket row information

Each row shows core metadata such as:

  • Status
  • Priority
  • Type
  • Assignee
  • Reporter email
  • Labels
  • SLA warning chip (with tooltip details)
  • Age chip
  • Resolution and first-response duration chips (formatted as days/hours/minutes when needed)

The age chip updates itself over time without forcing full-list rerenders.

Project member new-ticket alerts

In Project Settings -> Members, admins can enable a per-member toggle for new-ticket alerts in that project.

When enabled:

  • Discord workspaces notify opted-in members via DM
  • Non-Discord workspaces notify opted-in members via email
  • Users are not notified for tickets they just created themselves
  • Notification text follows the workspace language setting

Ticket detail

Open a ticket row to work in detail view.

Knowledge suggestions are loaded once when opening an existing ticket and then refreshed as you edit title/description. Existing ticket detail now renders from the main ticket document first. Slower sections such as core form metadata, template fields, conversation, and activity hydrate progressively with local skeleton placeholders instead of keeping the entire page behind one loading spinner. Reopening ticket detail or ticket settings shortly afterwards also reuses one live local ticket-settings source plus a short-lived template cache, so repeat opens feel faster inside the same workspace. The ticket detail header is selectable, so you can copy the visible ticket id directly from the title line. New tickets now use the same shared incremental workspace counter as tasks, events, and documents. During the transition period, older tickets can still show legacy random ids while newer tickets show shorter numeric ids. The activity timeline starts collapsed by default and expands only when you click the activity toggle in that section. The autosave banner now shows when the last successful save happened in a live relative format such as "just now" or "5 minutes ago" instead of showing a fixed clock time. Age, first-response, and resolution chips now expose exact event timestamps in tooltips so agents can inspect the precise creation, first-response, and resolution times without leaving the summary row.

Core fields

You can manage:

  • Title, description, type, priority
  • Assignee
  • Status
  • SLA
  • Customer
  • Reporter name/email
  • Notify email list
  • Labels

When another agent owns the ticket, the assignee field also offers a small Assign to me action so you can take ownership without reopening the member dropdown.

If the workspace has virtual coworkers in the Customer Support department, the assignee dropdown also shows those coworkers. Coworkers scoped to the current project are listed first. Assigning a ticket to a virtual coworker keeps that coworker responsible until you reassign the ticket, unassign it, or the coworker decides it cannot help anymore.

The additional notification email field includes a short inline hint that added addresses receive public ticket updates by email.

For tickets created from Discord, the app no longer shows the synthetic internal fallback email in ticket detail. Instead, the reporter is shown as a read-only guild member field without interactive dropdown controls. Tickets created by mail or the public ticket form still show the normal reporter email field.

When no customer options exist in workspace settings, the customer selector is hidden in ticket detail.
When no SLA definitions exist in project settings, the SLA selector is hidden in ticket detail.

Ticket type options come from project ticket settings.
If the project has no default type configured, selecting a type is required before creating the ticket.

For existing tickets, edits autosave automatically after a short delay. The ticket header shows whether changes are currently saving, already saved, or failed to save. Other ticket-detail actions such as create, message send, attachment actions, and link validation show inline notices in the same header area instead of disappearing as temporary snackbars. All ticket-detail labels, banners, validation messages, conversation badges, and linked-resource hints follow the app language. Master-ticket relation sections, relation dialogs, and progressive loading skeleton headings in ticket detail also follow the selected app language across all supported locales. In light theme, success banners in ticket detail use a darker success color so save-state text stays readable.

When creating a ticket, required fields are marked directly in the form with * and also show inline validation on the affected inputs so agents can see what is missing before the ticket is submitted.

When another agent changes the same ticket, the detail view refreshes from live ticket document updates.

Virtual coworker support

Projects can use virtual coworkers as ticket supporters when those coworkers are already scoped to the project.

Behavior:

  • New tickets in that project trigger internal virtual coworker assessments
  • Each eligible coworker can leave an internal note saying whether it can help
  • A virtual coworker can be assigned as the ticket assignee in the app
  • When an assigned virtual coworker accepts the ticket, it sends the first public support reply to the reporter
  • Reporter replies on VC-owned tickets are routed back to the assigned coworker
  • If the coworker decides it cannot help anymore, the ticket is reassigned back to the human who assigned the coworker and that human receives the normal assignment notification
  • Virtual coworkers now also hand tickets back earlier when the reporter explicitly asks for escalation or when the conversation starts looping on repeated clarification requests without reaching a fix

Internal coworker notes stay internal only. Public thread pages never expose them to the reporter, and decline/handoff is the only assignment-time path that creates an internal note instead of a public response.

Activity timeline

The Activity section shows an immutable audit history for ticket changes.

  • Who changed something
  • When it changed
  • What changed in human-readable labels and values (for example status names instead of internal ids)
  • No-op create-time placeholders that would display as the same visible before/after value are hidden

Conversation

The conversation area supports:

  • Public messages (visible to reporter)
  • Internal comments (agent-only context)
  • Author display names for support messages
  • User mentions in replies (for example @username)
  • A visibility selector next to Send, with automatic wrapping on narrow layouts

Mentioned workspace users get a direct notification after message send:

  • Discord workspaces: mention notification via DM
  • Non-Discord workspaces: mention notification via email
  • Direct-notification settings are respected

Ticket description is separate from conversation and is not injected as the first chat message.

Linked Ressources section

Use the resource link input to connect:

  • Tasks
  • Knowledge documents

Input suggestions are shown while typing, and linked resources are added by selecting one of the shown suggestions. Each linked item is clickable, so you can open the linked task or knowledge document directly from the ticket detail. The knowledge suggestion panel is only shown when at least one suggestion is available. If workspace search is not available for the current plan, the link search area shows the Pro upsell message instead of silently returning no results.

Ticket-to-ticket workflows are handled separately through dedicated sections:

  • Child Tickets
  • Duplicates
  • Related Tickets

These relation sections now keep their full available width even when still empty, so the detail layout does not collapse and then jump wider only after the first linked ticket is added. Relation add/remove actions also reuse the normal save-status banner in the ticket header instead of opening a second separate status banner.

For incident/duplicate workflows using explicit master tickets, child rollups, and bulk actions, see Master Tickets.

You can also create a task directly from the Linked Ressources section.
The created task is linked back to the ticket automatically. The task form opens without prefilled title/description so agents can define task wording explicitly. If the ticket already has a customer or labels, those values are also prefilled in the new task draft. The Linked tickets block in the task popup still shows the pending ticket link before task creation. Only the intended ticket link is prefilled for that new task tab; unrelated task-create query state is not reused.

Create knowledge draft from closed tickets

For tickets in a closed status category (resolved or rejected), agents can use Create knowledge draft.

This AI-prefilled draft flow is available on Pro workspaces.

This opens a new document draft tab and prefills a structured base with:

  • Issue
  • Context
  • Resolution
  • Reusable Steps
  • Related Ticket

On first save, the created document is automatically linked back to the source ticket.

If the link-back update fails, the document is still saved and an inline warning is shown in the document view with a retry action.

Attachments

Agents can upload ticket attachments directly in the ticket detail view.

On desktop, the attachments area also accepts drag and drop, so agents can drop files directly onto the ticket. Dropped files are added to the attachment list immediately while the app waits for the final stored attachment metadata.

From the same section, agents can open/download or remove ticket attachments. If one of these actions fails, the error stays visible in the inline notice area near the top of the ticket until you dismiss it or continue editing.

Template fields in tickets

When a ticket has a template, visible template fields appear in the detail view.

If a field is marked not user-editable, it is shown as read-only.

Create vs edit behavior

  • New ticket: explicit Create ticket action
  • The temporary Create ticket page no longer shows its own header close button
  • Existing ticket tabs also do not show a separate header close button; closing happens through the normal tab controls
  • The temporary Create ticket tab title includes the current project name so agents can distinguish parallel create flows more easily
  • After creation, the temporary Create ticket tab is replaced by the persisted ticket tab automatically
  • Existing ticket: autosave flow (no manual save button needed for regular edits)
  • New tickets can also be created as explicit master tickets through the Create as master ticket checkbox
  • For standard existing tickets, Convert to master ticket and Attach to master ticket are available in the relation area instead of being duplicated again in the top header
  • Master-ticket linking dialogs such as Attach to master ticket, Duplicates, and Related Tickets use the same app dialog shell as other bnder dialogs, so those flows behave consistently with the rest of the interface
  • If one of those relation/master dialogs is cancelled, the action button no longer shows a fake success state afterward
  • In the Linked Ressources card, the Create task action moves below the search field on narrow widths instead of squeezing into one overflowing row

Status-driven behavior to know

  • SLA warnings depend on ticket age and SLA settings
  • Closed categories (for example resolved/rejected) are treated as terminal states
  • If a reporter sends a new public message on a resolved ticket, the ticket reopens automatically
  • If an agent sends a new public support reply, the ticket is moved to the configured waiting_on_reporter status
  • If a reporter replies while the ticket is in waiting_on_reporter, the ticket moves back to the configured in-progress status automatically
  • Waiting-on-reporter timers are only started when entering waiting state (not reset by unrelated edits while already waiting)
  • When a reporter posts a new public message, the assigned agent gets a direct notification (Discord DM in Discord workspaces, email in non-Discord workspaces)
  • When a ticket is assigned or reassigned to an agent, that assignee also gets a direct notification (Discord DM in Discord workspaces, email in non-Discord workspaces). Assigning a ticket to yourself does not create an extra notification.
  • When a virtual coworker hands a ticket back because it cannot help, the original human assigner is reassigned and receives the same normal assignment notification flow.
  • When you move a task into a done column in Kanban, and this was the last open task linked to a ticket, the app offers a confirmation to close that ticket as resolved immediately.

Discord ticket workflow

The Ticket Manager Discord bot supports ticket workflows directly in Discord.

Use the command reference below for options and required permissions:

Create a ticket

Creates a new ticket as reporter. When the project enforces required template fields, Discord modal steps are shown first. The confirmation includes a public thread link so the reporter can continue without app access.
/ticket create
title
Login issue in customer portal
description
Users get an error after submitting credentials.
project
support
type
incident
priority
high
Ticket Manager

List my tickets

Shows your most recently updated Discord-reporter tickets.
/ticket mine
Ticket Manager

List support queue

Lists tickets you can manage as support agent, sorted by latest update.
/ticket queue
Ticket Manager
Requires MANAGE_TICKETS (project scope) permissions

Show ticket details

Shows one ticket summary and a direct app link. Reporters can only access their own Discord-created tickets.
/ticket info
ticket_id
TCK-1024
Ticket Manager
Requires Reporter self-access or MANAGE_TICKETS permissions

Reply publicly to a ticket

Adds a public message to a ticket. Agents reply as support, reporters reply as reporter.
/ticket reply
ticket_id
TCK-1024
message
We deployed a fix. Please check again.
Ticket Manager
Requires Reporter self-access or MANAGE_TICKETS permissions

Update ticket status

Changes one ticket status and applies status transition logic (for example closing timestamps).
/ticket status
ticket_id
TCK-1024
status
in_progress
Ticket Manager
Requires MANAGE_TICKETS (project scope) permissions

Assign ticket owner

Assigns the ticket to one Discord user.
/ticket assign
ticket_id
TCK-1024
assignee
@SupportAgent
Ticket Manager
Requires MANAGE_TICKETS (project scope) permissions

Add internal note

Adds an internal support note that is not visible to the reporter.
/ticket note
ticket_id
TCK-1024
message
Root cause points to SSO provider latency.
Ticket Manager
Requires MANAGE_TICKETS (project scope) permissions

Reporter-side commands are available to regular users.
Agent-side commands require MANAGE_TICKETS permission in the ticket project.

If a project enforces a ticket template with required user-editable fields, /ticket create opens a modal flow in Discord so the reporter can fill those required fields before the ticket is created.

Required template fields of type file are not supported in Discord slash-command creation.
In that case, reporters must use the public ticket page for that project.

When an agent replies to a Discord-created ticket, the reporter notification opens the public ticket thread page instead of the internal app. That keeps Discord reporters on the same reply flow as mail and public-form reporters.

Closed tickets now show first-response time in the same compact duration format as resolution time, so longer waits render as hours or days instead of only raw minutes.