Tickets

A ticket in OpsMerge is the unit of work — anything from "user can't print" to "migrate the whole CRM database". Tickets get created, triaged, worked, and closed; along the way, time gets logged, conversations happen, and SLAs run.

Where tickets come from

Five sources, in rough order of frequency:

1. Email — inbound mail to your connected mailbox.
2. Alerts — an RMM alert with "create ticket" action fires (see Monitoring).
3. Client portal — a portal user submits via the web form.
4. API / integrations — third-party tools post tickets via the REST API.
5. Manually — your team creates a ticket directly in the UI.

In all five cases, the ticket lands in the same queue and behaves the same way.

Ticket numbers and references

Every ticket has a type-prefixed reference — e.g. INC-1042. The number is a per-org sequential integer, allocated once and immutable; the prefix is derived from the ticket type:

Type	Prefix
Incident	INC
Service Request	REQ
Problem	PRB
Change	CHG
Task	TSK

Changing a ticket's type re-derives the prefix but never renumbers the ticket — the underlying number is the stable identity (it's also what subject-based reply threading keys on).

You can customise both at Settings → Tickets → Numbering:

• Prefixes — override the prefix per type (e.g. Service Request → SR). Leave a field blank to use the built-in default.
• Next ticket number — set where the sequence continues from, handy when migrating off another system. This is forward-only: you can jump the counter ahead, never back.

Ticket fields

Field	Notes
Subject	One-line summary. Searchable.
Client	Which client this ticket is for. Required.
Contact / Requester	The person at the client. Often auto-detected from email. Editable on the ticket page via a contact picker — the client's own contacts plus any floating (unassigned) contacts.
Priority	Low / Medium / High / Critical. Affects SLA and ordering.
Status	Open / In Progress / Waiting on Client / Resolved / Closed. Customisable.
Assignee	Who's working it. Can be unassigned.
Tags	Free-form labels for filtering and reporting.
Type	Incident / Service Request / Problem / Change / Task. Tickets raised from inbound email are auto-classified from the subject and body, and anything that matches no rule lands as Incident — so most email tickets start as incidents. Change it any time from the type badge in the ticket header (click it for the dropdown), the same way you change status or priority.
Description	The body — Markdown supported.
Internal notes	Comments only your team sees.
Time entries	Logged work, billable or non-billable.
Related assets	Endpoints, M365 users, etc. this ticket touches.
Related tickets	Parent/child or "see also".

Priority and the matrix

Priorities aren't free-form — they're set by a priority matrix that combines:

• Impact: how many users / how much of the business is affected.
• Urgency: how time-sensitive the resolution is.

Out of the box we ship an ITIL-standard matrix:

	Urgency: Low	Urgency: Medium	Urgency: High
Impact: Low	Low	Medium	Medium
Impact: Medium	Medium	Medium	High
Impact: High	Medium	High	Critical

