Running a Help Desk with Tickets

Every service business has the same leak: a request arrives — a phone call, an email to somebody's personal inbox, a note scrawled on the counter — and then it depends on one person remembering. Tickets close that leak. A ticket has an owner, a status, a due date, and an audit trail of everything anyone did to it. Nothing quietly evaporates because Dave went on vacation.

This article is about the Tickets area: when to use it, how to set it up so it doesn't become a dumping ground, and the handful of decisions that are genuinely hard.

When you'd use this

• Anything needing follow-up over more than one interaction. "Slip 42's power pedestal is tripping" is a ticket. "What time do you close?" is not.
• Work that isn't billable job work. A job/work order is for scheduled, invoiceable labor. A ticket is for the conversation around it — the complaint, the question, the escalation, the thing you might eventually turn into a job.
• Internal requests. IT access, facilities, "the gate code needs changing." Nothing says tickets have to come from customers.
• Anything where you need to prove what happened. Every field change writes an immutable history row with who, what, when, and the old and new value.

When it's the wrong tool: don't use tickets as a to-do list for one person, and don't use them for scheduled work. If it has a date, a technician, and a price, it's a job.

Support is the only door

The portal has exactly one way for a customer to reach you: the Support section. They open a ticket, it gets a number, a status and an owner, and they can watch its progress and reply in the thread.

Earlier versions also had a lightweight Contact Us form that dropped notes into a plain staff inbox — no status, no owner, no thread — with a "convert this to a ticket" action for the ones that mattered. That was a placeholder built before ticketing existed, and it's been removed along with the Inbox page. In practice the two-doors setup mostly produced messages nobody converted.

What this means for you: turn Support on under the Customer Portal settings, and control which categories customers may submit into per category (below). If you'd rather customers didn't open tickets themselves, turn portal submission off — they'll still see and reply to tickets you open on their behalf, which is usually what you actually want.

The mental model

Five things, and it's worth knowing how they relate before you start clicking:

1. Category — what kind of request. Also the permission unit and the routing unit. "Billing", "Dockside Maintenance", "IT — Level 1", "IT — Level 2".
2. Status — where it is. Behind each status name is one of five behaviors: New, Open, Pending, Resolved, Closed. More on this below, because it matters more than the name.
3. Priority — how urgent, and it carries a default due-date window.
4. Assignment — a person, a team, both, or nobody. Nobody-and-nobody means it's in the claim queue.
5. Followers — who gets emailed. Separate from assignment on purpose.

The queue and its scope tabs

The Tickets area opens on a queue with scope tabs. Each answers a different question:

• My Tickets — assigned to you. This is your work list; start here every morning.
• Claimable — open and owned by nobody. This is the shared pile. A ticket queued to a team still shows here until a human picks it up, because "has a team" is not the same as "has an owner."
• My Teams — anything routed to a team you're on.
• Following — tickets you asked to watch but don't own.
• Overdue — past due and in a status that's still counting.
• All Tickets — everything you're allowed to see, which is not necessarily everything that exists.

The default sort is priority first, then oldest-first inside each priority — so an Urgent ticket from an hour ago outranks a Normal one from Tuesday, but two Urgents resolve to whoever's been waiting longer.

Claiming vs. assigning

These are different verbs on purpose.

Claiming is you taking a ticket off the shared pile. Anyone who can work that category can claim, and if the ticket is queued to a specific team, you have to be on that team. Claiming is atomic — if two people hit it at the same moment, one gets it and the other gets told who beat them. No silent double-work.

Assigning is you giving a ticket to someone else, and it needs the Assign & Route permission. That's a deliberately higher bar: handing your work to a colleague should be a decision, not a reflex.

Recommendation: run on claiming for day-to-day work and reserve assigning for dispatchers and supervisors. Teams that assign everything centrally end up with a bottleneck at the person doing the assigning.

Public replies vs. internal notes — get this right

Every ticket is a chronological thread, and every message you add is one of two kinds:

• Public reply — appears on the customer's portal and is emailed to every follower, including the customer.
• Internal note — staff only. It never appears on the portal and is never included in a customer email.

