A CRM that works with no signal.

The offline-CRM lie

A real-estate agent is showing a basement-level condo. Buyer asks a question that turns the casual viewing into a real lead. The agent pulls out her phone to log it before the next showing in twenty minutes. The CRM opens, the spinner spins, and the screen says "We're having trouble connecting." She types the note anyway, taps save, and gets the same error. By the time she's back outside and has signal, the next showing's started and the lead never gets captured. By Friday she doesn't remember the buyer's name.

The basement has no signal. The CRM had "offline support." Both can be true at the same time.

"Offline support" is one of the most misleading checkboxes in CRM marketing. Almost every cloud CRM ships some version of it. Most of those versions mean: we cache the last few records you viewed, and we queue your writes, and we hope the sync goes through correctly when you reconnect. That's a meaningfully different thing from a CRM that works offline — where the device is the source of truth and the network is a backup channel, not a dependency.

If you do most of your sales work from a desk on stable Wi-Fi, the difference between the two architectures doesn't matter to you. If half your week happens in cars, parking garages, basements, conference floors, rural client sites, trains, planes, or anywhere with intermittent signal — the difference is whether your CRM is doing its job in the moments that matter or quietly failing.

What "offline support" actually means at each vendor

Public docs and product behavior as of May 2026. Vendor capabilities change quickly — verify against current product pages before relying on this.

Salesforce Mobile (Briefcase Builder)

Salesforce has the most mature offline story among the cloud CRMs. Briefcase Builder lets an administrator define an offline "briefcase" — a curated set of records and related data — that ships to a field user's device for offline use. The briefcase records are readable and editable offline; writes sync when reconnected. The catch is configuration: someone (usually an admin) has to define which records belong in the briefcase and refresh it. Records outside the briefcase aren't available. For planned offline work it can be made to function. For unplanned offline scenarios — a basement showing you didn't expect to enter, a flight you booked at the last minute — the experience falls back to whatever was already cached.

HubSpot Mobile

HubSpot's mobile app is primarily online. It caches some recent content for read access if you've just been in it, and it has limited write queueing for specific actions, but the core "create a contact, attach activity, move a deal stage on a record I haven't recently viewed" workflow requires a connection. There's no equivalent to Briefcase Builder. The offline experience is closer to graceful degradation than to a working workflow.

Pipedrive Mobile

Pipedrive's iOS and Android apps show cached records and queue a limited set of changes while offline. The functionality is narrower than Salesforce Briefcase: the cache is whatever you happened to view recently, and the queueable actions are limited. Most users discover the boundaries by hitting them in the moment.

Zoho CRM Mobile

Zoho ships an explicit "offline mode" you can enable from settings, which downloads a configurable subset of records to the device. It's closer to Salesforce's approach than HubSpot's. Setup is required and the offline corpus is finite — outside that corpus, the app is online-only.

Bigin by Zoho

Bigin is mobile-friendlier than Zoho's full CRM but follows the same broad pattern: pre-downloaded offline data works, anything outside the cache needs a connection.

Folk, Attio, Close, Copper

Web-first products with mobile companion apps. The offline story is the weakest of the group — most workflows require a live connection, and the mobile apps are primarily a window onto the web product.

Daylite

The outlier among the comparison set: Daylite is a native macOS and iOS CRM with genuine offline functionality, because the architecture predates the cloud-first generation. It's worth knowing about if you're shopping in this space — and it's not in the same price tier as the rest of the list.

The architecture difference

Two CRMs that both say "works offline" can mean two different things underneath.

Cached-view + queued-write is the architecture of most cloud CRMs. The mobile app is a thin client over a remote database. It caches some records locally for read access, queues a limited set of writes when offline, and treats the server as the source of truth. The user-visible behavior: it works for the records you happened to load, fails for records you didn't, and the queue can get into states (conflicts, validation failures, version mismatches) that the user doesn't see until later. The mental model is "online by default, degraded when offline."

Local-first is the architecture where the device's own data store is the source of truth. The app reads from local storage, writes to local storage, and treats the network as a sync channel — useful when present, ignored when absent. There's no "offline mode" to enable because there's no online-only mode to fall out of. The mental model is "offline by default, networked when convenient."

The local-first pattern got a lot of academic attention from Ink & Switch's 2019 essay and has since shown up in apps like Linear, Figma, and Notion (partial). For mobile CRM the pattern is rarer because the cloud-first generation got there first and the market hasn't pulled hard enough on offline to force a rewrite.

The difference shows up in one specific behavior: in a cached-view CRM, the question "can I create a new record I haven't seen before, while offline?" usually has the answer no. In a local-first CRM, the question doesn't really make sense — every record is a local record.

Where this actually matters

