Create, assign and reply to a ticket

Most support work is this loop. Doing it consistently is what makes the rest — reporting, SLAs, handovers — actually work.

The one thing worth being careful about is the difference between a public reply and an internal note.

Who this is for

Support agents, and anyone who occasionally logs a customer request.

Before you start

• Permission to create and update tickets.
• The contact the request is from, if they already exist — linking it means the ticket sits on their history.

Public reply versus internal note
A public reply goes to the customer. An internal note stays on the ticket for colleagues. They look similar in the interface and are completely different in consequence, so check which one you are writing before you send — particularly when you are being candid about a difficult case.

The loop

1. Create the ticket against a contact
   Log it from the contact where you can, so the request sits on their relationship rather than floating on its own.
2. Set priority and channel honestly
   Record how it actually arrived and how urgent it actually is. These two fields are what all your later reporting rests on.
3. Assign it
   Put it on a specific person. If your workspace has assignment rules, this happens automatically — check it landed somewhere sensible.
4. Reply to the customer
   Write the public reply. The first public reply is what stops the first-response clock, so a short honest holding answer beats a perfect answer sent tomorrow.
5. Use an internal note for context
   Anything you want a colleague to know but the customer should not read goes in an internal note — what you have already tried, what you suspect, who else is involved.
6. Move the status as reality changes
   Pending while you wait on the customer, on hold while you wait on someone else, solved when it is done. The status is how your colleagues know whether to touch it.

What you get

• Requests on the customer's record rather than in someone's inbox.
• A first-response time that reflects when you actually answered.
• Context preserved for whoever picks the ticket up next.
• A queue whose statuses describe reality.

Frequently asked questions

What starts the first-response clock, and what stops it?

It stops on the first public reply to the customer. Internal notes do not count, which is correct — the customer has not heard anything until you send them something.

Can I reply before assigning?

Yes, and often you should. Answering quickly matters more than routing perfectly. Assign it straight after.

What if a ticket turns out to be two problems?

Handle the one it was raised for and open a second ticket for the other. One ticket per problem keeps the history readable and the reporting honest.

The customer replied to a solved ticket. What now?

Move it back to an open status so it re-enters the queue. A reply on a finished ticket is easy to miss if the status still says solved.