This is the single most consequential control on the page. An internal note that reads "customer is being unreasonable, I'd just refund them to make it go away" is fine internally and catastrophic publicly.

Two habits that prevent accidents:

• Look at the toggle before you type, not after. Muscle memory is what gets people.
• Write internal notes as though they might be read out loud anyway. They're not secret from you — they're in the permanent record, they're discoverable, and a colleague can quote them back. Keep them factual: "Called at 2:15, no answer, left voicemail."

Note also that the first public reply from staff is what stamps the response clock. Internal notes don't count — the customer hasn't heard from you yet.

Statuses, and why the name doesn't matter

You can rename every status. Call "In Progress" whatever your team actually says. What you cannot change on the built-in statuses is the behavior underneath, and that's the part that drives automation:

Two things hang off this:

Auto-close. A ticket sitting in a Resolved status is still a live thread — the customer can reply and reopen it. After the auto-close window passes with no reply, it moves to Closed on its own. The default is 7 days, you can override it per category, and 0 means never auto-close. A busy front desk should keep 7; a category where customers routinely take two weeks to respond (insurance claims, warranty vendors) should be 21 or 30.

The due clock. The three Pending statuses pause it. If you're waiting on the customer, that time doesn't count against you — which is exactly right, and it's why "Pending Customer" is worth using instead of just leaving things In Progress.

Recommendation on adding statuses: don't, at first. The nine seeded ones cover almost everyone. Rename them to your team's vocabulary, live with them for a month, and only then add one if you find yourself repeatedly explaining a state that doesn't exist. Twelve statuses nobody can tell apart is worse than six good ones.

Priorities and due dates

Priority does two jobs: it sorts the queue, and it sets a default due date. The seeded set:

Set these to numbers you'd actually be embarrassed to miss. Targets nobody believes are worse than no targets — everything goes red, people stop looking at the color, and you've lost the signal.

If you set a due date by hand, it sticks. Changing the priority afterwards won't quietly move a date a person chose. That's deliberate: if you promised a customer Friday, a priority bump shouldn't silently rewrite the promise.

Categories and the permission matrix — the part people get wrong

Two layers control access, and both apply.

Layer one — the global permissions. These gate the module: View Assigned, View All, Create, Work, Assign & Route, Close & Delete, Configure, Reports. Assign them by role like any other permission.

Layer two — the per-category grant matrix, on the Permissions tab of Ticketing Setup. For each category, you grant a team or an individual a set of eleven independent capabilities: view, view notes, add note, create, assign in, assign out, change status, change priority, close, delete, and admin.

The pair that confuses everyone is assign in versus assign out, and it's the whole reason the matrix exists. Concretely:

You run "IT — Level 1" and "IT — Level 2". Level 2 handles anything involving customer payment data, and Level 1 must not read those tickets. You want a Level 1 tech to be able to escalate a ticket into Level 2 — but not to browse Level 2's queue afterwards.

Grant the Level 1 team assign in on the Level 2 category, and grant them nothing else there — no view, no view notes. They can push a ticket across the boundary and then it vanishes from their world. The escalation works; the confidentiality holds.

The reverse case matters too: assign out on a category is the right to take a ticket away from that category — reassign it or move it elsewhere. A team that can accept escalations but shouldn't be able to bounce them back gets assign-in without assign-out.

A simplification if you're small. There's a global switch — "Enforce Category Permissions" — that turns the matrix off entirely. With it off, the global permissions are the whole story: anyone who can work tickets can work every category. If you have eight staff and no confidential categories, turn it off and skip the matrix completely. Turn it back on the day you create a category not everyone should read; your grant rows are still there waiting.

One thing to know either way: View All, Assign & Route, Close & Delete and Configure are manager-level and bypass the matrix. If you gave someone View All to "help with reporting," you gave them read access to every category including the confidential one. Use Reports for reporting.

Following and unfollowing

Followers are who gets emailed — separate from who owns the ticket. You're added automatically when you're the requester, when you're assigned, or when you comment. Anyone can follow a ticket they can see, and anyone can unfollow.

