How to Audit a Failing CRM Implementation: A 5-Step Framework

Quick Answer: Audit a failing CRM in five steps: rebuild a scoring framework from the original business case, quantify data quality with queries on decision-critical fields, separate logins from real adoption and process compliance, reconcile record counts across systems, then rank findings by decision impact versus remediation cost.

Most CRM audits fail for the same reason the implementation did: they start with the software.

Someone inherits a Salesforce org with 400 custom fields, opens the object manager, and three weeks later produces a 60-slide deck recommending a rebuild. That deck is almost always wrong. In my experience across listed retail, catering, and dealer-network businesses in Greater China and Southeast Asia, the platform is rarely the binding constraint. The binding constraint is that nobody agreed what the CRM was supposed to measure, so nobody notices when it stops measuring it.

Related reading: Salesforce Snowflake Real-Time CDP Integration for APAC Retail

Related reading: Google Gemma 4 Offline iPhone AI Inference for APAC Retail

Related reading: Ecommerce Platform Comparison APAC 2026: 15 Platforms Ranked

Related reading: B2B Ecommerce Platform Migration 2026: An APAC Buyer's Guide

So when you learn how to audit a failing CRM implementation, invert the usual order. Audit the decisions the system is supposed to support first, then the data, then the humans, then the pipes. If you audit in the other direction you will find hundreds of defects and no way to rank them — which is how a remediation project becomes a replatform, and a replatform becomes the second failed implementation in the same company.

This is the five-step framework I use. It assumes you have read-only access and roughly three to four weeks of calendar time, not a blank cheque.

Prerequisites

Get these before you write a single query. Chasing access mid-audit is the single biggest cause of schedule slip.

Access and credentials

• Read-only admin or equivalent on the CRM. In Salesforce, a permission set with View All Data and View Setup and Configuration. In HubSpot, a Super Admin seat or at minimum a private app token with crm.objects.*.read scopes. In Dynamics 365, a System Customizer-style role scoped to read.
• Access to the audit/event log. Salesforce Event Monitoring (Shield) if licensed, otherwise Login History and Setup Audit Trail. HubSpot's Login Activity export. Dynamics 365 auditing tables.
• A queryable replica. If you have a data warehouse (BigQuery, Snowflake, Databricks) with the CRM synced via Fivetran, Airbyte, or Salesforce Data Cloud, use it. Running heavy analytical queries against a production org will get you throttled.
• CLI tooling. Salesforce CLI (sf) v2 or later, or curl plus a token for HubSpot/Dynamics.
• Integration inventory access — the middleware console (MuleSoft, Workato, n8n, Zapier), the CDP (Segment, mParticle), and the ERP/POS side of any sync.

Documents and people

• The original business case or project charter. If it does not exist, that is finding number one.
• The as-built configuration export. sf project retrieve start --metadata CustomObject,CustomField,Flow,ValidationRule gives you a diffable snapshot.
• Named interview slots with three sales reps, one sales manager, one service agent, one marketing ops person, and whoever owns the ERP. Not a workshop. One-on-ones.
• For multi-market APAC deployments: the data residency and consent position for each jurisdiction you operate in. Singapore's PDPA, Hong Kong's PDPO, mainland China's PIPL and Australia's Privacy Act do not share the same rules on cross-border transfer, and a CRM that silently replicates mainland customer records to a US-hosted marketing tool is a compliance defect, not a data quality one.

Related reading: Shopify vs Adobe Commerce APAC 2026: The Honest Verdict

Budget the access request first. In one engagement with a multi-brand catering group, security review for read-only warehouse access took longer than the data quality analysis itself.

Step 1: Rebuild the scoring framework before you touch the schema

You cannot call an implementation "failing" without a definition of success. Reconstruct one.

