CRM structure is one of those things that's trivial to change on day one and genuinely painful to restructure once real data has accumulated against it. A few decisions made early are worth getting right specifically because of that asymmetry.
Pipeline stages should be decision points, not activities
A common mistake is naming stages after things someone does — "Called", "Emailed", "Followed Up" — rather than after where the deal actually stands. Stages should represent a decision point in the buyer's journey: Enquired, Qualified, Proposal Sent, Negotiating, Won, Lost. Activity happens within a stage; it usually shouldn't define the stage itself.
One pipeline per genuinely different process
If your sales process and your client-onboarding process are fundamentally different, they should be separate pipelines — cramming both into one pipeline with a dozen stages makes reporting nearly meaningless, since "Stage 6" means something different depending on which type of deal you're looking at.
Custom fields: fewer, well-defined, and used consistently
Every custom field should have an obvious, singular purpose. If two team members would fill in a field differently given the same situation, the field's definition isn't clear enough yet — fix the definition before you fix the data.
- Prefer dropdown/picklist fields over free text wherever the answer set is finite — free text is where reporting quietly falls apart
- Avoid duplicating information that's already captured somewhere else in a different format
- Review custom fields periodically and retire ones nobody's filling in anymore
Tags are for filtering, not for status
Tags work best as a flexible, additive layer for segmentation — "webinar-attendee", "referral-source-x" — rather than for tracking something that changes over time, like deal status. Status belongs in the pipeline stage or a dedicated field, where there's exactly one current value, not in a tag that has to be manually removed when it's no longer accurate.
Design fields and automations together
A field that isn't referenced by any automation or report is a field that probably shouldn't exist yet. Before adding one, ask what will actually read or act on it — if the honest answer is "nothing yet," that's a sign to wait until there's a concrete use.
If your pipeline already doesn't match this and has real data in it, the fix is a migration of existing opportunities into a corrected structure — not necessarily starting over. See GHL Optimization if that's the situation you're in.