← All widgets · KLASTER Routing
We hand out leads by rule and explain every decision
The widget looks at the rule, the schedule, the rights and the customer history, picks a manager — and writes into the deal card and the log straight away: who received the lead, under which rule, who was skipped and why. Admins, dismissed staff and users without the right to edit deals in this pipeline never receive leads: that is built into the code, not into a checkbox.
Routing is configured — and still does not work
Routing that is configured and routing that works are different things. Here is what we found on an account where a routing widget was installed and “working”:
A share went to a dismissed user
The rule included a deactivated user with a 12% share. Nobody received those leads. The active employee with the same name was missing from the rule and got deals by hand.
Leads went to administrators
In 7 days the bot changed the owner 371 times, and 85 deals went to administrators. Administrators do not sell: those leads sat waiting for someone to notice.
The head of sales worked as a dispatcher
In the same seven days the head of sales reassigned 128 deals by hand — an exact measure of how badly automation was failing. Nobody was counting it.
Nobody knew why
The note said the owner had changed and nothing more. There was nothing to check the rule against, and nothing to catch anyone bypassing it: no one was left holding the evidence.
anonymised property developer account · 18 users · owner changes counted from events over 7 days · measured 14.09.2026
The log answers “why does he have this deal”, not a chat thread
The same lead, two notes in the deal card. On the left, what a typical widget writes. On the right, what we write.
Before
one lineThe rule is unknown, the strategy is unknown, the skipped people are not named. To find out why she got the lead, the head of sales opens the settings and checks them by hand.
Now
the whole decisionThe rule, the strategy, plan versus actual at the moment of the decision, and below them everyone who was considered and what got in their way. The same text goes into the log.
An example. Names and numbers are invented; the set of lines is real — that is how the log is built in the widget’s code.
How the widget makes a decision
Five steps, from the deal entering the stage to checking that nobody overwrote the decision. Each one ends in something you get.
A deal enters the stage
The stage trigger hands the deal to the widget. The trigger has one choice — “Rule”; everything else is configured in the widget’s own window. A deal created directly in the stage never entered it, so a reconciliation pass picks it up.
Result: the setup lives in one place instead of ten digital pipeline modals.
We cut out those who must not get it
Deactivated users, admins, free users, staff without rights on deals and without rights in this pipeline. The check runs at every decision, not when the rule is saved.
Result: the lead never disappears into someone who physically cannot open it.
We choose from the rest
By queue, by percentage or by quota. A repeat enquiry goes back to the previous manager; a night-time lead waits for the shift to start in the account’s time zone, not the server’s.
Result: the choice is explained by plan and actual at the moment of the decision, not by a monthly total.
We write the decision down
A note in the deal card and an entry in the log: rule, strategy, who got it, who was considered and what got in their way.
Result: a disputed hand-over is settled from the record, not from anyone’s memory.
We watch what happens next
Not accepted in time — the lead moves on to the next person, with a cap on rounds and a night pause. If a bot or an admin changes the owner right after us, it is an incident in the log, with who did it and after how many seconds.
Result: you see where automation argues with itself and how many leads the team reassigns by hand.
What is inside: 8 tabs
Its own window inside amoCRM, instead of settings scattered across digital pipeline triggers.
| Tab | What it gives you |
|---|---|
| Overview | Passed, median time to hand-over, reassigned by hand and how many deals currently sit on administrators. Zero in the last row is normal, and the row is always shown |
| Rules | Who takes part, under which strategy and at which pipeline stage it fires. Counters reset with a button, not by re-saving the trigger |
| Users | Who receives leads and who does not, with the reason: not in any rule, switched off, opted out. Next to it, the history: who was added, who was turned off and by whom |
| Schedules | Weekly and shift-based, with exceptions. With schedules on, a person without one receives nothing — stated up front instead of discovered later |
| Log | Filters by rule, person and result over a day, a week or a month. An empty period says so — “no decisions in the selected period” — instead of showing a blank table |
| Reports | Plan, passed, accepted and reassigned by hand — per member, as bars and by day. Accepted means the manager moved the stage or completed a task, not that they “saw” it |
| License | The key from your account, the expiry date and a direct answer to whether leads are being routed right now. When the licence expires routing stops; the log and the reports stay |
| Setup | Four steps to switch routing on at a stage and the webhook address with a “Copy” button. The check: move one deal into the stage and watch the owner change |
What the widget does differently
| The usual way | Our way |
|---|---|
| Routes to whoever is picked in the list: an admin, a dismissed user, someone with no rights | Hard filters that cannot be switched off: inactive, administrator, no right to edit deals, no rights in this pipeline. Checked at every decision, not when the rule is saved |
| A card note saying “owner changed”. Who and why — nowhere | Every decision explained: a note in the deal card and a log entry — rule, strategy, plan vs. actual, who was skipped and why |
| An inactive member’s share is lost | The share is redistributed among the rest. Counters live in the rule and reset with a button, not by re-saving the trigger |
| A report of “handed over” only | Three numbers side by side: handed over, accepted (the manager moved the stage) and reassigned by hand. The “Administrators” row is always shown, even at zero |
| Settings live in the digital pipeline trigger modal | The trigger has one choice: “Rule”. Everything else lives in the widget’s own window |
| Priced per user: the bigger the team, the more you pay | Priced per account. Ten people in the team or fifty, the payment is the same |
| The widget does not know what happens around it | Competing-automation detector: if a bot or an administrator changes the owner right after us, it is logged as an incident, not silence |
What it already does
Three strategies
By queue, by percentage and by quota. Each explains why this member was chosen, with plan and actual at the moment of decision.
Repeat enquiries
A customer you already worked with goes to the previous manager. Five modes: ignore, by contact, by company, by contact or company, same manager. The window is set in days.
Work schedules
Weekly and shift-based, with exceptions. The time zone comes from the CRM account, not the server: a night-time lead is routed in the morning, in the customer’s local time.
Timed reassignment
Not accepted in time — it goes to the next person. A cap on rounds and a night pause keep the deal from circling the team forever or waking people up.
Decision log
Every decision with a reason, every skip with an explanation, every competing-automation incident.
Reports per rule
Handed over, accepted and reassigned by hand — per member, with plan and actual. Plan/actual bars and a daily breakdown.
list verified against the engine code, the tab catalogue and the interface dictionary, not the documentation · 294 tests pass, 12 skipped, run in 696 ms without network or database · 8 tabs in the interface · 16.09.2026
What it lacks
A short list, and the reason the widget is not on sale yet.
No “online” status
We look at the schedule and rights, not at whether the manager’s browser is open right now. We do not promise it.
No Excel export of the log
The log exists and can be read and filtered in the interface. There is no export yet.
No release
The widget is not deployed to production and is not installed at any client. Until then there is no price, no install button and no date here.
What it will cost
The price will be per account, not per user: the payment does not grow because five more managers joined the team. The number itself appears on release day — there is nothing to name before that.
Meanwhile, the audit finds the same
Everything listed at the top of this page we find by hand during a CRM audit: who actually receives leads, whether it matches the setup, how often the bot changed the owner and how often the manager did. The audit is available now; the widget is not.
We will invite you to the first install
Write to us — we will tell you where the widget stands and invite you to the first installation. We will also ask how leads are routed at your company today: that conversation is useful to you even if you never install the widget.