Bot detection false positives: no decision without a reason
Protection that blocks without saying why ends up blocking a customer with nobody knowing how to let them back in. With Klacos, every decision keeps its reasons, every blocked visitor gets a reference, and you unblock them with one click. And nothing is enforced until you have seen who it would affect.
What a decision you cannot explain costs you
A customer blocked, no explanation
They write in to say they can no longer place an order. You find neither the cause nor a way to let them in without opening everything.
Settings tightened blind
You turn the screw on a bot without knowing which customers will be caught along the way.
Protection that ends up switched off
After a few complaints, the protection is turned off, and the bots come back.
What you should expect: that every decision is readable by you, that a visitor can flag themselves without hunting for you, and that you can fix it with one click.
Decisions you can read, and undo
The reason for every decision
A reference
A page in your branding
Appeals
An appeal queue
One-click unblock
APIs treated as APIs
Replay before you apply
Every decision keeps its reasons
For every visitor, the console shows the decision and its reasons, ranked from strongest to weakest, with the main one in plain words. You find it from the reference the visitor sends you.
Decisions from the web application firewall are there too, with the rule that stopped the request. So you always know whether a refusal came from bot-like behaviour or from an attack attempt. The page on how detection works follows a visit from request to decision.
What a blocked visitor goes through
They see a clear page
In your branding, it tells them they are blocked, without revealing what gave them away, and gives them a short reference that is easy to read out over the phone.
They appeal with one link
The page leads to a form where they ask to be let through, without having to track you down.
You see their request
It lands in the console’s appeal queue, alongside the decision and its reasons.
You let them back in
One click, and the unblock applies straight away. Their case then helps fine-tune your settings.
Observe first, decide next, enforce last
Everything starts in observation mode, site by site and for each kind of traffic: decisions are computed, nothing is applied, and you see who would have been affected. Before tightening a setting, you replay it against your past visits: the console shows which decisions would have changed, across how many requests, and how many came from visitors judged to be human. You adjust before the setting reaches a customer.
You then apply one step at a time, and each step can be undone in one move. That is how bot management and the rest of your site’s protection work.
The result: you can tighten your settings without worrying about your customers, and when one of them is stopped anyway, you know why and you let them through in one click.
Questions about decisions and appeals
Does the block page tell the visitor what gave them away?
No. It tells them they are blocked and gives them a reference. The detail stays in your console, so bots do not learn how to get through.
Can a visitor we know nothing about be blocked?
No. An unknown visitor is not blocked, and no single clue is enough to block anyone.
How long does it take to unblock someone?
One click in the console: the unblock applies straight away.
What if it is an API call that gets blocked?
The call gets a structured response carrying its reference. Your partner passes it on to you, and you find the decision just as you would for a visitor.
Protection you can explain to your customers
Request early access, or tell us about the blocks that have already cost you customers.