PSA

The PSA (Professional Services Automation) side of OpsMerge is the service desk and billing engine. It's what your team uses every day to track work, charge for it, and keep your MSP's commercial side healthy.

The pieces

• Tickets — the unit of work. Created from email, alerts, the portal, or directly. SLAs, priorities, kanban, assignment.
• Email gateway — inbound mail becomes tickets; replies go out from your client domains; DMARC/SPF/DKIM handled per-client.
• Workflows — ticket rules, notification templates, system notifications, audit log. The PSA automation engine.
• Contracts — block-hour, all-you-can-eat, per-asset. Drive billing and SLA expectations.
• Billing & invoices — generate, send, reconcile. QuickBooks/Xero push.
• Recurring invoices — automated monthly billing with live asset counts.
• Time tracking — manual + passive timer; billable/internal split.
• Notifications — auto-acknowledgements, comment notifications, configurable templates.

The flow

A typical PSA loop for a single piece of work:

Email/alert/portal       Ticket created
       │                     │
       │                     ├─> Triaged (priority, assignment)
       │                     │
       │                     ├─> Worked (time logged, comments, scripts run)
       │                     │
       │                     ├─> Closed (resolution captured)
       │                     │
       │                     └─> Billable time + entries flow into the next invoice
       │
End-of-month             Recurring invoices run automatically
       │                     │
       │                     └─> QBO/Xero push for accounting reconciliation

The whole thing is one product — no integration layer between "tickets" and "billing" because they share a database.

Mental model

The two ideas to internalise:

1. Contracts shape billing, not just SLAs

In OpsMerge a contract is the entry point for everything commercial about a client: what they pay monthly, how much support they get, whether per-asset billing applies. When you set up a client without a contract, recurring billing doesn't know what to do — so it doesn't run. Contracts are non-optional for any client you're charging monthly.

2. Tickets are how work gets done; time entries are how it gets billed

A ticket doesn't bill anything on its own. A time entry on a ticket, marked billable, flows into the next invoice for that client. This means closing a ticket without logging time is fine for non-billable work and a leak for billable work. The PSA UI has guards for this — when you close a ticket with no time logged, you're prompted to confirm.

What to set up first

In order, after the agent is installed and you've created your first client:

1. Contracts — define what each client pays for. Even a placeholder "manual ad-hoc billing" contract is better than no contract.
2. Email gateway — point your support email at the OpsMerge inbound mailbox. From this point, client emails become tickets.
3. Notifications — review and customise the auto-acknowledgement and comment-notification templates so your clients aren't getting our default text in your name.
4. Tickets — review priorities, SLAs, and the kanban view. Tune to match how your team works.

Time tracking, recurring invoicing, and billing details can wait until you've got real tickets to bill.

How OpsMerge PSA differs from others

A few quick notes for anyone migrating from HaloPSA, ConnectWise, Autotask, or similar:

• No separate "ticket types" or "service boards". Every ticket is just a ticket; you organise via tags, status, and assignment.
• GUI rules engine, no JavaScript sandbox. Routing, escalations, auto-replies, and assignment all happen through the visual builder at PSA → Workflows — six triggers, a condition tree, thirteen actions. We've deliberately avoided the "tenant-supplied JavaScript runs inside the PSA" trap that some competitors fell into.
• Billing is integrated, not bolted-on. The PSA's billing engine is the same as the RMM's asset counter — no spreadsheet reconciliation between "what the RMM monitored" and "what to bill".
• No portal designer. The client portal is opinionated; you can brand it (logo, colours, support details) but not redesign the layout.

Next

Start with Tickets for the day-to-day, or Contracts if you're setting up billing first.