How to Design ConnectWise Service Boards That Don't Fall Apart at Scale

I got a call last year from an MSP that had just crossed 55 technicians. Their ConnectWise instance had 34 service boards. Thirty-four. Some were created per client. Some were created per technician specialty. A few were created for one-time projects years ago and never decommissioned. Their dispatch team was spending more time figuring out which board a ticket belonged on than actually dispatching it.

When I asked the service manager how they reported on SLA compliance across the organization, she laughed. "We don't. We can't. The data is scattered across too many boards to mean anything."

That's what service board sprawl looks like at scale. And it doesn't happen because people are careless. It happens because every individual board creation decision made sense at the time. The problem is that nobody ever stepped back to look at the whole picture.

This post is about designing a board architecture that survives growth, based on what I've seen work (and fail) across dozens of ConnectWise environments.

Why Boards Break at Scale

To fix the problem, you need to understand why it happens. Service boards in ConnectWise aren't just containers for tickets. They're the foundation for:

• Routing logic (workflow rules reference specific boards)
• SLA policies (SLAs are applied per board)
• Dispatch views (dispatchers filter by board)
• Reporting (most reports are scoped to boards)
• Security roles (access control is board-level)
• Status workflows (each board has its own status set)

Every board you create multiplies the configuration surface area. A new board needs its own SLA configuration, its own status workflow, its own routing rules, and its own reporting setup. At 5 boards, that's manageable. At 15, it's a part-time job. At 30+, it's ungovernable.

The ConnectWise documentation covers board creation mechanics (ConnectWise Manage Documentation), but it doesn't tell you when you should or shouldn't create a new board. That's a design decision, and it's the one most MSPs get wrong.

The Two Board Architecture Models

In my experience, every ConnectWise board structure is some variation of two models: team-based boards or function-based boards. Understanding the difference is critical.

Team-Based Boards

Each board maps to a team or skill group. You might have a Help Desk board, a Network Engineering board, an Infrastructure board, and a Projects board. Tickets route to the board that matches the team responsible for the work.

Pros: Clear ownership. Each team owns their board and their queue. Dispatch is straightforward because the board tells you which team is responsible.

Cons: Tickets that need to move between teams require a board transfer, which can break SLA continuity and create confusing ticket histories. Reporting on a single client's experience requires pulling data across multiple boards.

Function-Based Boards

Each board maps to a type of work. You might have a Service (reactive) board, a Projects (planned) board, an Alerts (automated) board, and a Sales board. Tickets route based on what kind of work they represent, not who does the work. Team assignment happens at the ticket level, not the board level.

Pros: Simpler structure. Fewer boards means less configuration overhead. SLA policies map cleanly to work types. Client experience reporting is easier because all reactive support lives on one board regardless of which team handles it.

Cons: The dispatch view on a single board can get crowded. You need good use of sub-types, priorities, and team assignments to keep the queue navigable.

My Recommendation

For most MSPs, function-based boards scale better. The reason is simple: as you grow, you'll add more teams and specialties. With team-based boards, every new team means a new board, new SLAs, new workflow rules, and new reports. With function-based boards, a new team is just a new assignment option on the existing board structure.

I've seen MSPs successfully run 60+ technicians on 5-6 function-based boards. I've never seen an MSP successfully run 60+ technicians on 25+ team-based boards.

The Board Structure That Works at 50+ Techs

Here's the board architecture I recommend for MSPs that are scaling or already past the 30-tech mark. It's function-based with clear boundaries.

Board 1: Service Desk

This is your high-volume reactive board. Break/fix, incidents, service requests, how-do-I questions. Everything that clients submit or call in about lands here first.

Key design choices:

• Statuses: New, Triaged, In Progress, Waiting - Client, Waiting - Vendor, Scheduled, Resolved, Closed (8 statuses, no more)
• Triage happens here. Tickets that need specialist attention get reassigned to the appropriate team but stay on this board unless they're actually project work.
• SLAs are set at the priority level on this board, using the impact/urgency matrix to determine priority automatically

Board 2: Escalations

