Do slow reports mean we should replace the CRM?

Not as the default next step. Name the report, time one real run, and write down whether the cause looks like a query per row, a missing index, an oversized response or work that should leave the click. Steady the product you have before you treat it as disposable.

Should a heavy report stay inside the page click?

Not once a normal run is longer than a person will wait. Move that run to a background job and keep the result on the same report screen. A retry must not create a second email, charge or score. Ask that of your report even if the queue is a simple one you already run.

Can someone else’s timing predict our report?

No. A number from another product describes that operation, not your CRM. On one product a query loop became one aggregating query and dropped from a bit over twelve seconds to a bit over two. Use that as the shape of a check — one operation, before and after — not as a forecast.

Why does data isolation belong in a performance check?

A faster report that shows another customer’s rows is not an improvement. On one multi-tenant product each branch had its own database, and the indexes were designed for that split. Before you speed a report up, open it as two accounts that must not see each other.

CRM/SaaS reports crawl: queues and indexes without a full rewrite

What to check when a CRM or SaaS report makes people wait, before anyone proposes a new platform.

The Monday report is the one managers open first, and it is the one that crawls. An export for a customer, a branch comparison, a summary of last week's calls: someone starts it, waits, and then asks whether it is time to replace the CRM. A replacement quote answers a different question. The report is slow. A new product can still build that report the same way: inside the click, row by row, on a table nobody indexed, in a database shared by every branch.

This is for the owner of that product. The words that matter are the report, the person who waits, and whether one customer's data can appear on another customer's screen. Queues and indexes are how you fix those, not a reason to rewrite the platform. Time the report you already have. Then decide whether the wait belongs in a background job, in an index, or in a smaller response. A full rewrite is the last option, and only after those checks have a result.

1. Name the report people already wait on

A meeting that says "reporting is broken" and then jumps to a vendor shortlist has skipped the only fact you need. Broken does not say which report, which branch, or how long the wait is. Two reports can live in the same product and have nothing in common. One is a short list. The other joins every call, invoice and message for a month.

The person who feels it is not looking at the database. They feel a spinner, a timeout, or a spreadsheet that arrives after the stand-up is over. The proposal that follows is a new CRM, because that is a decision they know how to make. The report itself stays unnamed, so the new CRM inherits the same shape of question.

Write this on one page, next to the report:

The report's name, who runs it, and how often. "Sales", "a branch manager", "finance on Monday" is enough.
One real run, on a real date range, before any change. The seconds, and whether it timed out.
Whether the wait is on screen or only in an export. Those are different places to fix.
The decision the report supports. A number nobody uses is a different problem from a number people need before they call a customer.

A platform-wide claim — "the CRM is slow" — will not tell a developer which query to open. The same habit applies on a public site: name the screen before you redesign it. That pass is written up separately as what to check before a redesign.

2. Why a report crawls without the product being old

Age is a weak explanation. A young product crawls for the same reasons as an old one. The report reads the database once per row. The filtered column has no index. The response carries every field when the screen shows five.

The first version of a report is often a loop. For each customer, load their calls. For each call, load a score. It is correct, and it is slow once the rows are real. The same shape shows up outside CRMs. On one product, a query loop became a single aggregating query and that operation dropped from a bit over twelve seconds to a bit over two. The number belongs to that operation. It is not a forecast for your Monday export. What it shows is the shape of the work: one query instead of a loop, an index where search needed one, a response no larger than the screen.

Ask the person who can open the query:

Does the report run one query per row? If yes, write that down as the suspected cause.
Which column does the report filter or sort on, and does that column have an index?
How big is the response compared with the columns on screen? Extra fields are a contract problem, not a reason for a new CRM.
Does the report call an outside system for every row — telephony, accounting, mail? That wait is not fixed by a new table style.

3. When the report should leave the click

Some reports hold the browser open until every row is done. People retry. A retry that starts the same heavy work again makes the wait worse, and it can double a side effect if the job sends mail, writes a charge, or posts a score.

The report was built as a page because a page was the fastest way to show it once. Monthly ranges, branch roll-ups and file exports outgrow that page. The work is still correct. It no longer fits inside one request. A queue takes the run off the click, stores the result, and lets the person come back when it is ready. That is a smaller change than replacing the CRM.

Move it off the click when these are true:

A normal run is longer than a person will wait on a spinner. Treat it as background work.
You have written what a second run must not repeat: an email, a charge, a second score on the same call.
You have failed one run on purpose in a separate environment, started it again, and still have one result.
The result stays where the manager already looks: the same report screen, with a status, not a new product.

On one multi-tenant CRM, call processing ran as queue jobs. A retry had to find the work already recorded and stop, so a second attempt did not create a second result. The workflow connected call handling, telephony, messaging and accounting, then exposed the outcome through reporting. Your report may not be a call score. The question is the same: if this run is attempted twice, do you get one row or two? Ask that even when the queue is a simple one you already operate.

4. Check branch and customer boundaries before you speed the report up

A faster report that shows the wrong customer's rows is a worse report. Speed makes a leak easier to notice. In a CRM or SaaS product, branches, tenants or accounts share one application and must not share one another's records.

The convenient query is "all calls this month", with the filter applied in the page. Or there is one shared database, and some queries forget the column that says whose rows these are. An index makes that query faster. It does not add the missing filter. On one product, each branch had its own database, and the migrations and indexes were designed for that separation. The index served the boundary. It was not a substitute for the boundary.

Check the boundary before you celebrate a faster export:

Pick two accounts that must not see each other. Open the report as each of them, on the same date range.
Write down where the boundary lives: a separate database per branch, or a required filter that every report includes.
If you add an index, say which filter it supports. An index on the wrong column speeds a query you should not be running.
Do not copy production customer data into an unsecured test environment to try this. Use a reduced or anonymized copy.

5. A short plan that is not a rewrite

A proposal with two lines — "reporting is slow" and "replace the CRM" — is missing the third line you can write today. Immediate: the report people wait on, timed, with a suspected cause. Next: either one aggregating query and an index, or a background run that is safe to retry, plus a written answer on how accounts stay separate. Later: a new platform, if the product still fails the decision the report is for after those changes. Inherited production systems are usually steadied before anyone treats them as disposable. The decision is what to steady.

Keep the plan small enough to finish:

The timed report has an owner, and a repeated timing is the check that the change worked.
A replacement does not start until that timing exists and the boundary between accounts is written down.
Every number stays attached to the report that produced it. One export is not a claim about the whole company.

When to bring in a specialist

You can name the report, time it, and click through two accounts yourself. Ask for help when the suspected cause is a query or an index and nobody inside can read it, when a retry might send a second email or a second charge, or when a replacement quote is already moving and it does not mention this report.

I do this kind of reporting work on an existing CRM or SaaS product, without starting from an empty repository. Services cover performance, SaaS and backend systems, and AI integration, including the case where a report sits on top of telephony or another system you already run. Selected work is the same class of system: a report that had to stay correct under retry, and data that had to stay inside its own account. If you want to walk through one crawling report, message me on LinkedIn with its name, who waits on it, and the seconds you wrote down.