> ## Documentation Index
> Fetch the complete documentation index at: https://docs.writine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tickets

> Requests filed by visitors who would rather not wait for a reply.

A ticket is a request someone files instead of waiting in chat. They give an
email address, a subject and a message, and get a reference number back. You
work it from the Tickets screen and your reply reaches them by email.

Chat and tickets are two doors into the same team.

<Columns cols={2}>
  <Card title="Chat" icon="comment">
    For a visitor who is on the page now and wants an answer while they wait.
  </Card>

  <Card title="Tickets" icon="ticket">
    For everyone else, answered by email long after the page is closed.
  </Card>
</Columns>

## Filing one

The widget shows a link under the chat form, **Prefer a reply by email? File a
request**. It opens a short form asking for a name, an email address, a subject
and the message.

An email address is required here, unlike chat, because the answer arrives long
after the page has been closed.

Up to five files can be attached, 25 MB each: images, PDFs, plain text, CSV, ZIP
and Word or Excel documents. They upload straight to storage rather than through
the form, and a file only appears on the request once the upload has finished,
so your team never opens a link to something that never arrived.

Nobody creates an account and nobody sets a password.

## The reference

Every request gets a number that belongs to your workspace, so the first one you
ever receive is `#1`.

<Note>
  Numbers are per workspace, not global. Quoting `#42` to a visitor tells them
  nothing about how many requests anyone else has filed.
</Note>

## Working the queue

Tickets have their own screen, laid out as a table rather than a thread, because
nobody is sitting and waiting on one.

| Column | What it is for |
| - | - |
| Ref | The number the requester was given |
| Subject | What they wrote in the subject field |
| Requester | The name and email they gave |
| Priority | Low, normal, high or urgent |
| Status | Open, pending or resolved |
| Assignee | The member who owns it, if anyone |
| Due | An optional date, shown in red once it passes |
| Waiting | How long since the request last changed |

Narrow the queue by status, priority, assignee, or to only what is overdue, and
search by subject and requester. Sort by newest, oldest, priority or due date.
Open a request to see the full thread, change its triage and reply.

## Triage

Open a request and use the bar above the thread to set:

* **Priority**, from low to urgent
* **A due date**, which marks the request overdue once it passes while
  unresolved
* **Tags**, lowercased and de-duplicated as you add them
* **The subject**, if the one they wrote is not clear

Assignment and status work exactly as they do in the inbox.

## Replying

Type in the thread and send. A copy goes to the address the requester gave, with
your reference in the subject line.

<Warning>
  An internal note is never emailed. Notes are for your team, and a request is
  no different from a conversation in that respect.
</Warning>

## What is not supported yet

<Warning>
  Replying **to** that email does not reach you. There is no inbound email
  address, so a requester who wants to add something files a new request.
  Keep your reply self contained rather than asking a question back and
  expecting an answer by email.
</Warning>

## Plan limits

Requests and chats draw on the same daily allowance, counted per workspace. On
the Free plan that is ten a day in total, so filing requests does not quietly
spend the chats you were saving. Paid plans are unlimited.

<Card title="Plans and pricing" icon="credit-card" href="/docs/billing/plans">
  See what each plan includes and how the daily limit works.
</Card>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.