Ticket Setup

Use this guide to configure the ticket system from zero to production-ready.

1. Grant the required permission

Agents and admins who should manage tickets in the app need MANAGE_TICKETS.

Without this permission, the ticket UI is hidden and users cannot manage ticket workflows.

See Permissions.

2. Open project ticket settings

Go to Project Settings -> Tickets.

This tab controls project-level ticket behavior:

  • Public ticket intake for that project
  • Inbound ticket mailbox local-part (<local-part>@tickets.bnder.net)
  • Statuses
  • Ticket types (custom list per project)
  • Default ticket type (or none)
  • SLAs and default SLA (Pro)
  • Auto-close days for "waiting on reporter"
  • Enforced template
  • Template management

All ticket workflow changes in this area autosave automatically.

The ticket settings UI follows your app language, including mailbox setup, SLA labels, template editor fields, and autosave status text.

If you use Discord Ticket Manager and enforce templates with required user-editable fields, reporters are prompted for those fields during /ticket create via modal steps.

If an enforced required template field is a file field, Discord creation is not possible and reporters must use the public ticket form.

In Project Settings -> Tickets, enable public tickets for the project if external users should open tickets.

When enabled, the UI shows direct links for every configured page domain in your workspace.

If you have not configured page domains yet, set them up first in your workspace Pages settings.
See Pages.

4. Configure inbound project mailbox address

In Project Settings -> Tickets, configure the Inbound email-to-ticket mailbox card in the Public Ticket Intake section at the top. Set only the local-part for the project mailbox (the part before @tickets.bnder.net).

Example:

  • support-default -> support-default@tickets.bnder.net

Rules:

  • Must be globally unique
  • Uses lowercase letters, numbers, dots and hyphens
  • If unknown, inbound mails are rejected and the sender gets a guidance email

5. Configure workspace customers

Go to Workspace Settings -> Tickets.

Create customer profiles with:

  • Name
  • Optional company name
  • Customer emails and phone numbers
  • Optional customer-specific SLA (Pro)
  • Optional metadata for customer segmentation

Customer email addresses must be unique globally across workspaces to keep inbound email routing unambiguous. Customer mapping for inbound email is optional and used to auto-assign customer + SLA when available.

Customer limits scale with the workspace plan and Pro seats:

  • Free: 1 customer
  • Pro: 1 + 5 * seats customers

If the workspace reaches its customer cap, the app shows the exact current limit in the upgrade message.

These customer settings autosave automatically. Deleting a customer opens a confirmation dialog and applies immediately after confirmation.

Each customer gets a dedicated token-based public link that can preselect the customer on ticket creation.
Customer links can also work as private intake links for selected customers.

6. Define statuses

In project ticket settings, define your status list and status categories.

Status categories are used for workflow behavior (for example, whether a status is considered closed).

7. Define SLAs

SLA policies are available on Pro workspaces and scale with Pro seats:

  • Free: 0
  • Pro: 5 + 1 * seats

If the workspace reaches its SLA policy cap, the app shows the exact current limit in the upgrade message.

Create SLA definitions in project ticket settings:

  • Resolution target in minutes
  • Optional first-response target in minutes
  • Optional next-response target in minutes
  • Warning threshold in minutes per step (when warning chips begin)
  • Optional default business-hours window (timezone, weekdays, start/end hour)
  • Optional breach escalation users (selected workspace members)

The SLA editor uses compact single-line inputs so each SLA card stays readable even when several targets are configured side by side. Fields in this editor also keep a subtle outline in the default state so the inputs stay visible on flat project-settings surfaces.

Set a default SLA if needed.

Business-hours override priority

When SLA timers run, business hours are resolved in this order:

  1. Customer override
  2. Project override
  3. SLA default business hours

This lets you define baseline SLA calendars and still override them for specific customers/projects.

Current limitation: holiday calendars

Holiday calendars are not yet supported natively in the SLA engine. Only weekday + start/end-hour business windows are used for timer calculation.

8. Configure ticket types

In project ticket settings, define the ticket type list for this project.

You can:

  • Add custom type labels
  • Remove unused types
  • Set a project default type

If you set Default ticket type to None, agents must choose a type explicitly when creating a ticket.

9. Configure templates

Create ticket templates and fields in project ticket settings.

Each template field supports:

  • Field type (text, number, email, date, file, boolean)
  • Required
  • Visible
  • User editable
  • Default value

If Visible is enabled and User editable is disabled, the field is shown as read-only to users.

10. Enforce a template (optional)

Set an enforced template in project ticket settings if every newly created ticket must use that template.

When enforced:

  • New tickets in that project use the enforced template automatically
  • Public ticket creation in that project also uses it

11. Configure member new-ticket notifications

Go to Project Settings -> Members.

For each member, you can enable New ticket notifications for the current project.

Behavior:

  • Discord workspaces: opted-in members receive a DM for newly created tickets
  • Non-Discord workspaces: opted-in members receive an email for newly created tickets
  • Members with disabled direct notifications are skipped
  • The ticket creator is not notified about their own ticket creation action

12. Configure virtual coworker supporters

Virtual coworkers can support tickets when they are already scoped to the same project in the virtual coworker settings.

Behavior:

  • Only coworkers in the Customer Support department handle automated ticket support for reporter-facing ticket work
  • Any virtual coworker whose project scope includes the ticket project is treated as a ticket supporter for that project
  • New tickets in that project trigger one internal assessment queue entry per eligible virtual coworker
  • The coworker can leave an internal note saying whether it can help
  • Grant the coworker Write permission if it should update ticket fields or send support replies
  • Agents can assign the ticket directly to a virtual coworker from the assignee dropdown in ticket detail; all Customer Support coworkers are visible there and project-matching coworkers are listed first
  • After assignment, a coworker that accepts ownership sends the first public support reply to the reporter
  • If the coworker later declines or hands the ticket back, the human who assigned that coworker becomes the assignee again automatically
  • Coworkers are also expected to hand tickets back earlier when the reporter explicitly asks for escalation or when the conversation is stuck in repeated clarification loops without reaching a fix

Virtual coworker assessment notes and decline notes stay internal and are never shown on the public ticket thread page.

13. Validate the setup

Run this checklist:

  1. Create a ticket in the app
  2. Create a ticket through the public project link
  3. Send a test mail to the configured project inbox (<local-part>@tickets.bnder.net)
  4. Confirm status/SLA/template behavior
  5. Confirm emails contain thread and unsubscribe actions
  6. Confirm reporter can reply from thread page
  7. Confirm opted-in project members receive the new-ticket notification
  8. Confirm eligible virtual coworkers leave internal assessment notes for new tickets in supported projects
  9. Confirm assigning a ticket to a virtual coworker shows the coworker name in the internal app UI
  10. Confirm reporter replies on VC-owned tickets do not expose internal coworker notes on the public thread

Next guide: Working Tickets in the App

Ticket settings in the app follow your selected app language with native translations across the ticket project settings and workspace ticket settings screens, including customer management, integration labels, and related settings navigation.