HRMS buying checklist for Indian SMEs: 20 questions to ask any vendor

Every HRMS demos well. It is shown on clean data, with one location, one shift and an approval route that goes manager then HR. Your business has three sites, a supervisor who approves on the floor, and a founder who signs anything unusual.

The gap between those two is where implementations fail, so the questions worth asking are the ones that expose it before you sign.

Before the demo

Bring three things to every demo and insist they are used: last month's actual attendance data for one department, your real approval routes written down, and your three most awkward exceptions. A demo run on your material tells you in an hour what a trial tells you in a month.

The twenty questions

FIT
 1. Show me a leave request routed to a supervisor, then a
    function head, with a deputy when the first is on leave.
 2. How do I configure a rule that differs by location?
 3. Show a night shift crossing midnight, and where it lands.
 4. What happens to a correction raised after the cut-off?
 5. Can an employee see their own leave balance, and how is
    it computed?

YOUR DATA
 6. What is the minimum data needed to go live?
 7. How do you handle four spreadsheets with three date
    formats and missing joining dates?
 8. Who does the cleaning — you, us, or nobody?
 9. Can we export everything, at any time, in a usable form?
10. Where is our data hosted, and what happens if we leave?

THE EXCEPTIONS
11. Here are our three exceptions. Show me each one.
12. What cannot this product do that businesses like us ask for?
13. When a rule changes, do we configure it or raise a ticket?

AFTER GO-LIVE
14. Who owns our implementation, and are they the person in
    this room?
15. What is realistic elapsed time to a first real payroll
    cycle, including our own effort?
16. Which statutory outputs does the product produce, and
    which remain ours? (Confirm scope with your own adviser.)
17. What support response should we expect, and at what cost?
18. How are upgrades handled, and can they break our config?
19. Give me two customers of our size and sector to call.
20. What is the total first-year cost including implementation,
    training and any module we will inevitably need?

The four answers that should worry you

• "We can customise that." Often true and frequently expensive, and customisation is what makes upgrades painful later. Ask whether it is configuration or development, and who pays when it breaks.
• "Nobody has asked for that before." Either your requirement is genuinely unusual, or the vendor does not work with businesses like yours. Both are worth knowing.
• "That comes in the next release." Buy what exists today. Roadmaps slip, and you will be running payroll in the meantime.
• A demo that will not use your data. If a vendor will not load one department's real attendance, the reason is rarely convenience.

Question 19 is the one to actually do

Reference calls get skipped because they feel awkward and take time. They are the single most informative step in the whole evaluation, and the questions are simple: what took longer than expected, what do you still do outside the system, and would you buy it again.

Insist on a customer of your size and sector. A reference from a thousand-person company tells you nothing about how the product behaves when the person configuring it also runs payroll.

What price does and does not tell you

Per-employee-per-month pricing is easy to compare and rarely decides the outcome. The costs that actually differ are implementation effort, the modules you discover you need, and the internal time spent on data and decisions.

Ask for total first-year cost including all of it. A cheaper licence attached to a heavier implementation is often the more expensive choice, and it is the comparison most businesses never make.

Decide what you are buying first

The most common evaluation error is starting from features. Start instead from the three things costing you most this month — chasing attendance, rebuilding payroll inputs, answering balance queries — and evaluate against those. A product that fixes them and lacks a module you might want in three years is the better buy.

And be clear which problem is process rather than product. If your cut-off is not held and no one owns each input, no GullyHR software or any other will fix the lateness — the system will simply enforce a rule the business does not follow, and be blamed for it. That is why the two are usually settled together rather than in sequence, which is what HRMS implementation work is for.

If you want to run these twenty questions against a product configured on your own attendance and approval routes rather than on sample data, book a free demo of GullyHR software and bring last month's file.

Who should be in the demo

Not only the founder and whoever will own the system. Bring the person who actually assembles payroll inputs and one line manager who will approve things in it. They ask different questions and they are the two people whose refusal to adopt will quietly kill the project.

The payroll person will spot immediately whether the input flow matches reality. The line manager will tell you whether approving a request takes three clicks or eleven, which sounds trivial and is the difference between adoption and reversion to chat.

Their objections in the demo are cheap. The same objections in month three, after configuration, cost a great deal more — and are the most common reason an HRMS implementation stalls after a successful selection.

What to ask the vendor's existing customers

The reference call is offered by every vendor and conducted badly by almost every buyer, because the questions asked are the ones the reference is prepared for.

Asking whether they are happy with the product produces a yes, since the vendor chose them. The useful questions are narrower and harder to rehearse: what took longer than you expected, what did you have to change about how you work, and what do you still do outside the system.

The third is the most revealing. Every implementation leaves something outside the product, and a reference who says nothing is outside it has either not gone live properly or is not being candid. A specific answer — we still track one category of exception in a sheet — tells you something real about the boundaries.

Also ask when they last spoke to support and how it went. Product quality is visible in a demo; support quality is not, and it is what you will experience monthly for years. A reference who has to think about when they last needed support is giving you a better answer than one with a prepared anecdote about how responsive the team is.

One question the list deliberately leaves out: whether the product will make your HR function work. It will not, on its own. A system enforces the rules it is given, so if attendance has no owner and the cut-off moves whenever somebody senior asks, the software will faithfully enforce a rule the business does not keep — and be blamed for the result. Settling those rules is ordinary HR process consulting work, and it is worth doing in parallel with the evaluation rather than after the contract is signed.