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
  • Quick filters for My unresolved and My team's unresolved
  • Saved filter presets for frequently reused filter combinations
  • Status filter
  • Assignee filter, including Unassigned for tickets without an owner
  • 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 search prominent and places secondary filters behind a Filters toggle. Active filters stay visible as compact summary chips. Use My unresolved to focus on open tickets assigned to you. Use My team's unresolved to focus on unresolved tickets assigned to members of your People teams. You can also save the current search and filter combination as a preset from the filter dropdown. Saved presets sync with your Bnder account across devices. Ticket rows can appear before all settings-backed labels finish loading, so the list stays usable while status metadata hydrates in the background.

Starter and Pro seats can switch the ticket workspace to a Kanban board to work tickets by status. Free seats continue to use the ticket list.

Use the People view when you want to see ticket ownership by assignee. It groups tickets into columns for unassigned tickets, workspace members, and eligible virtual coworkers, and agents can drag a ticket into another column to reassign it.

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:

  • Slack workspaces notify opted-in members via Slack DM
  • Discord workspaces notify opted-in members via Discord DM
  • Bnder 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 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. The ticket detail header is selectable, so you can copy the visible ticket id directly from the title line. New tickets use the same shared incremental workspace counter as tasks, events, and documents. Older tickets can still show legacy random ids. The activity timeline starts collapsed by default and expands only when you click the activity toggle in that section. The autosave banner shows the last successful save in a relative format such as "just now" or "5 minutes ago". Age, first-response, and resolution chips expose exact event timestamps in tooltips so agents can inspect precise creation, first-response, and resolution times without leaving the summary row. For customer-linked tickets, the detail view shows a compact customer context section with profile data, portal access status, related customer tickets, a Show in customer portal switch, and a Copy portal link action when a public thread link is available.

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 reporter is shown as a read-only workspace member field without interactive dropdown controls. Tickets created by mail or the public ticket form still show the normal reporter email field.

Replies and notes

Use Public reply when the customer should receive the message by email or see it in the customer portal. Use Internal note when the message is only for workspace members.

Agents can attach files to public replies and internal notes. Files are uploaded before the message is sent, then shown on the message as preview tiles or downloadable file rows. Internal-note attachments stay visible only to workspace members with ticket access. Admins can set a maximum combined attachment size per ticket, and stored attachment bytes count toward the workspace file-storage allowance. Workspace upload-type restrictions also apply to agent ticket attachments. If admins only allow selected MIME types, other files are rejected before storage. Admins can also configure automatic cleanup for attachments on closed tickets after a retention period in days or months.

When you create a ticket inside a Discord workspace from the app, you can either:

  • Select a workspace member as the reporter
  • Enter the reporter email manually

Selecting a workspace member creates a Discord-origin reporter so follow-up reporter notifications stay in Discord direct messages.

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. Untouched projects use General as the default automatically. 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 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)
  • Message attachments with previews and authenticated downloads
  • 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:

  • Slack workspaces: mention notification via Slack DM
  • Discord workspaces: mention notification via Discord DM
  • Bnder 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. Descriptions, replies, internal notes, and master-ticket broadcast messages can contain up to 32,000 characters.

Linked Resources 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 seat, the link search area shows the Starter/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 keep their full available width even when they are empty, so the detail layout stays stable. Relation add/remove actions use the normal save-status banner in the ticket header.

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 Resources 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 when the workspace has at least one Pro seat.

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 ticket attachment area and message composer also accept drag and drop, so agents can drop files directly onto the ticket or the reply/note being written. 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
  • Temporary Create ticket pages use the normal tab controls for closing
  • Existing ticket tabs also use the normal tab controls for closing
  • 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)
  • In the new-ticket flow, changing the ticket type immediately re-resolves any enforced template for that type and refreshes the visible template fields
  • 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, no relation change is saved
  • In the Linked Resources card, the Create task action moves below the search field on narrow widths

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 (Slack DM in Slack workspaces, Discord DM in Discord workspaces, email in Bnder workspaces)
  • When a ticket is assigned or reassigned to an agent, that assignee also gets a direct notification (Slack DM in Slack workspaces, Discord DM in Discord workspaces, email in Bnder 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 or the selected ticket type enforces a ticket template with required user-editable fields, /ticket create opens a localized modal flow in Discord so the reporter can fill those required fields before the ticket is created.

Template fields of type textarea use a multiline Discord modal input so reporters can enter longer descriptions without switching to the public form.

Discord uses the selected ticket type, or the project's default type if none was passed, to decide which enforced template to apply. Custom ticket types follow the same flow.

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 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.