"The Four Minutes You Bill For But Did Not Work"

You are on a client call. The timer started when you opened your laptop at 9:02. It is 9:37 now. For the last four minutes you have been listening, not typing, not clicking, doing nothing a computer can detect. The timer does not know that. It just knows it is 9:37 and it started at 9:02, so you have billed thirty-five minutes, and thirty-one of them were real.

That four minutes is on the invoice

. The client will not question it. It is four minutes. But four minutes is not the point. The point is you know it is there, and the client does not, and that gap is the kind of thing that makes billing feel dishonest even when the invoice is technically accurate.

I am not going to tell you to stop billing for calls. You should bill for calls. You are working on the call. The problem is not the call. The problem is the timer cannot tell the difference between "on a call, working" and "away from the desk, timer still running," and you are the only one who knows which one just happened.

#The two ways this goes wrong

The first way is the one I just described. The timer runs while you are away. You notice at the end of the day, and you face a choice: trim it and bill less than the timer says, or leave it and bill for time you did not work. Most people leave it, because trimming feels like leaving money on the table, and because nobody wants to explain a hand-edited timesheet.

The second way is worse. The timer runs while you are away, you do not notice, and the client sees an invoice that is slightly too high. They probably will not say anything. But if they ever compare notes, or if they ask for a breakdown, the gap between the invoice and the work is right there, and "my timer was running" is not a defense.

Both cases come from the same place: the timer is running and nobody is watching it.

#What idle detection actually does

This is the case idle detection is built for, and I want to be precise about what it does and does not do, because it is easy to oversell.

owntime watches for input while the timer is running. If there is no activity for a configurable window, ten minutes by default, it prompts you. A notification and an idle bar. "Idle X minutes detected. Keep or trim?" Two choices. Log up to the point you went away, or keep running because you were working and the computer just could not see it.

That is all it does. It does not guess whether you were on a call. It does not read your calendar. It does not know you were in a meeting. It only knows the keyboard and mouse were still, and it asks you to confirm what that means.

The trim is manual on purpose. I thought about auto-trimming, and I decided against it, because auto-trimming assumes the idle detection is always right, and it is not. Sometimes you are reading a brief with the timer running and you do not touch the keyboard for ten minutes and you are absolutely working. Auto-trim would cut that. The prompt keeps you in the decision.

#The honest limits

Idle detection is a nudge, not a solution. If you never look at the prompt, it does not help. If you always click "keep running," it does not help. It only helps if you actually use the prompt to make a choice, which means it only helps if you care about the gap between the timer and the work.

It also only watches the computer. If you track time on your phone, or if you bill for work you do away from the desk, idle detection is not tracking that. It is a desktop feature for a desktop app, and it has the limits of both.

#The test

If you run a timer, here is the test. Let the idle prompt fire once. Read it honestly. Were you working, or were you away? Trim or keep based on the answer, not based on which choice bills more.

If the prompt makes you slightly uncomfortable, that is the point. The discomfort is the gap between the timer and the work, made visible. You can ignore it, but now you know it is there.

Try owntime free for 14 days · See pricing, one time

---