Project-Centric Lead Structure

Overview

In industries where sales pursuits are organized around discrete projects rather than individual buyer relationships — construction, architecture, specialty contracting, and similar fields — the default Salesforce lead model (lead name = person at a company) creates a structural mismatch. The lead record becomes ambiguous: is it about the person, the firm, or the project?

A project-centric lead structure reorients the lead record so that the project itself is the primary organizing unit. Contacts, firms, and roles are captured as attributes of or associations to that project record, rather than the project being an afterthought attached to a person.

The Problem with Person-Centric Leads

Standard Salesforce leads default to First Name / Last Name as the record identity. For transactional or relationship-driven sales this works well. It breaks down when:

• A single project involves multiple stakeholders across different firms (GC, architect, mason, owner)
• The same person may be involved in several unrelated projects simultaneously
• The sales team tracks and reports by project pipeline, not by contact pipeline
• Folder structures, prospect numbers, and downstream automations need to key off a project identifier

In these contexts, a lead named "John Smith" tells you almost nothing at a glance. A lead named "Tang Wing — Met Museum" is immediately actionable.

Solution: Project Name as Lead Identity

New "Project Name" Field

Add a dedicated Project Name field to the Lead object. This field:

• Captures the name the project is known by in the market (GC's name, owner's name, or internal shorthand — whatever the team actually uses)
• Becomes the primary display label for the lead in list views and reports
• Carries forward as the anchor identifier if the lead converts to an opportunity

Example from practice: Quarra Stone (a specialty stone contractor) pursued a project internally called "Tang Wing" and another called "Popswall" (JP Morgan's privately owned public space project). These names came from the GC and owner respectively. The lead name should match what the market calls the project, not an internal code.

Associated Records for Multiple Contacts

A single project lead will typically involve several contacts across different firms. Rather than forcing one contact into the lead's name fields, implement associated records (related list or junction object) to attach multiple contacts to a single lead, each tagged with their role:

• General Contractor (primary contract holder)
• Architect (design authority, often a back-channel influence)
• Mason / Installer (execution partner)
• Owner's Representative

This mirrors how project sales actually work: you may be contracting with the GC while simultaneously cultivating the architect for specification influence and the owner's rep for budget intelligence.

Primary Contact vs. Stakeholder Network

The lead record should distinguish between:

Relationship to Prospect Numbers and Folder Automation

Project-centric leads integrate cleanly with ^[1]. Because the project is the unit of identity, the prospect number assigned at lead creation travels with the project through conversion to opportunity — and can serve as the key for automated folder creation on the file server.

See ^[2] for the server-side implementation pattern involving API access via Vieth (or equivalent IT provider).

Reporting Benefits

When leads are named and organized by project:

• Pipeline reports show project names, immediately recognizable to the sales team
• Duplicate detection is easier (two reps pursuing the same project will create obvious collisions)
• Stage progression and BANT scoring (see ^[3]) are clearly associated with a specific pursuit, not a person
• Conversion history is traceable: "Tang Wing" as a lead → "Tang Wing" as an opportunity → "Tang Wing" as a closed deal

Implementation Notes

1. Create a Project_Name__c custom field on the Lead object (text, required or strongly encouraged)
2. Update list view columns to surface Project Name prominently; demote or remove the default Name column if it adds noise
3. Configure Associated Records (either native Salesforce related lists or a lightweight junction object) to support multiple contacts per lead with role picklist
4. Update lead naming conventions in any automation or flow that auto-populates the lead name field — consider a formula: Project Name — Primary Firm as a display label
5. Align with opportunity structure — opportunities in this domain are already typically named by project; leads should match so conversion is seamless

Client Evidence

• ^[4] — Implemented as part of their Salesforce buildout. Lincoln Durham (VP/principal) drove this requirement explicitly: "We're pursuing projects, not a person or a company. We're pursuing a project that that company is involved in." The existing startup sheet (an Excel file tracking all project stakeholders) served as the conceptual model for the associated records feature.