# How a CRM works | 121 CRM > A practical guide to how a CRM works, with working steps, a fictional example, review questions and clear limitations for UK small businesses. Useful CRM practice begins with a boundary the team can explain and test. This guide helps a small team turn how a crm works into a specific, testable way of working rather than a vague intention. It uses a bounded customer journey, clear ownership and evidence people can review, keeping how a CRM works grounded in real work rather than treating it as another abstract CRM ambition. ## How a CRM works in a working decision Fictional example using Marlow Studio; adapt the method to your own customers, responsibilities and configuration. ## Capabilities explained ### Contacts Stores a person or lead with contact details, activity, ownership and related records. **How it works:** Stores or organises supported business data under configured fields, permissions and record rules. **Why a business would use it:** Gives a team one place to understand who a customer is and what has happened. **Limitations:** The platform does not make imported, duplicated or incomplete data accurate without review. **Human responsibility:** A data owner must define the record model and resolve quality, ownership and access exceptions. ### Opportunities Represents a potential sale or deal linked to a contact, value, owner and pipeline position. **How it works:** Tracks a potential deal, stage, owner or task using configured pipeline and record rules. **Why a business would use it:** Shows which customer conversations are active commercial work rather than general contacts. **Limitations:** Pipeline position is only reliable when users and workflows update it consistently. **Human responsibility:** A responsible owner must qualify the deal, choose next actions and resolve stale or disputed status. ### Tasks Creates assigned, dated and optionally recurring actions against contacts or opportunities. **How it works:** Tracks a potential deal, stage, owner or task using configured pipeline and record rules. **Why a business would use it:** Turns the next step into owned work instead of leaving it inside notes or inboxes. **Limitations:** Pipeline position is only reliable when users and workflows update it consistently. **Human responsibility:** A responsible owner must qualify the deal, choose next actions and resolve stale or disputed status. ### Workflow builder Combines a start event with an ordered sequence of configurable actions. **How it works:** Runs an ordered sequence only after its configured trigger and conditions are met. **Why a business would use it:** Turns a repeatable customer process into a visible, reviewable flow. **Limitations:** Automation follows its configuration; it cannot repair poor data, unclear rules or an unavailable external service. **Human responsibility:** A process owner must approve, test, monitor and pause or correct faulty automation. ## Start with the decision behind how a CRM works The useful aim is to turn the topic into an operating decision that the team can explain, use and review. For how a CRM works, 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 operating decision as a question an owner can answer. Here, the practical task is to turn how a crm works into a specific, testable way of working rather than a vague intention. Name the customer stage and the later action this operating decision should inform. ### Evidence to bring into the room Collect the current customer journey, a sample of real working records and the people responsible for each handover. Use a small current sample to test this operating decision, including one example that did not follow the expected path. ### A boundary people can recognise The main risk is that a neat-looking record can still hide unclear ownership, incomplete history or a customer decision made elsewhere. State the stop, escalation or approval point for this operating decision 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 operating decision before changing every team or record. Each part of the how a CRM works trial should leave evidence that another person can inspect, challenge and repeat. ### 1. Trace the relationship Follow one recent customer from first contact to the latest decision. Mark the record, interaction and handover that carried the useful context; keep the practical aim in view: turn how a crm works into a specific, testable way of working rather than a vague intention. ### 2. Define the records State which facts belong to the contact, organisation, opportunity or activity, and name the authoritative location for each value; keep the practical aim in view: turn how a crm works into a specific, testable way of working rather than a vague intention. ### 3. Assign responsibility Give every material handover an accepting owner, an expected next action and a route for absence or disagreement; keep the practical aim in view: turn how a crm works into a specific, testable way of working rather than a vague intention. ### 4. Review actual use Compare the intended method with the records people really create. Treat workarounds as evidence about the design, training or access model; keep the practical aim in view: turn how a crm works into a specific, testable way of working rather than a vague intention. ## How Marlow Studio could apply the guide Marlow Studio is a small design consultancy. The team tests how a CRM works on one bounded customer journey, using fictional data and the existing working practice as its comparison point. ### The starting question Marlow Studio needs to turn how a crm works into a specific, testable way of working rather than a vague intention. The customer context needed for this operating decision 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 operating decision and records every exception. It changes only the minimum fields, ownership rules and prompts needed for this operating decision; one person can halt the trial if customer context is lost. ### The review conversation The owner checks whether records have an owner, a meaningful status and a dated next action. Staff compare the new route for this operating decision with the earlier practice, identify avoidable administration and show which awkward case still needs a person rather than another rule. ### The honest conclusion Do not read a feature description as a package promise; The agreed commercial scope and the live sub-account must be checked before reliance for this how a CRM works 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 how a CRM works design needs another look when staff create parallel lists, customers repeat information, ownership is disputed or lifecycle labels stop matching real relationships. Give this operating decision 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 operating decision into chat, ask what the agreed method failed to represent. Fix that problem before layering another automated action over this operating decision. ### Challenge the apparent signal The CRM shows captured events under chosen definitions. Before drawing a conclusion from this operating decision, check missing activity, timing, duplicated records and whether the population still matches the decision. ### Reconfirm availability and dependencies Do not read a feature description as a package promise; The agreed commercial scope and the live sub-account must be checked before reliance for how a CRM works. Recheck the providers, permissions, retention and communication rules supporting this operating decision when the scope changes. ### Give somebody the stop decision The accountable owner must be able to pause this operating decision, correct the record and explain why an exception was handled differently. Responsibility for this operating decision cannot be delegated to a status or score. ## Frequently asked questions ### What decision should come first in how a CRM works? Start with the question that changes a customer action or handover: how will the team turn how a crm works into a specific, testable way of working rather than a vague intention? Give this operating decision an owner and test it against a few current examples before choosing more configuration. ### What evidence is useful for reviewing how a CRM works? Bring the current customer journey, a sample of real working records and the people responsible for each handover. Include a normal case, a missing-information case and an exception so the review of this operating decision does not describe only the ideal journey. ### Where should automation stop when handling how a CRM works? Stop where context, consent, fairness, professional responsibility or an unusual customer need changes the appropriate action for this operating decision. A person should own that point in this operating decision and be able to explain the decision. ### What should trigger another review of how a CRM works? Review this operating decision when staff create parallel lists, customers repeat information, ownership is disputed or lifecycle labels stop matching real relationships. Also set a proportionate review date for this operating decision so quiet drift is found even when nobody raises an incident. ## Related CRM pages - [/crm/guides](https://121.direct/crm/guides) - [/crm/guides/crm-vs-contact-management](https://121.direct/crm/guides/crm-vs-contact-management) - [/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.