Take the original charter and extract every stated objective. Convert each into a metric you can compute today. If the charter says "improve pipeline visibility," the computable version is what percentage of closed-won revenue in the last two quarters passed through a CRM opportunity record with a stage change history? If it says "single customer view," it becomes what percentage of customers with transactions in two or more channels resolve to one CRM record?

Score each objective 0–3: 0 = not instrumented, 1 = instrumented but unreliable, 2 = working with known gaps, 3 = working. Publish the scores before you diagnose anything. This does two things: it stops the audit becoming a list of grievances, and it gives your steering committee a baseline they can be re-measured against in six months.

Here is the shape of the output you should be able to paste into a status update:

1CRM AUDIT BASELINE — Q1
2Objective                          Metric                          Score
3---------------------------------------------------------------------
4Pipeline visibility               62% of won rev has opp record      1
5Single customer view              41% cross-channel match rate       1
6Forecast accuracy                 not instrumented                   0
7Service SLA tracking              87% cases have first-response ts    2
8Marketing attribution             not instrumented                   0
9---------------------------------------------------------------------
10Weighted readiness: 0.8 / 3.0

The reason this matters commercially: a score of 0 on "not instrumented" is cheap to fix. A score of 1 on "instrumented but unreliable" is expensive, because you have to unwind bad history. Executives consistently assume the opposite.

Step 2: Run the data quality audit with queries, not opinions

Everyone knows the data is bad. Nobody knows which badness costs money. Quantify five failure classes.

Completeness on decision-critical fields only. Do not audit all 400 fields. Audit the ones that gate a workflow — owner, stage, close date, country, consent flag, account link.

1-- Salesforce SOQL: completeness on gating fields
2SELECT COUNT(Id) total,
3       COUNT(OwnerId) has_owner,
4       COUNT(AccountId) has_account,
5       COUNT(CloseDate) has_close_date
6FROM Opportunity
7WHERE CreatedDate = LAST_N_MONTHS:12

Run it from the CLI so the output is copy-pasteable into your report:

1sf data query \
2  --query "SELECT StageName, COUNT(Id) c FROM Opportunity \
3           WHERE IsClosed = false AND LastModifiedDate < LAST_N_DAYS:60 \
4           GROUP BY StageName" \
5  --target-org prod --result-format csv > stale_pipeline.csv

1StageName,c
2Qualification,1184
3Proposal,613
4Negotiation,402
5Verbal Commit,88

Two thousand-plus open opportunities untouched for 60 days is not a data problem. It is a forecast that does not exist. Say it that way.

Duplication, measured on the identifier your business actually uses. In APAC this is where generic CRM audit checklists break down. Email is a weak key in markets where WhatsApp, LINE, and WeChat carry the relationship. Phone number formatting varies wildly, and romanised Chinese names are unreliable for fuzzy matching — "Chan Wai Man", "Chen Weimin", and "陳偉文" can all be one person.

1-- Warehouse: duplicate rate on normalised mobile, HK/SG/TW/MY numbers
2WITH norm AS (
3  SELECT id,
4         REGEXP_REPLACE(COALESCE(mobilephone, phone), '[^0-9]', '') AS digits
5  FROM salesforce.contact
6  WHERE isdeleted = FALSE
7)
8SELECT RIGHT(digits, 8) AS local_key,
9       COUNT(*) AS records
10FROM norm
11WHERE LENGTH(digits) >= 8
12GROUP BY 1
13HAVING COUNT(*) > 1
14ORDER BY records DESC
15LIMIT 25;

Validity's State of CRM Data Management research has repeatedly found that a majority of CRM-using organisations report duplicate records as a top data concern, and that most respondents believe a meaningful share of their CRM data is inaccurate. Your job is to replace "a meaningful share" with a number for your own org.

Orphans and broken referential integrity. Contacts with no account, cases with no contact, opportunities on inactive accounts. These are the records that silently break reporting rollups.

1sf data query --query \
2  "SELECT COUNT(Id) FROM Contact WHERE AccountId = null" --target-org prod

