How Ruby AI writes deal intelligence into HubSpot

Ruby reads the calendar and writes a pre-meeting brief to the HubSpot deal up to 24 hours before the call. After the call, Ruby classifies the transcript into 4 deal properties (Compelling Event, Pain / Impact, Recommended Actions, Risks) and 1 analysis note, written to the same deal record the rep already opens.

Deal intelligence that lives in its own tab gets read when someone remembers, and pipeline review happens in HubSpot whether anyone remembers or not.

The decision Ruby makes before writing anything

Ruby produces structured deal intelligence by reading the transcript and the existing CRM record together, never the transcript on its own. HubSpot write-back is how the result gets delivered, not a separate feature bolted on beside it.

Ruby does not extract. Ruby classifies. Extraction pulls a date out of a transcript. Classification decides whether that date belongs in Compelling Event or nowhere at all. Reading the CRM record alongside the transcript is what makes that judgement possible, because the same sentence means one thing on a deal with an outstanding proposal and another on a first call.

Compelling Event runs on a hierarchy of evidence. A stated event carrying a named consequence and an owner lands first. A phrase lifted from the transcript alone clears a much higher bar: it qualifies only if it matches 1 of 6 urgency signals (Q3, board, deadline, renewal, close date, by end of) and sits inside a next step, an action item, or a pricing discussion.

Two worked examples, same input, two different outcomes.

A renewal date mentioned in passing. "Renewal" is one of the 6 urgency signals, so extraction would take it every time. Ruby takes it only when the date is attached to a next step or an action item. A rep asking "when does your current contract end?" and getting a flat answer produces no next step, so the date matches 1 of 2 conditions and Compelling Event stays empty.

A stakeholder silent for two weeks. Ruby weighs the same silence against where the deal actually sits. Two quiet weeks early in a deal reads as normal cadence. The same two weeks with a proposal outstanding registers as a risk, because Ruby raises its sensitivity as a deal moves closer to a decision. Ruby checks the person's role before scoring, too. Silence from a contact tagged economic buyer resolves differently from silence from a technical validator, on the same deal, in the same week.

The same discipline governs what does not get written. When 2 of the 4 fields classify and 2 do not, Ruby writes 2. Empty fields stay empty, so nothing arrives for a rep to delete.

The four fields on the HubSpot deal card

Ruby writes to 4 properties in a dedicated Ruby Insights group, each namespaced with a ruby_ prefix, and never touches a standard HubSpot deal field.

Compelling Event

Trigger: a stated event with an owner and a consequence, or a transcript phrase that passes both tests above.

Writes: Contract Expiration: current vendor agreement lapses 31 March, procurement confirmed no auto-renew. Risk if no action: buyer defaults to a 12-month extension. Urgency score: 78/100.

Ruby scores every compelling event out of 100, so a 40 and a 90 do not sit in the same field looking alike.

Pain / Impact

Trigger: use cases raised in the call that carry supporting evidence, plus objections that carry a severity and a named source.

Writes: each use case as a line with its evidence attached and how the buyer reacted, then each objection with its severity and who raised it.

Ruby writes up to 4 use cases, then fills the remaining space with objections, stopping at 6 lines total. A 45-minute call that surfaces 11 pain points arrives as the 6 that carried evidence, not as 11 fragments.

Recommended Actions

Trigger: an action carrying a priority, a timeline, and a rationale. Actions missing any of the three do not get written.

Writes: a numbered list, priority tag first. 1. [HIGH] Get the CFO into the 12 March technical review (this week). Economic buyer has not attended a session and paper process is unmapped.

Ruby writes the top 6 and stops. The priority tag is the field's whole job: it turns a list into a sequence.

Risks

Trigger: a concern carrying a severity, a type, and its own evidence.

Writes: [HIGH] (stakeholder risk) Economic buyer has not engaged directly. Champion has briefed by proxy twice; no calendar hold requested.

Ruby attaches up to 2 pieces of evidence per risk, and keeps a deliberate gap between the score that raises a flag and the score that clears it, so a deal sitting on the boundary does not get flagged and unflagged week after week.

The brief Ruby writes 24 hours before the call

Write-back does not start when a call ends. Ruby checks the calendar and briefs any eligible meeting starting inside the next 24 hours, then writes that brief to the linked deal as a HubSpot note headed Ruby Pre-Meeting Brief. Eligible means a prospect on the call: a meeting where every attendee sits on the rep's own domain gets 0 briefs, and a first meeting against a company with no account yet still gets one, researched from scratch.

Every brief opens and closes the same way, so the shape is recognisable before a word of it is read. The headers a rep sees:

• About The Attendees, then Attendees, a table with 1 row per person on the invite. These 2 lead every brief.

• Where We Stand and Last Meeting, on a deal with earlier calls. A first meeting has neither and carries Top Use Cases instead.

• Meeting Recommendations, in every brief, filtered to the people actually in the room.

• Deal Recap, carrying the current MEDDPICC score and deal health. Before a deal exists this reads Working Hypothesis or Account Angle, labelled as pre-validation thinking rather than confirmed positioning.

• Account Recap, or Company Snapshot when Ruby has no account on file yet.

Ruby delivers that brief in 2 places. The HubSpot note carries it in full. The email carries a version cut to under 300 words, with a link back to the deal for the rest. A rep can switch the email off, and Ruby writes the note either way, so the deal record never depends on who opened their inbox.

Beyond the deal card: post-meeting CRM updates

After the call, Ruby writes the full meeting analysis to the deal as a second HubSpot note, one per meeting, created once and then updated in place rather than stacked as duplicates. The note carries the complete analysis up to HubSpot's 65,536 character ceiling, so the long-form version lives on the record next to the 4 structured fields. It runs 9 sections, in this order:

• Meeting Summary

• Key Stakeholders, a table whose New? column flags anyone Ruby had not seen on this account before

• Pain Points and Business Impact

• Action Items, a table carrying Owner, Side, Action, Due and Status, so a commitment your team made reads differently from one the buyer made

• Next Steps

• Competitive Landscape, a table naming each competitor, the context, the sentiment, and who raised it

• Opportunities

• Quality Scorecard, scoring the call by dimension with the signals behind each score

• Strategic Recommendations

Stakeholder tagging runs across 8 HubSpot association labels: Champion, Economic Buyer, Technical Validator, User, Procurement, Compliance, Blocker, and Approver. Champion is the one label Ruby will not assign on a hunch. A contact who merely looks supportive gets tagged potential champion until the advocacy actually shows up, so the Champion filter in HubSpot stays worth filtering on.

Contact discovery resolves through 4 paths: match on email, match on LinkedIn URL, create a new contact, or skip. Ruby skips by default when a stakeholder surfaces as a name with no email and no LinkedIn profile, because a name-only contact is a duplicate waiting to happen. Admins can change that default. Ruby also writes 2 contact properties, Influence Level and Sentiment.

Where AI CRM write-back has to live

Every field above exists in HubSpot within seconds of the OAuth handshake, because Ruby creates the Ruby Insights property group and all 4 properties at connect rather than asking an admin to build them. Of 19 comparable products we surveyed in August 2026, 13 write custom deal properties and 1 creates those properties for the customer. From there the 4 properties and both notes sit on the deal record itself, with no second login and no export step standing between the analysis and the person who needs it. One admin connects HubSpot once, in about 2 minutes, and every rep in the org inherits the write-back with 0 setup of their own. 

Frequently Asked Questions