# User-acceptance test plan | 121 CRM > Test real work and exceptions before go-live. Use this practical, editable-on-page structure with instructions, a fictional example and clear review limits. Test real work and exceptions before go-live. This template provides a compact working structure, prompts for the information that matters and shows how Bramble Heating might complete it. It is guidance, not proof of legal, commercial or operational sufficiency. ## User-acceptance test plan at a glance Fictional completed example for Bramble Heating, a heating and maintenance firm. ## Capabilities explained ### 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. ### Testing and execution logs Supports test runs and operational evidence used to diagnose why a record did or did not follow a path. **How it works:** Runs an ordered sequence only after its configured trigger and conditions are met. **Why a business would use it:** Gives a human a way to verify automation and investigate exceptions. **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. ### 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. ## Complete the user-acceptance test plan in a short working session Bring the people who understand the source work and the people who will own the result. Complete the first version with evidence to hand, then test it rather than polishing it in isolation. ### Set a narrow scope Name the process, team, data population and decision covered by this user-acceptance test plan. Create another record when the owner, purpose or risk is materially different. ### Use observable wording Write facts, rules and expected results that another person can inspect. Replace words such as “quick”, “complete” or “automatic” with a time, population, event or named responsibility. ### Record uncertainty Mark missing evidence and unresolved decisions openly. Do not turn an unknown entitlement, data condition or approval into a positive answer simply to complete the sheet. ## The four parts of this user-acceptance test plan The prompts are deliberately small. Add a field only when it changes configuration, testing, ownership or a later decision. ### 1. Scenario and role Describe scenario and role for the exact scope being reviewed. Include the source of the information, the person responsible for keeping it current and the evidence that would show the entry is wrong or incomplete. ### 2. Expected result Describe expected result for the exact scope being reviewed. Include the source of the information, the person responsible for keeping it current and the evidence that would show the entry is wrong or incomplete. ### 3. Observed result Describe observed result for the exact scope being reviewed. Include the source of the information, the person responsible for keeping it current and the evidence that would show the entry is wrong or incomplete. ### 4. Defect, owner and retest Describe defect, owner and retest for the exact scope being reviewed. Include the source of the information, the person responsible for keeping it current and the evidence that would show the entry is wrong or incomplete. ## A completed extract for Bramble Heating Bramble Heating uses the template for one bounded CRM change. The example is intentionally modest: it shows the quality of a useful entry without suggesting a universal answer. ### Scenario and role The team wants one agreed record and owner for website enquiries received during working hours. Success means each valid enquiry has a source, owner and dated next action. ### Expected result Amina owns the working definition; Sam covers absence. The office team can edit the record, while managers can review exceptions and results. ### Observed result The team tests five ordinary examples plus a duplicate, an opt-out, missing information and an unassigned record. Every mismatch is logged for correction. ### Defect, owner and retest A person reviews the result after two weeks. Activation or wider use proceeds only if the sample reconciles and staff can handle exceptions without a private workaround. ## Treat the template as a decision record, not a certificate A completed worksheet helps people inspect their reasoning. It does not itself establish compliance, product availability or a successful implementation. ### Check the evidence Ask whether every important statement has an identifiable source and whether that source covers the current scope. Recheck vendor capability and account configuration separately. ### Test the handover Give the record to someone who did not write it. If they cannot explain the owner, rule, exception and next action, revise the wording before relying on it. ### Set a review trigger Review after a failed test, material process change, supplier change, new channel, altered responsibility or evidence that staff are bypassing the agreed method. ## Frequently asked questions ### Can we use this user-acceptance test plan without changing it? Use the structure as a starting point, but adapt the scope, fields, evidence and approvals to the real process. Delete prompts that do not affect a decision and add only those you can maintain. ### Is the user-acceptance test plan a legal or compliance template? No. It is an operational planning aid. Obtain appropriate professional advice where the work involves legal, regulatory, contractual, clinical or other specialist obligations. ### Does completing the user-acceptance test plan confirm a 121 CRM entitlement? No. Product features and account availability must be checked against the live configuration and agreed commercial scope before implementation. ### Who should approve the completed user-acceptance test plan? The person accountable for the affected process should review it with the people responsible for data, configuration, customer communication and exception handling. ## Related CRM pages - [/crm/guides](https://121.direct/crm/guides) - [/crm/guides/crm-implementation-checklist](https://121.direct/crm/guides/crm-implementation-checklist) - [/crm/templates/cutover-plan](https://121.direct/crm/templates/cutover-plan) This Markdown alternative contains public product information only. It provides no access to CRM accounts, records, credentials or payment execution.