Data standardisation is the process of making equivalent values identical. It sounds simple because the concept is simple. The execution is not - because real-world CRM data is full of creative variations that no one intended and everyone tolerates.
A single country field might contain: United Kingdom, UK, U.K., Great Britain, GB, England, Scotland, Wales, and United Kingdom of Great Britain and Northern Ireland. Each represents a valid entry by a well-meaning team member. Each creates a segmentation problem.
This guide covers standardisation for the five fields that cause the most problems in B2B CRMs:
- Company names
- Country values
- Job titles
- Phone numbers
- Postcodes
For each, we cover the standard to adopt, common variations to watch for, and platform-specific implementation in HubSpot and Salesforce.
Company Names
Company name inconsistency is the primary cause of duplicate records. "Acme Ltd," "Acme Limited," "ACME," "The Acme Group," and "Acme (UK) Ltd" might all refer to the same entity - and your CRM treats each as a different company.
Standard to adopt:
- Use the Companies House registered name as the canonical version for UK companies. This is the legally correct name and provides a single source of truth
- Strip common prefixes: remove leading "The" unless it is part of the registered name
- Standardise suffixes: choose either "Ltd" or "Limited" (not both) and apply consistently. We recommend "Ltd" as it is shorter and more commonly used in practice
- Title case: "Acme Digital Ltd" not "ACME DIGITAL LTD" or "acme digital ltd"
- Remove trading names in parentheses unless they are the primary brand: "Smith Holdings Ltd" not "Smith Holdings Ltd (trading as SmithCo)"
Common variations to clean:
- "Limited" vs "Ltd" - pick one
- "PLC" vs "Plc" vs "plc" - standardise to "Plc"
- "&" vs "and" - match the registered name
- Extra spaces, leading/trailing whitespace, double spaces
- Special characters: smart quotes, en-dashes vs hyphens
HubSpot implementation: HubSpot does not enforce company name formatting natively. Use a workflow to trim whitespace on company name changes. For bulk standardisation, export company records, clean in a spreadsheet using PROPER() and SUBSTITUTE() functions, then re-import with "Update existing records" selected. Consider using the Companies House company number as a secondary identifier in a custom property - this makes deduplication far more reliable than name matching alone.
Salesforce implementation: Use validation rules to enforce formatting on the Account Name field. A formula-based rule can reject entries with leading/trailing spaces or all-caps entries. For bulk cleanup, Data Loader with an Excel preprocessing step works well. Salesforce's built-in duplicate rules can be configured to catch near-matches on account names.
Country Values
Country fields are a standardisation nightmare because there is no universally agreed short form for most countries, and CRMs often ship with inconsistent default picklist values.
Standard to adopt: ISO 3166-1 alpha-2 codes (GB, US, DE, FR). These are unambiguous, universally recognised, and supported by virtually every integration and reporting tool. If two-letter codes feel too cryptic for your team, use the ISO full names instead: "United Kingdom of Great Britain and Northern Ireland" is too long, but a controlled picklist with "United Kingdom" is perfectly workable.
Common variations to clean:
- "UK" vs "GB" - ISO 3166 uses GB. If your team strongly prefers UK, that is fine, but pick one and enforce it
- "United Kingdom" vs "Great Britain" vs "England" - these are not the same thing geographically, but in a CRM context they usually mean the same thing. Standardise to your chosen value
- "USA" vs "US" vs "United States" vs "United States of America"
- Misspellings: "Untied Kingdom," "Untied States" (more common than you would think)
- Blank values where country is known from other data (postcode, phone number, domain)
HubSpot implementation: HubSpot's default Country property is a dropdown with predefined values, which prevents most variation. However, imported data and API-created records can bypass dropdown validation. Audit for non-standard values using a list filtered by "Country is none of [your valid values]." Clean exceptions manually or via workflow.
Salesforce implementation: Convert the Country field to a picklist if it is currently a text field. Salesforce offers State and Country picklists as a standard feature - enable them in Setup. This prevents free-text entry going forward and standardises historical data through a migration wizard.
Job Titles
Job titles are the most difficult field to standardise because there is no external authority, titles vary wildly across companies and cultures, and new titles appear constantly. A rigid approach fails. A flexible approach works.
Standard to adopt: Do not try to standardise the raw job title field. Instead, create two supporting fields:
- Job title (raw): The exact title as stated by the contact or found on LinkedIn. Never modify this - it is useful for personalisation
- Job level: A controlled picklist: C-Suite, VP, Director, Manager, Individual Contributor, Other
- Job function: A controlled picklist: Sales, Marketing, Operations, Finance, IT, HR, Executive, Other
This approach preserves the original data while giving you clean fields for segmentation and routing. A "Chief Revenue Officer" and a "CRO" both map to C-Suite / Sales without needing to reconcile the raw titles.
Common mapping challenges:
- "Head of" in UK companies is typically equivalent to "VP" in US companies
- "Managing Director" in UK SMEs is equivalent to "CEO" - not "Director"
- "Partner" varies by industry: in law and consulting it is senior; in other contexts it may be junior
- "Founder" without another title: map to C-Suite if the company has fewer than 50 employees, Executive otherwise
HubSpot implementation: Create custom properties for Job Level and Job Function as dropdown selects. Use workflows to auto-populate based on keyword matching: if Job Title contains "CEO" or "Chief" or "Managing Director," set Job Level to "C-Suite." Build 5-6 workflow branches to cover 80% of cases. Manually classify the remainder during quarterly audits.
Salesforce implementation: Create custom picklist fields on the Contact object. Use Flow Builder for automated classification with the same keyword-matching logic. Alternatively, use a formula field for basic classification and a trigger for more complex rules.
Standardising 50,000 records manually takes weeks. Our CRM cleanup service handles field standardisation, deduplication, and validation as a single project - typically delivered in 5-10 business days.
Phone Numbers
Phone number formatting is a solved problem technically (the E.164 standard exists) but an unsolved problem in practice (nobody follows it consistently).
Standard to adopt: E.164 format: +[country code][number] with no spaces, dashes, or parentheses. A UK mobile number becomes +447700900000. A UK landline becomes +442071234567.
If your team finds E.164 too unreadable, adopt a display format that adds spaces for readability while storing the E.164 version: +44 7700 900000 for mobile, +44 20 7123 4567 for London landlines.
Common variations to clean:
- Leading zero without country code: 07700 900000 - add +44 and remove leading 0
- Parentheses around area code: (020) 7123 4567 - remove parentheses, add +44
- Dashes: 020-7123-4567 - remove dashes
- "00" prefix instead of "+": 0044 7700 900000 - replace 00 with +
- Extension numbers: store separately in a dedicated field, not appended to the main number
- Non-numeric characters: "N/A," "TBC," "ask PA" - move to a notes field, clear the phone field
HubSpot implementation: HubSpot automatically formats phone numbers in some contexts but does not enforce a standard. Use a workflow with a format phone number action, or use the Operations Hub format data action to apply consistent formatting. For bulk cleanup, export, clean with a spreadsheet formula or script, and re-import.
Salesforce implementation: Use a validation rule on the Phone field to enforce format. A regex pattern like ^\+[0-9]{10,15}$ enforces E.164 at entry. For bulk cleanup, Data Loader with a preprocessing step handles the transformation. Salesforce Lightning also offers phone formatting in the UI layer.
Postcodes
UK postcodes follow a well-defined format, which makes standardisation straightforward - but the variations that creep in are surprisingly persistent.
Standard to adopt: Uppercase, with a single space before the final three characters. "SW1A 1AA" not "sw1a 1aa" or "SW1A1AA" or "sw1a 1aa."
Validation: UK postcodes follow specific patterns (A9 9AA, A99 9AA, A9A 9AA, AA9 9AA, AA99 9AA, AA9A 9AA). A regex validation rule catches malformed entries. The Royal Mail PAF (Postcode Address File) is the authoritative source for valid postcodes, though it requires a licence for commercial use.
Common issues:
- Missing space: "SW1A1AA" - insert space before last three characters
- Lowercase: "sw1a 1aa" - convert to uppercase
- Extra spaces: "SW1A 1AA" - reduce to single space
- Partial postcodes: "SW1A" - flag for completion, do not guess the inward code
- Non-UK formats: US ZIP codes, German PLZ - route to the correct country-specific field or format
HubSpot implementation: HubSpot does not validate postcode format natively. Use a workflow to uppercase the Postal Code property on change. For format enforcement, Operations Hub custom code actions can apply regex-based formatting. Alternatively, handle at the form level with input masks.
Salesforce implementation: Use a validation rule with the regex pattern for UK postcodes on the BillingPostalCode and ShippingPostalCode fields. A before-trigger Apex class can auto-format on save (uppercase, correct spacing) so users do not need to remember the exact format.
Making It Stick
Standardisation is not a one-time project. New records enter your CRM every day, and each one is an opportunity for non-standard data to creep back in. Three practices keep standardisation sustainable:
Enforce at entry: Validation rules, mandatory fields, and dropdown picklists prevent most non-standard data from being created. Every minute spent configuring CRM validation saves hours of future cleanup.
Automate formatting: Workflows and automation tools can apply standardisation rules to new records as they are created or updated. This catches data from integrations, imports, and API calls that bypass form-level validation.
Audit regularly: Run a monthly check for non-standard values in your key fields. A simple CRM report filtered by "is none of [valid values]" surfaces exceptions quickly. Address them before they accumulate.
If your CRM currently has thousands of non-standard values across these five fields, our CRM cleanup service can handle the initial standardisation while you focus on configuring the rules that prevent recurrence. For ongoing guidance, see our CRM data governance framework.
Which of these five fields is causing the most problems in your CRM right now?