Skip to content

Reassign a Lead

Most lead assignments should happen automatically — that’s what the routing engine is for. But there’s a small set of situations where a broker manually reassigns a lead, and getting those situations right matters.

This page covers the workflow and, more importantly, when to use it vs. trust the existing rotation.

From the admin lead detail page:

  1. Open the lead’s detail page.
  2. Find the Assigned Agent field in the lead-actions panel.
  3. Pick a new agent from the dropdown. The dropdown shows all agents at the brokerage, regardless of whether they’re currently lead-recipient-eligible — you have full control here.
  4. Save.

The reassignment is immediate. The lead’s card on the board updates to show the new assignee.

A workaround for the missing audit trail: in the lead’s activity log (the agent-facing notes timeline, not the lifecycle timeline), add a note like “Reassigned from Ryan to Josh — Ryan is on vacation through next week.” That note IS captured and gives future-you something to look back at.

Four legitimate cases. Most other reassignment urges are better solved by adjusting the routing configuration.

An agent goes on vacation, takes leave, or otherwise won’t be reachable for the lead’s response window. Their existing leads need to be redistributed, and new leads need to skip them in the rotation.

Better long-term fix: turn off the agent’s Lead Recipient toggle (under Team → Agents) so the routing engine skips them automatically. New leads stop landing on them; existing leads need manual reassignment.

When they return, turn the toggle back on.

The routing engine assigned the lead based on the inquiry text and the agent’s match criteria, but the actual conversation revealed the lead has a different need than the inquiry suggested. The original agent flags it; you reassign to a better-matched agent.

This is OK to do, but watch for the pattern. If you’re frequently reassigning leads from one agent to another, the match criteria on those agents probably needs updating — the routing engine is making the best decision it can with the data it has, and bad data leads to bad routes.

3. A reactivated archived lead has a stale original agent

Section titled “3. A reactivated archived lead has a stale original agent”

When a lead in ARCHIVED comes back (manually or via re-engagement signals), they keep their original assigned_agent_id. If that agent left the brokerage, was deactivated, or has switched specialties, the lead needs to be reassigned to a current eligible agent.

This is a known gap — re-engagement events don’t currently re-invoke the routing engine (TODO #2 in the design doc). Until that fix ships, manually check the assignment whenever you reactivate an archived lead. See recovering an archived lead for the agent-side workflow.

4. A specific deal needs a specific person

Section titled “4. A specific deal needs a specific person”

Sometimes the deal is high-value, sensitive, or otherwise a fit for a particular agent regardless of the routing engine’s normal logic. The classic case: a referral comes in that’s already been promised to a specific person.

This is a legitimate reassignment, but log the reason explicitly. The activity-log note serves as the record.

A few patterns where the urge to reassign is the wrong move.

If round-robin or another distribution mode has one agent with fewer active leads than others, the explanation is usually one of:

  • Their leads convert faster (fewer leads sitting in CONTACTING or QUALIFIED for long).
  • They’re at the back of the rotation right now.
  • Their match criteria are narrow, so semantic filtering skips them more often.

Pulling leads off other agents to “balance” the pipeline distorts the data. The routing engine is correct on average; an individual snapshot is misleading. Look at the lead count over a longer window (last 30 days) rather than the snapshot.

”This agent isn’t responding fast enough”

Section titled “”This agent isn’t responding fast enough””

If an agent is consistently slow on SLA, the answer is a conversation, not a reassignment. The lead they have now should stay theirs — moving it just teaches them that the broker will rescue stalled leads.

The exception: a specific stalled lead is time-critical (a hot inquiry that needs response in the next hour). Reassign that one and have the conversation separately.

”The routing assignment doesn’t feel right”

Section titled “”The routing assignment doesn’t feel right””

If the assignment doesn’t feel right but the agent IS available and competent for this kind of lead, leave it. The routing engine optimizes for fair distribution and relevance over time; individual assignments will sometimes feel slightly off without being wrong. Trust the system unless you can articulate a specific reason this lead needs a specific other agent.

If the feeling persists across many assignments, that’s signal to revisit the routing configuration, not to keep manually intervening.

”I want to handle this one personally”

Section titled “”I want to handle this one personally””

Acceptable on rare occasions — high-value referrals, friends-of-friends, deals you have specific context on. Not a daily pattern. If you find yourself doing this often, you’re effectively setting routing to primary_only while paying the cost of having round_robin configured. Make the routing match the behavior.

  • It doesn’t reset the SLA clock. The 5-minute target was set when the lead was created; reassigning at minute 4 still leaves the new agent with one minute.
  • It doesn’t notify the new agent in any push way. They’ll see the lead next time they refresh the board. If the lead is time-sensitive, message the agent directly.
  • It doesn’t reset the lead’s pipeline state. A lead in QUALIFIED with the old agent is in QUALIFIED with the new agent.
  • It doesn’t change the temperature score, the flags, or anything else on the lead. It only changes who’s responsible.

For the vacation case (one agent’s whole pipeline temporarily moving to a colleague), there isn’t a dedicated bulk-reassign UI today. Workarounds:

  • Filter the lead list by assigned_agent = <departing agent>, reassign one-by-one.
  • For a permanent departure, consider deactivating the agent and using the data-management tools to handle reassignment in bulk (admin-only).

Bulk reassignment is on the roadmap as a broker-facing feature; until then, the per-lead workflow is what’s available.