This is a separate board for a reason. Tickets that have breached SLA, require senior engineering, or involve complex multi-system problems get moved here. Having a dedicated escalation board gives you clean metrics on escalation volume, resolution time at the escalated tier, and engineer workload.

Key design choices:

• Tickets arrive here via workflow rule (SLA breach) or manual escalation by a tech
• Tighter SLA targets than the Service Desk board
• Assigned only to senior engineers and leads
• Every ticket on this board should have an internal note explaining why it was escalated

Board 3: Projects

Planned work with defined scope. Onboarding, migrations, infrastructure deployments, technology refreshes. Anything that has a start date, an end date, and a scope document.

Key design choices:

• Different status workflow: Scoping, Scheduled, In Progress, On Hold, QA/Review, Complete, Closed
• SLA is measured differently here (milestone-based, not response-time-based)
• Time entries on this board should map to project phases for profitability tracking
• Keep project tasks as child tickets under a parent project ticket for clean reporting

Board 4: Alerts / Monitoring

RMM-generated tickets, automated monitoring alerts, backup failures, patch compliance notifications. These come in at high volume and need a different handling workflow than human-generated tickets.

Key design choices:

• Auto-close rules for self-resolving alerts (server CPU spike that resolves within 15 minutes, for example)
• Consolidation rules to prevent 50 identical alerts from creating 50 identical tickets
• Different SLAs than the Service Desk (not every monitoring alert needs a 15-minute response)
• Techs should not need to manually close every resolved alert. Automation handles that.

According to industry data from ConnectWise's own benchmarking, MSPs that properly separate and auto-manage alert tickets reduce alert-related technician time by 30-40% compared to those who dump alerts into their main service queue (ConnectWise documentation and best practices).

Board 5: Internal

Internal IT, administrative tasks, procurement, HR-related tech requests. Work that serves the MSP itself rather than clients.

Key design choices:

• Simpler status workflow (New, In Progress, Done)
• No client-facing SLAs
• Used for tracking internal projects, tool evaluations, and operational improvements
• Keeps internal work visible without polluting client-facing metrics

Optional Board 6: Pre-Sales / Opportunities

If your sales process involves technical scoping or proof-of-concept work, a dedicated pre-sales board keeps that work visible and trackable without mixing it into the service or project queues.

That's 5-6 boards for an operation of any size. I've deployed this structure for MSPs ranging from 15 to 80 technicians and it holds up.

Status Workflows: The Rules

Statuses are the second most common source of board-related problems. Here are the rules I follow.

Rule 1: Every status must answer "who owns the next action?"

If a status doesn't make it immediately clear whether the ball is in the tech's court, the client's court, a vendor's court, or a manager's court, it's a bad status. "Pending" is a bad status. Pending what? Pending who? "Waiting - Client Response" is a good status.

Rule 2: No more than 10 statuses per board, aim for 7-8.

I've audited ConnectWise instances with 22 statuses on a single board. Nobody uses them correctly. Techs pick the one that seems closest to right, or they just leave everything in "In Progress" because they can't remember the difference between "Reviewing," "Under Investigation," "Researching," and "Analyzing." Those are four statuses that all mean the same thing.

Rule 3: Status names must be self-documenting.

