Don't Work Around the Software

LONDON. 2026-09-23. The Agency wishes to record an observation about the behaviour of handlers, and to state a position on it.

The observation is this. A handler running a pet-sitting business in the north of England was watched, over several months, adding a line to an invoice by hand. Every month, the same line. The software believed that an overnight stay begins in the morning and ends in the morning, because that is what overnight stays had always done. Her stays did not. She left one house in the afternoon; the next sitter arrived in the evening. One night of work fell between the two and the invoice never saw it.

So she typed it in. It took under a minute. She had been doing it for months.

The part that matters is how ordinary it had become

The Agency draws operatives' attention not to the missing night but to the minute.

A workaround does not stay a workaround. Within about three months it stops being a thing you are doing because the software cannot, and becomes simply how the job is done. It gets a place in the routine. It survives staff changes, because it is taught to the next person as though it were the work rather than a repair to the work. Nobody writes it down as a fault, because by then nobody experiences it as one.

That is why the handlers cannot wait to be told. By the time a workaround is comfortable enough to live with, it is invisible to the only person who can see it.

There is a distinction worth keeping. A workaround is not the same as a preference. If a business does something in an unusual order because it suits them, that is theirs and the software should stay out of it. A workaround is different: it is unpaid work, done repeatedly, to bridge a gap the software left. It has a cost, that cost is paid every month, and it is almost always paid by the person who has the least time.

The button is not the problem

When an operative asks for something, the handlers are less interested in the control being requested than in the reason it is wanted.

What is the operative actually trying to accomplish. Where the friction appears, and on whom it lands. Who else is in the process, because it is rarely only the person asking. Whether the software already holds enough to decide the thing by itself. And whether solving it once would give every other business a capability they did not have.

Sometimes it would not, and the handlers are permitted to say so. Not every individual way of working belongs in a platform shared by hundreds.

But the missing night was not a request for a box to type a night into. Underneath it was a fact about pet sitting that the software had never been told: a handover can happen at any hour, and two sitters can meet on the same day. Once that is understood rather than patched, several things stop being wrong at once — the price, the calendar that would not let the second stay begin on the day the first ended, and the invoice.

Do not remove friction by relocating it

Automation is not only about the person looking at the dashboard.

Every process has a far side. A walker. A client making a booking. Somebody completing a form, receiving an invoice, paying one. It is easy to solve one person's problem by giving somebody else another decision to make, and easier still to describe that as an improvement.

The Agency does not regard it as one. An automation that ends in another person's inbox is a transfer, not a saving.

What one business teaches, the next one inherits

The handler with the missing night did not get a workaround. What the platform got was an understanding of how overnight sitting is actually done, and every business that sits overnight now has it.

None of them will know where it came from. That is the correct outcome. A business that reports friction is not asking for a favour; it is doing the one thing no amount of planning can substitute for, which is telling the people who build the thing how the work is really done. A platform assembled this way slowly stops being a set of features and becomes a record of how an industry operates — and that record cannot be written in advance by anybody, however experienced.

Automation should be difficult to notice

The best of it has no button announcing itself.

A figure is right because the system knew the variables. Something appears because it is relevant, and something else does not appear because it is not. A fact entered once quietly changes what happens three screens away. A process that took five decisions takes one, or none.

That is the direction: less administration, fewer unnecessary decisions, fewer chances to make a mistake, and less software standing between a business and its actual work.

The instruction

There will always be boundaries, and a platform that tried to have none would serve nobody well. But *"the software doesn't work that way"* should not reliably end a conversation. Occasionally it ought to start one.

So the Agency's instruction to operatives is short, and it is the whole purpose of this statement.

Report the minute. Not the crisis — those get reported anyway. Report the small ordinary repair you have stopped noticing, the one you would train somebody else to do. Say what you were trying to accomplish rather than which button would have helped, because the handlers are frequently able to do something better than the button.

The address is support@mypetsitter.co.uk, or the support window inside the platform. A field agent reads both.

Behind one awkward little workaround there is usually a way of working that the software should have understood. Occasionally there is one nobody had thought of at all, and those are worth considerably more than the minute they cost you.

— DM