User-facing completions and the quiet ones behind them

Invoice totals treat every completion as equal. People in the app do not. A paragraph the writer requested is not the same event as a title suggestion generated for a record that nobody opened.

We split the inventory into waiting and not-waiting. Waiting means a person is looking at a control that will not finish until the model returns. Not-waiting covers precomputes, nightly jobs, embedding refreshes, and the various ‘just in case’ calls that accumulate on save hooks.

The split changes the conversation. A team that believes ‘users are talking to the model all day’ sometimes discovers that the waiting column is small and the save-hook column is not. That is not a moral judgement. It is a description of what the app chose to do with money and time.

Silent failure belongs in the same discussion. If a background rewrite can fail without a trace in the UI, the usage picture must still count the attempt. Otherwise the report will understate how often the app tried, and overstate how often a person saw a result.

One Petaling Jaya product we read had a nightly job that re-summarised every open ticket, including tickets whose text had not changed. The waiting usage — agents asking for a suggested reply — was modest. The nightly job was not. Nobody had named the job in the original inventory the team handed us; it lived in a scheduler with a cheerful name.

You do not need to stop background work to understand it. You need a row, a mark for waiting or not, and a way to see duplicates. Without those, stakeholder meetings become arguments about a single number that never meant one thing.

When you write to us, it helps to guess this split in one sentence: ‘We think people wait on the composer and the rest is background.’ Even a wrong guess gives the assessment a claim to test.