A useful CRM requirements checklist describes the work your team must perform and the evidence that will prove the system supports it. A list of product features is not enough. Before you compare subscriptions or approve a rebuild, agree on your users, records, handoffs, integrations, reporting and acceptance criteria.
TLDR: Start with business jobs, turn each essential job into a testable requirement, and separate must-have needs from preferences. Ask vendors and implementation partners to demonstrate those requirements with representative examples. Keep unresolved access, integration and reporting questions visible before you commit.
Product documentation checked August 28, 2026. The requirements below describe a fictional business. They are an evaluation method, not a claim that a particular HubSpot subscription satisfies every requirement.
“We need automation” does not explain what should happen, who should benefit or how failure would be detected. A better requirement is: “When a qualified inquiry enters the agreed queue, assign it using the approved territory rules and show exceptions to the sales coordinator.”
That statement creates questions you can answer. What makes an inquiry qualified? Which territory source is authoritative? What happens when the owner is absent? Who can correct a mistake? Those answers belong in the requirements document before someone builds a workflow.
We recommend interviewing the people who enter data, use it and resolve mistakes. Ask each person to walk through a recent job from start to finish. Capture the decision, required information, handoff and evidence of completion. Avoid collecting only management's reporting wishes while overlooking the work needed to produce reliable data.
If you are replacing or rebuilding an existing portal, use a HubSpot portal audit to distinguish a missing capability from an unclear process or broken configuration.
List the users and their responsibilities, including occasional users and external support. Then name the business entities you need to track. A person, an organization, a sales opportunity and a service request represent different things, even if your current spreadsheet places them in one row.
HubSpot's CRM product page describes contact management, deal pipelines and other CRM capabilities. Treat that description as a starting point for evaluation. It does not prove that your proposed record model, access pattern or reporting requirement is supported in the subscription you are considering. HubSpot: CRM software.
For each entity, document:
Use ordinary examples to test the model. Can one person work with two organizations? Can one customer have several concurrent opportunities? Can a support request exist without an active sales opportunity? The answers should shape the design rather than become exceptions discovered after launch.
The following table is a fictional requirements register for a small business with a sales team and a service coordinator. The priorities and tests are illustrative, not a standard package specification.
| ID | Priority | Business requirement | Evidence required for acceptance |
|---|---|---|---|
| REQ-01 | Must | A coordinator can find the correct customer record | Demonstrate an exact match, a similar name and a duplicate exception without merging records automatically |
| REQ-02 | Must | Qualified inquiries reach the correct queue | Run approved examples for each territory, a missing territory and an unavailable owner |
| REQ-03 | Must | Finance can reconcile the agreed revenue report | Reconcile a small approved dataset using a documented date, amount and deal-status definition |
| REQ-04 | Must | Restricted information stays restricted | Test an allowed user and a disallowed user with the intended permission configuration |
| REQ-05 | Should | The service coordinator can see relevant sales context | Demonstrate the agreed information without exposing unrelated restricted fields |
| REQ-06 | Should | A manager can identify incomplete records | Show the defined completeness exceptions and the person responsible for correction |
| REQ-07 | Could | Users can personalize a nonessential view | Demonstrate the convenience after all must-have requirements have a supported solution |
“Must” should mean the business cannot accept the proposed scope without that requirement. If everything is a must, the label stops helping you make tradeoffs. Ask the sponsor what can be deferred and record the operational consequence.
A requirement is not accepted because a feature exists. Acceptance needs a demonstration, the relevant account conditions and a named reviewer. Mark unresolved items as unresolved rather than assuming a future upgrade or custom build will solve them.
For each connected system, specify the record type, field, direction and source of truth. Explain how the integration should behave when a record is missing, duplicated, changed twice or temporarily unavailable.
We recommend including a failure case in every integration demonstration. A successful transfer of one clean record does not show how your team will identify a delayed update or resolve a conflicting value. Define the person who receives an exception, the information they need and the point at which they should stop further changes.
Ask for separate evidence for native functionality, a marketplace application and custom development. Record the subscription, application and maintenance assumptions behind the proposed solution. Keep technical feasibility separate from an approved commercial quote.
Choose the decisions the reports must support. Then define the population, date field, amount field, exclusions and attribution rules for each report. Two reports can use similar names while measuring different things.
For example, a fictional manager might need open opportunities by expected close month, while finance needs closed revenue by an agreed accounting period. Those requirements should not be collapsed into a single “revenue dashboard” line item.
Build a small expected-results dataset for each essential report. Include an excluded record and an ambiguous case so the reviewer can explain the boundary. Do not use production totals as the only acceptance test if nobody can independently reconcile them.
Ask each vendor or partner to respond to the same requirements register. Record whether the proposed solution is demonstrated, conditional, requires additional work or is unsupported. A persuasive demo should not replace a written account of those conditions.
Your initial CRM feature review can help frame questions, but current entitlement and product documentation should govern a purchase decision. Historical articles and screenshots are not a current quote.
Before approval, identify the owner for implementation, migration, training and ongoing administration. Keep estimates, dependencies and exclusions visible. A requirement that depends on unavailable source data remains a dependency even if the software can technically handle it.
Selworthy's HubSpot onboarding and training page is the relevant next step for discussing a requirements-led implementation. You can also contact Selworthy with your current system, must-have jobs and unresolved questions. Keep credentials and sensitive customer data out of the initial message.
Bring representatives from sales, marketing, customer support and operations into the same discussion. Ask each group to identify a decision it cannot make reliably today and the information it needs to make that decision. This gives your CRM requirements a business purpose beyond replacing a spreadsheet.
For contact management, a sales representative may need to identify the right person and see relevant customer interactions. For lead management, the team may need to distinguish a new inquiry from an existing opportunity. For customer communication management, it may need to know whether a promised response has an owner. These are different jobs. They should not become one vague requirement called “better customer relationships.”
Use the same exercise for business goals. If the goal is improving customer retention, identify the service or renewal decision the CRM must support. Do not promise that buying CRM software will improve retention by itself. If sales forecasting matters, define the sales pipeline stages, required dates and evidence behind an expected outcome before asking for a chart.
Ask a future user to complete a representative task using the proposed design. Can they find the correct record, understand what to update and identify a missing value? Record where they hesitate and whether the problem requires training, a clearer layout or a different process.
Include occasional users. A manager who opens the CRM once a week may need different navigation from a sales rep who uses it throughout the day. Do not confuse a polished demonstration with evidence that both groups can perform their jobs.
A CRM vendor should explain the supported connection, its limitations and who maintains it. List the systems that create customer data, the fields each system owns and the person who resolves conflicting updates. Keep data security and access customer by customer where the business requires it, rather than assuming one broad user role is sufficient.
In your comparison, distinguish an included CRM feature from a separate marketing automation product, paid application or custom integration. Record those dependencies in the proposed cost. Training, migration, support and ongoing configuration are separate planning considerations even when the software subscription is straightforward.
Your working register can use these fields: requirement ID, business need, affected user, source data, priority, expected result, proposed solution, unresolved dependency and decision owner. Add the demonstration date and its outcome when evidence becomes available.
Do not mark a requirement satisfied because a vendor says it is on a roadmap. Keep future functionality separate from demonstrated functionality and decide whether the business can accept that dependency. Choosing the right CRM means choosing a supportable operating arrangement as well as a product.
Ask the team to demonstrate one complete sales process using the proposed CRM system. Follow an inquiry through qualification, ownership, an open opportunity and an agreed outcome. At each step, identify the customer data, decision and evidence required to proceed.
A small business may need a simpler CRM solution than a larger organization, but it still needs clear business needs and accountable owners. Do not confuse fewer users with permission to leave identity, access or handoff rules undefined.
Keep the evaluation process comparable across vendors. Use the same requirements, representative records and expected results. The right CRM solution is the one whose demonstrated capabilities and operating commitments fit the chosen scope, not the one with the longest feature list.
Include the users, business jobs, record model, relationships, integrations, reports, access requirements, adoption needs and acceptance criteria. Each essential requirement should have an owner and a way to demonstrate that the proposed system satisfies it.
Use must, should and could only after defining the consequence of deferral. A must-have requirement should block acceptance if it lacks an approved solution. Convenience features can wait until the essential business process is supported.
We recommend defining essential jobs first, then checking the current subscription and implementation requirements for each job. Product names and feature lists alone do not establish that a proposed solution fits your workflow, data model or access needs.
A requirement defines an outcome the business needs and how it will be accepted. An implementation task describes work required to deliver that outcome. Keep them linked so a completed configuration task is not mistaken for an accepted business result.