Practical CRM design for real operational clarity
When people think about CRMs, they almost always jump straight to deals. However, you can use tickets instead of deals in HubSpot
Deals pipelines. Sales stages. Forecasts and revenue projections. Yes, deals are critical when money is moving.
But here’s the truth I’ve learned from years of building and fixing CRMs for real organisations.
Not everything is a sale. Not every interaction belongs in a deals pipeline.
And forcing everything through sales logic is one of the fastest ways to break adoption.
Sometimes, the right tool is not a deal at all.
It’s a ticket.
The problem with forcing everything into deals
Deals are designed to track commercial progression.
They work brilliantly when the outcome is revenue and the journey is linear.
The problem starts when teams try to use deals to manage things that are not actually sales.
Examples I see all the time include internal requests, service delivery, onboarding tasks, follow-ups, issue resolution, renewals that are operational rather than commercial, and client support that has nothing to do with selling.
What happens next is predictable.
- Pipelines become cluttered
- Forecasts become unreliable
- Sales teams lose trust in the data
- Operations teams start working outside the CRM
- Leadership stops believing the reports
At that point, the CRM is no longer a system of record.
It’s just another place people are forced to update.
What tickets are actually designed for
Tickets exist to track work, not revenue.
They are perfect when something needs to be logged, owned, progressed, and resolved.
They shine when the outcome is completion, not conversion.
In HubSpot, tickets give you structure without sales pressure.
- Clear ownership
- Defined statuses
- Service level expectations
- Visibility across teams
Most importantly, tickets allow people to do their job without pretending they are selling something.
That distinction matters more than most leaders realise.
When I deliberately choose tickets over deals
I regularly use tickets instead of deals in scenarios like these.
Client onboarding tasks once a deal is closed
Post-sale delivery and implementation work
Internal requests between teams
Consultancy follow-ups that are time-based rather than value-based
Support and issue management
Operational renewals that are fixed and predictable
In these cases, putting the work into a deals pipeline would distort reality.
There is no negotiation. No close probability. No commercial risk. So why force it?
Tickets allow the work to exist honestly in the system, which is exactly what good CRM design should do.
Why does this improve adoption and trust
People disengage from CRMs when the system does not match how work actually happens.
Using tickets appropriately does three important things.
First, it reduces cognitive load.
People know where to log work without second-guessing.
Second, it protects sales data.
Revenue pipelines stay clean and meaningful.
Third, it builds trust.
When reports reflect reality, leaders stop asking for spreadsheets on the side.
That is when a CRM becomes a support system rather than a compliance exercise.
Deals and tickets are not rivals
This is not an either-or decision.
The best CRMs use both, clearly and intentionally.
Deals track commercial opportunity.
Tickets track delivery, service, and operational reality.
When those two are separated properly, everything downstream improves.
Reporting becomes sharper.
Ownership becomes clearer.
Processes become easier to follow.
And most importantly, people stop fighting the system.
Final thought
A CRM should reflect how your organisation actually works, not how someone thinks it should work.
If you are forcing non-sales activity into deals, the issue is not your people.
It’s the design.
Sometimes the smartest CRM decision you can make is choosing a ticket instead of a deal.
That is not cutting corners.
That is respecting how work really gets done.
I recently posted a blog called Why Most CRMs Fail Humans Before Humans Fail CRMs Its a great read and resource when planning a CRM Build and will offer more insight into creating with function in mind.