Get Started
Sales Suite
Field Ops
Marketing
Service CRM
Integrations & Apps
FloStack
Distribution Engine: How Weighted Distribution Works
1. Feature Overview
Weighted distribution lets you assign leads to users in a configured ratio rather than equally. For example, a senior rep with a weight of 8 receives more leads than a junior rep with a weight of 2, in proportion to their weights. This article explains how the algorithm distributes leads under normal conditions and how it handles users going offline and coming back online.
Weighted distribution is one of the user selection methods available in the Distribution Engine. To configure it, see the Distribution Engine article.
2. Prerequisites
- To enable Distribution Engine, contact support@leadsquared.com.
- Distribution Engine is only available on NextGen.
3. How it works
Weighted distribution uses a Weighted Round Robin algorithm. Instead of giving one user all their leads before moving to the next, the system interleaves assignments so that the configured ratio emerges gradually.
The algorithm works by maintaining a running credit score for each user. On every lead assignment:
- Each user’s configured weight is added to their current credit.
- The user with the highest credit is selected to receive the lead.
- The total weight (sum of all users’ weights) is subtracted from the selected user’s credit.
- The cycle repeats for the next lead.
This self-corrects continuously. A user who has just received a lead is penalised in the next round, giving other users a chance to surface.
Example: How the first two leads are assigned
Consider five users with weights 8, 7, 5, 5, and 2. The total weight is 27. All credits start at 0.
Lead 1
- Step 1, add each user’s weight to their credit. User 1 = 0 + 8 = 8, User 2 = 0 + 7 = 7, User 3 = 0 + 5 = 5, User 4 = 0 + 5 = 5, User 5 = 0 + 2 = 2.
- Step 2, select the user with the highest credit. User 1 has the highest credit at 8, so User 1 receives the lead.
- Step 3, subtract the total weight from the selected user. User 1’s credit becomes 8 − 27 = −19. The other users’ credits stay where they are.
At this point you might expect User 1 to win again on the next lead, since their weight is the highest. They do not, because the credits carry forward.
Lead 2
- Step 1, add each user’s weight to their current credit. User 1 = −19 + 8 = −11, User 2 = 7 + 7 = 14, User 3 = 5 + 5 = 10, User 4 = 5 + 5 = 10, User 5 = 2 + 2 = 4.
- Step 2, select the user with the highest credit. User 2 now has the highest credit at 14, so User 2 receives the lead.
- Step 3, subtract the total weight from the selected user. User 2’s credit becomes 14 − 27 = −13.
User 1’s negative credit from lead 1 keeps them out of contention for a few rounds. As their weight gets added each round, their credit climbs back up, and they win again once it overtakes the others. This is how the ratio plays out smoothly instead of in bursts.
Note:
- Credits can go negative, as the −19 above shows. This is normal. A negative credit is simply the system’s way of remembering that a user has received more than their share recently. Over the course of a full cycle, the credit returns to zero.
- When two users have the same credit at the moment of assignment, the system uses a consistent tie-breaking rule so the outcome is predictable across runs.
4. Standard distribution Example
Consider five users configured with the following weights:
| User | Weight | Share of leads |
|---|---|---|
| User 1 | 8 | 30% |
| User 2 | 7 | 26% |
| User 3 | 5 | 18% |
| User 4 | 5 | 18% |
| User 5 | 2 | 8% |
| Total | 27 | 100% |
Tracing the first few assignments
All credits start at zero. The trace below shows the first six lead assignments. The same logic continues for every subsequent lead.
| Lead | Credits before selection | Selected | Credits after |
|---|---|---|---|
| 1 | U1=8, U2=7, U3=5, U4=5, U5=2 | User 1 | U1=−19, U2=7, U3=5, U4=5, U5=2 |
| 2 | U1=−11, U2=14, U3=10, U4=10, U5=4 | User 2 | U1=−11, U2=−13, U3=10, U4=10, U5=4 |
| 3 | U1=−3, U2=−6, U3=15, U4=15, U5=6 | User 3 | U1=−3, U2=−6, U3=−12, U4=15, U5=6 |
| 4 | U1=5, U2=1, U3=−7, U4=20, U5=8 | User 4 | U1=5, U2=1, U3=−7, U4=−7, U5=8 |
| 5 | U1=13, U2=8, U3=−2, U4=−2, U5=10 | User 1 | U1=−14, U2=8, U3=−2, U4=−2, U5=10 |
| 6 | U1=−6, U2=15, U3=3, U4=3, U5=12 | User 2 | U1=−6, U2=−12, U3=3, U4=3, U5=12 |
Result after a full cycle
A full cycle equals the sum of all weights. In this configuration, the total weight is 27, so the cycle completes after 27 lead assignments. At the end of the cycle, all credits return to zero and the pattern repeats.
| User | Assignments in cycle | Configured weight | Matches the ratio |
|---|---|---|---|
| User 1 | 8 | 8 | Yes |
| User 2 | 7 | 7 | Yes |
| User 3 | 5 | 5 | Yes |
| User 4 | 5 | 5 | Yes |
| User 5 | 2 | 2 | Yes |
Key behaviours to note
- Smooth interleaving, not batching:Â User 1 has the highest weight, but the system does not assign all eight of User 1’s leads in a row. Assignments are spaced out so that other users surface in between.
- No user is starved:Â Even with a weight of only 2, User 5 is guaranteed to surface at predictable intervals within each cycle.
- Equal weights produce equal assignments:Â User 3 and User 4 have the same weight, so they receive the same number of leads per cycle.
- The cycle length equals the total weight:Â With weights summing to 27, one full cycle completes after 27 leads. At 100 leads per day, the cycle completes multiple times each day, keeping the ratio accurate even over short windows.
5. When users go offline and come back
In real-world usage, users move between available and unavailable states throughout the day. The algorithm handles this with two rules:
- When a user goes offline, their credit is frozen. No weight is added to their credit while they are unavailable.
- When a user comes back online, they re-enter with their frozen credit. There is no burst of catch-up leads, and no penalty for being away.
The following scenario uses the same five users from the earlier example and walks through three phases of availability.
| Phase | Leads | Available users |
|---|---|---|
| Phase 1 | 1 to 10 | User 1, User 4, User 5 |
| Phase 2 | 11 to 22 | All five users |
| Phase 3 | 23 onwards | User 1, User 4, User 5 |
Phase 1: User 2 and User 3 are offline
Only User 1, User 4, and User 5 are active. The total active weight is 15 (8 + 5 + 2). User 2 and User 3 sit frozen at a credit of 0.
Over the first 10 leads, the active users receive assignments in roughly their configured ratio of 8:5:2.
| User | Assignments in Phase 1 | Status |
|---|---|---|
| User 1 | 6 | Active |
| User 2 | 0 | Offline (credit frozen at 0) |
| User 3 | 0 | Offline (credit frozen at 0) |
| User 4 | 3 | Active |
| User 5 | 1 | Active |
At the end of Phase 1, the credit state is: User 1 = −10, User 2 = 0 (frozen), User 3 = 0 (frozen), User 4 = 5, User 5 = 5.
Phase 2: All five users are online
User 2 and User 3 rejoin the pool. They re-enter at their frozen credit of 0 and start competing normally from lead 11 onwards. The total active weight is now 27.
Over the next 12 leads, the assignments distribute as follows:
| User | Assignments in Phase 2 | Status |
|---|---|---|
| User 1 | 3 | Active |
| User 2 | 3 | Active (re-entered) |
| User 3 | 2 | Active (re-entered) |
| User 4 | 3 | Active |
| User 5 | 1 | Active |
At the end of Phase 2 (after lead 22), User 2 and User 3 go offline again. The credit state at this moment is: User 1 = 5, User 2 = 3 (frozen), User 3 = 6 (frozen), User 4 = −16, User 5 = 2.
Phase 3: User 2 and User 3 go offline again
The active pool returns to User 1, User 4, and User 5. Notice that User 4 enters this phase with a credit of −16, because it was assigned lead 22 just before the phase change. User 1 enters with a credit of 5.
As a result, User 1 receives several of the early leads in this phase while User 4’s negative credit gradually unwinds. Over the next 8 leads, the distribution is:
| User | Assignments in leads 23 to 30 | Status |
|---|---|---|
| User 1 | 5 | Active |
| User 4 | 2 | Active (recovering from −16 credit) |
| User 5 | 1 | Active |
Over the next full cycle, the ratio between User 1, User 4, and User 5 returns to the configured 8:5:2.
6. Things to keep in mind
1. No backfill for missed leads
When a user is offline, they do not accumulate a queue of leads waiting for them. The system does not compensate when they return. They simply rejoin the active pool at their frozen credit and compete normally from that point onwards.
2. No burst on re-entry
Because credits are frozen rather than inflated during offline periods, a returning user does not receive a sudden flood of leads. They re-enter at their previous credit and surface naturally over the next few cycles.
In the scenario above, User 2 was offline for the first 10 leads. When User 2 came back online, their credit was still 0, the same value it had when they went offline. On lead 11, User 2’s weight of 7 was added on top, bringing them to 7. They did not receive an immediate lead because other users had higher credits at that point. User 2 surfaced naturally a couple of leads later, in line with the configured ratio.
3. Credit carries forward across phases
When the active pool changes, the credits of the users who remain online are preserved. This means a user who was assigned a lead immediately before a phase change will start the next phase with a negative credit, and may receive fewer leads in the short term. Likewise, a user who was waiting their turn enters the next phase with positive credit and may receive more leads early on.
In the scenario above, User 4 was assigned lead 22 right before User 2 and User 3 went offline. This left User 4 with a credit of −16 entering Phase 3. User 1, on the other hand, entered Phase 3 with a credit of 5. As a result, User 1 received most of the early leads in Phase 3 while User 4’s negative credit gradually recovered. By the end of the next full cycle, the ratio between User 1, User 4, and User 5 returned to the configured 8:5:2.
This is the expected behaviour. The system is not over-assigning to User 1, it is honouring the credit that had already built up before the phase change.
4. Fairness is eventual, not instantaneous
Availability changes can produce short-term imbalances. The algorithm does not force an immediate correction. Instead, the credit system absorbs the disruption and the ratios converge back to the configured weights over the next cycle.
Any Questions?
We’d love to answer your questions or hear your own unique use cases. Feel free to share your experiences in the comments section below.