Five situations that surface the difference between the two architectures:

The basement showing. Real-estate agents working condos, downtown listings, and older buildings hit zero-signal rooms constantly. The lead capture has to happen in the moment — by the next showing, the context is gone.

The conference floor. Trade-show WiFi is famously unusable. Cellular gets jammed by density. The exact moment when a busy sales person is collecting the most leads is the moment when the CRM is least likely to work.

The flight. Domestic short-hauls without WiFi, international long-hauls where the WiFi is expensive enough that nobody buys it, or "WiFi-equipped" planes where the satellite drops every twenty minutes. The 4 hours of uninterrupted phone time is exactly when a rep wants to clean up a pipeline.

The rural client. Insurance brokers driving to a farm, an agricultural client, a remote home health visit. Coverage isn't a guarantee and the visit can't be rescheduled.

The international. Anyone traveling with roaming disabled. Anyone working in a market where the local data plan hasn't activated yet. Anyone in a country where their carrier just doesn't work well.

The common thread isn't poverty of infrastructure — it's that signal availability isn't always predictable, and the CRM's job is to capture work in the moment. Anything that introduces a "let me wait until I have signal" pattern is anything that introduces a memory test.

The 30-second test

If you're shopping for a mobile CRM right now, or auditing the one you already use, this is the test:

1. Turn on Airplane Mode.
2. Open the CRM app.
3. Try to: view a contact you haven't opened recently, create a new lead from scratch, change a deal's stage, log an activity, attach a voice note.

If any of those fail with a "no connection" error, the CRM is cached-view + queue, not local-first. If all five work as if nothing changed, the CRM is local-first.

The test takes less time than reading a product page about offline support, and the answer is more reliable than the marketing copy.

How Yuzen handles offline

Yuzen is built local-first by design. The architecture has three pieces.

The data store is local. Leads, activities, pipeline stages, and notes live in an in-memory store backed by JSON in the app's local storage. Reads and writes don't touch the network. The store is the source of truth; the server is a sync target.

Contacts come from the iPhone's native address book. There's no separate contact database to keep in sync. The Contacts framework is on-device by definition — Yuzen reads from it directly, and when you tap a contact to attach to a lead, the data is local.

The AI is on-device. Business card OCR runs through Apple's Vision framework. Voice transcription runs through the iOS Speech framework. Structured action extraction (turning a voice transcript into stage changes, value updates, and tasks) runs through Apple Foundation Models on the device's Neural Engine. No cloud round trips, no API keys, no quota.

The combination means the user-facing offline experience is the same as the online experience. You can run an entire trade-show day or a transcontinental flight inside Yuzen without thinking about connectivity. When the network comes back, a background sync queue pushes the day's changes to the server. The queue persists across app restarts and phone reboots, so a dropped session doesn't lose work.

There's no "offline mode" toggle. There's nothing to enable. The default is local-first; the network is a convenience layer.

Honest comparison

The first useful column is "create records offline." That's the workflow that separates a working offline CRM from a tool that shows you stuff but can't capture new work. The second is "voice / AI offline" — most cloud CRMs route those features through a cloud model, so even apps with reasonable offline data handling lose their AI features the moment signal drops.

Why most CRMs aren't built this way

Architecture inertia, mostly. The big cloud CRMs were built as web apps in the late 2000s and early 2010s, when "mobile" meant a thin wrapper around the web product. Retrofitting a local-first data layer onto an app that was designed around a remote database is expensive — it's effectively a rewrite of the data tier. The product teams that have tried (Salesforce with Briefcase Builder, Zoho with Offline Mode) have ended up with a curated subset of offline, because the alternative requires sponsoring a multi-year project the market hasn't loudly demanded.

The CRMs that are local-first tend to be the ones built native-mobile from day one, with a small enough surface area that the architecture decision was tractable. That's a small list, and most of the entries are recent (or are products like Daylite that predate the cloud generation).

The shape of the market means the offline-first option is structurally rare. If the workflow matters to you, the shortlist is small.

The short version

"Works offline" in CRM marketing usually means cached-view of records you already loaded, plus a queue of pending writes that may or may not survive. For most desk-bound inside sales, that's fine. For anyone whose work happens in cars, basements, conference floors, rural client sites, or planes, the difference between cached-view offline and actually-offline is the difference between a tool that captures the moment and a tool that doesn't.

The 30-second test — Airplane Mode + try to create a new lead from scratch — separates the two architectures cleanly. If you can, you have a local-first CRM. If you can't, you have a cloud CRM with offline marketing copy.

Yuzen is local-first by design. Contacts come from the iPhone's address book, leads and activities live in a local store, and voice and OCR run on-device. Airplane Mode is indistinguishable from connected Mode. $7.99/month.

Related