Validation rule and required-field bypass. If reps can save a record without the fields your reports depend on, they will. Diff your validation rules against the fields in your executive dashboards. Any dashboard field with no enforcement is a future zero.

Consent and lawful-basis integrity. For any contact you market to, can you produce the timestamp, source, and jurisdiction of consent? In a Singapore or Australian deployment, a marketable contact with no consent provenance is a liability sitting inside your "asset." Count them.

Output of step 2 should be one page: five failure classes, a record count and a percentage each, and the specific report or workflow each one breaks.

Step 3: Separate logins from adoption from process compliance

This is where most audits are lazy. Login counts measure nothing. A rep who logs in daily to look up a phone number and then closes deals over WhatsApp has 100% login rate and 0% adoption.

Measure three tiers.

Tier 1 — presence. Are they in the system?

1sf data query --query \
2  "SELECT LoginTime, UserId, Status, Application \
3   FROM LoginHistory WHERE LoginTime = LAST_N_DAYS:30" \
4  --target-org prod --result-format csv > logins.csv

Tier 2 — creation and mutation. Are they putting data in? This is the query that usually causes the uncomfortable meeting.

1-- Warehouse: records created per user per week, last 8 weeks
2SELECT u.name,
3       DATE_TRUNC('week', t.createddate) AS wk,
4       COUNT(*) AS activities
5FROM salesforce.task t
6JOIN salesforce.user u ON u.id = t.ownerid
7WHERE u.isactive = TRUE
8  AND u.profileid IN (SELECT id FROM salesforce.profile WHERE name LIKE '%Sales%')
9  AND t.createddate > CURRENT_DATE - INTERVAL '56 days'
10GROUP BY 1, 2
11ORDER BY 1, 2;

On HubSpot, the equivalent shape via the CRM API:

1curl -s -X POST \
2  https://api.hubapi.com/crm/v3/objects/deals/search \
3  -H "Authorization: Bearer $HUBSPOT_TOKEN" \
4  -H "Content-Type: application/json" \
5  -d '{
6    "filterGroups": [{"filters": [
7      {"propertyName": "hs_lastmodifieddate",
8       "operator": "LT", "value": "1735689600000"},
9      {"propertyName": "hs_is_closed",
10       "operator": "EQ", "value": "false"}
11    ]}],
12    "properties": ["dealname","hubspot_owner_id","dealstage"],
13    "limit": 100
14  }' | jq '.total'

Tier 3 — process compliance. Does the sequence of events in the CRM match the sequence of events in the sales process? Pull stage-change history and look for opportunities that jump from Qualification to Closed Won in a single edit on the last day of the quarter. That pattern means the CRM is a reporting formality, entered retrospectively. No amount of training fixes it; only changing what the compensation and forecast process depends on does.

When you interview reps, ask one question and then stop talking: "Walk me through the last deal you closed, from first contact to signature, and tell me every system you touched." You will hear about the spreadsheet. There is always a spreadsheet. The spreadsheet is the requirements document your implementation partner never got.

Salesforce's own State of Sales research has consistently reported that sellers spend the majority of their week on non-selling activity, including administrative and data entry work. If your CRM increased that share, adoption will not recover through mandate.

Step 4: Trace the integrations end to end, not in the console

Integration dashboards lie by design — they report on the jobs that ran, not the records that should have moved. Audit by reconciliation instead.

Pick one business object that crosses systems. Customer, order, or case. Count it in every system for the same window and compare.

1-- Reconciliation: orders in commerce platform vs CRM vs ERP, last 30 days
2SELECT 'commerce' AS src, COUNT(*) FROM shopify.orders
3  WHERE created_at > CURRENT_DATE - 30
4UNION ALL
5SELECT 'crm', COUNT(*) FROM salesforce.opportunity
6  WHERE createddate > CURRENT_DATE - 30 AND recordtype_name = 'Ecommerce'
7UNION ALL
8SELECT 'erp', COUNT(*) FROM sap.sales_order
9  WHERE doc_date > CURRENT_DATE - 30;

