Configure Lead Distribution

Use lead distribution when new enquiries should move from an open queue to the right salesperson without manual sorting. Brixi can distribute leads through workflow automation, either by assigning the lead directly or by asking eligible users to claim it within a set time.

Lead distribution is most useful for leads from portals, ads, website forms, WhatsApp, imports, and other connected sources where response speed matters. A good setup decides which leads enter the workflow, which rule they match, who is eligible to receive them, what happens when nobody can take them, and how managers review the outcome later.

Think of lead distribution as a decision path: the workflow finds the right leads, the distribution rules decide the right owner group, the assignment model decides whether the lead is assigned or claimed, and the default user catches anything that cannot be routed safely.

Entry pointAutomation -> Workflows

Article summary	Details
Best for	Sales managers and account admins setting up lead routing.
Main outcome	New leads are assigned or offered for claim automatically.
Roles	Admin, sales manager, sales agent.
Requires	Workflow access, eligible users or teams, and a clear lead source or rule.
Related reports	Workflow runs, lead source reports, owner activity, response time, and conversion reports.

Who Can Do This

Account admins and sales managers usually configure distribution rules because they control team access, owner assignment, source routing, and escalation behavior. Sales agents receive leads from the workflow or claim leads when the rule requires acceptance.

If you cannot see Automation, Workflows, or the owner fields used in a distribution action, ask your admin to confirm your role and permissions.

What Lead Distribution Controls

Distribution detail	Why it matters
Trigger	Decides when the workflow starts, such as when a contact or lead is created.
Conditions	Limits routing by source, campaign, location, product, product interest, ad ID, ad group ID, project, enquiry type, team, budget, or other available lead fields.
Rules	Define which matching leads go to which users, teams, claim queues, or default user.
Rule order	Decides which rule wins when a lead could match more than one rule.
Eligible users	Defines who can receive or claim the lead.
Routing method	Decides whether the lead is assigned directly, rotated across a group, sent to a team queue, or offered for claim.
Business hours	Prevents leads from being routed to unavailable teams when your process requires live response.
Claim window	Sets how long a user has to claim before the lead moves to the next rule or fallback.
Default user	Keeps the lead accountable when no rule matches, no eligible user is available, or no one claims it.
Follow-up actions	Creates the next task, notification, message, or manager alert after distribution.

How Brixi Chooses an Owner

When a lead arrives, Brixi does not randomly assign it. The automation follows the setup you define. Understanding this order helps you troubleshoot almost every routing issue.

Step	What happens	What to check if it looks wrong
1. Workflow enrollment	The lead must match the workflow trigger, such as a new contact or new lead.	Confirm the workflow is published and the lead was created in the way the trigger expects.
2. Workflow conditions	The workflow checks broad conditions before the distribution action, such as source or campaign.	Confirm the lead has the same field values your condition expects.
3. Distribution rule matching	Brixi checks distribution rules in order and uses the first rule that matches.	Confirm the most specific rule is above broader rules.
4. Assignment or claim	Brixi assigns directly, rotates to an eligible user, or opens a claim opportunity depending on the model.	Confirm users are active, eligible, and available under the rule settings.
5. Default user fallback	If no rule can assign the lead, the default user receives it.	Confirm the default user is active and monitored.

The workflow trigger and conditions decide whether the lead reaches distribution at all. The distribution rules decide where the lead should go once it gets there. This separation is important: if a lead never enters the workflow, changing the distribution rule will not fix it. If the lead enters the workflow but reaches the wrong owner, review the rule conditions, rule order, and default user.

Choose a Distribution Model

Brixi supports two common lead distribution models.

Model	Use it when	Avoid it when	What the user sees
Non-claim-based distribution	Every matching lead should be assigned immediately to an owner or team.	Users must actively confirm they can work each lead before ownership changes.	The lead appears as assigned to the selected user, usually with a task or notification.
Claim-based distribution	Multiple users are eligible, but ownership should go to the first available user who accepts the lead.	Leads need guaranteed ownership immediately and claim delays would hurt response time.	Eligible users receive a claim notification or queue item and one user claims ownership.

