Write down your own process first
Before looking at any software, put the current state on one page. How working time is captured, how pay is calculated, how leave is requested, who gets which report and when.
That page becomes your requirements document. Without it every demo looks convincing and the decision gets made on impression.
While you are there, mark the three most painful problems. The system has to solve those three. Everything else is a bonus.
Is attendance the foundation or an add-on
This is the most important question and it is the one least often asked.
In many HRM systems attendance is built as an add-on module: the core is an employee database, and working time is connected from outside or typed in. In a system like that, payroll still needs checking by hand.
If you need accurate working time, attendance has to sit in the foundation. Testing that is easy: ask what source arrival and departure times come from, and whether they feed pay automatically.
What kind of staff do you have
Fixed-site staff and mobile staff need different capture methods. If you have both, they must run in one system.
Otherwise you get two separate reports and reconcile them by hand at month end, which cancels out the benefit you bought the automation for.
- Office, manufacturing, retail, clinic: terminal
- Sales, delivery, construction, field service: geofenced mobile app
- Mixed team: both, in one system
Integrations and export
Ask early how the system talks to the other software you run.
In most cases full integration is unnecessary and exporting a report to accounting is enough. What matters is that the export format carries the columns you use and does not need reworking by hand every month.
If you run 1C or another specialised system, settle the integration question before signing anything.
The pricing model
Price is usually tied to headcount, but the details differ and they move the total noticeably.
Pin down the following: whether the number of branches is capped, whether device cost is included in the plan, whether extra modules are billed separately, and how the plan changes as you grow.
Working with vendors who do not publish a price takes longer: every question means waiting for a call back.
Language and support
Interface language turns out to matter more than people expect. In manufacturing and construction part of the workforce reads only their own language, and will simply not use an app they cannot follow.
Settle the support question too: which language, and which timezone. Working with a support desk in another country is slow in practice.
Trial period and rollout
Buying a system with no trial is a risk. What a demo hides is exactly what shows up in real use.
During the trial, run at least one full monthly cycle: let attendance accumulate, calculate payroll and compare the result against your old method. If they disagree, do not sign until you understand why.
Ask about rollout time as well. Technical setup finishes quickly, but a team settling in takes months.
The checklist
Put these questions to the vendor.
- What source do arrival and departure times come from
- Is pay calculated from attendance automatically
- How do mobile staff record attendance
- Is data lost when the internet drops
- Is the number of branches capped
- What formats can reports be exported in
- Which languages are the interface and support available in
- How long is the trial and does it need a card
- Can modules be switched on in stages
- Is every action written to a log
In short
- Start by writing down your process, not by watching a demo
- If attendance is an add-on, payroll still gets checked by hand
- A mixed team needs both capture methods in one system
- Run at least one full monthly cycle during the trial
- With hidden pricing, every question costs a phone call