PSA Health Checks: What We Look For and Why It Matters

A PSA health check is the most common starting point for the work I do. It's also the most misunderstood. People expect a quick glance and a thumbs up or thumbs down. What they actually get is a detailed analysis of how their PSA is configured versus how it should be configured for their specific business — and a prioritized list of what's costing them the most money or time.

Here's what I actually look at and why.

Ticket flow architecture

I start by mapping how tickets move through the system from creation to closure. Not how the documentation says they should move — how they actually move based on real ticket data.

I pull a sample of 100–200 recent closed tickets and trace the lifecycle: creation source (email, portal, phone, RMM alert), initial board assignment, status transitions, assignment changes, time entry patterns, and closure path.

What I'm looking for: bottlenecks where tickets sit in a status for too long, tickets that bounce between multiple techs (indicating a routing or skill-matching problem), tickets that skip expected statuses (indicating the workflow isn't being followed), and tickets closed without time entries (indicating work isn't being captured).

This analysis usually takes about an hour. The findings are almost always some combination of: routing gaps (tickets landing on the wrong board or with the wrong tech), status compliance issues (techs skipping statuses because the workflow has too many steps), and time entry gaps (work being done but not logged).

Agreement and billing configuration

This is where the financial findings live, and it's the section that pays for the health check.

I review every active agreement against three dimensions:

Structural integrity. Is the agreement type appropriate for the service delivery model? Are additions configured for variable-count products? Are exclusions defined for out-of-scope work? Are the billing cycle and terms correct?

Data accuracy. Do the quantities in the agreement additions match what's actually deployed? I cross-reference against vendor consoles, RMM agent counts, and M365 license data. Every discrepancy is documented with the monthly dollar impact.

Coverage rules. Are the board/type coverage rules correctly configured so that in-scope work gets applied to the agreement and out-of-scope work gets flagged for separate billing? Misconfigured coverage rules are one of the most common sources of revenue leakage.

On average, I find between $2,000 and $8,000 per month in billing discrepancies during this section. The MSP owner usually knows billing "isn't perfect" but doesn't know the specific number until someone goes through it line by line.

Workflow automation audit

I review every active workflow rule or automation. For each one, I check whether it's still relevant to a current business process, whether it conflicts with other rules, whether it's firing correctly (based on ticket data), and whether it's documented.

I also identify automations that should exist but don't — the manual processes that could and should be handled by workflow rules. Auto-routing, SLA escalation, stale ticket alerting, client follow-ups — the standard set that I described in my workflow rules post.

The typical finding: MSPs have either too few workflow rules (everything is manual) or too many poorly maintained rules (some working, some broken, some conflicting, nobody sure which is which). Both situations cost time. The fix is different for each.

Integration health

Every active integration gets checked for three things: is it running (no sync errors or failures), is it accurate (data matches between systems), and is it complete (all necessary data types are flowing).

I focus on the high-value integrations: PSA to accounting, PSA to RMM, and PSA to any vendor portal that affects billing. A broken accounting sync means manual invoice creation. A broken RMM integration means alert-to-ticket gaps. A broken vendor sync means billing discrepancies.

I also check for integrations that should exist but don't. If the MSP is using a tool that has a PSA integration available and it's not configured, that's a recommendation.

Data hygiene

PSA databases accumulate garbage over time. Decommissioned configurations still marked as active. Contacts for people who left the client's company years ago. Members (internal users) who are inactive but still appear in dropdowns. Custom fields with data nobody uses. Boards with no recent tickets.

Data hygiene doesn't feel urgent until it affects something that matters. Stale configurations skew per-device billing. Inactive members clutter the assignment interface. Unused custom fields slow down ticket creation because techs have to scroll past them.

I document the cleanup needed and estimate the effort. Some of it's quick (deactivate old members). Some of it's tedious but necessary (review and clean up the configuration item database).

The deliverable

Every health check ends with a written report organized into three tiers:

Critical — findings that are directly costing money or creating significant operational risk. These get fixed first. Typical examples: billing discrepancies, broken accounting sync, missing workflow automation for high-volume ticket types.

Important — findings that are costing time or reducing efficiency but aren't causing direct revenue impact. Fix within 30 days. Typical examples: board consolidation, status cleanup, integration health issues.

Recommended — improvements that would make things better but aren't causing active problems. Fix when bandwidth allows. Typical examples: client portal configuration, additional reporting, custom field cleanup.

Each finding includes the specific problem, the business impact (in dollars or hours where possible), and the specific fix — not a vague recommendation, but the actual configuration change or process update needed.

---

A PSA health check is PaxRig's recommended starting point. Book a discovery call and I'll tell you whether it makes sense for your situation.