Non-Claim-Based Distribution

Use non-claim-based distribution for high-volume sources, assigned territories, fixed teams, or processes where the system should decide the owner without asking users to accept first. This model is simple and predictable: the workflow matches the lead, chooses the owner based on your rule, and updates ownership immediately.

This is a good fit when managers already know who should handle each source, when teams work fixed shifts, or when speed matters more than user choice.

Common non-claim patterns include:

• Round-robin assignment across an inside-sales team.
• Source-based assignment, such as website leads to one team and ad leads to another.
• Territory assignment, such as city or branch-based routing.
• Senior-agent assignment for premium campaigns or high-budget enquiries.
• Manager assignment for leads that require review before sales follow-up.

Claim-Based Distribution

Use claim-based distribution when availability changes throughout the day or when you want agents to actively accept a lead before ownership is final. The workflow offers the lead to eligible users, waits for a claim, then assigns the lead to the user who claims it.

This is a good fit for shared queues, walk-in enquiries, inbound call-back pools, or teams where the first available salesperson should take action. Always set a fallback so unclaimed leads do not stay idle.

Common claim-based patterns include:

• A shared inbound queue where the first available user claims the lead.
• A branch or floor team where availability changes throughout the day.
• Time-sensitive enquiries where the fastest responder should own the lead.
• A specialist queue where only trained users can claim certain leads.
• A manager-reviewed queue where unclaimed leads escalate after the claim window.

Plan Distribution Rules

A distribution rule is the matching logic that tells Brixi where a lead should go. In automation, the workflow decides when the distribution should run, and the distribution rules decide who should receive or claim the lead.

Use one rule when all matching leads can go to the same team. Use multiple rules when different sources, campaigns, locations, products, budgets, or teams need different owners.

Rule setting	How to use it
Rule name	Use a clear name such as "Facebook - West team" or "Website - Senior agents".
Match conditions	Choose the lead details that must match the rule, such as source, campaign, ad ID, ad group ID, product, product ID, project, enquiry type, city, product interest, lead stage, budget, or tag.
Assigned users or team	Select the users, group, or team that can receive the lead when the rule matches.
Distribution method	Choose direct assignment, rotation, claim-based assignment, or another available method in your workspace.
Business hours	Decide whether the rule should run only when the selected team is working.
Claim window	For claim-based rules, decide how long users have to claim before the rule moves on.
Default user	Select the user who should receive the lead when no rule matches or the matching rule cannot assign it.

Rule order matters when more than one rule could match the same lead. Put the most specific rules first, such as campaign-specific or city-specific rules. Put broader catch-all rules later. The default user is the final safety net, not the main routing strategy.

Good rule design usually follows these principles:

• Start with the business decision: source, territory, product, budget, campaign, or language.
• Keep each rule easy to explain in one sentence.
• Avoid combining too many unrelated conditions in one rule.
• Put high-priority or narrow rules above broad rules.
• Keep a broad rule near the end only if it is truly safe for all remaining leads.
• Use the default user for exceptions, not for normal daily routing.
• Review unmatched leads regularly; they usually reveal missing source data or rules that are too strict.

Example rule order:

1. Google Ads - Premium campaign routes to senior agents.
2. Website leads - Mumbai routes to the Mumbai sales team.
3. All website leads routes to the inside-sales team.
4. Default user receives anything that does not match or cannot be assigned.

Match Conditions

Match conditions are the lead details Brixi checks inside a rule. They should use fields your team reliably captures. If a field is often blank or inconsistent, a rule that depends on that field may miss leads and send them to the default user.

Reliable conditions are usually:

• Source, such as website form, Facebook, Google Ads, WhatsApp, or portal.
• Campaign, when campaigns are named consistently.
• Ad ID, when a specific ad should route to a specific team or owner.
• Ad group ID, when leads from a set of ads should share the same routing rule.
• Product or product ID, when the customer is interested in a specific product, service, plan, property type, or inventory item.
• Project, when the customer is enquiring about a specific project or inventory group.
• Interested In, when the lead form or integration captures what the customer is interested in.
• City, branch, location, or service area.
• Product, project, service, or interest.
• Team or business unit.
• Budget or lead score when those values are captured before distribution.
• Tags added by an integration, import, form, or earlier workflow step.

