Building the Feature: Decision Making Units

Building the Feature: Decision Making Units

Finding the people who actually say "yes"

Imagine this: you’ve been preparing a deal for weeks. You’ve done your research, aligned internally, and every signal from the prospect looks positive. Then the response comes back:

“I don’t have authority to approve this deal.”

Or worse, you realize you’ve been researching someone who left the company months ago.

The impact is immediate. Outreach is misdirected, credibility takes a hit, and time is lost chasing decisions that were never in scope to begin with.

This isn’t an edge case. In complex B2B deals, decision authority is often fragmented, undocumented, and outdated.

Building a solution

It would be convenient if an AI model could create a step-by-step plan to close any deal. We're not there yet. But we can get closer by addressing one of the most failure-prone parts of the process: understanding who actually influences and approves a decision.

That’s where we start laying the foundation of the Decision Making Unit (DMU) feature.

Most think that the bigger part of building a feature is actually coding it, but when executed correctly, most time goes toward scoping it out, creating a plan, and the testing in between. The DMU feature followed the exact same path. We had to set goals and restrictions. One of those goals was making sure that the DMU's found are actually trustworthy. You don't want to talk to the wrong people, and you sure don't want an AI to hallucinate those people.

Building the feature wasn’t primarily about writing code. Most of the effort went into defining scope, setting constraints, and validating assumptions, so the output would be something users could rely on in real decision-making scenarios.

One of our core requirements was trustworthiness. If users are going to act on DMU insights, they need confidence that the people surfaced actually exist, are relevant, and hold real influence. An AI that hallucinates stakeholders does more harm than good.

Trustworthy data, or nothing at all

We could've taken the easy route: scrape some names, assign a job title next to them and call it a day. But that defeats the purpose entirely. If you're going to rely on a Decision Making Unit feature to guide your outreach, the data needs to be something you can act on without second-guessing.

So we set a strict rule: if we can't verify it, we don't show it.

For each person we surface, you get their name, their role, and a clear classification: Key decision maker or Key influencer. That distinction matters. Influencers build internal support, decision makers sign off on the deal. Talk to them in the wrong order, or focus on the wrong person, and you're back to square one.

A quick win: LinkedIn search

Once the core DMU data was in place, we asked ourselves a simple question: what's the smallest addition that meaningfully reduces friction?

The answer was a LinkedIn search button. Not a direct link to someone's profile (we can't guarantee that) but a search pre-filled with the right query. One click, and you're looking at results that help you verify:

  • Is this person still at the company?
  • What's their actual title?
  • Do we have mutual connections?

Individually, this saves a few minutes. Across multiple stakeholders and deals, it removes hours of repetitive, low-value verification work.

What this unlocks

This is only version one. The foundation. But even at this stage, the implications go beyond just closing deals faster.

Think Procurement: You are vetting a new supplier. Historical DMU data shows who was involved in comparable decisions at similar companies. This is invaluable for reference checks or warm introductions through your network.

Think Internal Alignment: A colleague closed a deal with a specific company two years ago. Who were the decision makers then? Who were the influencers that helped get the deal across the line?

This kind of institutional knowledge is typically fragmented, buried in CRMs, or lost when people change roles. Once decision knowledge is structured, teams move from reconstructing the past to acting with clarity in the present. Structuring it makes decision history searchable and repeatable, making your teams more efficient.