Platform pain
1.9 stars: when the field app is the weakest link
The field app is the weakest link because it is the one component your reps actually touch, and Salesforce Maps carries a 1.9-star App Store rating to prove the point. Reviewers report the app crashing every twenty minutes, draining phone batteries, and shipping route and marker regressions in recent releases. Your data model can be immaculate; if the phone dies in a parking lot with no signal, none of it reaches the customer.
What does a 1.9-star rating actually measure?
App-store reviews are the closest thing to honest telemetry you get from a field force that will never file a support ticket. As of September 2025, Salesforce Maps sits at 1.9 out of 5 across 26 ratings on Apple's App Store. That is not a feature request in disguise. One rep's App Store review reads:
It's crashing every 20 Minutes. It's hardly usable!
Another simply reports that it drains the phone's battery. A rating built on 26 reviews is a small sample, but that is the point: reps almost never rate an internal tool, so it takes a genuinely bad day to move someone to write one at all. A low mean sitting on a low count is worse signal than it looks, not better. The reviews you can read are also the fraction that survived the funnel of a rep bothering to open the App Store after a bad shift; the silent majority just stop opening the app and go back to a spreadsheet and their own memory of the route.
Why is the rep app the weakest link in a CRM stack?
The rep app is where CRM strategy meets a parking lot with no signal. Upstream sits a data model, territory logic, dashboards, and the integration bill that funds all of it. Every dollar of that investment is delivered to a customer through one process, on one phone, held by someone who has about ninety seconds before the next call. If the app cold-starts slowly or dies mid-visit, the entire stack above it is invisible. Nobody in the field cares how elegant the object model is when the screen is still loading.
This is why a field productivity tool should be judged by battery drain and cold-start time, not by a feature matrix. The matrix wins the procurement demo, where the phone is charged, on office Wi-Fi, and driven by a sales engineer who knows exactly which buttons not to press. The battery meter wins the actual shift, where none of those conditions hold.
What happens when a release ships regressions?
Reviewers describe a recent release that, by their account, arrived with a batch of new bugs: broken routing, in-app navigation misfiring, and markers not displaying on the map at all. For a back-office user, a regression is an annoyance you route around until the next patch. For a rep, broken routing means the day's plan is wrong before the first call, and missing markers mean the accounts simply are not on the map to visit.
The harder problem is that the release cadence is not yours. You inherit it. When the schedule and the regressions both land on someone else's calendar, you are living with a platform's roadmap moving under you — except here it moves under a person standing in a loading bay, not a service in a data centre. The blast radius of a bad build is measured in missed calls, not stack traces.
How should a field app actually be measured?
Swap the feature matrix for a field-grade scorecard. The two columns rarely agree.
| What the demo measures | What the shift measures |
|---|---|
| Number of map layers and filters | Cold-start time to the first usable pin |
| Territory optimisation features | Battery drain across a full eight-hour route |
| Reporting and dashboard depth | Crash-free sessions per rep per day |
| Number of integrations | Behaviour at zero bars of signal |
None of these are exotic. They are the physics of a delivery or merchandising run: an eight-hour shift, dozens of stops, patchy coverage, and a battery that has to last until the last drop. Battery is not a soft metric here either. A map-centric app is close to worst case for a phone: continuous GPS, cellular radios reaching for a signal that is not there, and map tiles rendering with the screen bright enough to read in a sunlit cab. Get any of those wrong and the device is at twenty percent by lunch, which is a support problem, a safety problem, and a data-quality problem all at once, because a rep with a dying phone stops logging visits. An app that scores well on this list can be feature-thin and still beloved; an app that scores badly can win every demo and still earn 1.9 stars from the people who depend on it.
Where does the fix actually start?
The direction out is unglamorous and mostly architectural: treat the mobile client as a first-class consumer on the event bus, with offline-first sync, a crash budget you monitor like an SLA, and a release train you control — the shape of thing we build into a delivery suite on one event bus. Staffing is part of it too, because the bench of people who know any niche field platform deeply is usually thinner than the logo suggests.
The wider shift is that field-force telemetry is leaking into the open. A rep's phone now rates your route-to-market strategy in public, one star at a time, and that number is starting to appear in board decks next to adoption and pipeline. The brewers who treat the app-store rating as a first-class KPI rather than a vanity metric will be the ones who notice the parking-lot problems before their competitors' reps do.
Frequently asked questions
Why does Salesforce Maps have a low App Store rating?
As of September 2025 it sits at 1.9 out of 5 across 26 ratings, with reviewers citing crashes about every twenty minutes, battery drain, and regressions like broken routing and missing markers in recent releases. App-store reviews are effectively unfiltered telemetry from field reps.
How should we evaluate a field sales app before buying it?
Measure cold-start time to the first usable screen, battery drain across a full shift, crash-free sessions per rep per day, and behaviour at zero signal. Feature matrices win demos; those four metrics decide whether reps actually keep using it in the field.
Is the fix just switching vendors?
Not necessarily. The deeper fix is treating the mobile client as a first-class consumer on your event bus, with offline-first sync and a release cadence you control, rather than a thin skin over CRM whose roadmap and regressions move under you on someone else's schedule.
Stuck with exactly this?
BrewOS builds the full route-to-market stack for global brewers — order capture, stock, loyalty, returnables, delivery and analytics on one event bus, run by a team of ~20 engineers. Bring us the feature that’s been stuck the longest and we’ll show you how we’d ship it in days.
Book a 30-minute walkthrough