Why is your recruitment CRM so slow?
Almost never your internet, and almost never your laptop. Four causes explain nearly all of it, and three of them are decisions somebody made rather than problems that can be tuned away.
Ask AI about this
Slowness is the complaint agency owners hear most and act on least, because it never arrives as a single fault. Nobody raises a ticket saying the software is four seconds slower than it should be. It shows up as consultants being tired of it, as a spreadsheet appearing, as people batching work up to avoid the screen that takes a while.
It is also worth real money. A few seconds on something done sixty times a day, across a team, is a working week a month. So it is worth understanding what actually causes it, because the fix depends entirely on which of these you have.
Cause one: the software is a long way from you
Most business software runs in one data centre. Every click travels there and back, and the further away you are the longer that takes, regardless of how fast your connection is.
This is why the same product feels quick in London and sluggish in Dubai, Sydney or Singapore. The distance is fixed and no amount of bandwidth removes it. A team in the vendor's home region will genuinely never see the problem your team lives with, which is why support struggles to reproduce it.
The modern arrangement runs the parts that handle your clicks close to wherever you are, leaving only the genuinely central work to travel. We do it that way, which is why the product feels the same in Dubai as it does in Manchester.
The test is simple. Ask the vendor where their software runs, and ask to speak to a customer in your region rather than theirs.
Cause two: it fetches far more than it shows you
Open a candidate and the screen shows perhaps thirty fields. Behind it, a poorly built product may be fetching the whole record, every note, every application, every file reference and every related company, then throwing most of it away.
This is invisible on a small database and becomes crippling on a large one, which is why the software your agency loved in year one is heavy in year four. Nothing changed except that you succeeded.
The symptom is distinctive. Lists and searches get slower as you grow, and the biggest, longest-standing records are the slowest to open. If your best clients are the slowest screens in the building, this is what you have.
Cause three: everything is loaded at once
Some products fetch everything the screen might need before showing you anything, so you wait for the slowest part of the page even when you only wanted the phone number.
You can spot this without any technical knowledge. If the screen is blank and then appears all at once, you are waiting for the slowest thing on it. If it appears in pieces, with the important part first, somebody has thought about your time.
Watch this deliberately on a demo. It tells you whether the people who built the product ever use it under pressure.
Cause four: an old core that cannot be made faster
The last cause is the serious one. Some of the recruitment software in this market is built on cores written well over a decade ago, in a style where every request does far more work than it needs to, and where the shape of the data makes certain questions expensive no matter how much hardware is thrown at them.
You can recognise this from the outside by the pattern of it. Some screens are fine and specific ones are always bad, usually the ones that summarise, report or search across a lot of records. Hardware upgrades produce a small improvement that fades. Support suggests you narrow your search.
Being honest about our own product, we have an older core too, and it still runs a great deal of what an agency does. The difference is what you do about it. We put a modern layer in front of it and have been moving capability out piece by piece, so the expensive questions get answered by the new part while the old one keeps running underneath. The wrong answer is to announce a rewrite, and the worse answer is to tell customers it is fine.
Telling the four apart
| What you notice | Most likely cause | Can the vendor fix it? |
|---|---|---|
| Slow for your region, fine for the vendor | Distance to the software | Yes, but it is architectural work |
| Worse every year as data grows | Fetching far more than it shows | Yes, screen by screen |
| Blank, then everything at once | Loading it all before showing any | Yes, and quickly |
| Specific screens always bad, hardware does not help | An old core | Only by moving that work out, over years |
What to do about it
Measure it before you raise it, because impressions get argued with and numbers do not. Pick the three screens your consultants use most, time them with a stopwatch at ten in the morning, and do it on three different days. Then send the vendor the numbers and ask which of the four causes it is.
The answer you get is worth as much as the fix. A vendor who says it is one of the first three and explains what they will do is worth staying with. A vendor who blames your connection without having measured anything has told you they are not going to look.
Speed is not a feature and it never wins a demo, which is exactly why it is a good test of whether the people building your software use it themselves.
Lokesh is Founder and Head of Engineering at Recruitly.
