← Notes

Promise what your operation can sustain

My opinion: the promise of human service is made by default, without anyone checking whether someone exists to keep it — and it costs more than promising nothing.

The promise of human service enters products by default. It comes in the template, it comes from market expectation, it comes from the feeling that offering a person is always more generous than not offering one. It almost never comes with the question of who is going to answer.

My opinion is that this unkept promise costs more than its absence. A visitor who does not see a talk-to-someone button looks for another path — reads more, books a slot, writes, gives up quickly. A visitor who sees the button, presses it and waits is stuck in an expectation I created. I traded their autonomy for a queue that does not exist.

The evidence that this is structural, and not personal sloppiness, is in how much companies with teams miss the same target. A lead response time survey records that "Nearly 1 in 5 companies didn't respond by email altogether". If the promise breaks with a team in place, it will not stop breaking because I tried harder.

What I argue for is unpopular and honest: design from capacity. If my capacity is to reply within a few hours, the interface should promise a few hours — or promise no conversation at all, and offer what can be finished alone: a booking, an asynchronous path, an automatic reply that settles the simple case.

And here is the part I am interested in building. A fallback, to me, is not the embarrassed plan B; it is the product I can sustain. A set of agents that carries the conversation to a possible outcome is not replacing the agent I would have hired — it is replacing the silence I have.