Ticket Setup

Use this guide to prepare a project for customer support.

1. Grant access

Agents need the Manage tickets permission in the project. Without it, they cannot open or manage the ticket area.

See Permissions.

2. Open ticket settings

Go to Project Settings → Tickets. Project settings control:

  • Public ticket intake
  • Email intake and customer mailbox
  • Statuses and ticket types
  • SLAs
  • Waiting-on-reporter auto-close timing
  • Templates and required fields

Changes save automatically.

3. Enable public ticket intake

Enable Public tickets when external users should create tickets from your Bnder Pages domain. The settings page shows the public links for each configured domain.

If no domain exists yet, configure one in Workspace Settings → Pages. See Pages and Public Ticket Portal.

4. Configure email routing

Info: 

Email intake and reply-by-email require Pro.

You can either connect a shared customer mailbox with SMTP/IMAP or use a Bnder fallback address such as support@tickets.bnder.net as shown in your project settings.

Use a shared support mailbox rather than a personal agent mailbox. Test inbound and outbound mail separately before publishing the address.

See Ticket Email Routing.

5. Add customers

Go to Workspace Settings → Tickets to create customer profiles. A customer can include:

  • Name and company
  • Email addresses and phone numbers
  • Customer-specific SLA
  • Metadata for reporting and segmentation

Customer email addresses must be unique. Customer links can preselect a customer on a project-specific intake form.

Available privacy actions include:

  • Deactivate to block portal login while keeping history
  • Reactivate to restore login
  • Anonymize to remove identifying profile details while retaining useful ticket history
  • Delete to remove the reusable customer profile

Customer capacity depends on Pro seats. The settings page shows the current limit.

6. Define statuses

Create the statuses agents use to move tickets through the workflow. Each status belongs to a category, which determines whether Bnder treats the ticket as open, waiting, resolved, or rejected.

Resolved and rejected statuses also include a Notify reporter switch. Turn it off for internal terminal states, such as spam triage, that should not send a status-change update to the reporter or other notification recipients.

7. Define SLAs

SLAs require Pro. An SLA can include:

  • Resolution target
  • First-response and next-response targets
  • Warning threshold
  • Business hours and timezone
  • Members notified when a breach occurs

Set a default SLA when most tickets should use the same policy. Customer and project business-hour overrides take precedence over the SLA default.

Holiday calendars are not currently included in SLA timer calculations.

8. Configure ticket types and templates

Define the types available in the project and select a default type. Untouched projects use General. Choosing no default requires agents and reporters to select a type.

Templates can contain text, multiline text, number, email, date, file, and boolean fields. Fields can be required, visible, editable, or prefilled.

You can enforce one template for the project or bind different templates to individual ticket types. Type-specific templates take precedence.

Discord ticket creation supports required form fields except required file fields. Reporters must use the public ticket form when a required file field is present.

9. Configure notifications

Under Project Settings → Members, enable New ticket notifications for members who should be alerted. Notifications use Slack DM, Discord DM, or email according to workspace type and personal settings. Ticket creators do not receive a notification for their own ticket.

10. Optional automation

For virtual coworker support:

  1. Choose the Customer Support department.
  2. Include the ticket project in the coworker's project scope.
  3. Grant Write permission if it should update tickets or reply.
  4. Assign a ticket to the coworker when it should take ownership.

Assessment and handoff notes stay internal.

People routing policies can assign new unassigned tickets and react to SLA warnings or breaches. See Ticket Routing with People.

11. Test the setup

Before inviting customers:

  1. Create a ticket in the app.
  2. Create one through the public project link.
  3. Send a test email to the project inbox if email routing is enabled.
  4. Confirm statuses, SLAs, types, and required template fields.
  5. Reply from the public ticket thread.
  6. Confirm the intended project members receive notifications.
  7. Preview and test any routing or virtual coworker automation.

Next: Working Tickets in the App.