Contact

Origin & evolution

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 model🗃️Data 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.

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 stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → is tagged with a role, so the deal team can see where the coverage is thin.

How it works in practice

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 review🧐Security 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 risk🎲RiskComplianceA risk to the product or businessView reference → into a task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →.

Contact vs. its neighbours

• Lead is a person of unverified interest, often without a confirmed company, sitting before qualification. A contact has been qualified and attached to a known account. A lead is a question; a contact is an answer with an address.
• Account is the organisation the contact belongs to. The deal value lives on the account; the relationship lives on the contact. One account holds many contacts, which is why single-threaded deals are fragile.
• Stakeholder is a role-flavoured view of a contact: the same person, described by their influence over a specific decision. Every stakeholder is a contact, but a contact only becomes a stakeholder once you know what part they play.

In the graph

In the Unified Product Graph, contact📇ContactSales & RevenueA person within an account sits in the sales domain within the Business, GTM & Growth region, and it hangs off its organisation through account_contains_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?