# Defining CRM metrics | 121 CRM > A practical guide to defining CRM metrics, with working steps, a fictional example, review questions and clear limitations for UK small businesses. The useful outcome is a repeatable decision with an owner, evidence and an exception route. This guide helps a small team define the population, event, period, exclusions and owner behind every reported number. It uses a bounded customer journey, clear ownership and evidence people can review, keeping defining CRM metrics grounded in real work rather than treating it as another abstract CRM ambition. ## Defining CRM metrics in a working decision Fictional example using Marlow Studio; adapt the method to your own customers, responsibilities and configuration. ## Capabilities explained ### Dashboards Combines supported widgets and filters into an operational view for ongoing monitoring. **How it works:** Aggregates eligible source data into configured dashboards, reports or exports. **Why a business would use it:** Helps a team review the few measures needed for the next decision. **Limitations:** A report reflects available source data and configuration; it does not prove causation or data completeness. **Human responsibility:** A person must interpret results, investigate gaps and decide what action is justified. ### Custom reports Builds multi-page reports from selected widgets, sections, themes and date settings. **How it works:** Aggregates eligible source data into configured dashboards, reports or exports. **Why a business would use it:** Packages relevant performance information for a particular audience instead of exporting everything. **Limitations:** A report reflects available source data and configuration; it does not prove causation or data completeness. **Human responsibility:** A person must interpret results, investigate gaps and decide what action is justified. ### Attribution reporting Uses captured source and journey data to report supported lead and revenue attribution views. **How it works:** Aggregates eligible source data into configured dashboards, reports or exports. **Why a business would use it:** Helps a team investigate which recorded routes contributed to an enquiry or sale. **Limitations:** A report reflects available source data and configuration; it does not prove causation or data completeness. **Human responsibility:** A person must interpret results, investigate gaps and decide what action is justified. ### Audit logs Records supported user, account and settings activity for filtering and operational review. **How it works:** Controls agency or sub-account configuration that determines access, packaging, governance or billing. **Why a business would use it:** Helps an administrator investigate changes and maintain accountability. **Limitations:** Availability and control depth depend on agency plan, role and current account configuration. **Human responsibility:** An authorised administrator must review, approve and audit material changes. ### Users, roles and permissions Controls whether a user acts at agency or sub-account level and which supported areas they can access. **How it works:** Controls agency or sub-account configuration that determines access, packaging, governance or billing. **Why a business would use it:** Limits day-to-day access to the work a person actually needs to perform. **Limitations:** Availability and control depth depend on agency plan, role and current account configuration. **Human responsibility:** An authorised administrator must review, approve and audit material changes. ## Start with the decision behind defining CRM metrics The useful aim is to produce a decision-useful view whose definitions and limitations are understood. For defining CRM metrics, define what needs to change, who owns the choice and how the team will recognise a better customer or staff outcome. ### The question to answer Write this reporting method as a question an owner can answer. Here, the practical task is to define the population, event, period, exclusions and owner behind every reported number. Name the customer stage and the later action this reporting method should inform. ### Evidence to bring into the room Collect written metric definitions, source-field checks, reconciled samples and named review owners. Use a small current sample to test this reporting method, including one example that did not follow the expected path. ### A boundary people can recognise The main risk is that a precise figure can be misleading when definitions, source coverage, timing or exclusions have changed. State the stop, escalation or approval point for this reporting method in ordinary language and give it to a named person. ## A four-part method the team can test Try this method on a representative slice of this reporting method before changing every team or record. Each part of the defining CRM metrics trial should leave evidence that another person can inspect, challenge and repeat. ### 1. Define the measure Write the population, event, period, exclusions, calculation, owner and decision before placing a number on a dashboard; keep the practical aim in view: define the population, event, period, exclusions and owner behind every reported number. ### 2. Validate the inputs Trace a sample back to source records and check missing, late, duplicated and manually changed values; keep the practical aim in view: define the population, event, period, exclusions and owner behind every reported number. ### 3. Investigate movement Compare like periods and segments, then look for process or data changes before attributing a rise or fall to performance; keep the practical aim in view: define the population, event, period, exclusions and owner behind every reported number. ### 4. Record the decision State what the review changed, who owns the next investigation and when the definition or data source will be checked again; keep the practical aim in view: define the population, event, period, exclusions and owner behind every reported number. ## How Marlow Studio could apply the guide Marlow Studio is a small design consultancy. The team tests defining CRM metrics on one bounded customer journey, using fictional data and the existing working practice as its comparison point. ### The starting question Marlow Studio needs to define the population, event, period, exclusions and owner behind every reported number. The customer context needed for this reporting method exists today, but it is spread across records and individual knowledge, so another colleague cannot consistently explain the next decision. ### The bounded trial The team selects ten recent examples, applies the four-part method to this reporting method and records every exception. It changes only the minimum fields, ownership rules and prompts needed for this reporting method; one person can halt the trial if customer context is lost. ### The review conversation The owner checks whether a reader can trace each figure to its definition, period, source and known limitation. Staff compare the new route for this reporting method with the earlier practice, identify avoidable administration and show which awkward case still needs a person rather than another rule. ### The honest conclusion The examples use evidenced CRM building blocks without claiming that every block is active for every customer or free of separate provider charges for this defining CRM metrics trial. The trial can show whether the method is clearer for Marlow Studio; it cannot promise revenue, growth or a universal result. ## Limits, warning signs and review points The defining CRM metrics design needs another look when teams argue about definitions, totals do not reconcile, a source changes or a dashboard no longer leads to a decision. Give this reporting method both a calendar review and an event-driven trigger so a once-useful configuration does not quietly become misleading. ### Treat workarounds as evidence If staff keep a private list, retype the same value or move this reporting method into chat, ask what the agreed method failed to represent. Fix that problem before layering another automated action over this reporting method. ### Challenge the apparent signal The CRM shows captured events under chosen definitions. Before drawing a conclusion from this reporting method, check missing activity, timing, duplicated records and whether the population still matches the decision. ### Reconfirm availability and dependencies The examples use evidenced CRM building blocks without claiming that every block is active for every customer or free of separate provider charges for defining CRM metrics. Recheck the providers, permissions, retention and communication rules supporting this reporting method when the scope changes. ### Give somebody the stop decision The accountable owner must be able to pause this reporting method, correct the record and explain why an exception was handled differently. Responsibility for this reporting method cannot be delegated to a status or score. ## Frequently asked questions ### What decision should come first in defining CRM metrics? Start with the question that changes a customer action or handover: how will the team define the population, event, period, exclusions and owner behind every reported number? Give this reporting method an owner and test it against a few current examples before choosing more configuration. ### What evidence is useful for reviewing defining CRM metrics? Bring written metric definitions, source-field checks, reconciled samples and named review owners. Include a normal case, a missing-information case and an exception so the review of this reporting method does not describe only the ideal journey. ### Where should automation stop when handling defining CRM metrics? Stop where context, consent, fairness, professional responsibility or an unusual customer need changes the appropriate action for this reporting method. A person should own that point in this reporting method and be able to explain the decision. ### What should trigger another review of defining CRM metrics? Review this reporting method when teams argue about definitions, totals do not reconcile, a source changes or a dashboard no longer leads to a decision. Also set a proportionate review date for this reporting method so quiet drift is found even when nobody raises an incident. ## Related CRM pages - [/crm/guides](https://121.direct/crm/guides) - [/crm/guides/attribution-limitations](https://121.direct/crm/guides/attribution-limitations) - [/crm/features/customer-management](https://121.direct/crm/features/customer-management) This Markdown alternative contains public product information only. It provides no access to CRM accounts, records, credentials or payment execution.