You can customise the matrix at Settings → PSA → Priority matrix. We preserve any customisation across migrations — the only time we touch your matrix is when fixing a known seed bug (migration 000146 backfilled an inverted ITIL matrix for tenants who hadn't yet customised theirs).

SLAs

Every ticket has an SLA clock attached based on:

• The client's contract SLA tier (Bronze / Silver / Gold or custom).
• The ticket priority.

The clock pauses when status is "Waiting on Client" and resumes when the client replies. Time-to-first-response and time-to-resolution are tracked separately.

SLAs surface in the UI:

• Green = within SLA, comfortable margin.
• Amber = within SLA, approaching breach.
• Red = breached.

Reports surface SLA performance per client, per technician, per ticket type.

The ticket list

Tickets → Table.

The list leads with the ticket-number reference (INC-1042), and carries Requester and Company columns so you can see who raised each ticket and for which client without opening it.

By default the list shows the most recently updated tickets first. Click a column header to sort the whole list by that column instead — Number, Status, Priority, Type, Subject, Created and Updated are sortable. Click again to flip the direction, and a third time to return to the default order.

Every ticket table — this list and the others across the app — lets you tailor the columns:

• Resize — drag a column header's edge.
• Reorder — drag a header to a new position.
• Show / hide — pick which columns appear.

Your layout is saved per user in the database, so it follows you across browsers and devices.

The dashboard tickets row

The main dashboard carries a Tickets panel so the day starts with the queue in view, without opening the list:

• Headline stats — open tickets (with unassigned and awaiting-triage counts), SLA-overdue tickets (missed response and missed resolution, excluding paused tickets), open urgent-priority tickets, and today's resolved vs created.
• Status donut — open tickets split by New / Open / Pending / Waiting on customer. Click a segment to jump to the list filtered to that status.
• 14-day trend — tickets created vs resolved per day, bucketed in your organisation's timezone. Resolved keeping pace with created is the health signal; a widening gap means the backlog is growing.

Counts exclude merged-away and archived tickets, matching the list's defaults. The panel only appears for users with the View tickets permission on a plan that includes the PSA.

The kanban view

Tickets → Kanban.

Columns = statuses. Cards = tickets. Drag to change status. Group by assignee, client, or priority. The kanban view is opinionated about which statuses appear as columns — by default the four primary statuses (Open, In Progress, Waiting on Client, Resolved). Settings → PSA → Kanban lets you customise.

For larger teams, kanban + "group by assignee" is the daily-standup view of choice.

Working a ticket

Open a ticket:

1. Read the conversation — public and internal entries in chronological order.
2. Set status to "In Progress" so other techs know you're on it.
3. Take action — comment to the client (replies go out via the email gateway), comment internally, run a script against the endpoint, etc.
4. Log time as you go. The header has a Start timer button for the active-work pattern; manual entries via the Time tab are fine too. See Time tracking.
5. Close when done. The closing prompt asks about unbilled time — confirm before discarding.

Comments: public vs internal

• Public comment = goes to the client via email (and appears in the portal). Treated as ticket correspondence.
• Internal note = only your team sees it. Useful for "I tried X, didn't work" or "ping me before responding, I have context".

Toggle the type before posting. There's a visual difference (internal notes are yellow-tinted).

Don't accidentally email your test reply

When debugging a ticket flow, use internal notes — not public comments with "test" content. Use the Internal toggle. Public comments fire emails and reach real client inboxes.

Assignment

Assign to a specific technician, or leave unassigned (visible to everyone in the relevant queue). Round-robin auto-assignment isn't on by default; if you want it, set it in Settings → PSA → Assignment rules.

The first technician to send a public reply on an unassigned ticket claims it automatically — replying is taking ownership. Internal notes, automations and vendor conversations never claim, and a later reply from a second technician never steals an existing assignment.

You can also assign to a team rather than a person — useful for "this ticket needs L2 attention" patterns. Teams are configured in Settings → Users → Teams.

CC'd people (email participants)

When a customer emails your connected mailbox and CCs colleagues, those people are captured as the ticket's participants. Participants:

• receive every public reply on the ticket by email (in the CC header, with the requester in To),
• can reply themselves — their replies land on the same ticket instead of opening a new one,
• appear on the ticket header chip, where you can also CC someone manually or remove a CC. The requester can't be removed.

New CCs on later replies are merged in automatically. If a participant's address turns out to be an auto-responder (out-of-office bots, monitoring systems), it is muted automatically so replies can't loop — its incoming mail still lands on the ticket, it just stops receiving notifications. Internal notes are never sent to participants.

Replies you send are threaded into the customer's existing email conversation (they show up under the original message in Outlook or Gmail, not as a new email), and they carry any attachments and CCs you add. Attachments over roughly 3 MB can't go by email — you'll get a clear "too large" message rather than a silent failure; share those via a link instead.

Merging duplicate tickets

If two tickets are the same issue:

1. Open one of them.
2. ⋯ → Merge.
3. Pick the target ticket.
4. Confirm.

The source ticket's comments are folded into the target as a single combined timeline; the source goes to status "Closed - Merged" and links to the target. Time entries are not automatically merged (they stay on the original ticket) — this is a deliberate audit choice.

VIP contacts

Tickets from contacts flagged as VIP (see Clients & contacts) get special handling:

• Priority floor — bumped one level from whatever the matrix says (Low → Medium, etc.).
• Visual flag — VIP badge in the ticket list and on the ticket page.
• Optional escalation rule — notify a specific person/team on VIP ticket creation.
• No "Waiting on Client" SLA pause by default — the SLA keeps running even when waiting on the VIP (configurable).

Closing and reopening

Closing a ticket sets closed_at and stops the SLA clock. The ticket is read-only after close; comments still appear but the ticket can't be edited.

To reopen: ⋯ → Reopen. The SLA clock restarts from where it was, plus a configurable penalty (default: no penalty, but some MSPs set "reopens add 1 hour to SLA used").

Tickets can be closed via:

• The Close button (manual, prompts about unbilled time).
• Auto-close after N days of "Resolved" with no activity (default: 7 days).
• Portal close (the client themselves resolves).
• A close rule (e.g. "no response in 10 days = auto-close").

Auto-close discards unbilled time

Auto-close and portal-close discard any unbilled time on the ticket. Only manual close from the Stop timer action commits time. If you use the timer, you must stop it manually for the time to bill.

Bulk actions

Select multiple tickets:

• Re-assign en masse.
• Change status (e.g. close all matching tickets).
• Add tags.
• Export to CSV.

Bulk actions respect the current filter, so you can scope by client / tag / status first, then bulk-action what remains.

Common patterns

"Triage queue at 8am"

1. Tickets → filter: Open, unassigned.
2. Sort by priority desc, then created-at asc.
3. Assign each to the right tech.
4. Move to "In Progress" if the tech can start now, otherwise leave at "Open" with a comment.

"Service request approval"

For tickets typed "Service Request":

• Add an internal note "needs approval from <stakeholder>".
• Set status "Waiting on Client" (or a custom "Awaiting approval").
• A notification rule can ping the stakeholder via email.

"Recurring task / planned maintenance"

For known recurring work, OpsMerge supports recurring tickets (template tickets that materialise on a schedule). Set up at Settings → PSA → Recurring tickets.

Common issues

Ticket from a known contact came in with the wrong client. The client's email domains don't match the sender's domain — see Connected mailboxes.

SLA is "amber" but the client is genuinely fine waiting. Use the Waiting on Client status — SLA pauses. Or document the agreement and adjust the SLA tier for that contract.

Bulk-close left tickets in a weird state. Bulk actions respect filters but don't run hooks (no notifications, no integration push). Use deliberately for cleanup, not for routine work.

Kanban view loaded slowly. Default load is the last 60 days of tickets. For high-volume tenants, narrow the time window or filter by client.

AI assistance in the composer

With an AI key configured (Settings → AI), the reply composer offers:

• Draft reply with AI — generates a first draft grounded in your knowledge base, with citations to the articles it used. If the KB has no coverage for the topic, it says so rather than inventing an answer.
• Improve with AI — takes the reply you typed and polishes it: spelling, grammar and a professional, friendly tone, without changing the meaning or the technical details. Nothing is added that you didn't write. There's a one-click Undo if you prefer your original.

Both are draft-only — nothing is ever sent automatically, and the Send button is always yours to press. Both count against the same daily AI allowance and can be switched off per-tenant under Settings → AI.

Next

• Connected mailboxes — where most tickets come from
• Time tracking — logging billable work
• Notifications — controlling what gets emailed to whom