What You Are Actually Buying

Timesheet software is sold as a category. It is four products, and most vendors are strong at one or two and adequate at the rest.

The four products inside the category

A time clock. Records when someone started and stopped. Terminals, badges, mobile check-in. Its hard problems are reliability, offline operation and edit auditing.

A project time recorder. Records duration against a project or matter. Its hard problems are the category structure, entry friction and approval.

A billing engine. Turns recorded time into invoices. Its hard problems are rates, increments, write-offs and multi-currency.

A workforce management suite. Rotas, absence, scheduling, compliance rules. Its hard problems are the rule engine and the number of jurisdictions it covers.

No product is genuinely excellent at all four, and the marketing does not tell you which is the core.

How to tell which is the core

Look at the pricing page. The thing charged per seat is usually the core; the rest is a module.

Look at the integration list. A product built around billing integrates with accounting systems first; a clock integrates with payroll.

Look at what the demonstration opens on. Vendors demonstrate their strongest screen first, and they are right to.

Ask which module was released most recently. The newest module is the one with the fewest customers and the most gaps.

Ask how many customers use the module you care about, specifically, rather than the product overall.

What this means for a shortlist

Name your core need first, then treat everything else as secondary.

A product whose core matches yours will do the secondary things adequately. One whose core is elsewhere will do your core badly, whatever the feature list says.

Two good products beat one that covers everything, where the integration between them is straightforward. This is unpopular with procurement and is frequently the right answer.

The requirement nobody writes down

Whether the system is for recording or for monitoring.

Most products do both, and the monitoring features are frequently enabled by default. If your requirement is a record of hours, say so, and check what the product does out of the box rather than what it can be configured to do.

This belongs in the requirements document, because it determines which vendors are viable and it is much harder to argue after a contract is signed.

Before any demonstration

Write down the core product you need, in a sentence.

Write down what you are not buying, which is usually three of the four above.

Write down the integrations that must work, named systems, not categories.

Circulate it. The list changes once people read it, and that change is cheaper now than during implementation.

The module question

One question that reveals more than a feature comparison.

How many customers use the module you need, specifically?

Not the product overall. A vendor with ten thousand customers on the clock and forty on the billing engine is two different risks depending on which you are buying.

Ask when that module was released. The newest one has the fewest customers and the most gaps.

Ask for a reference on that module, at your size. Inability to supply one is the answer.

Who this is for

Three audiences, with different reasons to be here.

Whoever has been asked to choose a system and needs to know which questions decide the outcome.

Whoever will run it afterwards, which is frequently not the same person and is frequently not consulted.

Whoever has to sign the contract, for whom the terms about export, change control and renewal matter more than the feature list.

These notes are written for the first, with the other two's concerns raised where they arise — because the usual failure is that they arrive too late.

Separate scope from labels

Category names hide very different operating models. A provider’s feature overview is a useful inventory, but each relevant item still needs a scenario, permission check and plan confirmation.