Doorknocking that keeps working when the signal doesn't

Every field organiser has a sixth sense for dead spots. The apartment block with concrete walls. The rural road where the bars vanish. The stairwell that swallows your signal whole. For years that's exactly where canvassing software fell over – you'd knock, tap a result, and watch a spinner turn while the data went nowhere.

We built the Uprise canvasser app so the signal is never the thing standing between a volunteer and a recorded conversation. Here's how it holds up when the network doesn't.

The dead-spot problem is a data-loss problem

A dropped door isn't just an inconvenience. It's a hole in your data. If a volunteer knocks fifteen doors in a basement block and the app only saves the three that happened near a window, your support numbers are wrong, your follow-up list is wrong, and your reporting quietly lies to you.

So the app assumes the network will fail. Not as an edge case – as the normal state of a canvassing shift. Everything is designed to work first, sync second.

An outbox that lives on the phone

When a volunteer records a door knock – the disposition, the survey answers, the support score – it doesn't get posted straight to a server and hope for the best. It gets written to an outbox stored right on the device, in the browser's own database.

That means:

• Every knock is saved the instant it's tapped. No spinner, no wait, no lost result.
• The queue survives. Close the app, lock the phone, walk into a lift – the queued knocks are still there when you come back.
• Sync happens the moment there's signal again. When the connection returns, the outbox flushes automatically. Volunteers don't have to remember to press anything, and organisers don't have to chase missing data at the end of the day.

A canvasser can work a full turf underground and surface to find every single door already on its way to the campaign.

What happens when the sync finally runs

Queueing is the easy half. The interesting question is what happens when forty knocks arrive at once, an hour late, from a phone that has been in a basement.

Each queued knock carries its own identity and its own timestamp, so the order it happened in is preserved rather than the order it uploaded in. If the same knock is sent twice – a flaky connection that dropped mid-request and retried – it lands once. And a knock that fails validation doesn't take the other thirty-nine with it; it stays in the queue and reports itself rather than disappearing quietly.

That last property is the one that matters at 6pm on a Saturday. "Everything synced except these two, here they are" is a manageable problem. "Some of it synced" is not.

Route optimisation with zero bars

Here's the part that surprises people: the app doesn't just store data offline, it thinks offline.

Work out the best order to walk a list of addresses and you're solving a genuinely hard routing problem. Most tools do that on a server, which means the moment you lose signal, your smart route turns back into a random list. Ours runs the optimisation on the device.

The app uses a nearest-neighbour pass to build a sensible route, then a 2-opt pass to untangle the crossings and shorten it – all inside the service worker, with no network call at all. A volunteer standing on a corner with no reception can still re-order their remaining doors into the shortest sensible walk and get moving.

That's fewer steps, less backtracking, and more doors per hour – in exactly the places where connectivity is worst and canvassing is usually hardest.

Why the routing has to be local

It is worth being precise about why this is on the device rather than the server, because it sounds like an implementation detail and isn't.

A route is only useful at the moment a volunteer needs to decide which door is next. That decision happens on a footpath, mid-shift, often after the plan has already changed – someone skipped a block, a street was inaccessible, they have forty minutes left rather than ninety. If re-optimising requires a network round trip, then the exact conditions that make a good route valuable are the conditions in which you cannot get one.

Running it locally also means it is instant. A volunteer will re-order their list if it costs a tap. They will not if it costs a spinner and a maybe.

Install it like an app

The canvasser tool is a progressive web app, which is a technical way of saying: your volunteers install it to their home screen straight from a link, with nothing to download from an app store and no approval queue to wait on.

That matters more than it sounds. When you onboard a room full of volunteers on a Saturday morning, every extra step costs you people. "Open this link, tap add to home screen" gets everyone knocking in minutes. Once it's installed, it opens like any other app on the phone – full screen, ready to go, working whether or not there's a connection at that moment.

What this means on a Saturday

Picture the shift you actually run. Twenty volunteers, mixed suburbs, patchy coverage, a couple of high-rise turfs nobody wants because "the app never works in there".

With an on-device outbox and on-device routing, those turfs stop being a problem. Volunteers knock, record, and move on without thinking about signal. The high-rise gets covered properly for the first time. And when everyone comes back to the meeting point, the data isn't a guess reconstructed from memory – it's every door, in order, already synced.

Field work is hard enough. Losing conversations to a coverage map shouldn't be part of it.

Plan turf around coverage, not despite it

Once the app stops caring about signal, coverage stops being a reason to avoid a turf – and that changes how you cut them. The high-rise that everyone has quietly skipped for three campaigns is usually dense, walkable and under-canvassed by every other campaign too. It is often the best value turf on your map.

Two habits follow from that:

• Stop excluding areas for connectivity. Exclude them for access, for safety, for genuine strategic reasons – but not because "the app never works in there".
• Send your most experienced pair in first. Not because it is technically harder, but because the myth needs one visible counter-example to die.

There is more on sizing and cutting turf in Turf and walk lists.

Cut your turf, hand out the link, and let the app worry about the network.

Read more

• Running a doorknock weekend – the full sequence, from cutting turf a week out to the debrief on the day.
• Turf and walk lists – sizing turf to a shift, and knowing your real coverage.
• Reading your results – what to do with the data once it has synced.
• Election day operations – the same machinery, on the one day it cannot fail.