A lead is a request or a potential client before they become a client in the base. Leads live separately from the client base and are linked to it softly: a person can leave a request without being your client yet, and mixing these states is inconvenient. A separate leads list shows what sales needs right now: who reached out, how long they have been waiting, who is on it and what comes next.
What a lead is
A form on the site, an email, a call, a messenger message, an upload from a spreadsheet — everything turns into a lead, and every lead collects the same things: where it came from (channel, source, ad mark), when it reached out, who owns it and what has already been done. A lead does not scatter data across different lists but keeps its own history: repeat approaches, answers, moves between statuses.
Statuses and disqualification
Lead statuses are a setting, not a hard-wired set: incoming, in progress, qualified, rejected and so on, each with its order and color. So they can be adjusted to your own sales process. Every move is necessarily logged as an event with a reason, so the history shows not “a field changed” but “moved to in progress on March 5, reason: called us himself”.
A lead can be rejected only with a reason given — the reasons list is configurable too. Nothing is lost: rejected leads and leads recognized as spam do not vanish but stay in a separate state. This is a matter of principle: even spam sometimes turns out to be a real approach. Spam lies for 180 days, lost requests for a year, then they are cleaned away automatically.
One request intake
All channels converge on one intake order: a form on the site, public intake by key, an email, a call, a chat, an upload from a file. Because of this there is no “site requests lie separately and emails separately”: every approach passes the same checks and lands in one list.
Intake has protection from junk and from losses. Protection: a rate limit (no more than 20 requests per hour from one source), a minimum fill-out time, a hidden trap for automatic bots, a request size limit. From losses: not one request is rejected silently — every approach is written into the intake log with its outcome and reason (accepted, repeat, rejected, spam) and the submitted data kept. If a request was rejected, you can always look up why and create it by hand if you like.
Public intake addresses
Every source gets its own public intake address with its own key. A request can be sent right from a form on any site — including someone else’s, for example a partner’s page or a landing page you did not build. The key can be replaced at any moment if the old one leaked, and the old one stops being accepted at once.
This public intake can only create leads and never touches the client base — it can neither read nor change a contact or a company. That is safer: even if the key leaks, an attacker could at worst send a junk request, not see your clients. Which sites are allowed to send requests is configurable too: by default we accept from anywhere (the form works out of the box), and if you like — only from your own sites.
The ready form page
If you have no site with a form, the product gives a ready public page with a request form — you can point advertising at it right away without building anything. The form’s fields are configurable, and the look follows the product’s common theme. It is the fastest way to start accepting requests: you get the address, put it into the ads, and the requests start flowing into the base.
Gluing repeats before routing
A person who submitted the form twice must not get two cards and two owners. So before any routing the product answers the question “who is this”: a repeat request from an already-known person attaches to the existing lead as an extra approach instead of creating a new card. The lead shows how many times the person reached out and when the last time was. And if the requester already exists in the client base, the request links softly to their card, and the owner of that client answers — more logical than a random person on duty.
The mandatory owner
Not one lead stays without an owner — that is a rule, not a wish. The owner is assigned by an understandable order: first the owner of the already-known client (if the requester was found in the base), then the routing rules you set, and if none fired — a fallback. The routing rules are configurable: round-robin, to the least loaded, at random, to a specific person. Work schedules and the current load count, so a request does not go to someone on vacation or already buried in work.
The decision of who got the lead is not hidden: the log shows which rule fired, who was considered at all and why exactly this person was chosen. If the request was picked up by the fallback (meaning all rules missed), the product raises a signal — a lead without an owner counts as an error, not a normal state.
Glass-box scoring
A lead has a quality score — a number that helps you understand who to throw force at first. The score adds up from understandable rules: “has a phone” gives so many points, “came from search” so many. The main thing is that the score is not a black box: the card shows every rule and its contribution, so it is always clear what the number is made of. The rules also “decay”: the older a trait, the less it weighs. The number only hints at priority — it never changes the lead’s status by itself.
There is also a report on the rules’ setup: it shows whether the score really helps — whether “hot” leads convert more often than the rest. If a rule catches everyone indiscriminately and distinguishes nothing, that will show in the numbers.
Reaction-time control
The speed of the first answer is often more important than any discount: the client goes to whoever answered first. So every request has a first-touch deadline. The deadline rules are set by conditions (by source, by request type), the countdown starts at the moment of arrival, and the default is 30 minutes. The first answer counts as a real outgoing approach to the person — a call, an email, a message, not an automatic acknowledgment.
If the deadline is breached, the product raises a signal and climbs the alert level (up to three levels), but does it with sensible pauses so it does not bury you in notifications. The Leads section and the home screen show the deadline picture: how fast you answer on average, in the worst case, and how many requests got no answer at all. So you see not only “fine on average” but the tail too.
Qualification and conversion
When a lead is ready to become a client, it is “converted”: it becomes a contact, if needed a company, and a deal is opened for it. Conversion is not deleting the lead but a move that keeps the history: the card keeps both where the person came from and what was already said. Every move shows what is missing for the next status: which fields are empty and what needs finding out. A mistaken conversion can be undone within 48 hours — the data returns to its place.
Sources and statistics
Every request source — a site, an ad, a partner, a messenger — has its own record in the sources registry. This answers marketing’s main question: which channel brought not just requests but money. The reports show the funnel per source: how many reached out, how many were repeats, how many turned out to be junk, how many got to a deal and how much money they brought.
A separate report shows how many requests have been lying around: how many days they sit without a touch, what the worst and the typical case are, and which owner it concerns. Not to blame anybody, but to see where the process stalls. All reports export as a spreadsheet — convenient to hand to management or accounting.
Email and task sequences
Not every lead should be worked in one rush: sometimes a steady series of touches is needed — “call, then an email, then another email in a week”. This is called a sequence: a pre-written touch plan that unfolds by days and turns into tasks for the owner. A sequence is a setting: it can be changed and applied to one lead or to a group. Every step leaves a trace in the history, so it is visible which touch the person is at and what has already been done.
Notifications into your systems
Lead events can be reported to external systems: for example, send a signal into your messenger or accounting system when a new request arrives. This is called a webhook notification — the product sends a message to the given address and, if the receiver does not answer, retries several times, recording the outcome of every attempt. If something did not get through, it will be visible, not lost silently.
What the product does not do
Honestly, so there are no false expectations:
- There is no autonomous selling — the product helps you work with requests, but the talks, the decisions and the closing of deals stay with the human and the agent.
- Spam is not recognized perfectly — simple traps cut off the obvious bots, but there is no such thing as no junk at all; on the other hand not one rejected request is lost — it can always be looked up.
- The Leads add-on is switched on separately — without it the working base, the deals and everything else work, but there is no request intake and no routing.
Next → Deals & Pipeline