One customer record that sales, service and marketing all trust.
Most CRM problems come down to three duplicate accounts, a contact who opted out in one system and not the other, and a rep who can see records they shouldn't. We fix the data model, the integrations and the access rules together.
CRM solutions cover the systems and processes a company uses to manage customer relationships across sales, service and marketing.
Cohash implements and repairs CRM on Salesforce and Microsoft Dynamics 365. We design the customer data model, build integrations to ERP and customer identity systems, set up sharing and security rules, and load CRM data into your warehouse for reporting.
you probably need this if
Sales, service and marketing each count a different number of customers.
A contact opted out of email in one system and keeps receiving campaigns from another.
Reps can see accounts outside their territory, because someone opened up sharing rules to fix a bug.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your CRM Solutions, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · crm solutions3 open
openSales, service and marketing each count a different number of customers.
recurringA contact opted out of email in one system and keeps receiving campaigns from another.
blockedReps can see accounts outside their territory, because someone opened up sharing rules to fix a bug.
exposure
Customer data modelCRM and customer identitySharing and field securityIntegration with ERP and billingMigration between CRMsAdoption fixes
startrehearsehandover
Discovery
Design
Build and migrate
Launch and hand over
we are here
ready to hand over
Each customer has one account holding all its contacts and opportunities, and pipeline…
A customer opts out in one channel, and every system that sends email gets it.
Each portal user maps to one contact.
Customer data model and duplicate-matching rules
chapter 01 · where it hurts
Why teams reach out
Sales, service and marketing each count a different number of customers.
A contact opted out of email in one system and keeps receiving campaigns from another.
Reps can see accounts outside their territory, because someone opened up sharing rules to fix a bug.
chapter 02 · what we change
How we solve it
Customer data model
CRM and customer identity
Sharing and field security
Integration with ERP and billing
Migration between CRMs
Adoption fixes
chapter 03 · how it runs
Our approach
Discovery
Design
Build and migrate
Launch and hand over
chapter 04 · where you end up
What changes
Each customer has one account holding all its contacts and opportunities, and pipeline is counted once.
A customer opts out in one channel, and every system that sends email gets it.
Each portal user maps to one contact.
Customer data model and duplicate-matching rules
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Accounts, contacts, households and hierarchies designed once, with matching and merge rules that stop duplicates at the point of entry.
When customers sign in through Auth0, Okta or Entra External ID, we link that identity to the CRM contact so consent, preferences and support history stay attached to one person.
We design role hierarchies, sharing rules, permission sets and field security from who needs what, then log in as real personas to check.
We sync orders, invoices and entitlements through APIs or middleware and decide up front which system owns each field, so two systems never fight over it.
Moves from legacy CRM, or between Salesforce and Dynamics 365, with a data mapping your business owners sign off and a rehearsed cut-over.
Page layouts, list views and automation trimmed to what reps actually use, measured with login and field-usage data.
capability 01 / 06in production
Customer data model
Accounts, contacts, households and hierarchies designed once, with matching and merge rules that stop duplicates at the point of entry.
When customers sign in through Auth0, Okta or Entra External ID, we link that identity to the CRM contact so consent, preferences and support history stay attached to one person.
We sync orders, invoices and entitlements through APIs or middleware and decide up front which system owns each field, so two systems never fight over it.
We pieced these together from CRM Solutions situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Two acquisitions and three accounts for each customer
composite · not a client story
Beforethe situation
Two acquisitions brought two more CRMs into Salesforce through one-time loads. Many customers now exist as three accounts spelled differently. Their contacts are split across them, and territory reports double-count pipeline.
What we dothe work
We profile duplicates on normalized name, web domain and tax ID. Sales ops agrees a survivorship rule for each field. Merges run in reviewed batches, each with a rollback file, and duplicate and matching rules are switched on so new duplicates get blocked at entry.
Afterwhere you end up
Each customer has one account holding all its contacts and opportunities, and pipeline is counted once. Someone trying to create a duplicate gets stopped.
case file 02
An opt-out that reached marketing and never reached service
composite · not a client story
Beforethe situation
A customer unsubscribed in the marketing platform. The service team's Dynamics 365 instance never heard about it and kept sending survey emails, which turned into a privacy complaint.
What we dothe work
We pick one system to hold the consent record and model consent in it by channel and purpose. When consent changes, we publish an event to every system that sends email. A send with no consent behind it is blocked. Each day a reconciliation report flags drift.
Afterwhere you end up
A customer opts out in one channel, and every system that sends email gets it. If two systems disagree, we see it on the reconciliation report before the customer has to complain.
case file 03
Portal logins with no link to the CRM contact
composite · not a client story
Beforethe situation
Customers sign in to a support portal through Auth0, but the portal creates its own profile rather than linking to the CRM contact. Agents can't tell who opened a case. Profile changes go nowhere.
What we dothe work
The CRM contact ID goes into the Auth0 user's app metadata. Existing users are matched by verified email, and collisions get manual review. We agree which system owns name, email and phone, then sync changes through an Auth0 Action or an event stream.
Afterwhere you end up
Each portal user maps to one contact. On the case, agents see the signed-in customer, and a profile edit lands in whichever system owns that field.
How one customer record links CRM, customer identity and ERP
Customer sign-ins from your CIAM platform link to a single CRM contact, which carries consent and service history. The CRM exchanges orders and billing data with the ERP under field-ownership rules, and both feed the warehouse.
01 · Customer touchpoints
Customer identityAuth0 · Okta · Entra External ID → CRM · identity link
Portal and web formssign-up · preferences · cases → Matching and merge rules · new contacts
02 · CRM
CRMSalesforce · Dynamics 365 → ERP and billing · orders→ Warehouse · CRM data
Matching and merge rulesaccounts · contacts · households → CRM · deduplicated record
03 · Back office
ERP and billingorders · invoices · entitlements → CRM · invoices and status→ Warehouse · billing data
04 · Analytics
WarehouseSnowflake
Read the diagram as text
Customer identity → CRM: identity link
Portal and web forms → Matching and merge rules: new contacts
Matching and merge rules → CRM: deduplicated record
CRM → ERP and billing: orders
ERP and billing → CRM: invoices and status
CRM → Warehouse: CRM data
ERP and billing → Warehouse: billing data
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Discovery
We profile your CRM data, list integrations and custom code, and interview the teams who live in it every day.
step 02
Design
Target data model, sharing model, integration contracts and a migration plan, agreed with sales, service and IT.
step 03
Build and migrate
We build configuration and integrations in a sandbox, then run trial data loads until the counts reconcile.
step 04
Launch and hand over
Go-live support, admin runbooks, and training for whoever maintains it next.
you keep
What you're left with
We write these for your CRM Solutions setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
design01
Customer data model and duplicate-matching rules
yours to keep
tests02
Sharing and permission design with test personas
yours to keep
document03
Integration contracts listing the owner of each synced field
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your CRM Solutions work. The ones who've done it answer differently from the ones who've read about it.
Q1
What survivorship rules decide which duplicate wins each field?
Merging without field-level rules loses the newest phone number or the right billing address. Rules agreed with the data owners, plus a rollback file, make each merge reviewable.
Q2
Which system will hold consent, and how quickly will an opt-out reach the others?
An opt-out that takes days to sync is still a violation in the meantime. The design should name the consent record and the maximum delay for every system that sends messages.
Q3
How will you test the sharing model as real users instead of as an admin?
Sharing models that look right on a diagram leak through implicit sharing, manual shares and integration users. Testing as each persona shows what people can actually open.
Q4
How will the migration prove nothing was lost?
Record counts and amount totals per object should reconcile before sign-off. Without reconciliation reports, a migration can't show what didn't arrive.
01Should we choose Salesforce or Dynamics 365?
It depends on what you already run and who will maintain it. Heavy Microsoft 365 and Azure shops often find Dynamics 365 and Dataverse easier to integrate. Teams that need a broad partner app ecosystem often prefer Salesforce. We compare licensing, integration effort and skills before recommending one.
02How long does a CRM implementation take?
It depends on the number of integrations, the volume and quality of data to migrate, and how many business units go live. We give a timeline after discovery rather than before.
03Can you connect our customer login to the CRM?
Yes. We do this a lot. The CIAM identity gets mapped to a CRM contact, we decide who owns consent and profile fields, and the sync keeps both sides honest.
04Do you also clean up existing CRM data?
We do, in batches you can audit. Before that, we profile duplicates, missing fields and orphaned records and agree merge rules with the data owners.
05What drives the cost of a CRM project?
Mostly the number of integrations, how much data has to move and how clean it is, and how far your processes stray from the product's defaults. Licensing is separate. The vendor sets that.
related
Often paired with
Projects on CRM Solutions usually end up touching one of these, so they're worth a look.
