Fix stages that move backwards
A stage ladder is meant to be climbed. When a deal or a person is recorded at a stage they already passed, every conversion rate and every time-in-stage figure built on those moves is wrong. This article shows you how to find the records it happened on, name what moved them, and repair the cause; for close dates that keep sliding instead, read Fix close dates that keep being pushed.
Before you start
Plan required
Any plan except Starter. Field discipline sits on the Analysis screen, which Starter does not include.
Permissions required
Nothing on the Analysis screen writes to your tool, so a read-only connection runs this check. The repair itself is made in your own tool, by whoever administers it.
- A stage or lifecycle field with a picklist. MarqIQ reads a picklist of stages as “meant to move forwards only”, so a free-text stage field is never tested this way.
- Change history on at least 20 of the records checked for that field. Below that MarqIQ names the field as untested rather than judging it.
- On Salesforce, deal stage is always testable, because Salesforce records stage, amount and close date on every opportunity. Any other field needs Field History Tracking switched on for it.
- On Microsoft Dynamics, the column needs auditing switched on. A column with auditing off has no history, and MarqIQ says so rather than praising it for never changing.
Find the finding
Open Insights in the left-hand menu, then Analysis.
Pick the tool whose stages you are checking along the top.
Open the Field discipline tab.
The first read takes up to a minute. On HubSpot, Salesforce and Marketo the change history comes back in bulk; on Pipedrive, Zoho CRM and Microsoft Dynamics it is one call per record, which is why those read fewer records. The reading is kept for a day, and the line above the cards gives the date it was taken.
Look under Fields being used against their purpose for a card headed “<your stage field>” is going backwards.
It carries a red Used against its purpose tag when the fault is large, an amber Early signs tag when it is small, and a separate Still happening tag when the most recent backward move was inside the last 90 days.
Read What we found before anything else.
Three lines: how many of the records checked moved backwards and what share that is, who or what made the moves with a count against each, and the month of the most recent one.
When the card is absent
Look in Behaving as they should instead. A line headed “<your stage field>” only moves forwards means MarqIQ tested the field and found no backward move on the records checked. A field named as untested at the foot of How each field was read has fewer than 20 records carrying any history for it, which is a different answer again.
What the figures are measured on
The share on the card is of the records MarqIQ read, never of your whole database. Read the sample before you repeat the percentage to anybody.
| Tool | Records whose history is read | Why that number |
|---|---|---|
| HubSpot, Salesforce | Up to 600 people and 600 deals | These tools serve change history in bulk, so a wider sample costs about 25 calls an object |
| Marketo | Up to 600 people | Marketo serves history in bulk too. It syncs people and not deals, so only a lifecycle or status ladder on people is tested |
| Pipedrive, Zoho CRM, Microsoft Dynamics | Up to 60 people and 60 deals | These tools give a record’s change log one record at a time, so the sample is smaller and the card says so |
At most 30 fields an object are read: the ones carrying a promise first, then the busiest picklists.
- The sample is spread evenly across the whole store, not taken from the newest records. Older records have had longer to be overwritten, so the newest records would hide exactly what this looks for.
- The card appears once at least three records moved backwards and they are 2% or more of the records checked. It is tagged Used against its purpose at 10% or more and at least five records, and Early signs below that.
- A field is judged only when at least 20 of the records checked carry history for it.
- Marketo keeps about 25 months of field changes, so anything older cannot be seen. Salesforce keeps 18 to 24 months, and only for tracked fields.
Two moves that are not counted, and one that is
A move between pipelines is not a step down: each pipeline is its own ladder, and MarqIQ compares stages only within the ladder they belong to. Stages whose names say they are off the ladder — lost, disqualified, unqualified, nurture, recycled, on hold, no decision, churn, junk, bad, other — are held out of the comparison. That last rule has a consequence worth knowing: a deal closed as lost and later reopened at an earlier stage does count, because the lost value is skipped and the stage before it is compared with the stage after it.
Open the records it happened on
Click Show the N deals on the card.
N is the real total. MarqIQ carries at most 200 record ids per finding; above that the panel says it is showing an even spread of 200 of the total, taken across the set rather than from one end of it.
Read the names and the detail line under each one.
Records are listed by something you would recognise, never by an id alone.
Click Open beside a record to see it in your tool.
Links work for HubSpot, Pipedrive, Salesforce and Microsoft Dynamics. Marketo and Zoho CRM are listed without links: MarqIQ holds Marketo’s API address rather than the address you sign in to, and Zoho’s record addresses carry an organisation id MarqIQ does not hold. A guessed link would land nowhere, so none is offered.
Open that record’s own change history in your tool and read the stage entries.
This is the check that settles it. The history names the day, the old value, the new value and who made the change.
Note
Where a link is missing because MarqIQ has the connection but not the tool’s web address, the panel says which and tells you that reconnecting the tool picks it up. The records are still listed.
Name the cause from the writers line
The second line of What we found is the one that decides your fix. It names what made the backward moves, with a count against each, and adds “and N other sources” when there are more than three.
| What the line names | What it usually is | What to change |
|---|---|---|
| A workflow, by name | An automation that writes a fixed stage on every run, with no “only if empty” condition on it | Open that workflow and add the condition, or remove the stage action from it altogether |
| A form, by name | A form set to stamp an early stage on every submission, including submissions from people already further on | Set the form to write the stage only when it is empty |
| An import | A spreadsheet upload carrying a stage column, applied over people who had already moved on | Remove the stage column from the import template, or map it to a separate field |
| A connected app, or the Salesforce sync | Another system is the one deciding stages, and the two disagree | Decide which system owns the field and stop the other writing to it |
| A person, typing it into the record | A rep correcting a mis-stage, or sending a stalled deal back to look busy | This is an agreement problem, not a settings problem. See the next section |
Note
Salesforce and Microsoft Dynamics name the account a change was made under, not whether a flow or an integration made it under that account’s name. Where one account carries hundreds of moves, check whether it belongs to a person or to an integration before you speak to anybody.
Make the repair in your tool
MarqIQ does not write this fix for you. The changes it can propose today fill empty first-touch fields on HubSpot and Marketo people, and nothing else, so a stage repair is made by hand in your own tool.
The card prints a numbered fix under How to fix it, and it differs for deals and for people.
On deals
Agree what each stage means as an event the buyer has completed.
A stage defined by something the buyer did has few reasons to be taken back. A stage defined by how a rep feels has one every week.
Record a stall somewhere other than the stage.
MarqIQ looks through the fields you already have and names one for this when it finds it — a field whose label mentions stall, on hold, blocked, next step or next action. Where you have none, it says so and suggests the smallest thing to add: a “stalled” checkbox or a next-step date.
Close a dead deal as lost and open a new deal if it comes back.
This keeps the first deal’s cycle time honest and stops the reopened one counting as a backward move.
Fix whatever the writers line named, using the table above.
On people
Keep the stage field as the furthest point a person has reached.
Record someone going cold in a status field instead.
MarqIQ checks your own fields first: where one already offers a recycled, nurture, on-hold, cold, not-ready, disqualified or unqualified value, the card names that field and that value. Where none of your fields on people offers one, the card says so and tells you to add it to a status field rather than to the stage field.
Make the form, import or integration named above write a stage only when the stage is empty.
What to tell anyone reading the reports meanwhile
The damage is arithmetic, and it is worth stating plainly rather than leaving somebody to discover it in a board pack.
- On deals: stage-to-stage conversion and time in stage are calculated from these moves. A deal that goes back is counted as entering the earlier stage twice, so the early pipeline looks fuller than it is and the sales cycle looks different from what it is.
- On people: a person sent backwards is counted at the lower stage again and may lose the date they first qualified, so conversion rates fall and the same person can be handed to sales twice.
- Fixing the cause today does not repair the history. Reports covering the period before the fix still carry the double counting, and the only honest thing to do is say which period that is.
- Quote the sample with the share. “12% of stages moved backwards” means nothing on its own; “12% of the 600 deals whose history was read” can be checked.
Check the fix held
Wait until new stage changes have had time to accumulate.
The Still happening tag is set from the most recent backward move being inside the last 90 days, so it takes that long to clear on its own.
Open Field discipline again for the same tool.
Click Read the latest from your tool.
The reading is kept for a day, so without this you are looking at yesterday’s history. The button reads Reading… while it works and the page dims rather than emptying.
Compare the writers line with the one you started from.
A workflow that no longer appears in it is the proof the change took. A count that has stopped growing is the proof for a cause you cannot switch off.
Run the check the card gives under See it for yourself.
It names the report to build in your own tool and the number it should show.
If it did not work
There is no Field discipline tab for this tool
Why: The tool keeps no per-field change history MarqIQ can read. Pardot, Mailchimp, Salesforce Marketing Cloud, Adobe Campaign and Adobe Journey Optimizer are all in that position.
Fix: Run the check on a tool that does keep one: HubSpot, Salesforce, Marketo, Pipedrive, Zoho CRM or Microsoft Dynamics.
The tab says your stage field carries a purpose and could not be tested
Why: Fewer than 20 of the records checked have any history for that field. A field with no history would look as though it never changed, and MarqIQ will not praise a field for that.
Fix: On Salesforce, switch Field History Tracking on for it in Setup › Object Manager › the object › Fields & Relationships › Set History Tracking; history starts from that day. On Dynamics, switch auditing on in Power Apps › Tables › the table › Columns. On the other tools, the field is genuinely rarely written and there is nothing to fix.
Dynamics shows no findings at all and mentions auditing
Why: Auditing is not switched on for any contact, lead or opportunity column, so no field has a history to test.
Fix: Switch it on in Power Platform admin centre › the environment › Settings › Audit, then for the tables and columns you want checked. History starts from that day, so the check is worth re-running a few weeks later.
You know a deal moved backwards and it is not in the list
Why: That deal was not in the sample. MarqIQ reads up to 600 records an object on HubSpot, Salesforce and Marketo, and up to 60 on Pipedrive, Zoho CRM and Microsoft Dynamics.
Fix: Treat the share as the finding, not the list. Where you need every record, build the same report in your own tool using the check printed under See it for yourself.
A move you consider backwards was not counted
Why: It was either a move between pipelines, which is a different ladder, or a move to or from a stage whose name marks it as off the ladder — lost, disqualified, unqualified, nurture, recycled, on hold, no decision, churn, junk, bad or other.
Fix: Nothing to fix. If a stage of yours belongs on the ladder but carries one of those words in its name, rename it in your tool so it reads as a rung.
A card says most deals reach the final stage without passing through the middle ones
Why: That is a second finding on the same field, raised when the ladder has at least four rungs, at least ten of the records checked reached its top rung, and half or more of those were never recorded at any middle stage. It means deals are being entered after they were already decided.
Fix: Create the deal when the first real sales conversation happens, not when the contract arrives. A weekly pipeline review that starts from “what is missing from this list” brings it down quickly. The two findings never appear as one card, so work them separately.
You fixed the workflow and the card still shows the same share
Why: The card counts what has already happened. Past moves stay in the history, and the reading is kept for a day.
Fix: Click Read the latest from your tool to force a fresh read, then watch the writers line rather than the share. The named workflow dropping out of it is the signal; the share falls only as the sample fills with records created since the fix.
The writers line names one user account for hundreds of moves
Why: On Salesforce and Dynamics the history names the account a change was made under, and an integration usually runs under a named account.
Fix: Check in your tool whether that account belongs to a person or to an integration before you raise it with anybody. Where it is an integration, the fix is in the integration’s mapping, not in a conversation.
Next steps
Related articles
Was this article helpful?