Your workspace may show these fields with readable labels such as Ad ID, Ad Group ID, Product, Product ID, Project, and Interested In. Use Interested In when a rule depends on what the customer selected or asked about.

Be careful with free-text fields. If one form sends "Mumbai" and another sends "mumbai city", the rule may not behave the way managers expect. Standardize important fields before using them for routing. ID-based fields such as ad ID, ad group ID, and product ID are often more reliable than names because IDs usually stay exact even when display names change.

Use product-based filters when the sales team is organized around what the customer wants to buy or discuss. For example, one team may handle a premium plan, another team may handle resale inventory, and another may handle a specific product category. Use project-based filters when routing depends on the selected project, development, location-based project, or inventory group. If both product and project data are present, place the more specific rule first.

Set the Default User

The default user is the backup owner for leads that cannot be routed by the normal rules. This user is important because every distribution setup has exceptions: missing source data, inactive users, after-hours routing, expired claim windows, or a lead that does not match any rule.

Use a default user who can monitor and correct routing problems. In many teams, this is a sales manager, sales operations user, or admin-owned queue account. Avoid choosing a user who is often unavailable, because the default user may receive the leads that need the most attention.

The default user can receive a lead when:

• No distribution rule matches the lead.
• The matching rule has no active eligible users.
• Business hours prevent the selected rule from assigning the lead.
• A claim window expires and no user claims the lead.
• Required lead data is missing or does not match the rule conditions.
• A user or team was removed from the workspace after the rule was created.

Review default-user assignments often. A few default-user leads are normal. A large number usually means a source is missing data, a rule is too narrow, users are unavailable, or the workflow conditions no longer match the way leads are being created.

Before You Start

Decide these items before building the workflow:

• Which sources should use this rule.
• Which rules you need and which one should run first.
• Whether ad ID, ad group ID, product, product ID, project, or interested-in details should control routing.
• Which users, teams, or groups are eligible.
• Whether routing should run all day or only during business hours.
• Whether leads should be assigned directly or claimed first.
• How long a claim window should stay open.
• Which default user should receive the lead if no rule matches, no user is eligible, or no one claims it.
• What manager notification should run when the default user receives a lead.
• Which follow-up task or notification should be created after assignment.

Configure Non-Claim-Based Distribution

1. Go to Automation.
2. Open Workflows.
3. Choose New workflow or open an existing workflow.
4. Add a trigger such as Contact created, Lead created, or the source-specific event your workspace uses.
5. Add conditions for source, campaign, ad ID, ad group ID, product, product ID, project, interested-in details, location, product interest, team, or any field that should control routing.
6. Add the Distribute Lead action.
7. Choose a direct assignment or non-claim distribution option.
8. Create or select the distribution rule.
9. Add rule conditions, such as source, campaign, ad ID, ad group ID, product, product ID, project, interested-in details, city, product interest, budget, or tag.
10. Select the eligible users, team, group, or distribution policy for that rule.
11. Set the rule order if there is more than one rule.
12. Set business hours if the rule should only assign during working time.
13. Choose the default user for unmatched leads or leads that cannot be assigned.
14. Add a follow-up action, such as Create task, Send notification, or Add note.
15. Save the workflow.
16. Test with one lead that should match the rule and one lead that should go to the default user.
17. Publish the workflow after both tests route correctly.

After publishing, every matching lead should receive an owner automatically. Leads that do not match a rule, or cannot be assigned to the matching rule's users, should go to the configured default user. The owner should also see any task or notification configured after the distribution action.

For non-claim distribution, the most important test is ownership speed. A lead should not wait for user action. If the workflow runs and the rule matches, ownership should change immediately and the next follow-up task should be visible to the new owner.

Configure Claim-Based Distribution

