MapLogics
Sign inBook a demoTry it free

Service area checker

Tell people whether you serve them, before they fill in the form.

A visitor who submits an enquiry you cannot fulfil costs you a rejection email and them a wasted afternoon. Ask the same question your dispatcher would, at the top of the page.

Try it freeBook a demo

Two lines, or the API

The drop-in checker is two elements. It renders in a shadow root, so your stylesheet cannot reach into it and it cannot reach into your page, and the script is loaded asynchronously: nothing about it can delay your own page from rendering.

The drop-in checkerhtml

<div data-maplogics-widget="mlw_your_widget_token"></div>
<script async src="https://maplogics.com/embed/v1.js"></script>

You create the token on the Embed page in the app and list the sites it may be used from. The token is public by design, since it sits in your page source where anyone can read it, and that list of sites is what stops somebody else spending your quota with it. The same page sets the wording for each answer, the button colour and an optional link to send people to next.

Or build it yourself

The checker is a thin thing over one endpoint, and if you want your own markup, your own states or your own analytics, call it directly. The demo at the top of our home page is this and nothing more.

Checking an address from a web pagejs

const response = await fetch('https://api.maplogics.com/v1/resolve', {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    authorization: 'Bearer ' + YOUR_PUBLIC_KEY,
  },
  body: JSON.stringify({
    address: { line1, city, region, postal_code },
    context: { service: 'plumbing' },
  }),
})

const { status, territory, location, reason_code } = await response.json()
// status is 'resolved', 'unserviceable', 'ambiguous' or 'no_coverage'.

Four answers, not two

"Yes" and "no" is not enough to write a good page against. These are the four things that can be true, and each one deserves different copy.

resolved
You serve it, and here is the branch. Send them into the enquiry form.
no_coverage
No territory covers the address. Offer a waiting list rather than a dead end.
unserviceable
A territory covers it, but a rule ruled it out. Often worth saying why, since the reason is frequently something the visitor can change.
ambiguous
Two territories cover it and nothing separates them. Rare, and a signal to fix the configuration rather than to show a visitor an error.

What it does not do

There is no address autocomplete. We geocode the address a visitor finishes typing; we do not suggest addresses as they type. If you want that, put your own autocomplete in front of your own form and call the API directly.

The checker asks about one service, chosen when you configure it, so a page that needs to ask about several is a page that calls the API. It also has no opinion about what happens next beyond the one link you give it: it is a checker, not a booking flow.

It answers what your published configuration says, not your draft. An edit you have not published changes nothing on your site, which is the behaviour you want the first time somebody is halfway through redrawing a territory.