MapLogics
Sign in Book a demo Try it free

Lead routing

Route the enquiry, and be able to say why.

A lead going to the wrong branch is annoying. A lead going to the wrong branch and nobody being able to explain how is a franchise dispute. Every decision here comes back with the rule that made it.

Try it free Book a demo

Five stages, always in this order

Order is not a setting. Rules that can run in any order produce decisions nobody can reconstruct, and a routing engine whose output depends on which rule was written first is a routing engine that will eventually be blamed for something it did correctly.

  1. 1

    Exclusions

    Anything you never serve, removed first. A postcode you have written off, a site you are not insured for.

  2. 2

    Eligibility

    Of the branches that cover this address, which ones can actually do this job. Certification, equipment, hours.

  3. 3

    Assignment

    Which one gets it. Priority, an explicit rule, or the nearest branch that survived the two stages above.

  4. 4

    Fallback

    What happens when nothing qualified. A named backup, or an honest answer that nobody can take it.

  5. 5

    Output

    The fields your CRM needs on the way out: a queue name, an owner, a service level.

What comes back

A territory, the branch that owns it, and a reason code. The codes are stable strings rather than prose, so your CRM can branch on them and your support team can look them up. There is a page in the docs for every one, including what to do about it.

Ask for a trace and you also get the stages above, each with what it did. That is the artefact that ends a dispute: not an opinion about what should have happened, but a record of what did.

Reaching the systems you already run

  • Call it directly

    One HTTPS request per address, from a form, a CRM automation or a backend job.

  • Send it a list

    Upload the addresses you already have and get a file back with the decision on each row, your original identifiers intact.

  • Have it tell you

    Signed webhooks when a decision is made or a configuration is published, with delivery recorded and failures replayable.

What it does not do

It does not run your code. Rules are a fixed set of conditions and effects, which is what makes a decision reproducible a year later. If a rule cannot express something, that is a gap worth telling us about rather than a scripting hook.

It does not decide round-robin or by capacity. It answers a question about geography and eligibility; who is next in the rota is a question your CRM is better placed to answer.

There is no packaged CRM integration yet. The API and the webhooks are how you connect it.