Your reps aren't lying, their MEDDPICC checkboxes are

Your sales calls already contain the truth about every deal's health. A buyer quantified the pain, or didn't. The economic buyer showed up, or didn't. And recording the call did not close that gap. The transcript exists, somewhere in a library nobody reopens, but nobody turns 40 minutes of it into 8 qualification scores after every call. So the CRM checkbox still gets ticked from memory of how the call felt.

That checkbox is what your forecast is built on.

Reps do nothing. That's the point.

Ruby scores MEDDPICC from the evidence instead: all 8 elements, on a weighted 100-point scale, from what was said on calls and what sits on the CRM record. No rep fills in a scorecard. Scoring runs each time Ruby processes a meeting, with 0 fields for the rep to maintain, so qualification stops being an end-of-week CRM chore and starts being a byproduct of the calls reps were already having.

The trade for that automation is discipline. Each element score must carry a specific, source-cited piece of evidence. An element with no data behind it scores 0 and its gap gets named. A vague "they're frustrated with their current tool" contributes nothing, because nothing verifiable was said. That is the rule for everything Ruby writes, not just this score: no evidence, no entry.

And one more thing separates this score from a qualification checklist: Ruby never hands back a grade without the move that improves it. Most scoring is a report card. It tells you where the deal stands and leaves the "now what" to you. Ruby's is an action card.

What a scored deal looks like

Here is a simulated excerpt of the analysis Ruby writes after a discovery call:

Every line follows the same contract. A score in its weighted range, a trend against the last analysis, and when something is missing, the gap named in plain language. A gap is not allowed to exist without its next move: every gap Ruby flags carries a recommended action, and every analysis closes with a short, prioritized list of what to do next. A score of 54 is trivia. "54, because the economic buyer has never attended a session, so get them into the technical review this week" is a plan.

How the score is built

The 8 elements are not 8 equal tenths. Ruby's default weights sum to 100, with Implicated Pain the heaviest at 20 points and Paper Process the lightest at 5:

A deal scores in that weighted space directly, so a strong Paper Process cannot paper over a missing Champion. And the arithmetic itself is deterministic: Ruby's model judges the evidence, not the math, so the same 8 element scores produce the same total every time, and 2 deals carrying the same score are actually comparable.

Three more design decisions sit inside the scorecard:

Champion status is earned, not assigned. Exactly one part of the system is allowed to tag a contact as Champion. Everything else that spots promising behaviour writes "potential champion" instead, and the contact stays there until the advocacy actually shows up in the record. That restraint is why a Champion filter built on Ruby's data stays worth filtering on.

Economic Buyer engagement is read in context, not on a timer. Ruby tags stakeholders across 8 roles, Economic Buyer among them, and weighs their activity by role and by deal stage. Two quiet weeks from an economic buyer in early discovery reads as normal cadence. The same 2 weeks with a proposal outstanding registers as a risk, because the economic buyer is a relationship a deal cannot lose quietly.

A zero on Paper Process is read by stage. Ruby scores every element against expectations for where the deal currently sits. Paper Process at zero in discovery is not a gap; nobody should be mapping legal review on a second call. The same zero at proposal stage is a gap, and it gets flagged. Weighting Paper Process at 5 keeps early-stage and mid-stage scores anchored to pain, power, and advocacy, the elements that predict whether there will be a paper process to run at all.

Every element carries its own trend

A single number moving from 61 to 64 tells you almost nothing about what changed. So Ruby tracks each of the 8 elements against the previous analysis and marks it improved, unchanged, declined, or new. A declined element is always flagged, even when the total went up, because a Champion score dropping 3 points while Metrics rose 5 is not a healthier deal. It is a different deal.

Where the score goes to work

The score feeds straight into Ruby's deal health score, and carries more weight there than any other input. The rest comes from meeting quality, stakeholder engagement, and deal velocity, so a deal cannot look healthy on qualification alone.

That health score decides when a deal gets flagged as at risk, and the flag is built to be hard to earn and hard to clear. A deal has to fall clearly before Ruby raises it, and climb clearly higher before it comes down. So a deal hovering on the boundary does not get flagged one week and cleared the next. A flag from Ruby means something moved.

The score also travels. Up to 24 hours before a scheduled call, Ruby writes a pre-meeting brief onto the CRM deal record with the current MEDDPICC score inside it. The rep walks in knowing which elements are covered and which are still open, before the buyer says a word.

Stop guessing deal health. Let the evidence speak.

See how Ruby writes deal intelligence into HubSpot →

Frequently Asked Questions