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 a client's support address, routed via the email gateway.
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 (optional, defaults to Incident).
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.

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 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.

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.

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 domain field doesn't match the sender's domain — see Email gateway.

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.

Next

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