Your reps are not ignoring your signals. They cannot find them. Enrichment is in one tool, intent in another, call notes in a third, a useful mention in a Slack thread, and the account list the team actually works from is a spreadsheet someone built three weeks ago. So reps open the CRM and pick accounts on instinct. The data is not wrong. It is in the wrong place.
The CRM is not the place to fix this, and neither is one more tool. What is missing is a layer between them: one screen that ranks the accounts, shows why each one matters today, and runs on rules the team can read.
Karl Rafidimanana, a GTM engineer at TRA, demoed that layer live in San Francisco in September. TRA builds revenue systems for GTM teams, and every client, whatever its stack, hit the same wall.
Why the prioritization tool did not fix it #
One of TRA’s clients was paying around $50,000 a year for a tool meant to do exactly this: surface the right accounts at the right moment. They cancelled it. The scores were not the problem. The tool could not version its rules, and it could not tell a rep why an account scored the way it did.
Both failures are fatal for the same reason. A rep who cannot see why an account is at the top of the list does not trust the list, and goes back to instinct. A sales leader who cannot see what changed in the rules cannot tell whether last month’s drop in meetings is the market or the model.
Three layers, each with one job #
What TRA built instead has three parts:
| Layer | Where it lives | What it does |
|---|---|---|
| Data | Cargo | Enrichment, signals and account context, in one place |
| Logic | GitHub | The ICP definition and the scoring model, as code |
| Interface | A custom app, hosted on Cargo | The one place reps look, and the one place they act |
The split is the point. The ICP definition a VP of Sales revisits every quarter stops living in a document and starts living in a file: readable, reviewable, and testable against known accounts before it reaches the team.
That matters because small changes move a lot. Give one firmographic trait 10 points instead of 4 and Monday’s list is different for every rep. Changed in a settings screen, that is a filter someone adjusted and maybe mentioned. Changed in git, it has a timestamp, a reviewer, a reason, a way back, and a test run against real accounts before it ships.
What the rep sees #
Open the app and the accounts are already ranked. For each one:
- The score, broken down. Not “82”, but which traits and signals produced it.
- Why now. The specific signal that moved it up this week.
- Who to contact. The people on the account, with the reason each is on the list.
- A way to push back. If a contact is wrong for this account, the rep says so in the app, and the feedback goes to the agent that picked them, so the same mistake does not come back.
The last point is what makes it improve. Without it, a GTM engineer has to go and ask reps why an account is a bad fit. With it, the answer arrives on its own.
It does not replace the CRM #
This is the objection every sales leader raises, and it is the wrong frame. The CRM stays the system of record and the process layer: opportunities, stages, forecasts. What it was never built for is the activity layer: which accounts to work today, and why. Bolting that onto the CRM usually means custom code inside a system that fights it.
Noah Adelstein laid out the choices in the fireside at the same event. Build the interface inside your CRM, build it yourself, or buy a tool. His experience was that teams build their own in a couple of months, and John Kutay built Rippling’s for 2,000 people in under a year. His conclusion: for a company growing fast, building it yourself is usually the right move, because it is faster, cheaper, and fits the way your team sells.
My addition: which to pick depends on what your system of record really is. If the CRM holds everything, building on it can make sense. Once the real source of truth is a warehouse, because the CRM cannot hold all the data, it is simpler to build a new interface on that than to keep bending the CRM’s.
How to start #
Karl’s three lessons from building this across clients:
- Start with one model. For TRA it was ICP scoring. Not the whole book of business, not every signal. One model, in code, feeding one ranked list.
- Test behavior before release. Run a rule change against accounts you already know the answer for before any rep sees it.
- Keep the evidence in the interface. A score is not enough. Show why the account matters and why now, because the rep is the one who has to act on it.
Then measure outcomes, not activity. Once reps work from one ranked list, a drop in meetings stops being a question about tools and setup. It becomes a question about signals and scoring, which is a question you can answer with a pull request.
FAQ #
It is the layer between the CRM and the reps that decides which accounts to work today and why. It ranks accounts from scoring rules and live signals, shows the reason for each one, and collects rep feedback. The CRM remains the system of record for opportunities, stages and forecasts.
You can, but CRMs are built to record process, not to rank accounts from live data, so it usually means fighting the platform with custom code. Once the real source of truth is a warehouse rather than the CRM, a separate interface on top of that data is simpler to build and maintain.
Most often because reps cannot see why an account is ranked where it is, and leaders cannot see how the rules changed. Without an explanation, reps stop trusting the list. Without a history of the rules, nobody can tell whether a drop in results is the market or the model.
In a version-controlled repository, as code. That gives every change a timestamp, a reviewer, a reason and a way to revert, and it lets the team test a change against known accounts before it reaches reps.
AurelienSept 30, 2026