How to Manage Multiple Dealership Branches from One Platform

One platform should not mean unrestricted access

Dealer groups want a connected operating view, but each user does not need every record. A sound multi-branch model combines shared process definitions with tenant, branch and role boundaries. Owners and authorized managers may need wider visibility; sales and service users usually need the context required for their responsibilities.

Dealer’s Edge follows a multi-tenant principle: one platform, many independent dealerships and zero data mixing as the architectural objective. Within a dealership, branch-linked users and permissions support appropriate operational scope. Review the current multi-branch capabilities and security approach together.

Model the organization before configuring software

Document the legal and operational structure: independent dealerships or tenants, branches within each dealership, teams, managers and shared functions. Do not use branch labels to compensate for unclear ownership or combine separate dealerships merely to simplify reporting.

• Tenant or independent dealership boundary
• Branch names and identifiers
• Roles and responsibilities
• Users who work across more than one branch
• Records that remain branch-specific
• Metrics that can be aggregated for authorized oversight

Standardize definitions before comparing branches

A shared dashboard is not useful if each branch records stages, outcomes and sources differently. Define the minimum enquiry fields, lead stages, follow-up outcomes, lost reasons and service statuses that every participating branch will use. Allow local variation only when it represents a real operating difference.

Document the definition beside the field or process, train with examples and audit a small sample regularly. The goal is comparable evidence—not forcing every branch into an artificial process.

Keep branch and individual ownership visible

Every active enquiry should show the responsible branch and user. If a customer changes location or a specialist takes over, record the reassignment and preserve the permitted history. Silent transfers create duplicate contact and make branch performance unreliable.

Define rules for shared digital leads, walk-ins, repeat customers and service enquiries. Use geography, product, workload or explicit customer choice only where the rule is fair and operationally supported. Managers should be able to inspect exceptions without overriding tenant isolation.

Design access from responsibilities, not seniority labels

• Sales consultant: assigned or branch-permitted enquiries and customer context
• Branch manager: branch team activity and outcomes
• Service user: permitted service and customer/vehicle context
• Group manager: approved cross-branch reporting and oversight
• Administrator: configuration responsibilities without unnecessary operational data access

Interface visibility is not a security control by itself. Protected actions and records must also be authorized on the server. Blog or marketing work must never change authentication, RBAC, branch scope or tenant checks.

Compare branches with context, not league tables alone

Branch results depend on enquiry mix, market, staffing, model availability and operating hours. Compare conversion and activity only after definitions and data quality are aligned. Use reporting to find operational questions: why is one stage ageing, why are lost reasons incomplete, or why does one source receive slower follow-up?

Keep access to reports aligned with business responsibility. A useful group view can aggregate permitted results without exposing every underlying customer record to every user.

Roll out branch by branch with an acceptance checklist

• Confirm tenant and branch mapping.
• Create roles and least-privilege access.
• Test lead capture, assignment and reassignment.
• Test Customer 360 and service context for each role.
• Validate reports against a known fictional dataset.
• Train branch managers on exceptions and data quality.
• Add branches only after the first workflow is stable.

Use a dedicated fictional scenario in a Dealer’s Edge demonstration to validate the model without exposing customer data.