Why is your recruitment CRM so slow?
Almost never your internet and almost never your laptop. Four causes explain nearly all of it, three of them are decisions somebody made rather than problems that can be tuned away, and you can work out which one you have in an afternoon with a stopwatch.
Ask AI about this
Slowness is the complaint agency owners hear most often 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 arrives as consultants being tired of it, as a spreadsheet appearing, as people batching work up to avoid a screen that takes a while, as the candidate search being done in someone's head instead of in the system.
It is also worth real money, and the arithmetic is unforgiving. A few seconds on something a consultant does sixty times a day, across a team, is a working week a month that you are paying for and not billing. So it is worth knowing what actually causes it, because the four causes need completely different responses and only one of them can be fixed by your vendor this quarter.
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. Distance is not bandwidth, and buying a better line does not help.
This is why the same product feels quick in London and sluggish in Dubai, Sydney or Singapore, and why it gets worse for your team and never for the vendor's. A support team sitting next to the data centre will genuinely never reproduce what your team lives with, which is why these tickets get closed as cannot reproduce and why raising it a second time feels pointless.
The modern arrangement runs the parts that answer your clicks close to wherever you are, leaving only the genuinely central work to make the long trip. We build that way, which is why the product feels the same in Dubai as it does in Manchester.
How to recognise it. Everything is uniformly a bit slow rather than specific screens being bad, and it is worse for one office than another. Ask the vendor where their software runs and ask to speak to a customer in your region rather than one of 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 entire record, every note, every application, every file reference and every related company, then discarding most of it before drawing anything.
This is invisible on a small database and crippling on a large one, which is why the software your agency loved in year one feels heavy in year four. Nothing changed except that you succeeded. It is also why the vendor's demo is always fast: a demo account has forty candidates in it.
How to recognise it. The symptom is distinctive. Lists and searches get slower as you grow, and your 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, and it is the most common cause in agencies past their fifth year.
The good news is that this one is fixable by the vendor, screen by screen, without a rewrite. The question worth asking is whether they are doing it. Ask what they have made faster in the last six months. A vendor who is working on it has a list and slightly nerdy enthusiasm about it. A vendor who is not will talk about your data volumes as though they were your fault.
Cause three: everything is loaded before anything is shown
Some products fetch everything the screen might need before showing you any of it, so you wait for the slowest thing on the page even when all you wanted was the phone number.
You can spot this without any technical knowledge at all, and it is the easiest test on this page. If the screen is blank and then appears all at once, you are waiting for the slowest item on it. If it appears in pieces with the important part first, somebody has thought about your time.
Watch for it deliberately on every demo. It tells you something about the people who built the product that no feature list will, which is whether any of them has ever used it under pressure with a client on the phone.
This is the cheapest of the four to fix and the most commonly left unfixed, because it never shows up as a bug report. Nobody writes in to say the page arrives in the wrong order.
Cause four: an old core that cannot be made faster
The last cause is the serious one. Some 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 stored data makes certain questions expensive no matter how much hardware is thrown at them.
You can recognise this from outside by the pattern. Most screens are fine and specific ones are always bad, usually the ones that summarise, report or search across many records. Hardware upgrades produce a small improvement that fades within months. Support suggests you narrow your search, filter by a shorter date range, or run the report overnight. That last suggestion is the diagnostic one: being asked to schedule a report that used to be a screen means the work cannot be made fast, only moved to a time when nobody is watching.
Being honest about our own product, we have an older core too, and it still runs a great deal of what an agency does every day. 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. Anything touching that core has to leave the old behaviour working, so that if the new path fails the old one carries on.
The wrong answer is to announce a rewrite, which is how companies lose two years and a customer base. The worse answer is to tell customers it is fine. Any vendor claiming their product has no old parts is either very new or not being straight with you, and the honest version of that answer is a plan rather than a denial.
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 over quarters |
| Worse every year as your data grows | Fetching far more than it shows | Yes, screen by screen, if they are working on it |
| 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 |
How to raise it so something happens
Measure it before you raise it. Impressions get argued with and numbers do not, and you will be arguing with somebody whose own experience of the product is genuinely faster than yours.
Pick the three screens your consultants use most. Time them with a stopwatch at ten in the morning, which is when your database and their servers are both busy, and do it on three different days so nobody can call it a one-off. Write down the numbers, the office, and what was on screen.
Then send the vendor the numbers and ask a specific question: which of these four is it. Naming the four causes changes the conversation, because a vague complaint invites a vague answer and a specific one does not.
The answer you get back is worth as much as any fix. A vendor who says it is one of the first three, explains which, and tells you what they are going to do is worth staying with. A vendor who blames your connection without having measured anything has told you they are not going to look, and that is a useful thing to learn while you still have options.
Speed is not a feature, it never wins a demo, and no salesperson has ever lost a deal over it. That is exactly why it is one of the better tests of whether the people building your software use it themselves.
Lokesh is Founder and Head of Engineering at Recruitly.
