Start here · the basics

Kanban for MSPs

Tickets pile up, projects slip, and nobody can see who is drowning. Kanban fixes that for managed service providers: every job becomes a card, you cap what is in progress, and work actually finishes.

Tickets, projects, sales, internal jobs, procurement. Same board, same rules.

Drag the cards
Huddle board · tickets & tasks
Ready2
New laptop setupAcme Dental
DNS cutoverHarbor Law
In progress3 / 2
VPN not connectingRiverside Clinic
Mailbox migrationLakeside CPA
Firewall replacementSummit Tax Group
Completed1
Printer installHarbor Law

In Progress is over the WIP limit!
Focus on finishing instead of starting.

That's the whole idea!
Now imagine this live with your PSA.

The basics

So what is Kanban?

It is a way of running work where every job is visible as a card, the amount in progress is capped, and the team pulls the next priority instead of juggling everything at once. It is not just for service tickets. The same board runs projects, sales, internal improvements, and procurement, and the cards are your real work, not a copy you keep up to date by hand.

In one line

Make the work move, and keep it visible while it does.

Everything below is just how that happens on a board.

The core ideas

Three rules, and four things that make them work

None of this is experimental. Kanban started on Toyota's factory floor in the 1950s, then reshaped software teams, hospitals, and logistics. MSPs are just late to it. Here it is in plain terms. Flip the marked cards to see the real thing in TopLeft.

Start with three rules

To doDoingDone
Visualize the work shown in the TopLeft product
See in TopLeft
Rule 1

Visualize the work

Every piece of work becomes a card, whether it is a ticket, a project task, a deal, or an internal job. One board shows the whole operation, so nobody has to ask what to work on or chase a status in chat.

In progress2 / 2nextfull: finish one first
Rule 2

Limit work in progress

Cap how many cards can be in progress at once: a whole column, or each technician’s lane. When it is full, you finish before you start. Per-tech limits are what actually stop one engineer juggling ten open tickets. Stop starting, start finishing.

Next uppull the next card when you have room
Rule 3

Pull, not push

Instead of a dispatcher pushing a pile onto each tech, people pull the next most important card when they have room. Work is assigned by capacity, not guesswork.

Four things that make them work

To doDoingDone

Left-to-right flow

Cards move through stages: to do, doing, done. You watch work flow across the board, and a card that stops moving is a problem you can see immediately.

AcmeHarborClinic
Swimlanes shown in the TopLeft product
See in TopLeft

Swimlanes

Group the board into rows by client, technician, or priority. The same cards, sliced the way the conversation needs: per-client for a review, per-tech for dispatch.

10 min

Daily huddles

A daily stand-up at the board, 10 to 15 minutes when the team comes prepared. They move cards, surface blockers out loud, and agree what gets pulled next.

Throughput upCycle time down
Flow metrics shown in the TopLeft product
See in TopLeft

Flow metrics

Cycle time, how long a card takes to cross the board, and throughput, cards finished per week, tell you whether changes are working. Numbers, not gut feel.

Not just tickets

One board pattern, every kind of work

Kanban is not a service-desk trick. Anything that moves through stages can live on a board with the same three rules: make it visible, limit what is in progress, pull the next priority. These are the boards MSPs run most.

Service

Reactive tickets triaged and pulled by priority, so nothing falls through and SLAs hold. Run the whole service desk on one board.

Projects

Onboardings, migrations, and rollouts with stages and dependencies on the board, and real capacity behind the dates you give clients.

Sales

Your pipeline as a board. Deals visible by stage, so nothing stalls in proposal-sent for three weeks. You will not WIP-limit sales the way you do the service desk, but you will see the stuck deals.

Internal improvements

The "we should fix that" list that never gets done. Put it on a board, cap it, and it finally moves instead of living in one person’s head.

Procurement

Hardware and license orders tracked from request to received, so nobody waits on a mystery PO and the install does not stall.

The hard case

The engineer who owns both project work and service tickets is where most MSPs struggle: the loud ticket always wins and the migration slips a week. Put both streams on one board, in that person’s lane, and project work stops losing to the noise.

In practice

What a week looks like with a board

Once the habits land, the day runs differently. This is the rhythm MSPs describe after Kanban becomes how they work.

Walk in and know what to work on

A short daily huddle at the board starts the day. Everyone sees what is in motion and what is next, no long status meeting required.

Finish before you start

WIP limits keep each person driving a few cards to done instead of leaving ten half-open. Work actually closes.

Blockers surface the same day

A card that stops moving stands out immediately, so a stuck project gets unblocked that morning rather than a week later.

Give real start dates

Capacity is on screen, so when a client asks when you can begin, you give them an answer you can keep.

Reality check

A P1 will blow up the plan by 10am. Kanban does not pretend otherwise. When the emergency lands, a visible board with WIP limits means everyone can see what got bumped and why, instead of the schedule quietly falling apart. The board absorbs the interrupt. A calendar cannot.

For the owner: when work finishes instead of stalling at 80 percent, the same team clears more. That is capacity you would otherwise hire for, plus start dates you can keep and a way to spot overload before someone burns out and quits.