1src       count
2commerce  18442
3crm       17109
4erp       18440

A 7% gap between commerce and CRM with the ERP matching commerce tells you exactly where the failure sits, and it is not ambiguous. Now find the shape of the missing 1,333 records — one market, one payment method, one product type, one character-encoding case. In a dealer-network manufacturer engagement, the discriminator turned out to be records whose address fields contained non-ASCII characters hitting a field-length limit downstream. That is a two-day fix that had been reported for a year as "the CRM is unreliable."

For CDP-mediated stacks, check delivery per destination rather than per event. Segment's Delivery Overview and mParticle's event-forwarding metrics both distinguish events received from events delivered, and the gap between them is where your "missing customers" live. Also check whether identity resolution is doing what you assumed:

1// Segment: are you actually aliasing anonymous to known?
2analytics.identify(userId, {
3  email: '[email protected]',
4  phone: '+85290000000',
5  consent_marketing: true,
6  consent_source: 'checkout_v3',
7  jurisdiction: 'HK'
8});

If identify fires without a stable userId on the majority of sessions, your CDP is generating profile sprawl, not resolving it.

On ServiceNow-centred stacks, run the same reconciliation logic against the relevant tables and check the Integration Hub / MID Server error logs for silently retried transactions. On Dynamics 365, check the Dual-write error log and the Power Platform admin centre's flow failure history — Power Automate flows that fail on 2% of runs and are never re-run are one of the most common causes of drift I see.

Finally: audit the authoritative source per field. Write it down. If both the CRM and the ERP can update customer.credit_terms, you do not have an integration, you have a race condition.

Step 5: Build a remediation prioritisation matrix

You will finish steps 1–4 with 40 to 80 findings. Ranking them by severity is a trap — severity ignores cost. Rank on two axes and force items into four buckets.

Axis 1 — Decision impact. Does fixing this change a decision someone makes about revenue, staffing, or spend? Not "is it wrong," but "does anyone act on it."

Axis 2 — Cost to remediate, expressed in engineering days plus the change-management load. A field rename is one day of engineering and thirty days of behaviour change. Count both.

Bucket A — High impact, low cost: do in the next sprint

Stale-pipeline hygiene rules, validation on dashboard-critical fields, re-running failed integration jobs with backfill, deduplication on a single normalised key. These are the findings that make the audit self-funding, and they should be in flight before your report is even circulated.

Bucket B — High impact, high cost: charter as projects with named owners

Identity resolution redesign, consent architecture rebuild for multi-jurisdiction APAC operation, replacing a bidirectional sync with a single source of truth. Each needs its own business case. Do not bundle them into a "CRM remediation programme" — bundling is how you recreate the original failure.

Bucket C — Low impact, low cost: batch quarterly

Unused custom fields, dead reports, orphaned Flows, inactive users still consuming licences. Worth doing for the licence savings and the reduction in cognitive load on admins. Not worth a steering committee.

Bucket D — Low impact, high cost: write down and close

The hardest discipline in the audit. Explicitly decide not to fix things. Publish that list. It is the only defence against scope creep in month four.

One rule I hold to: no remediation item ships without a monitoring query attached. If you fix duplicate contacts and do not deploy a weekly duplicate-rate check, you will be running the same audit in eighteen months.

What are the common challenges when implementing a CRM?

The failure patterns cluster tightly, and they are mostly organisational rather than technical. Centric Consulting's analysis of CRM project failure puts lack of executive alignment and undefined sales process at the top of the list, ahead of anything to do with software.

In APAC deployments specifically, add four:

