A business analyst needs to understand one simple thing: CRM never starts with the system. It starts with expectations. And almost always with a conflict between those expectations.
Gathering requirements and working with user stories isn’t about ‘what the system should do’. It’s about who it should work for and what reality it changes.
CRM for small businesses: speed is more important than perfection
In small businesses, everything is simple, and yet at the same time, it is the most complicated.
There are no complex organisational structures here. Often, the owner is simultaneously the CEO, the sales manager, and the main user of the future system.
Their requirement sounds something like this:
‘I want to see everything and not miss a thing.’
If we translate this into a user story, a poor version looks like this:
As the owner, I want a CRM to control the business.
This isn’t a user story; it’s a concern.
A better way to phrase it is:
As the owner, I want to see all active deals on a single screen so that I can understand where we’re losing money.
In a small business, the roles on a project are minimal:
Owner = Product Owner
1–2 key staff members = process experts
Integrator = architect + analyst + methodologist
The main risk here is the temptation to automate chaos.
The analyst’s task is not to collect all the requests, but to filter them through the following questions:
- Does this create value?
- Does this save time?
- Does this affect the bottom line?
Because in small business, CRM should not be ‘correct’, but alive.
Medium-sized business: politics begins
In medium-sized businesses, CRM is no longer about control, but about coordination.
Roles emerge:
- The owner – expects transparency
- The commercial director – expects manageability
- Department heads – expect influence
- Users – expect not to be tormented
And here the first real conflict arises:
The owner wants analytics
Senior management — control
Managers — flexibility
Users — scalability
It is at this point that the user story ceases to be a technical tool and becomes a negotiating tool.
A poorly worded requirement:
The system must record all the manager’s actions.
This sounds like a lack of trust.
Successful:
As a department head, I want to see the history of interactions with the client so that I can help the manager close deals.
A difference in intent.
Big business: the battle for the model of reality
In big business, CRM is no longer just a tool. It is a political system.
Here we see:
- Strategic stakeholders
- Operational process owners
- IT department
- End users
- Control services
And each of them wants something different:
- Business wants speed
- IT wants stability
- Control wants regulation
- The user wants a minimum of clicks
A failed requirement at this level looks like this:
It is necessary to implement the approval of all commercial proposals.
This is a symptom of fear.
Successful:
As a financial controller, I want to approve proposals with a margin of less than 20% in order to maintain profitability.
Here, the user story serves as a way of limiting complexity.
Because large businesses always want to automate everything.
But a CRM should only automate what creates value.
Conflicts that are an inevitable part of CRM
The same contradictions arise in every project:
- Control vs trust
- Standardisation vs flexibility
- Analytics vs usability
- Speed vs accuracy
For example, a change request:
- Add another 12 mandatory fields to the customer card.
- The reason is the manager’s desire to have more data.
- The consequence is that users stop filling in even the basic fields.
The correct formulation looks like this:
As marketing director, I want to segment customers by acquisition source to evaluate the effectiveness of channels.
And then we ask:
Can this be achieved without manual input?
Can it be automated?
Does everyone need this?
A change request is not a wish list. It is a new business requirement.
How not to lose focus
The analyst’s job is to be a translator:
- between business and IT
- between control and freedom
- between the owner and the person ‘pushing buttons’
It is important to always maintain three levels of value:
The owner sees the business
The manager manages the process
The user does the work
If the system is only convenient for the analyst, it will be sabotaged.
If it is only for users, it does not drive the business.
Balance is achieved by asking a simple question for every user story:
Whose problem are we solving?
Because CRM fails not when it is complex.
It fails when:
- the owner sees no point in it
- the manager has no influence
- the user does not want to open it
So, the analyst’s key task is to ensure that, in the end:
- the owner gains transparency
- the manager gains speed
- the executive gains a management tool
And that the system ceases to be a ‘project’ and instead becomes part of daily work.
Because a good CRM/ERP isn’t one that controls everything, but one without which it’s already inconvenient to work.