Unfollowing sticks. Once you opt out of a ticket, being assigned to it or commenting on it won't quietly put you back on the list. Only clicking Follow yourself will. So an opt-out is a real opt-out, not something the system undoes behind your back — which means you can safely mute a noisy thread you're cc'd on.

Attaching records

You can link an existing job, service agreement, reservation, asset, or map slot to a ticket. Do this liberally — a ticket that says "pedestal at slip 42" is fine; a ticket linked to the actual slip and the actual asset is findable a year later when the same pedestal fails again.

File attachments go through the normal document library, so ticket files inherit your approval workflow, expiry tracking and version history rather than sitting in a separate pile.

Letting customers submit from the portal

Customer submission is off for every category until you switch it on — exposing a queue to the public should be a conscious decision, not a default.

To open one up: mark the category as portal-visible, give it a customer-facing label and a short description (this shows on the submit form and is your best chance to route people correctly — "Billing questions, invoice disputes, payment problems"), then decide three things:

• Can customers set priority? Default is no, and leave it there. Everyone picks Urgent.
• Can customers mark a ticket resolved? Default is yes. Keep it — a customer closing their own ticket is the cheapest possible resolution.
• Can customers attach files? Usually yes. A photo of the problem saves a site visit.

Then decide visibility: submitter means a customer sees only the tickets they personally opened; account means everyone on the account sees all of it. Households want submitter. A commercial account with an office manager who needs oversight wants account. Default is submitter — the safer of the two.

When a customer replies to a ticket you'd already resolved, it reopens automatically rather than being filed silently. That's on by default and should stay on.

One limitation to plan around: there is no email-to-ticket. Customers cannot open or reply to a ticket by emailing you. Every notification the system sends says so explicitly and links back to the portal. If your customers are habitual email-repliers, say so on the submit form and in your signature.

Routing rules

Routing rules run once, when a ticket is created — never on edit. Each rule has conditions (category, priority, source, account, a keyword in the subject or body, inside or outside business hours) and actions (set the team, the owner, the category, the priority, the status, or a due window).

They evaluate in order and keep going unless a rule is marked to stop. That's the useful part: a broad rule assigns everything from the portal to the front desk, and a narrow rule below it bumps anything containing "no power" to Urgent. Both apply.

Start with two or three rules, not twenty. The most valuable ones are usually:

1. Everything from the portal → the front-desk team.
2. Keyword "leak" / "no power" / "flooding" → Urgent.
3. Outside business hours → the on-call team.

Common mistakes

• Posting an internal note as a public reply. The one mistake with real consequences. Check the toggle before you type, and write internal notes you'd be comfortable having quoted.
• Granting View All to solve a reporting problem. View All bypasses your category permissions entirely. If someone needs numbers, give them the Reports permission instead — it shows the metrics without opening every confidential thread.
• Building the permission matrix before you need it. If you have one support queue and eight staff, turn category enforcement off. You can turn it on the day you actually create a category with a confidentiality boundary, and nothing is lost.
• Leaving everything In Progress while you wait on someone. Use Pending Customer or Pending Third Party. Those statuses pause the due clock, so your overdue list reflects work you are sitting on — which is the only version of that list worth looking at.
• Setting auto-close to 0 "just to be safe." All you get is a Resolved list that grows forever and stops meaning anything. Seven days is fine. Customers who need longer will reply, and replying reopens the ticket.
• Creating a category per customer, or per staff member. Categories are a permission and routing boundary, not a filing system. You want five to fifteen of them, ever. Use linked records and search to find things.
• Renaming a status and expecting behavior to follow. Renaming is safe and encouraged — but calling something "Done" doesn't make it behave as Resolved. The behavior is set when the status is created, and it's what auto-close and the due clock actually read.

Related articles

• (Once "Setting up the customer portal" is written, link to it here.)
• (Once "Built-in roles explained" is written, link to it here.)
• Setting up email and SMTP — ticket notifications go out through your normal mail queue, so this has to work first.
• Email deliverability: fixing spam