A real TopLeft board, swimlanes by client
A TopLeft Kanban board with swimlanes grouping cards by client

The daily habit

The daily huddle that keeps the board honest

If WIP limits are the one rule, the daily huddle is the one ritual. It is a short stand-up at the board, and it is where the methodology actually lives. Skip it and the board slowly drifts out of date.

What it is

Ten minutes most mornings, fifteen at the most, the whole delivery team at the board. It only stays that short when people come prepared, with their tickets already in the right status. You do not read status out loud. You walk the board.

  1. 1Start at the right. Anything finished since yesterday? Clear it out of Done.
  2. 2Walk left through In progress. What moved, what is stuck, who needs a hand today?
  3. 3Name blockers out loud and decide who clears each one.
  4. 4Only then pull new work, up to the WIP limit, by priority.

Why it works

  • Blockers surface the same morning instead of a week later.
  • One short stand-up replaces the pile of status meetings.
  • It keeps WIP honest. When a column is full, the team finishes before it starts.
  • Leadership gets a real pulse on delivery without interrupting anyone.
  • The cadence builds accountability, with the board as the single source of truth.

The huddle is short because the board did the explaining. No prep, no slide, no recap.

The part tools skip

The board is 10%. The habits are the other 90%.

Kanban shares a family with Lean and Agile, and you do not need to keep them straight. In MSP terms: Kanban makes the work visible and limits what is in progress. Lean means cutting the steps that do not help the client. Agile means adjusting fast when the day changes. The board is where all three show up.

Which is why buying a board and stopping there rarely moves the numbers. The change is in the daily huddle, the pull habit, and the WIP limit the team actually holds to.

We run an MSP ourselves. This is the playbook we use.

Wim Kerkhoff, founder of TopLeft and MSP owner.

See it on your own board

The tool

10%

The board, the swimlanes, the dashboards, the sync

Most tool evaluations stop at the waterline.

The methodology

90%

Daily practices

Daily huddle · pull-based workflow · WIP limits · single-tasking

Workflow design

Stages and swimlanes · triage and dispatch · capacity planning

Roles and accountability

Dispatcher freed from scheduling · leadership cadence · team rhythm

Mindset and culture

Lean mindset · continuous improvement · flow over rigid perfection

Common questions

Questions MSPs ask

What is Kanban for an MSP?
Kanban is a way of running work where every ticket and project task is a card on a board. Cards move left to right as the work gets done, you cap how many can be in progress at once, and the team pulls the next most important card instead of being handed a pile. It sits on top of your PSA, so the cards are your real work.
Is Kanban just Trello with extra steps?
No. Columns alone are not Kanban. The discipline is in the WIP limits, pulling work instead of pushing it, swimlanes by client or tech, and flow metrics. A generic board also has no live PSA data, so it goes stale. Kanban on your PSA stays in sync.
Do I have to leave my PSA?
No. The board reads from and writes back to ConnectWise, Autotask, or HaloPSA. Tickets and time stay in the PSA. The board is the visual layer on top, not a replacement, and there is no double entry.
How do WIP limits actually work?
A WIP limit caps how many cards can be in progress at once. You can cap a whole column, or cap each technician’s lane. When it is full, you cannot start new work until something finishes. Per-tech limits are what actually change behavior: they stop one engineer juggling ten open tickets. The phrase to remember is stop starting, start finishing.
What is throughput in Kanban?
Throughput is the number of cards a team finishes in a given week. Watch it next to cycle time: rising throughput with steady or falling cycle time means flow is improving. Those two numbers tell you whether a change actually helped.
What is the difference between Kanban and Scrum?
Scrum batches work into fixed sprints with planning and review ceremonies. Kanban is continuous flow: work enters and leaves the board as capacity frees up, with no sprint boundary. Most MSP work is continuous and interrupt-driven, so Kanban tends to fit service delivery better.
How long does it take to roll out?
Teams usually start simple: four or five columns and one or two WIP limits, then add swimlanes and metrics over a few weeks. The slowest part is the habit change, the daily huddle and the shift to pulling work, which is exactly why coaching matters more than the software.
How do I get my team to actually use it?
Honestly, this is the hard part, and it is a people problem, not a software one. Most Kanban rollouts die the same way: the board goes stale because nobody updates it, so people drift back to the PSA and chat. It survives when the daily huddle is non-negotiable and a manager holds the WIP limit when a tech wants to start just one more. Start small and let early wins pull the rest of the team in.
Does Kanban only work for tickets and projects?
No. The same board pattern fits any work that moves through stages: service tickets, project tasks, sales deals, internal improvement initiatives, and procurement. Most MSPs run several boards, one per kind of work, with the same rules on each.

See Kanban on your own board

Book a 30-minute demo. We walk through a live board built the way an MSP runs it, show how WIP limits and swimlanes work, and connect it to how you run delivery today. No commitment.

Prefer to read first? More Kanban articles on the blog →

SOC 2 Type II compliant. Your tickets and time stay in your PSA.