1. Go to Automation.
2. Open Workflows.
3. Choose New workflow or open an existing workflow.
4. Add the trigger that captures the incoming lead.
5. Add conditions so only the right leads enter the claim flow.
6. Add the Distribute Lead action.
7. Choose a claim-based distribution option.
8. Create or select the claim rule.
9. Add rule conditions, such as source, campaign, ad ID, ad group ID, product, product ID, project, interested-in details, city, product interest, budget, or tag.
10. Select the eligible users, team, group, or claim queue.
11. Set the rule order if there is more than one claim rule.
12. Set the claim window, such as a short window for urgent enquiries or a longer window for lower-priority sources.
13. Choose what happens when a user claims the lead.
14. Choose what happens when nobody claims the lead, such as retrying another group, moving to the next rule, assigning the default user, or notifying a manager.
15. Choose the default user for unclaimed leads or leads that do not match any rule.
16. Add a task or notification after the claim succeeds.
17. Save and test with a sample lead that should be claimed.
18. Test another sample lead that should reach the default user.
19. Publish the workflow when the claim, default user, and follow-up actions work as expected.

After publishing, eligible users should see the claim opportunity. Once one user claims the lead, Brixi should make that user the owner and continue the workflow actions that depend on ownership. If nobody claims the lead before the claim window ends, the rule should follow the fallback path you configured, usually the next rule, the default user, or a manager notification.

For claim-based distribution, the most important test is the full claim lifecycle:

1. The right users see the claim opportunity.
2. One user can claim the lead.
3. Other users no longer own or claim the same lead after it is claimed.
4. The claimed user becomes the lead owner.
5. The post-claim task or notification is created for the owner.
6. An unclaimed lead moves to the fallback path when the claim window expires.

Example Setups

Scenario	Recommended setup
Website form leads should rotate across a fixed inside-sales team	Non-claim distribution with eligible inside-sales users and a first-call task.
Premium campaign leads should go to senior agents only	Non-claim distribution filtered by campaign, budget, or tag.
One high-performing ad needs a dedicated closer	Non-claim distribution filtered by ad ID.
Leads from a paid ad group need one response team	Distribution filtered by ad group ID.
Leads for a specific product need a specialist team	Distribution filtered by product or product ID.
Leads interested in a specific project need a specialist team	Distribution filtered by project or Interested In.
Walk-in enquiries should go to the first available floor agent	Claim-based distribution with a short claim window and manager fallback.
After-hours leads should wait for the next working shift	Distribution with business hours and a morning follow-up task.
Source-specific leads should go to specialist teams	Conditions by source, then separate distribution actions for each team.
Leads missing source data should still have an owner	A default user, usually a sales manager or operations owner, catches unmatched leads.

Detailed Examples

Example 1: Direct Assignment for Website Leads

A sales manager wants all website form leads to rotate across the inside-sales team. Premium website leads should go to senior agents, while all other website leads should go to the regular inside-sales team.

Recommended setup:

1. Trigger the workflow when a new lead or contact is created.
2. Add a workflow condition for source equals website form.
3. Add the Distribute Lead action.
4. Create rule 1: campaign or budget indicates premium, assign to senior agents.
5. Create rule 2: source equals website form, assign to inside-sales team.
6. Set the default user to the sales manager.
7. Add a call task due immediately for the assigned owner.

Expected result: premium website leads go to senior agents first because that rule is more specific. Standard website leads go to the inside-sales team. Leads missing campaign or budget data still route through the broader website rule. Leads that cannot match any rule go to the default user.

Example 2: Claim-Based Routing for Shared Inbound Leads

A team wants new WhatsApp leads to be claimed by the first available agent. If nobody claims the lead within the claim window, a manager should receive it.

Recommended setup:

1. Trigger the workflow when a WhatsApp lead is created.
2. Add conditions for the WhatsApp source or inbox channel.
3. Add the Distribute Lead action.
4. Create a claim rule for the eligible inbound team.
5. Set a short claim window for urgent response.
6. Set the default user to the inbound sales manager.
7. Add a notification when the default user receives an unclaimed lead.
8. Add a first-response task for the user who claims the lead.

Expected result: agents receive the claim opportunity, the first claiming agent becomes owner, and the follow-up task is assigned to that owner. If nobody claims in time, the lead moves to the default user so the manager can reassign or follow up.

Example 3: Ad, Product, and Project-Based Routing

