Franchisees get their own pipeline, their own inbox, their own caregivers, their own WellSky connection. Franchisor gets rollups and brand control. Nobody sees another location's data unless they should. Enforced at the database, not in app code.
Either everyone sees everyone's leads (a privacy disaster you can't actually ship to a system with 80 owner-operators), or the franchisor sees nothing and runs the brand on monthly Excel exports from each unit. Neither is OK. Franchisees need their own world, where their leads, their caregivers, and their numbers belong to them. Franchisor needs rollups that arrive on Tuesday morning, not three weeks later, and brand consistency that isn't enforced through PDFs and hope.
units in a typical US home care franchise system.
office staff at the median franchise unit. Nobody has time to learn a fifth tool.
franchisor field-coach to franchisee ratio. Without rollups, coaching is reactive.
Industry estimates from IFA franchise-system data and home care industry surveys (Home Care Pulse, IBISWorld).
Every row in the database carries a location_id. Every query goes through Row-Level Security policies at the database layer. Franchisee A literally cannot read Franchisee B's contacts. Not because the app forgets to filter, because Postgres won't return the rows.
Franchisor sees the rollup. Coaches see the units assigned to them. Owner-operators see their own unit. The same dataset, the same product, three different views, zero ambiguity.
location_id on every domain table.Tuesday morning, you already know which units are lagging and on which inputs.
Master templates inherit down. Per-location overrides where state law actually requires.
Inbound leads route by ZIP, by territory, by SLA fallback. No more shared inbox arguments.
You bought a territory. CareRM treats it like one. The leads you paid to generate stay yours. The caregivers you recruited stay yours. The WellSky tenant you run on is yours, one per location. Nobody at another unit sees your inbox, your pipeline, or your numbers. Not the franchisee next door. Not the franchisee across the country.
The BAA lives at the brand level so the franchisor signs once. Per-location override is allowed where a unit uses a different sub-vendor (e.g. local answering service). Every action writes to a per-location audit log. State-by-state referral-fee legality (California, Florida, New York and others) is gated automatically in the UI so a unit can't accidentally do the thing their state forbids.
Founding-member pricing is locked in from a regular $997. Every feature on this page (rollups, brand templates, lead distribution, per-location audit, RLS scoping) ships in the standard plan. No multi-location surcharge. No enterprise upsell to get the franchisor dashboard.
For 5+ unit operators or franchisor-led system rollouts, talk to us about volume. We'll work out billing (one invoice to HQ, or per-unit invoicing to franchisees, or both) so it matches how your system actually runs.
Yes. HQ publishes master templates for SMS, email, AI Voice greetings, and HIPAA disclosure text. Locations inherit by default. A location can request an override (and HQ can require approval for it), or HQ can lock a template entirely. The most common pattern is locked disclosure text plus editable greeting tone.
Yes. The greeting, qualifying questions, business hours, and handoff rules are per-location. HQ sets the floor (disclosure script, brand voice, prohibited content) and the location personalizes within those guardrails. A 4-location operator can run four greetings without four separate accounts.
All three. Configure routing by ZIP code, by named territory polygon, or by source (e.g. paid lead provider sends to a specific unit). Fallback rules handle the case where the assigned unit does not respond inside the SLA window. Route to a neighbor unit, escalate to HQ, or both.
No. Every row in the database carries a location_id, and Row-Level Security policies bound to per-tenant database roles enforce isolation at the Postgres layer. It is not an app-level filter that could be forgotten. A query run as Franchisee A literally cannot return Franchisee B’s rows.
Whichever you want. The default for franchisor-led rollouts is a single consolidated invoice to HQ with a per-location line item. The default for franchisee-led adoption is per-unit invoicing direct to the owner-operator. Mixed setups are fine. Tell us which model fits your franchise agreement and we will configure it.
Coaches get a scoped role that sees the rollup for their assigned units plus drill-down into operational signals (response time, source mix, SLA breaches, WellSky sync health) without exposing PHI inside conversations. The audit log records every drill-down, so units know exactly who looked at what and when.