Concept

Digital distance

The idea underneath every build note · Founder, Klaros

There is one idea underneath everything we write down, and it has needed a name for a while. We have been using this one across the build notes without ever defining it in a single place, which is its own small version of the problem it describes.

Why it does not show up anywhere

Most failures announce themselves. An outage generates tickets. An exception generates a log line. An incorrect charge generates an argument, usually a loud one. Every feedback mechanism a company builds is shaped around the assumption that a problem will eventually be described by somebody.

Distance produces none of that. It produces silence, and silence reads identically to satisfaction on every dashboard ever built.

This is why it cannot be found reactively. Waiting to hear about it is waiting for the one signal the failure mode structurally does not emit. It has to be found by checking whether the machinery that closes the gap is actually running, which is a much less comfortable habit than reading a support queue, because it means going and looking on days when nobody has complained.

It runs in both directions

The obvious direction is between a business and the people it serves. A shopper who has bought from the same jeweller for three years expects to be recognised. If the software opens a blank thread and asks who they are, the distance is the space between those two states.

The less obvious direction, and the one we hold ourselves to, is between a software vendor and its own customers. You believed the plan included three lines. The wallet drained faster than the page implied. Leaving turned out to mean a support ticket. Nobody argues about these. They just remember them.

A vendor is not exempt from the thing it sells against. That symmetry is the reason the build notes exist in the form they do, and the reason they include the parts that are not flattering.

Four documented instances

The concept would be worth very little if it stayed abstract. Each of these is a real defect in our own code, with the note that documents it.

Read together, those four are the same failure wearing different clothes. In every one, the software reported success while doing nothing the person would recognise as success, and in every one the person affected had no way to know, and therefore no way to tell us.

What it is not

The term is narrow on purpose, because a concept that explains everything explains nothing.

• Not personalisation. Personalisation is about making messages feel tailored. Distance is about whether the underlying knowledge exists at all. Inserting a first name into a template that knows nothing else about somebody increases the distance, because it raises the implied claim without raising what is actually known.
• Not downtime. An outage is loud, bounded and gets fixed, because everybody can see it. Distance is quiet, open-ended and often survives for months, because nobody can.
• Not bad support. Bad support is an interaction the customer had and disliked. Distance is usually the interaction they did not bother to have.
• Not a data-volume problem. Holding more records does not close it. A system that has stored everything about somebody and surfaces none of it at the moment of contact is exactly as distant as one that stored nothing.

What we actually do about it

Naming the gap is not the same as closing it. Four mechanisms in Klaros exist specifically for this, and each is checkable rather than claimed.

Context carries forward instead of starting when the software first notices somebody. Most business software's memory of a customer begins at a lead form or a first invoice, which means everything the business genuinely knew before that is invisible to the tool. Klaros starts from the relationship that already exists on WhatsApp, which is the whole reason the philosophy page puts that belief first.

Enrichment turns a phone number into a contact the business already understands a little, before the first reply is typed. Consent is an evidenced ledger rather than a checkbox, because "we have consent" should be provable to the person it concerns and not merely asserted about them. And our own billing and delivery paths get audited against what we publish, which is what produced the notes above.

What we have not fixed

This would be a dishonest page if it ended at the tidy part.

We cannot measure digital distance. Not approximately, not with a proxy metric, not yet. Everything above describes finding specific instances after the fact, by auditing a mechanism and discovering it had stopped. That is genuinely better than waiting for complaints, and it is nowhere near a measurement.

The honest position is that we know the shape of the failure, we have four documented cases of it in our own product, and we have no number that tells us whether it is getting better or worse. A concept you can only confirm in hindsight is a diagnosis, not an instrument. Naming it is the first half of the work.

Written 8 August 2026. We append when the facts change. Related: the belief this comes from, all build notes, opt-in proof.