The business problem
Most enterprise transformation problems do not begin with the absence of data.
They begin with too much data in too many places.
Sales had one system.
Orders had another.
Customer information existed somewhere else.
Targets lived in spreadsheets.
Visit details were partly digital and partly dependent on individual habits.
Issues moved through calls, WhatsApp groups and escalation chains.
Management reports were generated, but often after the moment when the information could have changed the decision.
Everyone had data.
Very few people had context.
For a field salesperson, this meant moving between systems while trying to answer basic questions.
Which customer should I visit?
What did they buy last time?
Is there an outstanding issue?
What is my target position?
Has an order been processed?
What should I follow up today?
For a manager, the questions were different.
Where are we behind?
Which territories need intervention?
Is low performance a demand issue, an execution issue or simply a reporting gap?
Which activity is actually translating into orders?
The challenge was therefore not to digitise one more form.
It was to connect the decisions people made every day.
The product approach
The Happy State
We imagined the field salesperson starting the day with clarity.
They should know their priorities.
They should be able to see the customer context before the visit.
During the interaction, they should be able to capture relevant information with minimal effort.
If an order was placed, it should move into the appropriate workflow.
If an issue was raised, it should have a visible owner.
If a follow-up was required, the system should remember.
Managers should see the same operating reality at an aggregated level.
The happy state looked like:
Plan → Visit → Understand → Act → Order / Resolve → Follow Up → Learn
One continuous loop.
Not a collection of disconnected applications.
Product Thinking: Start With Decisions, Not Features
One of the easiest mistakes in enterprise software is to begin with a feature list.
We tried to begin with decisions.
What decision is the salesperson trying to make at 9:00 AM?
What information is needed before entering a customer location?
What decision does a manager make when reviewing a territory?
What event should trigger a follow-up?
Which data is useful immediately, and which data is collected only because it has always been collected?
This changed several conversations.
Instead of asking, “What fields should the CRM contain?”, we asked, “What does the user need to know or do at this moment?”
That led us to think in workflows.
Designing the Solution
Daily Planning
The system needed to help users translate monthly or quarterly objectives into daily execution.
The goal was not to micromanage the field team.
It was to reduce the amount of mental and administrative effort required to decide what to do next.
Customer Context
Before a visit, users needed a practical view of the account.
Not every data point.
The useful ones.
This could include recent orders, outstanding issues, payment status, product mix, previous visit notes, open opportunities or engagement history.
The principle was simple:
Context before capture.
Enterprise applications often ask users to give data before giving them anything useful in return.
We tried to reverse that.
Field Execution
During a visit, the application needed to make common actions fast.
The more time a salesperson spent operating the app, the less attention they had for the actual customer.
Capture therefore needed to be selective.
Where possible, data was auto-populated, inferred or reused.
Order and Workflow Integration
If a field interaction resulted in an order, issue or request, it should not disappear into another disconnected process.
Manager Visibility
Manager dashboards were designed around intervention rather than decoration.
A chart is useful only if it helps someone decide what to do.
What made it difficult
Enterprise transformation creates an unusual design constraint.
You are rarely starting with a blank sheet.
There are existing systems.
Existing processes.
Existing roles.
Existing reports.
Existing incentives.
Existing workarounds.
And every workaround exists for a reason, even if that reason is no longer valid.
Replacing everything at once would have created unnecessary disruption.
Keeping everything unchanged would have defeated the purpose.
So the real challenge became deciding what to preserve, what to integrate, what to simplify and what to retire.
Data quality was another major issue.
A beautiful user interface cannot compensate for unreliable master data.
If customer records are duplicated, hierarchies are outdated or identifiers do not match across systems, the product quickly loses credibility.
Users do not distinguish between a data problem and an app problem.
To them, the product is wrong.
Adoption was also complicated by a familiar paradox.
The organisation wanted better data from the field.
The field team wanted less data entry.
Both were reasonable.
The product had to create enough value for the user that data capture felt like part of doing the job rather than an additional reporting burden.
That meant continuously questioning every field, every approval and every mandatory step.
Implementation
We implemented the transformation progressively rather than attempting a single large cutover.
Early versions focused on a limited set of high-frequency workflows.
These were selected based on three criteria: frequency of use, business impact and ability to measure improvement.
We monitored adoption by role and region, not just total logins.
A user opening the app did not necessarily mean the product had become part of the operating process.
We therefore tracked deeper signals such as planned vs completed visits, active users, repeat usage, orders created through the workflow, follow-up completion, issue closure, data completeness and time spent on key tasks.
Feedback from the field was treated as product input, but not every request became a feature.
A common enterprise product-management challenge is distinguishing between a genuine recurring need and a local process preference.
We looked for patterns across users, territories and roles before changing the core experience.
Implementation also required management alignment.
Digital transformation becomes fragile when the software says one thing and the operating process says another.
Policies, review mechanisms and field expectations had to move together with the product.
What this work reinforces
The biggest lesson was that digital transformation is not the same as digitisation.
Digitisation puts an existing process on a screen.
Transformation changes the operating logic.
Sometimes that means automation.
Sometimes integration.
Sometimes removing a step entirely.
And sometimes the most valuable change is simply making information available before a decision instead of after it.
The project also reinforced something I now strongly believe about enterprise products.
If the user experiences the system primarily as a reporting obligation, adoption will always require pressure.
If the system helps the user perform the job better, adoption begins to create its own momentum.
The difference between those two outcomes is usually not technology.
It is product design.