CRM implementation for US revenue teams
A CRM your team updates without being chased
We implement and repair CRM systems for marketing, sales and service teams — lifecycle stages, pipelines, data model, permissions, migration, integrations and reporting designed around the operating process, so the system is still usable six months after launch.
- Lifecycle, pipelines and permissions designed around your real process
- Migration with deduplication, test import and reconciliation counts
- Accounts, data and documentation stay in your ownership
- Adoption treated as the deliverable, measured after launch
The short answer
CRM implementation configures or migrates platforms like HubSpot, Salesforce, Dynamics and Zoho around how your team actually sells — pipeline stages, data model, automation, integrations and the migration itself, with adoption treated as the deliverable rather than an afterthought. A CRM nobody updates is an expensive list.
- Platforms
- HubSpot · Salesforce · Dynamics · Zoho
- Migration rule
- Deduplicated, mapped, test-imported before cutover
- Adoption measure
- Whether reps update it without being chased
- Integration scope
- Forms, email, ads, analytics, finance
The blueprint
We agree the data model before anyone touches a field
Objects, properties, associations and one named owner per field — written down and signed off before configuration starts.
object · contact
The person, and the consent that travels with them
One record per human, deduplicated on email with a documented merge rule. Lifecycle stage lives here and syncs downward, so contact-level definitions decide what every marketing report says.
Associates tocompanydealstickets
| Property | What it is | Owner |
|---|---|---|
| Unique identifier — dedupe key | System | |
| lifecycle_stage | Subscriber → Customer, single select | Ops |
| lead_status | Working set for sales, not lifecycle | Sales |
| contact_owner | User — routing + accountability | Sales |
| original_source | Set once, never overwritten | Marketing |
| consent_basis | Legal basis + timestamp + source | Legal / Ops |
Lifecycle stage never moves backwards automatically. Regression is a manual, logged decision with an owner.
object · company
The account, and who is allowed to own it
Deduplicated on domain, with parent–child associations for groups and subsidiaries. This is where firmographics belong so contact records stay clean and reporting can roll up by account.
Associates tocontactsdealsparent co.
| Property | What it is | Owner |
|---|---|---|
| domain | Unique identifier — dedupe key | System |
| account_tier | Enterprise / mid / SMB, single select | Sales |
| parent_company | Association — group rollups | Ops |
| company_owner | User — territory rules apply | Sales |
| industry | Controlled list, no free text | Marketing |
| account_status | Prospect / customer / churned | Service |
Firmographics live on the company only. Duplicating them onto contacts guarantees two versions of the truth.
object · deal / opportunity
The forecast, and what a stage change actually means
One pipeline per materially different sales process — not one per team preference. Every stage change must be caused by something the buyer did, which is what makes a forecast defensible.
Associates tocontactscompanyproducts
| Property | What it is | Owner |
|---|---|---|
| pipeline | New business / renewal / partner | Ops |
| deal_stage | Buyer-observable exit criteria | Sales |
| amount | Currency — line items where used | Sales |
| close_date | Required, forecast integrity | Sales |
| loss_reason | Required on closed-lost | Sales |
| campaign_influence | Read-only, attribution model | Marketing |
A stage cannot be advanced by internal activity alone. If the buyer did nothing, the deal did not move.
object · ticket
Post-sale reality, connected to revenue
Service data is not a separate world. Ticket volume, SLA breaches and reopen rates on an account are the earliest churn signal you have — but only if they associate to the same company record.
Associates tocontactcompanydeal
| Property | What it is | Owner |
|---|---|---|
| ticket_pipeline | Support / onboarding / billing | Service |
| status | Stage with SLA target per step | Service |
| priority | Rules-based, not self-selected | Service |
| first_response_at | Timestamp — SLA reporting | System |
| reopen_count | Number — quality signal | Service |
| linked_deal | Association — churn risk view | Ops |
Every ticket associates to a company. Orphan tickets make account health impossible to report on.
object · custom
Earned, not assumed
Subscriptions, locations, vehicles, courses, properties — a custom object is right when the thing has its own lifecycle and its own reporting need. Most requests for one are actually a missing field.
Associates tocompanydealcontact
| Property | What it is | Owner |
|---|---|---|
| record_name | Human-readable primary display | Ops |
| own_lifecycle | Must exist, or use a property | Ops |
| association_map | Documented cardinality | Ops |
| reporting_purpose | Named report before build | Ops |
| licence_check | Tier + API limits confirmed | Ops |
| retention_rule | Archive + deletion policy | Legal / Ops |
No custom object ships without a named report that cannot be built any other way.
Lifecycle
Every stage needs an entry rule, an exit rule and an owner
If a stage cannot be tested by looking at the record, it will be applied inconsistently — and every report built on it becomes negotiable.
Subscriber
Owned by MarketingLead
Owned by MarketingMQL
Owned by MarketingSQL
Owned by SalesOpportunity
Owned by SalesCustomer
Owned by ServiceWhy CRM projects fail
Software gets configured before the process is agreed
Five failures account for most of the CRM rescues we are called into. None of them are a platform problem.
- 01reports nobody trusts
Lifecycle stages mean different things to each team
Marketing Qualified Lead, Sales Qualified Lead, opportunity and customer are used loosely, so every report is negotiable and handoffs get argued instead of measured.
- 02unusable forms + reports
Every request becomes a custom field
Duplicate and ambiguous properties multiply until forms are unusable, automation fires on the wrong value and two dashboards give two answers to the same question.
- 03day-one data debt
Migration copies historical clutter
Old duplicates, invalid picklist values and long-dead records move across untouched, so the new system inherits the credibility problem of the old one on day one.
- 04no comparable forecast
Pipelines represent departments, not processes
A pipeline per team preference rather than per materially different sales process makes stage conversion meaningless and forecasting impossible to compare.
- 05shadow spreadsheets
Adoption is left to training day
Views, tasks, required fields, automation, management behaviour and reporting are what drive daily use. A single training session cannot substitute for any of them.
Scope
What a CRM implementation can include
Scoped in phases so the highest-risk part can be funded first, rather than one launch that has to go right all at once.
- phase 01
Requirements & platform fit
Users, objects, workflows, integrations, compliance, reporting, licences and ownership assessed before a platform is recommended.
- phase 02
Data model & field dictionary
Contacts, companies, deals, tickets, products, custom objects, associations and one documented owner per property.
- phase 02
Lifecycle & pipelines
Observable stage definitions, entry and exit rules, pipeline design per sales process and required fields per stage.
- phase 04
Migration & cleanup
Audit, mapping, deduplication, test import into a sandbox, reconciliation counts per object and signed-off cutover.
- phase 05
Integrations & automation
Forms, email, calendars, advertising, analytics, finance and custom systems — documented with owners and error handling.
- phase 07
Permissions & governance
Roles, teams, sensitive-field access and a change-control route for new fields, workflows and release requests.
- phase 06
Reporting & dashboards
Role-specific views, pipeline and forecast reporting, campaign influence and the numbers managers actually run the week from.
- phase 06
Training & adoption
Role-based training, playbooks, required actions, launch office hours and post-launch usage monitoring.
Platforms we implement
Certified on ten. Loyal to none.
We hold no reseller margin on any of these, so the platform recommendation you get is the one your process and licences actually justify.
SalesforceSales Cloud
HubSpotCRM + hubs
Dynamics 365Microsoft stack
Zoho CRMCost-sensitive
PipedrivePipeline-first
Monday CRMOps-led teams
FreshsalesFreshworks suite
CreatioLow-code BPM
Bitrix24All-in-one
Zendesk SellSupport-led
Running something not listed — Sugar, Copper, Close, a bespoke build? We have migrated off all of them.
Platform names and logos are trademarks of their respective owners, shown to identify the systems we implement. Digital Otters is not affiliated with or endorsed by them.
Platform fit
The best CRM is the one you can operate responsibly
Each of these is the right answer for a different shape of business. What follows is where each one earns its place, and the way each one goes wrong.
HubSpot: fast to launch, easy to over-customise
Strong fit when marketing, sales and service should share one system and the team wants to run it themselves. Our work concentrates on keeping the data model tight as usage grows.
What we build
- Object + property architecture
- Lifecycle stage sync rules
- Deal pipelines + required fields
- Workflows and lead routing
- Custom reports + dashboards
- Forms, CTAs and consent
The trap
Every stakeholder request becomes a new property. Within a year the forms are unusable, reports disagree and nobody trusts the numbers. We install a field dictionary and a change-request route before that starts.
Licence reality
Hub tiers and seat types decide what is actually possible. We confirm limits before designing, so the blueprint does not need a licence upgrade to work.
Salesforce: powerful, and unforgiving of vague process
Right when the sales process is genuinely complex — territories, approvals, products, multi-currency. It will model whatever you specify, including a process nobody agreed on.
What we build
- Object + record type design
- Sales process + stage criteria
- Validation + approval rules
- Campaign influence setup
- Permission sets + profiles
- Reports, dashboards, forecasting
The trap
Configuration outruns documentation. Admins change, rules stay, and six months later nobody knows why a field is required. We ship a written configuration register with every release.
Licence reality
Editions and API limits shape integration design. We confirm both before committing to a middleware or direct-integration approach.
Dynamics 365: strongest inside a Microsoft estate
The logical choice when Entra ID, Teams, Outlook and Power BI already run the business. Our focus is the prospect-to-quote process and clean reporting into Power BI.
What we build
- Lead + opportunity qualification
- Prospect-to-quote process
- Business rules + flows
- Power Automate integrations
- Security roles + teams
- Power BI reporting model
The trap
Treating it as an IT project rather than a revenue project. It gets deployed correctly and used by nobody. We run the same adoption workstream here as on any other platform.
Licence reality
App and Power Platform licensing is layered. We map required capabilities to licences early so cost is known before build, not after.
Zoho: capable when the scope stays disciplined
A pragmatic fit for cost-sensitive stacks and smaller teams that still need real pipeline discipline. It rewards a simple, well-governed data model.
What we build
- Module + field design
- Pipeline + stage rules
- Blueprint process automation
- Deluge scripting where needed
- Role + profile permissions
- Analytics dashboards
The trap
Assuming enterprise-grade complexity will fit. Over-engineering here creates maintenance nobody in the team can carry. We keep the model deliberately narrow and documented.
Licence reality
Edition limits on automation, custom fields and API calls are the real constraint. We design inside them rather than around them.
Migration
The riskiest hour of a CRM project is the import
Five gates, each with something written down at the end of it. Nothing moves until the one before it has been signed off.
- 01sign-off
Field mapping agreed in writing
Source field to destination property, with the transformation rule and what happens to values that do not map. Nothing is decided during the import.
Evidence · mapping doc - 02before move
Deduplication before anything moves
Duplicates are merged in the source, on documented keys, with a survivorship rule per property. Merging after import is far more expensive.
Evidence · merge log - 03sandbox
Full test import into a sandbox
The complete dataset, not a sample, imported into a test environment so association failures and picklist rejections surface before they matter.
Evidence · test report - 04per object
Reconciliation counts on every object
Record counts, association counts and spot-checked values compared source to destination, with any variance explained before sign-off.
Evidence · count sheet - 05safety net
Old system read-only for a full cycle
The legacy CRM stays available and read-only until the new one has survived a complete sales cycle. Rollback stays possible until it is proven.
Evidence · cutover plan
History is the asset
Closed-won deals, activity timelines and original source data are what make future reporting possible. We migrate them deliberately, not accidentally.
Archive, do not delete
Inactive records are mapped to an archive state with a retention rule, so nothing is lost and nothing clutters the working views.
One reconciliation owner
A single named person on your side signs off the counts. Shared accountability at cutover is how variances get waved through.
Delivery
Seven phases, with responsibilities named up front
Every phase ends in something you can hold. The two right-hand columns exist so nothing sits in the gap between our team and yours.
| Phase | What happens | We do | You do |
|---|---|---|---|
| 01DiscoverOutput · process map | Map users, journeys and systemsInterview stakeholders and document processes, pain points, existing reports, data sources and who governs what today. | Workshops, interviews, written findings | Access, stakeholder time, current reports |
| 02DesignOutput · blueprint doc | Create the CRM blueprintDefine objects, associations, properties, lifecycle stages, pipelines, ownership, permissions and integration scope. | Blueprint, field dictionary, options | Decisions and written sign-off |
| 03ConfigureOutput · sandbox build | Build in a controlled environmentCreate properties, views, stages, automation, templates and reporting in a test environment first, never in production. | Configuration and internal QA | Review sessions, edge cases |
| 04MigrateOutput · count sheet | Clean, import and reconcileRun test migrations, resolve duplicates, validate associations, produce counts and obtain sign-off before cutover. | Mapping, dedupe, test import, counts | Data owner sign-off |
| 05IntegrateOutput · integration register | Connect marketing, sales and serviceImplement forms, email, calendars, advertising, analytics, finance or custom systems with monitoring and error handling. | Build, documentation, monitoring | Credentials, vendor access |
| 06LaunchOutput · playbooks | Train by role and support adoptionRole-based training, office hours, playbooks and the management reports that reinforce the agreed process from week one. | Training, launch support, reports | Attendance, manager reinforcement |
| 07GovernOutput · change log | Maintain quality and change controlReview new fields, workflows, permissions, data quality and release requests so the system does not drift back. | Reviews, recommendations, admin | Platform owner, request triage |
Measurement
What we evaluate after launch
Adoption is a design outcome, so it gets measured like one. These are reviewed at the post-launch checkpoints, not asserted at handover.
Data quality
completenessCompleteness, duplicate rate, valid picklist values, ownership coverage and association accuracy per object.
92%Process adoption
active useActive users, timeliness of updates, task completion and the disappearance of shadow spreadsheets.
78%Handoff quality
acceptanceSpeed and acceptance rate from marketing to sales, and from sales to service, with returned-lead reasons logged.
84%Pipeline reliability
forecastStage ageing, conversion by stage, forecast consistency and opportunity hygiene against the agreed criteria.
71%Operational efficiency
time savedManual work removed, response time, routing accuracy and hours recovered from building reports by hand.
88%
Fit
When a CRM project will actually get adopted
Strong fit when
- Marketing, sales and service leaders can define their real workflows
- A platform owner and decision-maker will govern the implementation
- Historical data can be audited and cleaned before migration
- The organisation will train users and reinforce the agreed process
Poor fit when
- The CRM is expected to fix unclear sales and service accountability by itself
- Every stakeholder requires unrestricted customisation
- There is no owner for data, permissions or future changes
- Everything must migrate without validating quality or relevance
Engagement
Five ways clients buy this work
Priced after requirements discovery, in US dollars, with assumptions and support boundaries written down. Platform subscriptions stay separate and are paid by you.
- 01shape · 2–3 weeksScope this
Requirements & platform selection
A short, defensible assessment: users, objects, workflows, integrations, compliance and licences — ending in a recommendation you could take to a board.
- 02shape · phased buildGet an estimate
New CRM implementation
Blueprint through launch: data model, lifecycle, pipelines, permissions, integrations, reporting, training and adoption support.
- 03shape · per volumePlan a migration
CRM migration & cleanup
Platform-to-platform migration with mapping, deduplication, test import, reconciliation and a read-only legacy period.
- 04shape · fixed sprintBook a rescue
CRM repair & governance project
For accounts that grew without control: field rationalisation, stage redefinition, permission review and a change-control route.
- 05shape · monthlyDiscuss a retainer
Ongoing administration & optimisation
Monthly admin, release review, reporting changes, data-quality monitoring and a backlog worked with your platform owner.
Evidence
Evidence you can review before you sign
Anonymised versions of the three documents this work actually produces. Ask and we will send them.
- object-lifecycle-map.pdf
Object and lifecycle map
An anonymised blueprint showing how contacts, companies, deals, tickets and stages are defined and associated on a real project.
- objects + associations
- stage entry / exit rules
- field owner per property
- migration-test-plan.xlsx
Migration test plan
The mapping, deduplication, test-import and reconciliation checks we run before any cutover, with the sign-off points marked.
- source → destination map
- dedupe + survivorship rules
- reconciliation count sheet
- adoption-acceptance.pdf
Adoption acceptance plan
How role views, required actions, training and launch measures are agreed before the system goes live — and what we measure after.
- role-based view specs
- required-field minimum set
- post-launch usage review
Before you scope
Questions buyers ask before scoping
The nine that come up on almost every first call.
What is included in CRM implementation?
It can include requirements gathering, platform selection, the data model, lifecycle stages, pipelines, migration, permissions, integrations, automation, reports, training and launch support. Which of those you need depends on whether we are building new, repairing an existing account or migrating in stages — we scope it in phases so you can fund the highest-risk part first.
Which CRM platforms do you implement?
HubSpot, Salesforce, Microsoft Dynamics and Zoho, plus suitable alternatives after assessing requirements and licences. We are not a single-vendor partner, so platform selection is an assessment rather than a recommendation we were always going to make.
How long does a CRM implementation take?
It depends on process complexity, data volume, integrations, custom objects, stakeholder decision speed and the quality of the data being migrated. A phased implementation is usually safer than one large launch: get the core objects, pipelines and migration right, then add integrations and automation once people are using it.
Can you migrate data from our existing CRM?
Yes. We audit, map, clean, deduplicate, test-import and reconcile before final migration, and the old system stays read-only until the new one has survived a full sales cycle. Reconciliation counts are produced per object and signed off before cutover.
How should lifecycle stages be defined?
Each stage needs an observable business definition, an owner, an entry rule, an exit rule and a reporting purpose. If a stage cannot be tested by looking at the record, it will be applied inconsistently. Platform defaults can be customised where the process genuinely requires it — but fewer, clearer stages beat a longer list.
Do you integrate the CRM with the website and advertising platforms?
Yes, subject to platform APIs, consent, identifiers, licences and access. Every integration is documented with an owner, a data direction, a failure mode and error handling — so when something breaks, it is obvious who fixes what.
How do you improve user adoption?
We simplify the data model, build role-specific views, cut required fields to what reps will realistically fill, automate something that saves them time before asking anything of them, train by role, support launch and give managers reports that reinforce the agreed process. Adoption is a design outcome, not a training-day outcome.
How much do CRM implementation services cost?
Pricing depends on users, objects, pipelines, migration volume, integrations, automation, reporting, permissions and training. We provide a phased US-dollar proposal after requirements discovery, with assumptions and support boundaries written down. Platform subscription costs are separate and paid directly by you.
Can you work with our US sales and marketing teams?
Yes. Discovery, workshops, documentation, training and launch support are delivered remotely across US time zones, with responsibilities divided explicitly between Digital Otters and your team so nothing sits in the gap between us.
Why us
Commercial strategy and platform implementation, in your accounts
- Sequence
Process before configuration
Stage, ownership and handoff definitions get resolved before fields and workflows start multiplying.
- Scope
Marketing, sales and service together
The CRM is designed as shared operating infrastructure, not a sales-only database with a marketing bolt-on.
- Ownership
Client-owned system
Accounts, data, documentation and administrative ownership stay with you. No hostage retainers.
- Evidence
Documented, testable delivery
Blueprints, count sheets, integration registers and change logs — so the work can be audited, not just described.
Start here
Build a CRM your team operates without being chased
Send the platform you are on, the teams involved and what is breaking. You get a phased plan back, not a proposal template.
Remote delivery across US time zones · Founded 2014
- A phased implementation or repair plan, in order of risk
- Which phase to fund first, and what it unlocks
- Responsibilities split between our team and yours
- A US-dollar range with assumptions written down
