QueueDeskDocs
Main website Go to dashboard
Documentation

Getting Started

  • Quickstart Guide
  • Workspace Setup
  • Inviting your Team

Ticketing & ITIL

  • Incidents vs Service Requests
  • Categories, Custom Fields & Ticket Numbering
  • SLA Rules & Priorities
  • Ticket Stages, On Hold & SLA Pause
  • Assignment Rules & Groups
  • Ticket List View & Canned Replies
  • Closure Rules, Approvals & CSAT Surveys
  • Merging Duplicates & Linking Major Incidents

Service Catalog & Knowledge Base

  • Service Catalog
  • Knowledge Base

QueAssist (AI Copilot)

  • AI Triage & Categorization
  • Agentic Auto-Resolution
  • QueAssist Settings & Usage Quota
  • AI Agent Access — Connect Claude, Cursor & ChatGPT
  • No-Code Playbooks
  • Identity Scoping & Safety

Channels & Email

  • Email Forwarding Setup
  • Portal Mode — Forms vs AI Chat

People & Identity

  • External Users
  • Single Sign-On & SCIM Directory Sync

Integrations

  • Connecting Integrations & Custom MCP Servers

Billing & Plans

  • Billing & Plans
DocsTicketing & ITILClosure Rules, Approvals & CSAT Surveys

Closure Rules, Approvals & CSAT Surveys

Three settings that govern how a ticket's lifecycle ends — what agents must do to resolve and close it, when a request needs sign-off first, and how you measure satisfaction afterward.


1. Closure Rules (Settings → Closure rules)

Every toggle here saves immediately.

SettingDefaultWhat it does
Require resolution notes on resolveOnAgent must write at least 10 characters explaining the fix before resolving.
Require close code on closeOnAgent must pick a close code (see below) before closing.
Require assignment group before resolvingOnTicket must belong to a group before it can be resolved.
Require named assignee (stricter)OffTicket must also be assigned to a specific agent, not just a group.

Close codes — the default set is Solved, Duplicate, User error, Cancelled, Workaround. Add your own with a short code (e.g. escalated) and a display label. You need at least one close code active at all times.

Auto-close resolved tickets — optionally close tickets automatically after they've sat in Resolved for a set number of days (default: 3, adjustable 1–365). These are closed with the code auto_closed so you can always tell which closures were automatic.

2. Approval Workflow (Settings → Approval workflow)

Turn this on for Service Requests and/or Changes to require sign-off before an agent proceeds:

  • •When enabled for a ticket type, the ticket can't be resolved or closed until its approval is Approved.
  • •Default due date offset (1–365 days, default 5) pre-fills a due date on new Service Requests / Changes so approvals don't stall indefinitely.

Sending an approval request

Open any Service Request or Change and use Send for approval in the Approval section of the ticket sidebar. That opens a window with two ways to choose an approver:

Approver typeWho you can pickWhen to use it
Team memberAnyone invited to this workspace — owner, admin, agent and employee. Search by name or email.Internal sign-off — a line manager, team lead, IT manager, or department head.
External emailAny email address, including people outside your company. Email is required; name is optional.Someone who doesn't use QueueDesk — a client, a supplier, or a finance manager who just needs to say yes or no.

Employees appear in the Team member list even though they only use the portal, because the most common approver is a line manager who isn't an agent. Approvers decide straight from the email, so an employee needs no extra access to approve. Staff (owner, admin, agent) are listed first, and each result shows the person's role.

Allowing external approvers

External approvers are off by default. An admin or owner turns them on with the Allow external approvers toggle in Settings → Approval workflow.

Keep in mind that an external approval email contains the ticket number and ticket title, so it leaves your workspace. Leave the toggle off if approvals should never go outside your team — agents will then only be able to pick people already in the workspace, and the External email tab explains that it's disabled.

If you type a workspace member's own address into the External email tab, QueueDesk recognises them and treats the approval as internal — they won't be marked as an external approver.

What the approver sees

The experience is identical for internal and external approvers:

  • •They get one email with Approve and Reject buttons. No QueueDesk account and no login are needed — external approvers don't need to be invited to your workspace.
  • •Either button opens a short page where they can add a comment before confirming. A comment is required when rejecting and optional when approving.
  • •The link is single use. Once a decision is recorded, revisiting the link just shows what was already decided.
  • •External approvers get one extra line of context in the email explaining who sent it and why, since they've likely never seen QueueDesk before.

Once a decision is made, the ticket's approval status becomes Approved or Rejected, and the approver's comment appears in the Approval section along with the date and time of the decision. Approvals sent to someone outside the workspace are labelled with an External badge there, so you can always tell internal sign-off apart from external.

Who gets told about the decision

As soon as the approver approves or rejects, QueueDesk emails three people — no one has to watch the ticket:

  • •The agent who sent the approval request, so the person waiting on the answer hears first.
  • •The assigned agent, if the ticket is assigned to someone else.
  • •The employee who raised the ticket, in plain language ("Your request was approved") with a link to their portal ticket.

Every email carries the decision and the exact date and time it was made, shown in your workspace's time zone — set that under Settings → Branding, and see Workspace Setup. If one person is more than one of the above, they get a single email. The decision is also written to the ticket's Activity timeline, so there's a permanent record even if an email bounces.

Who can see the approver's comment

By default the approver's comment goes to everyone above, including the employee who raised the ticket — a rejected request should come with a reason. If your approvals routinely touch budget, headcount or anything else you'd rather keep between staff, turn off Share approver comments with the requester in Settings → Approval workflow. The requester is still told the outcome; they just don't see the comment, and your team still sees it in full on the ticket.

Either way the approver is told which applies, in a line under the comment box, before they write anything — so nobody has to guess who's about to read it.

Need a different approver, or want to chase a stalled one? Use Re-send for approval — it starts a fresh request (and a fresh single-use link) and you can switch approver type while doing it.

3. CSAT Surveys (Settings → CSAT surveys)

Automatically ask requesters how satisfied they were once their ticket is resolved.

  • •Enable CSAT surveys — off by default.
  • •Send delay after resolution — 0 means immediately; you can delay up to 7 days (10,080 minutes) so the survey doesn't arrive before the requester has actually tried the fix.
  • •Survey message — customize the question shown (default: "How satisfied were you with the support you received?"), up to 300 characters.
  • •Ratings use a 5-star scale.

Responses are visible on the ticket's activity timeline and roll up into your satisfaction reporting.

Next, read Service Catalog to give employees a browsable menu of things they can request.