CRM Architecture

CRM architecture consulting starts with the work people perform between first contact and the end of a customer relationship. We identify how an enquiry enters, what makes it qualified, who owns the next action, which evidence advances a deal, how a handover reaches delivery and how renewal, expansion, support or closure is recorded. The model must also cover legitimate exceptions: multiple buyers, resellers, long procurement cycles, reactivated opportunities and accounts served by more than one team.

The written boundary names the business units, lifecycle stages, record types, users, roles, source systems, communication channels, reports, automations, migration history, environments, training, acceptance and post-launch responsibility. A new CRM for one sales team is not the same commission as a multi-region system connecting marketing, finance, customer service and delivery. A platform clean-up is not automatically a reimplementation, and a prototype is not production operation.

We assess built-in capability before recommending customisation. Salesforce, HubSpot, Microsoft Dynamics 365, Pipedrive, Zoho and a custom interface can all be relevant, but no platform is promised before requirements, account tier, regional availability, API access, security and total operating cost are checked. The proposed architecture distinguishes configuration, extension, integration and custom software so the buyer can see what must be maintained after launch.

A CRM implementation does not guarantee more revenue, a shorter sales cycle or higher adoption. Those outcomes also depend on demand, offer quality, staffing, management discipline and use. We can verify configured stages, ownership, validations, permissions, migration totals, automation behaviour, reports and training completion. Commercial impact is measured later against an agreed baseline; it is never inferred from the presence of software.

The data model expresses the business, not the spreadsheet that happened to exist first. Contacts, organisations, leads, opportunities, products, subscriptions, cases, locations, partners and activities are modelled only where they represent distinct things with distinct rules. Properties have a business definition, data type, valid values, sensitivity, source, owner and retention need. A custom object is introduced because the relationship requires it, not because adding another table is easy.

Identity rules prevent a person, company or deal from multiplying unnoticed. We define matching keys, duplicate thresholds, survivorship, merge authority and exceptions for shared addresses, subsidiaries, franchisees and people acting for several organisations. Email is not always a safe universal identifier. Automated merging is bounded, logged and reversible where practical; ambiguous cases go to a named human queue.

Ownership is separated from visibility. The record owner may be responsible for the next action, while a regional team has access, marketing governs consent and finance controls a billing field. Required fields appear at the stage where they become necessary rather than burdening every new enquiry. Validation protects decisions and downstream systems, but it should not force users to invent data merely to save a record.

Definitions and changes are governed. Each important property records its purpose, allowed source, edit authority and consumers. Renaming a field in the interface does not silently change its business meaning. Material schema changes are versioned, tested against integrations and reports, and accompanied by a migration or compatibility plan. Deprecated fields are retired deliberately instead of remaining as competing truths.

Sales pipeline design works when stages correspond to events the organisation can recognise. Qualified may require agreed fit and an identified problem; proposal sent may require a versioned proposal record; committed may require a named decision path rather than a hopeful probability. Entry and exit criteria, permissible backward movement, lost reasons, inactivity rules and reopening are written. Forecast categories and deal stages remain separate where they answer different questions.

Queues and ownership rules make the next action visible. Assignment can consider region, language, product, capacity, account relationship or regulated expertise, but it needs a fallback when data is missing or nobody is available. Service-level clocks start and stop on defined events. Reassignment, absence, duplicate enquiries and disputed ownership follow a recorded route instead of disappearing into private inboxes.

Automation handles stable, authorised steps. It may create a task, enrich an internal field from an approved source, send an approved transactional message, request consent, route an exception or synchronise a status. It must not send unsolicited bulk communication, invent customer facts, overwrite a trusted value without precedence rules or close a commercial record on an opaque model judgement. High-impact actions retain approval, audit evidence and an accessible manual path.

Reporting follows the lifecycle contract. Conversion, velocity, ageing, source, coverage and forecast measures name their population, timestamp and exclusions. A stage change made for administrative convenience must not become a false buying signal. Managers need the records behind an aggregate and the data-quality context around it. Activity counts are not treated as proof of relationship quality, buyer intent or future revenue.

Migration begins with an inventory and a decision about what deserves to move. Sources, owners, volume, quality, sensitivity, history, attachments, duplicates and deletion obligations are assessed. Configuration data and customer records need different treatment. We map fields and values, transform representative samples, run a rehearsal, reconcile counts and key totals, record rejects and agree the cutover. A backup or extract is preserved according to the written recovery plan before the old source is changed.

Integrations have explicit direction, authority and failure behaviour. For every connection we state which system creates a record, which may update it, how conflicts are resolved, how often data moves, what identifier is used, what is logged and who handles retries. Webhooks, APIs, file exchanges and middleware have different guarantees. A two-way arrow on a diagram is not an integration contract.

Access follows least privilege. Roles reflect work, not status alone, and distinguish viewing, editing, exporting, deleting, configuring and administering. Sensitive customer, health, financial or employee information may require field- or row-level controls, regional boundaries, retention and audit. Service accounts have named owners, scoped permissions, managed secrets and revocation paths. Development and testing use separated environments and suitably controlled data where risk requires it.

Audit coverage is stated precisely. Record changes, ownership, sharing, automation runs, exports and reads are not logged identically on every platform or licence tier. We verify what the authorised account can record and retain instead of promising a universal audit trail. Consent, lawful basis, suppression and deletion requirements remain client decisions supported by documented configuration; CRM installation by itself does not create legal compliance.

Acceptance uses end-to-end scenarios: capture an enquiry, qualify it, create the right relationships, assign it, move it with evidence, generate the agreed output, hand it to delivery, handle a duplicate, withdraw consent, report an exception and recover a failed integration. Permissions are tested as each role, not only as an administrator. Migration samples and totals are reconciled, automations are observed, mobile views are checked and critical exports are opened.

Training is organised around decisions and tasks rather than a tour of buttons. Users learn what each stage means, what must be recorded, where the next action lives, how to handle an exception and where to report a defect. Managers learn how not to distort the pipeline by demanding premature stage changes. Administrators receive the data dictionary, role model, automation register, integration map, release record and operating runbook.

Adoption is not the login count. We inspect completion of required decisions, unowned records, stale actions, rejected data, duplicate trends, manual workarounds, support questions and the quality of pipeline reviews. Low use may indicate poor design or irrelevant scope; high activity can still be meaningless. Changes are prioritised against observed friction and business need, then pass through the same definition and testing discipline.

Operational ownership covers platform releases, expired credentials, failed synchronisation, queue growth, storage, API limits, permission changes, new fields, report drift and user access. Monitoring hours, response expectations, change capacity and escalation are written. No 24/7 support, fixed response, unlimited administration or platform uptime commitment is implied unless the proposal expressly includes it.

AI assistance is treated as a bounded capability within this system. It may summarise approved records, suggest a next action, classify a request or draft text for review. It does not create facts, infer consent, silently change material fields or make autonomous commercial decisions by default. Inputs, retrieved sources, permissions, human approval, output evidence, model change and cost are considered before activation.