• Multi-entity, multi-currency complexity treated as a phase two. A group operating across Hong Kong, Taiwan, and Malaysia has different legal entities, tax treatments, and sales motions. Deferring that modelling produces a schema that fits nobody.
• Channel mismatch. If the relationship lives on WhatsApp, LINE, or WeChat and the CRM only logs email, the CRM will always be a partial record. Instrument the channel that exists rather than mandating the one that does not.
• Cross-border data flow assumptions. PIPL, PDPA, PDPO, and the Australian Privacy Act impose different obligations. A single global instance with no residency segmentation is a defect you inherit quietly.
• Localisation of identity data. Name matching, address formats, and phone normalisation across CJK and Southeast Asian markets defeat out-of-the-box dedupe logic.

What are the 5 steps in the CRM process?

Worth distinguishing from the audit steps above, because teams conflate them. The customer relationship management process itself is generally described as: generate awareness and acquire leads; qualify and capture those leads into records; convert them through a defined sales process; deliver service and support post-sale; and drive retention, expansion, and advocacy.

The reason this matters to your audit: a failing implementation almost always instruments steps two and three well and steps four and five barely at all. That is why the CRM feels useful to sales managers and useless to everyone else, and why renewal and repeat-purchase forecasting is the first thing to break in retail and dealer-network businesses.

Auditing a failing CRM implementation in Salesforce, Dynamics, or ServiceNow

The framework holds across platforms; the evidence sources differ.

Salesforce. Start with Setup Audit Trail, Login History, Optimizer, and the Health Check score. Retrieve metadata with the CLI and diff Flows and validation rules against what your dashboards depend on. Salesforce's Well-Architected guidance is a genuinely useful yardstick for judging whether the org is trending toward or away from maintainability.

Dynamics 365. Audit the Dual-write mapping table, Power Platform flow run history, and the solution layering — unmanaged customisations stacked over managed solutions are a reliable predictor of upgrade pain.

ServiceNow. Check the update set history for direct production changes, the Integration Hub transaction logs, and whether CSM tables have been extended in ways that break out-of-the-box reporting.

HubSpot. Audit workflow enrolment overlaps, property duplication (the number of near-identical lifecyclestage variants is usually diagnostic), and the API rate-limit error rate on your integrations.

Your decision checklist

Run through this before you commit to any remediation plan. Knowing how to audit a failing CRM implementation is mostly knowing when to stop auditing and start deciding.

• Can you state, in one sentence with a number, what the CRM was supposed to improve and by how much? If not, do not proceed — you have no acceptance criteria.
• Do you have a baseline score published and acknowledged by the executive sponsor? Unpublished baselines get renegotiated later.
• Have you measured duplicate rate on the identifier your market actually uses, not on email?
• Can you name the authoritative system for every field that two systems can write?
• Have you reconciled record counts across systems for at least one object, and can you describe the shape of the gap?
• Have you separated login rate from creation rate from process compliance, and do you know which one is actually broken?
• Is every Bucket A item scheduled with a named owner and a monitoring query?
• Have you written down the Bucket D items you are deliberately not fixing, and has the sponsor signed that list?
• Does your remediation plan avoid replatforming? If it recommends a new CRM, can you show that the failure was caused by a platform capability gap rather than process or data ownership? In most audits I have run, it cannot.

If you answer yes to all nine, you have a remediation plan. If you answer no to more than three, you have a scoping exercise dressed up as an audit — go back to Step 1.

If you want a second pair of eyes on an inherited CRM before you commit budget to a rebuild, Branch8's team runs this framework across Salesforce, HubSpot, and Dynamics deployments in Hong Kong, Singapore, Taipei, and Sydney — get in touch and we will tell you honestly whether you need a fix or a replatform.

Sources

• Salesforce Developers — SOQL and SOSL Reference
• Salesforce — Well-Architected
• HubSpot Developers — CRM API Documentation
• Microsoft Learn — Dynamics 365 Documentation
• ServiceNow — Product Documentation
• Twilio Segment — Documentation
• Validity — CRM Data Management Research
• Centric Consulting — Why CRM Projects Fail
• PDPC Singapore — Personal Data Protection Act