There are un-intrusive bots for that

Theres already things like followupthen.com. also a few tokls for monitoring if your emails are replied to in gmail i think already

It's a bit simplistic to think that.

I've never been a fan of these overly technical solutions to what is actually a social issue.

Measurement in processes is a kind of Heisenberg situation. Every time you measure something, you have potential for affecting it. For example, if I go to a developer and repeatedly ask if they are done yet, there is a good probability that the developer will decide to be "done" just to get me off their back. Later when you discover that important things were skipped in order to get it out the door quickly, you will have a problem.

Because of this, it is better to have "passive" measurement. In other words, the activity itself should indicate whether or not it is done. If we were watching someone dig a ditch, we could decide if the ditch were dug just by looking at it. If it wasn't done, we could get a feeling for how long it will take by looking at how much was done so far. If we do that discretely, then the worker is not affected.

Of course, with software, this is not really feasible most of the time. You could insist that people check in their code often and follow the progress, but most management does not want to be so involved. Instead, it's better to have a shared document where a developer marks that they have started development on something and marks when they have finished (i.e. the code is merged and is or can be shipped).

As long as the developers are good about indicating this (and, as a manager, you should be strict about making sure this is done), then you know when tasks are started and finished. What's missing is "how much longer". Again, it is not a good idea to ask the developer. Instead we should rely on statistics.

Each task will take a certain amount of time. We can estimate that time. The estimate is a random variable with a certain distribution. I'm not sure what that distribution will be, but let's consider a case where each task is set up so that it is expected to take about the same amount of time. The time between completions might reasonably be governed by an exponential probability distribution. In other words, over time it becomes more and more likely that the task will be complete. For each task, there is an average completion time. Furthermore, if we group the tasks into a reasonably sized iteration (say 30 or more tasks), we can measure the average of these averages over many iterations.

As an example, say we have 10 iterations, each with 30 tasks. Each iteration will have an average duration for the task over the 30 tasks. We can then compute the average of those averages over the 10 iterations. The cool thing is that no matter what the distribution of the individual tasks, the average of the average is normally distributed. This distribution has the wonderful property that half of the distribution lies to the left of the mean and half lies to the right.

This allows you to predict pretty closely when an iteration will finish (though not individual tasks!). In other words, you can take that average of the average, multiply it by 30 (the iteration size) and 50% of the time you will complete the iteration in under that amount of time. If you also look at the variance you can calculate the 70%, 90% or whatever completion rate you desire.

Of course, it doesn't always work -- only when your team works well together and when they aren't pressured or pestered all the time. It's the manager's job to ensure that this happens -- let the statistics predict completion time.

You may be wondering, "What if I want to know the completion time of an individual task"? My answer: as a general rule, don't do that. It's a terribly horrible idea. It breaks your team. Of course there are times when you absolutely need to do it, in which case you can pester them in person. You should do it so infrequently that using a service would seem ludicrous. If you absolutely must micro-manage your team for every task, then you have broken your team and no tool is going to save you.

The author of the article has proved there's a market. If you think there's a better way then there's money on the table waiting for you to pick it up. Until you prove your ideas with execution, they'll remain conjecture.