An individual person within an account
A contact is a single named person inside an account: the human a seller actually emails, calls, and persuades. A contact carries the role that person plays in a buying decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → that usually involves several people.
The contact record arrived with the first contact-management software of the 1980s, tools like ACT! that digitised the salesperson's Rolodex. Early CRM treated a contact as a standalone card. The relational turn, formalised by the account-centric data modelData ModelData & AnalyticsA data model or schemaView reference → that Salesforce shipped from 1999, subordinated the contact to an account: many contacts belong to one company, and the deal sits against the company.
The sharper thinking came from how complex deals are actually won. MEDDIC, created inside PTC in 1996 by Dick Dunkel and Jack Napoli under John McMahon, named the roles that matter inside an account: the economic buyer who controls the budget, and the champion who sells internally when the rep is not in the room. A contact stopped being a generic person and became a person playing a part.
The Challenger Customer complicates the champion concept: not every internally supportive contact can actually move a deal. Its research distinguishes the "mobiliser" — a contact who is willing to challenge their own organisation and drive consensus across the buying group — from the merely talkative, who voice support but cannot deliver agreement among their colleagues. By that reading, identifying a contact's role is only half the jobJobUserJob To Be Done: what the user is trying to accomplishView reference →; the contact record also needsNeedUserA user need, pain, desire, or constraintView reference → to capture whether that person can credibly build consensus for a decision inside their own organisation.
Field data later quantified why this matters. Gartner research puts the average enterprise buying committee at six to ten people, and deals that thread four or more members close at roughly twice the rate of single-threaded ones. The modern contact record reflects that: each stakeholderStakeholderTeam & OrganisationA person with influence over the productView reference → is tagged with a role, so the deal team can see where the coverage is thin.
A rep working a £90k deal at a logistics firm opens with one contact, a mid-level operations manager who replied to a campaign. That manager is the champion: keen, vocal, unable to sign anything. Mapping the account surfaces three more people. A VP of operations holds the budget (the economic buyer), an IT lead owns the security reviewSecurity ReviewSecurityA security reviewView reference → (the technical evaluator), and a procurement officer controls the paperwork. The rep creates a contact record for each, tags the role, and notes that the VP relationship is cold. That single gap, an unworked economic buyer, is the most common reason deals this size stall late. The map turns an invisible riskRiskComplianceA risk to the product or businessView reference → into a taskTaskProduct SpecificationA unit of work within a story or epicView reference →.
Neil Rackham's large-sale research, published as SPIN Selling, reached a parallel finding from a different angle: in complex deals, different contacts hold different types of concerns, and a sequence of questions that works on one person (someone living with the operational problem) fails on another (someone with budget authority but no direct pain). Rackham's data showed that single-contact selling breaks down precisely at the size of deal where multiple people each own a slice of the decision — the same fragility the buying-committee evidenceEvidenceValidationData supporting or refuting a hypothesisView reference → later confirmed.
In the Unified Product Graph, ContactSales & RevenueA person within an account sits in the sales domain within the Business, GTM & Growth region, and it hangs off its organisation through contactAccountcontainsContacthierarchy. That parentage is deliberate: a contact has no standing without an account, so the edge enforces the relational model that flat contact lists lose. From there a contact connects outward to the buying roles and the deal it influences, which lets the graph answer the question a flat CRM cannot show at a glance: is this deal carried by one keen champion, or covered across the people who can actually say yes?account_contains_contact
Type-specific fields on BaseNode
contact_rolestringJob title or role within the account
is_decision_makerbooleanWhether this person has purchasing authority
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
1 edge type connected to this entity.
account_contains_contact