Making It Cheap to Ask a Question

An approver who spots a problem faces a choice between approving something they doubt and starting a process that costs them a relationship, costs the employee twenty minutes, and may cost somebody their pay date.

The practical lesson in “Making It Cheap to Ask a Question” is that a timesheet only becomes reliable through a process people can operate consistently. For teams exploring mouse jiggler detection, review the platform here can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.

Given that choice, they approve. Every time, and correctly, because the cost of the alternative is real and the cost of approving falls on somebody else months later. Changing the choice is a design problem, not a motivational one.

For a separate benchmark relevant to “Making It Cheap to Ask a Question”, consult the GOV.UK working-hours guidance. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

What makes refusing expensive

Rejection is all-or-nothing in most configurations. A query about one line sends the whole week back to draft, and the person has to resubmit everything.

Rejection blocks payment. An unresolved question means the whole timesheet is unapproved, which in a coupled workflow means the person is not paid, which makes every query a threat.

Rejection is formal. It generates a status, a notification and sometimes an escalation, for what is often a two-sentence question.

And rejection has no middle setting. There is no way to say "approved, but check this next time".

The four changes

Line-level query. The approver flags one entry; the rest of the week is approved and proceeds. The employee answers one question. Most products support this and most implementations route everything through whole-week rejection because that is the default.

Pay the undisputed hours. A queried line does not hold the rest. This usually follows automatically from line-level query and sometimes needs the payroll interface changed to handle a partial approval.

An informal channel. A message rather than a status change. Faster, less confrontational, answered more often. The system should record that a question was asked and answered without dressing it as a rejection.

An observation that is not a query. A note attached to an approved record: this is fine, but the coding looks unusual — worth a word. It costs nothing and it is how patterns get caught before they become corrections.

The effect on the rate

Organisations making these changes typically see the query rate move from zero to somewhere between five and fifteen per cent within two periods, with no instruction to anybody and no change in approver behaviour beyond the availability of a cheaper option.

The downstream correction rate falls by more than the query rate rises, which is the part that pays for it: a question asked before approval costs minutes, and the same error found at invoice or at audit costs considerably more.

What to watch

A query rate that stays at zero after the changes means something else is wrong — usually that approvers have no independent knowledge, or no window, or both, and the query mechanism was not the binding constraint.

A query rate above twenty per cent usually means the codes are ambiguous or the guidance is missing, and the queries are all the same question. Look at what is being asked; it is a specification for a fix upstream.

And watch the resolution time. Queries that sit unanswered for a week are worse than no queries, because they hold records open and generate chasing. A query should have a default: resolved in two working days or escalated, not left open indefinitely.

The thing that does not work

Setting a target refusal rate. Within one period approvers will refuse the correct number of timesheets, selected for convenience rather than for doubt, and the measure will be destroyed along with the goodwill.

The rate is an indicator, not a target. What you change is the price of the action, and then you watch what the rate does.

Answering one well

The other half of making queries cheap is making them easy to answer. A query that arrives as a status change with no text, requiring the person to log in, find the record and guess what is wrong, will take three days and two exchanges.

A query should say which line, what the question is, and what would resolve it, and should be answerable in a reply. Where the answer is a correction, the person should be able to make it without resubmitting the week. Both are configuration, both are usually available, and together they are the difference between a query loop of hours and one of days.