The first question in a timekeeping implementation is often a configuration question: can the system do this? A more useful starting point is: what should happen in the working day, and why?

That small change makes a workshop much more concrete. Instead of discussing an abstract approval process, walk through a manager reviewing a missing clock-out during a busy period. Who sees it? What information do they need? What happens if they do nothing?

Start with a scenario, not a setting

Write a short story with a clear trigger and an observable outcome. For example: an employee reports a missing clock-out; the manager checks the reported finish time and supporting information; the employee can see what was corrected and who approved it.

The useful part is the method: make the operational intent explicit before deciding how to support it.

For each scenario, capture four things:

  1. The person: who is trying to get something done?
  2. The decision: what do they need to decide, approve, or correct?
  3. The exception: what happens when the normal path fails?
  4. The evidence: how will you know the process worked?

Give the exceptions their own airtime

An ordinary working day is the easiest story to tell. The awkward cases reveal more: the absent approver, the late change, the employee assigned to two teams, the correction after an internal deadline.

Ask the people doing the work to describe these situations. Record the intended behaviour in plain language before translating it into configuration. Where policy is unclear, identify an owner for that decision rather than letting a technical setting silently become policy.

A configuration decision should have an operational reason you can explain without opening the system.

A case: the approver who is on leave

A team approves time at the end of each month. In week four the approving manager goes on leave, and every timesheet in that team sits unapproved until they return.

The configuration instinct is immediate: the system supports delegation, so turn delegation on. That answers how. It does not answer the question the business actually has.

Who should approve in that manager’s place? A peer manager who did not see any of those shifts and cannot vouch for them? The approver’s own manager, two steps removed from the floor? A senior member of the team, who now approves their own colleagues’ hours?

Each of those is a defensible answer in some organisations and unacceptable in others. The difference is not technical. It is about whose judgement the business is willing to stand behind when a record is questioned months later.

Settle that first. Then the delegation setting becomes a short conversation instead of a long one, because everyone already agrees what it is supposed to achieve. Skip it, and whoever configures the system ends up choosing the organisation’s approval policy by default, usually without knowing that is what they are doing.

That is the pattern worth watching for: a technical setting that quietly answers a question nobody has asked out loud.

Make the scenario useful twice

The same scenario can later become a test. State the starting conditions, the action, and the expected result. Include what employees and managers can actually see, not only what an administrator can verify.

That creates a practical line from discovery to acceptance: a real need, an agreed behaviour, and a way to check it. Product versions, licensed modules and local requirements will affect the eventual design, so confirm the implementation details against the documentation for your environment.

A question for your next workshop: which recurring exception is your team still resolving outside the system, and what makes that workaround necessary?