A workspace runs multiple ads for different products and projects. The sales manager wants leads from one premium ad to go to senior agents, leads for a specific product to go to a product specialist team, all leads from a larger ad group to go to an inside-sales team, and project-specific enquiries to go to project specialists.

Recommended setup:

1. Trigger the workflow when a new ad lead, contact, or enquiry is created.
2. Create rule 1 for the exact Ad ID or ad_id that represents the premium ad.
3. Create rule 2 for the exact Product, Product ID, product, or product_id when a product-specific team should own the lead.
4. Create rule 3 for the selected Project when the lead is tied to a specific project.
5. Create rule 4 for the Ad Group ID or ad_group_id that represents the wider campaign group.
6. Add an Interested In condition when the customer's selected interest should change the destination team.
7. Put the exact ad ID, product, and project rules above the broader ad group rule.
8. Set the default user to the sales manager or sales operations owner.
9. Add a task for the final owner to call the lead.

Expected result: the most specific match wins. A lead from the premium ad goes to senior agents even if it also belongs to the broader ad group. A lead with a matching product or product ID goes to the product specialist team. A lead with a selected project or Interested In value can route to the project specialist. A lead that only has the ad group ID goes to the inside-sales team. If the incoming lead is missing those fields, the default user receives it.

Example 4: Multi-Rule Routing by Location

A workspace has city-specific teams. Leads from Mumbai should go to the Mumbai team, leads from Bengaluru should go to the Bengaluru team, and leads with no city should go to sales operations.

Recommended setup:

1. Trigger the workflow for new leads from all relevant sources.
2. Create rule 1 for city equals Mumbai.
3. Create rule 2 for city equals Bengaluru.
4. Create a broader rule for leads where the region is known but the city is not specific.
5. Set the default user to sales operations.
6. Review default-user leads weekly to identify missing city data.

Expected result: city-specific leads route to the correct team. Leads with missing or inconsistent city values go to the default user, where sales operations can fix the data and update the owner.

Check the Result

After testing or publishing, confirm:

• The workflow run shows the lead entered the correct branch.
• The lead matched the expected distribution rule.
• The lead has the expected owner after distribution or claim.
• Leads with missing or unmatched data go to the default user.
• The task, notification, note, or message action ran after assignment.
• Unclaimed leads moved to the next rule or default user instead of staying open.
• Managers can review assignments in workflow history and reporting.

Test more than one sample lead before publishing. Use one lead that should match each rule, one lead that should not match any rule, and one lead with missing data. If you use claim-based distribution, also test one lead that is claimed and one lead that expires without a claim.

Common Issues

Issue	What to check
Lead did not enter the workflow	Confirm the trigger matches the way the lead was created and the workflow is published.
Lead entered the wrong branch	Review source, campaign, team, and field conditions.
Lead matched the wrong rule	Move the more specific rule above the broader rule.
No owner was assigned	Check eligible users, business hours, user availability, rule conditions, and default user.
Default user receives too many leads	Review missing lead data, overly strict conditions, inactive users, and claim windows that expire too quickly.
Claim notification did not reach users	Confirm the selected users are eligible and notification settings are enabled.
Claim expired too quickly	Increase the claim window or reduce the number of competing notifications.
Same user receives too many leads	Review the eligible owner list and routing method.
Leads route outside working time	Check business hours and workspace time zone.

Ask your admin first if you cannot see Automation, cannot edit workflows, cannot select a user or team, or do not receive claim notifications.

Contact Brixi support if the workflow is published, the trigger and conditions match the lead, eligible users exist, and Brixi still does not assign or offer the lead correctly. Include the workflow name, sample lead, expected owner or claim group, and the time the lead arrived.

Reporting Impact

Lead distribution affects owner activity, lead source reporting, response time, task completion, and conversion reporting. Review workflow runs first to confirm the rule behaved correctly, then compare owner-level activity and source performance after the workflow has handled enough leads to show a pattern.

Related Articles

Need	Article
Build the workflow from scratch	Create a workflow
Choose the right automation action	Choose workflow actions
Review workflow outcomes	Automation reports and analytics