The manual-ticketing tax MSPs pay every day
If you run monitoring and a PSA side by side, you already know the tax. An alert fires in your monitoring tool. Someone — a tech, a dispatcher, an after-hours engineer — has to notice it, open a ticket, type in what's wrong, pick the right customer, set a priority, and route it to a board or queue. Minutes per incident, multiplied by every blip across every PBX in the fleet.
Then comes the worse half: closing it. The trunk re-registers at 2:14 a.m. The service restarts itself. The instance comes back the moment the customer's ISP recovers. The problem is gone — but the ticket is still sitting open, because closing tickets is nobody's favourite job and the person who opened it has moved on. So the queue fills with incidents that resolved themselves hours ago.
That gap between "the PBX is fine" and "the ticket says it isn't" is corrosive. It inflates your open-ticket counts, poisons your SLA and time-to-resolution reporting, and trains everyone to distrust the board ("half of these are probably already fixed"). For an MSP, a PSA that doesn't reflect reality is worse than no PSA — it's a confidently wrong source of truth. The manual-ticketing tax isn't just the labour; it's the slow erosion of the one system your whole service desk is supposed to trust.
How closed-loop create + resolve works
Sikurd's PSA integration is built around one idea: the ticket should be born and die with the incident, untouched by human hands. Two automatic halves make that happen.
The open half — auto-create on alert
When Sikurd raises an alert on an instance — a trunk drops, a service stops, the instance goes unreachable, a backup goes stale — it immediately creates a ticket in your PSA. The ticket carries a clear title (the human-readable alert type plus the instance name), a description with the message, the instance FQDN, the severity, and the alert type, and a priority derived from severity. No one types anything. The ticket exists within seconds of the condition being detected.
The close half — auto-resolve on clear
This is the half almost nothing else does. Sikurd's alerting auto-resolves an alert on the next poll once the condition clears — the trunk re-registers, the service comes back, the instance answers again. The moment that happens, Sikurd reaches back into your PSA and resolves the exact ticket it opened, moving it to your configured "closed"/"complete"/"resolved" status. The loop closes itself. Your queue empties as fast as the fleet recovers.
One outage, one ticket (dedupe)
Real outages are messy: a single PBX going down can trip instance-down, trunk-down, service-down, and backup-stale alerts within the same minute. Naively, that's four tickets for one event — exactly the noise that buries an on-call queue. Sikurd dedupes instead. The first alert on an instance opens one ticket; every subsequent alert on that same instance is appended to it as a note. Crucially, the closing logic is sibling-aware: the ticket only resolves once every alert folded into it has cleared. If three of four conditions recover but one is still broken, the ticket stays open (with a note recording the partial recovery) until the last one heals. You get a faithful one-ticket-per-outage record, and it never closes early on a still-degraded PBX.
The reconcile sweep — for the rare stuck ticket
Auto-resolve can occasionally fail for reasons outside Sikurd's control: someone renamed a status in the PSA, the API had a transient hiccup, or a tenant changed their "complete" status ID. When that happens, Sikurd doesn't fail silently — it records the failure reason on the ticket so you can see, inside Sikurd, "this alert healed itself but the ticket is stuck open because <reason>." Then a one-click reconcile sweep walks every ticket that's resolved in Sikurd but still open in the PSA and retries the close against your current config. Fix the setting, run the sweep, and the backlog of stuck-open tickets clears in one pass.
Per-customer mapping, boards, queues, and priority
A closed loop is only useful if every ticket lands in exactly the right place. Sikurd gives you that control without making you babysit it.
- Per-instance company mapping. Each 3CX instance in Sikurd is mapped to a specific company / client / customer in your PSA. A ticket for "Acme Corp HQ" always opens under Acme's account — never a sibling tenant's. If an instance has no mapping, Sikurd deliberately skips ticket creation rather than guess, because a ticket filed against the wrong customer is worse than no ticket at all.
- Boards and queues. ConnectWise tickets open on the service board you name. Autotask tickets drop into the queue ID you specify. Point the loop at the right destination once and every future ticket follows.
- Status names you control. PSAs let you rename their status picklists, and that's exactly where naive integrations break on auto-close. Sikurd lets you set the open and closed status names for ConnectWise and the numeric "complete" status for Autotask, so even a heavily customized workflow closes cleanly. (HaloPSA and Syncro map to their standard resolved statuses.)
- Priority from severity. Alert severity maps straight to PSA priority — a critical alert opens at your top priority, a warning a notch below — so urgent incidents surface at the top of the board automatically.
There's also a quieter benefit to reading status the other way: when your help desk picks up a Sikurd-opened ticket and moves it off "New," Sikurd can see that and acknowledge the underlying alert — so the on-call rotation doesn't keep getting paged about a problem a human is already working.
The four PSAs — all fully implemented
These aren't stubs or "coming soon" logos. Each integration has a complete create-and-resolve implementation that the closed loop runs on:
- Autotask (Datto PSA). Auto-detects your API zone, opens tickets in your chosen queue, and closes them to a configurable "complete" status ID (so customized workflows resolve correctly). Supports threaded notes for the dedupe flow.
- ConnectWise Manage. Opens tickets on your named service board at the open status you configure and closes them to your configured closed status. Maps severity to ConnectWise's "1 - Critical" … "4 - Low" priority scale.
- HaloPSA. OAuth2 client-credentials auth, opens tickets against the mapped client, resolves to Halo's resolved status, with full company lookup for mapping.
- Syncro MSP. Opens tickets against the mapped customer and moves them to Resolved on clear, with a direct deep link back to the ticket.
You connect one PSA per Sikurd account. Whichever one you run, the behaviour is the same: tickets that open themselves on the alert and close themselves on the fix.
Why this keeps your PSA honest
The point of binding a ticket's lifecycle to the real state of the PBX is that your board stops drifting from reality. Open-ticket counts mean something again. Time-to-resolution metrics reflect actual recovery, not when a human happened to remember to click "close." Your techs stop spending the start of every shift triaging incidents that fixed themselves overnight. And the trust comes back: when the board says there's an open incident, there's an open incident.
For an MSP managing many customer PBXs, that's the difference between a PSA that documents your service and a PSA that creates work. Closed-loop ticketing puts the documentation on autopilot so your people can spend their time on the incidents that actually need a human.
Adjacent reading
- How to monitor 3CX trunk health — the kind of alert that opens (and closes) a ticket.
- AI voice alerts vs PagerDuty for 3CX MSPs — escalation for the incidents that can't wait.
- Best tools for managing multiple 3CX servers — where PSA integration fits in the wider toolkit.