Your newest hire should understand what a status means without looking it up. "New" is clear. "In Progress" is clear. "W/C" is not clear (I've actually seen this as a status, it meant "Waiting on Client"). "S2-ENG" is not clear (this was "Stage 2 - Engineering Review" at one shop).

Rule 4: Define explicit transitions.

Not every status should be reachable from every other status. A ticket shouldn't go from "New" directly to "Closed" without passing through "In Progress" first. ConnectWise supports status workflow transitions through the board configuration. Use them. Define the allowed paths and enforce them.

According to ConnectWise's own implementation guidance, the most efficient MSPs maintain between 6-9 statuses per board with clearly defined transition rules (ConnectWise Manage Setup Documentation).

When to Split a Board

Despite my preference for fewer boards, there are legitimate reasons to create a new one. Here's my decision framework:

Split when the work type needs a fundamentally different status workflow. Reactive service tickets and projects have different lifecycles. They need different statuses. That justifies separate boards.

Split when the SLA model is fundamentally different. Alert tickets and human-submitted tickets need different response targets. Different boards let you apply different SLA configurations cleanly.

Split when security or visibility requirements differ. If certain technicians should never see certain tickets (pre-sales pricing, for instance), board-level security roles are the cleanest way to enforce that in ConnectWise.

Do NOT split because:

• A client is "special" and wants their own board (use client-level reporting instead)
• A technician wants their own board (use assignment views and saved filters)
• A ticket type is "different" (use sub-types and categories within the existing board)
• You want cleaner reporting for one specific metric (build a report with filters instead of creating a board)

When to Merge Boards

If you're reading this and recognizing your environment in the "34 boards" story from the intro, here's how to consolidate without breaking things.

Step 1: Audit ticket volume per board

Pull a report showing ticket count by board for the last 90 days. Any board with fewer than 10 tickets per month is a candidate for merging. If it exists, you need to ask why. Is the work type legitimate but low-volume? Or is it a board that was created for a specific situation and never cleaned up?

Step 2: Map the status workflows

Lay out the statuses for each board side by side. You'll find that most of your boards use nearly identical status sets with minor variations. Those boards can share a single status workflow on a combined board.

Step 3: Identify the workflow rules that reference each board

This is the tedious but critical step. Every workflow rule, SLA policy, and report that references a board you're merging needs to be updated. Miss one, and you'll have silent failures.

Step 4: Merge in phases

Don't merge 20 boards into 5 in one weekend. Merge two boards at a time. Update the routing rules. Run for a week. Verify that tickets are landing correctly. Then merge the next two. This takes longer but dramatically reduces the risk of something going wrong at scale.

Step 5: Communicate the change

Tell your team before you merge boards, not after. Explain what's changing, why, and how their daily workflow will be affected. Techs who suddenly can't find their tickets because the board names changed will not thank you for the efficiency improvement.

The Reporting Test

Here's how I validate whether a board architecture works: try to answer these five questions using only your standard reporting.

1. What is our average first-response time across all reactive service tickets?
2. How many tickets are currently open per client?
3. What is our SLA compliance rate this month?
4. Which technician has the highest backlog?
5. How much time did we spend on project work versus reactive work this week?

If your board structure makes any of those questions hard to answer, something's wrong. With a clean function-based board architecture (Service Desk, Escalations, Projects, Alerts, Internal), every one of those questions is a single report with no cross-board gymnastics required.

With 34 client-specific boards? Good luck.

What This Looks Like in Practice

I worked with an MSP last year that went from 28 boards to 6. The migration took about three weeks of active configuration work, phased over six weeks to allow for testing between merges.

The results after 90 days:

• Dispatch time per ticket dropped from an average of 4 minutes to under 1 minute
• SLA compliance reporting went from "we don't really track it" to 94% across the organization
• The service manager recovered roughly 8 hours per week that had been spent managing board-specific configurations, workflow rules, and routing exceptions
• New technician onboarding went from "shadow someone for two weeks to learn which board to use" to "here are the five boards, here's what goes where"

Those results aren't unusual. They're what happens when you reduce complexity to what the operation actually needs instead of what accumulated over time.

Getting Started

If your ConnectWise instance has more boards than you need, start with the audit. Count your boards. Pull the ticket volume numbers. Map the status workflows. Identify the overlaps.

Then make a plan. You don't have to do this in a weekend. A phased consolidation over 4-6 weeks is more realistic and less risky. The goal isn't perfection on day one. The goal is a board architecture that you can explain to a new hire in under five minutes, that your dispatch team can navigate without a cheat sheet, and that produces clean reporting without cross-board workarounds.

If that sounds like more than you want to take on while simultaneously running your MSP, that's a fair assessment. Board consolidation is high-impact but time-intensive, and doing it wrong can disrupt your entire ticket flow.

---

PaxRig helps MSPs redesign their ConnectWise board architecture without disrupting daily operations. If your boards have outgrown your team, book a discovery call and I'll walk through what a clean structure looks like for your specific operation.