Round-robin gets assignment off the ground. It's fair, predictable, and dumb — it doesn't know who's actually buried, who's free, or who could realistically pick up the next ticket today versus next Tuesday. NextAvailable is the upgrade. It picks the user who will actually have an open slot first, based on real calendar load. To do that, it needs to see your team's pending work — which is what floating todos are for.
Problem: Round-robin assigned the last six tickets to Bob because it was his turn. Bob's calendar is back-to-back for the next two days. Alice has open slots all afternoon. The customer who got Bob's ticket waits 36 hours. The system was fair, and the customer experience was bad.
Horizon's answer: NextAvailable assignment. Instead of rotating turns, it looks at each candidate's actual calendar, asks "when could this user fit a Y-minute block of work?", and picks the user whose first-available window comes soonest. Bob is busy — skipped. Alice is free this afternoon — picked. The customer gets a real-world-fastest response, not just a rotation-fair one.
NextAvailable only works if Horizon can see the team's pending workload. Scheduled todos are visible automatically (they have committed times). The work that isn't on a calendar yet — the queue of "tickets I haven't started yet but need to do" — is invisible unless you model it explicitly. That's where floating todos come in.
Problem: An agent has 14 open tickets. None of them have scheduled todos because none have committed customer times. Their calendar looks empty all afternoon. NextAvailable thinks they're free. They're not.
Horizon's answer: Floating todos. A floating todo is "this ticket needs N minutes of work, sometime". It doesn't have a fixed time — it has a rank (Critical / Promoted / Normal / Demoted / Buried) and a duration estimate. Floating todos are how the agent's actual workload becomes visible to the calendar layer.
When a floating todo exists for every open ticket on a team, NextAvailable can answer the real question: "who has the next gap big enough to fit this new ticket?" Without floating todos, NextAvailable degrades to the same blindness as round-robin.
The right setup is: as a ticket gets assigned (or gets work pending), a floating todo is auto-created for it with a duration estimate. The estimate comes from a Time Estimate Policy (the next lesson). The floating todo represents the workload, lives on the agent's queue, and either gets converted into scheduled work or gets closed when the ticket closes.
NextAvailable doesn't just look at empty time on the calendar. It runs a configurable strategy that decides which existing items count as blocking the search for an open window:
| Strategy | What blocks the candidate's calendar |
|---|---|
| Ignore Floating ToDos | only scheduled events block; floating work is ignored |
| All ToDos Blocking | every todo blocks — scheduled events plus all floating todos |
| Higher Priority Blocking | scheduled events plus floating todos ranked higher than the new ticket — lower-ranked floating work doesn't block |
| Priority Queue | floating todos are treated as a priority-ranked queue and blocking is computed accordingly |
For a typical MSP service desk, Higher Priority Blocking is the most useful — "a new Critical ticket can interrupt Normal floating work, but not the other way around". Start there unless you have a specific reason to pick differently.
The plugin also takes:
You already created a helpdesk assignment policy with round-robin in the previous lesson. Upgrading it is an in-place change:
The same level, same team, same SIDEWAYS direction. Just a smarter user-picking method.
Don't upgrade the alerts policy. Alerts are about speed of acknowledgement, not fit into someone's day. Round-robin (or even round-robin with a priority-on-call schedule) is the right fit for alerts. Leave it alone.
NextAvailable is only as good as the floating todos backing it. You have two ways to create them:
For NextAvailable to be reliable across the team, every active ticket should have a floating todo. That only happens consistently if the lifecycle creates them automatically.
After switching to NextAvailable:
If recommendations look identical to what round-robin would have picked, your floating todos probably aren't there yet. Check that the lifecycle is creating them and that they have realistic durations.
The most common NextAvailable misconfiguration: floating todos exist but have no durations (or all have the same default duration). NextAvailable can't differentiate workload between users — Bob with 14 small floating todos looks the same as Alice with 2 huge ones. The Time Estimate Policy in the next lesson is what makes durations meaningful. Until that's set up, NextAvailable runs at reduced accuracy.
Tip: Don't make the leap to NextAvailable until floating todos are reliably created and have meaningful durations. Going early gets you the configuration overhead with none of the upside — NextAvailable degrades to round-robin behavior when it can't see real workload. The order is: get round-robin stable → set up automatic floating todo creation in the lifecycle → set up the Time Estimate Policy → then flip the method to NextAvailable.