Multi-rooftop dealership software
Groups rarely fail on capability. They fail on comparability — every store keeps its numbers a slightly different way, so the group report is assembled by hand and trusted by nobody. ShiftPilot AI is multi-tenant at the data layer, so rooftop detail and group roll-up come from the same records.
What group operations actually need
A group needs three things at once: hard isolation so one rooftop cannot read another's customers, a shared process definition so stores are measured on the same basis, and a roll-up that an executive can read without an analyst assembling it.
Those requirements conflict if isolation is added on top of a single-store product later. They only coexist when tenancy is part of the data model from the beginning.
The problems it addresses
Duplicate customer records across sibling stores. A GM who cannot see the store they were just promoted into. Group reporting that arrives days late and disagrees with the store's own numbers. Access that was granted for a project two years ago and never revoked.
Each of those is a governance problem before it is a reporting problem.
How ShiftPilot AI handles it
Tenancy is enforced in the database with row-level security on every dealership-scoped table, and roles live in a dedicated role table checked by security-definer functions that match on dealership — so a role granted at one rooftop does not silently apply at another.
Feature flags, entitlements, and demo status resolve server-side from the tenant control plane rather than from anything the browser supplies. Rooftop configuration is versioned. Metrics carry their identity scope, so a store figure and a group figure are never rendered interchangeably.
Reads are built for scale rather than convenience: composite tenant-scoped indexes, keyset pagination on large lists, and bounded date ranges on heavy analytical queries, with heavy work pushed to background jobs.
What requires an integration
Group-level consolidation with an external DMS, accounting system, or OEM reporting feed depends on the group's own provider contracts and credentials. Messaging across stores requires an approved provider account per configured channel.
Who uses it
Group executives and dealer principals read cross-store performance and approval exposure. Regional and general managers work their own rooftops with the same tooling. IT and compliance owners govern access, delegation, and audit evidence centrally instead of per store.
Implementation considerations
The decisions that matter are organisational: which definitions are group-standard and which stay store-local, who may delegate administrative access, and how a rooftop is onboarded or retired. Rollout is normally phased rooftop by rooftop so process changes can be validated before they are group-wide. Actual timelines depend on your data and approvals.
Connected workflows
Group leaders usually start from operations visibility and the dealer principal view. Isolation details are described on the security page.
Common questions
- How is one rooftop's data kept separate from another's?
- Every record is scoped to a dealership and enforced at the database layer with row-level security, not only in the interface. A user sees a rooftop because their role grants it, and roles are stored separately from user profiles so access cannot be escalated by editing a profile field.
- Can a group executive see all stores at once?
- Yes, where their role grants it. Roll-up views aggregate across the rooftops a user is entitled to, and the identity scope of a metric is carried with it so a group number and a store number cannot be confused for one another.
- Does each rooftop get its own configuration?
- Yes. Fee schedules, workflow settings, and operational configuration are held per rooftop and versioned, so a change is attributable and reversible rather than silently applied group-wide.
- What happens when a user moves between stores?
- Role grants are per dealership. Changing which rooftop a person can access is a role change, and cached tenant data is invalidated on identity change so a previous store's data is not left in the browser.
- Is this a replacement for our group DMS?
- No. ShiftPilot AI is a controlled operating layer above the transactional systems. Any DMS synchronization requires an approved provider connection held by the group.
Related solutions
- Automotive CRMLead scoring, follow-up journeys, and a unified Customer 360 timeline for sales and BDC teams.
- Desking and finance readinessDeal structure, payment scenarios, gross visibility, and finance-readiness checklists in one desk.
- Documents and e-signDocument packets, signer links, completion tracking, and a reviewable evidence trail.
- Dealership operationsOperational signals, approvals, task ownership, and manager visibility across sales and service.
Role views: For dealer principals · For general managers
Group walkthrough
See rooftop-level detail and group-level roll-up together
We will show tenant isolation, rooftop switching, role-based access, and how group leadership reads performance across stores without exporting spreadsheets.
Prefer to pick a time straight away? This is a secondary path — it books a slot but does not record a lead, so the form above is still the fastest way for us to prepare. Book directly in Google Calendar.