The mobile CRM most teams have, and do not use
Nearly every CRM ships a mobile client. Field adoption of those clients is, in most organisations, poor — and the explanations offered tend to be about user resistance or training. Watch someone actually try to use one between meetings and the real reason is immediate.
The typical mobile layout inherits the desktop record: every field, every related list, every tab, compressed onto a phone. On a desk that density is useful. In a car park with three minutes before a meeting, it is unusable. The person opens it, cannot find the two things they need, and stops opening it.
What does field work actually require?
Field work has a rhythm office work does not. There is a short window before a meeting, a conversation during which the phone should stay in a pocket, and a short window afterwards — usually in a car, often in a hurry — when the record either gets updated or does not.
That rhythm generates three requirements, and almost nothing else matters:
- Pre-meeting context in one screen. Who this is, what we sold them, what happened last time, what is currently open or escalated, what the commercial position is. One screen, no navigation, loaded before they leave the car.
- Post-meeting capture in under thirty seconds. What happened, what was committed, what happens next, when. If it takes longer than the walk back to the car it will be deferred — and deferred notes are written from memory that evening, if at all.
- Function without a connection. Basements, warehouses, industrial sites, and rural routes all defeat signal. A client that spins on a loading indicator in front of a customer is uninstalled that week.
Why does the desktop-parity instinct keep winning?
Because parity is easy to specify and easy to demonstrate. "Everything you can do at your desk, on your phone" is a clean requirement and a good demo. It is also a description of a worse product.
The better specification is subtractive and harder to write: identify the five tasks field staff perform repeatedly, design each to complete in seconds, and deliberately exclude the rest. Anything not on that list should be a deep link back to the full system rather than a cramped reimplementation.
Subtraction is politically difficult, because every function will argue for its fields. The counterargument is empirical: a mobile client with fifty fields collects worse data than one with six, because the six get filled accurately and the fifty get skipped or guessed.
How do you make capture fast enough?
By removing typing wherever possible. A phone keyboard in a car park is the constraint the whole design should route around.
- Voice notes transcribed against the account record, rather than typed summaries
- Tap-to-select outcomes for the common cases, with free text as an option rather than the default
- Automatic context — which account, which contact, which time — derived from calendar and location rather than re-entered
- Next action as a required single tap, because the follow-up commitment is the field with the highest value and the highest decay rate
Then close the loop visibly. The note captured after Tuesday's visit should be the first thing on the pre-meeting screen at the next visit. When the person entering data is the first to benefit from it, capture stops needing enforcement.
How to evaluate what you already have
Before commissioning anything, run a timing test. Take three field staff and time them: opening the app and reaching full account context, then logging a completed visit. If context takes more than fifteen seconds or capture more than thirty, you have a specific, fixable defect — and in most cases it is a mobile layout problem rather than a platform problem.
Cut the mobile page layout to the fields that matter in the field, put the three requirements above in front of the people who will live with them, and re-time. Most organisations recover usable mobile CRM from the system they already own. The ones that genuinely need something custom — usually because of offline requirements or a workflow the platform cannot express — will know it from the timing data rather than from a vendor pitch.