May 09, 2025·8 min
Build a Multi-Location Salon Web App: Rotation & Analytics
Learn how to plan and build a web app for multi-location beauty salons: booking, staff rotation, permissions, and revenue analytics with practical steps.
Learn how to plan and build a web app for multi-location beauty salons: booking, staff rotation, permissions, and revenue analytics with practical steps.
Before you draw screens or choose tools, get specific about what “better” means for your salons. A multi-location app can solve a lot of problems, but if the goals aren’t clear, you’ll ship features nobody relies on.
Pick 3–5 outcomes and attach numbers to them. Common examples for salons include:
These goals become the acceptance criteria for your MVP: if the app doesn’t move these metrics, it’s not done.
Multi-location operations usually involve distinct roles:
For each role, write down what they do daily—and what they should not be allowed to change.
Document both the “happy path” and the messy reality:
Multi-location isn’t just “add a location field.” Decide upfront:
Answering these questions early prevents painful rewrites later—especially in booking rules and reporting.
Before you design calendars or dashboards, you need a shared “source of truth” for what your salon business is: where you operate, who works there, what you sell, and who you serve. Strong core data is what keeps multi-location booking, rotation, and reporting consistent.
Each location should store practical operational details:
Tip: model “resources” explicitly (Chair 1, Color Room) rather than as notes. It’s the simplest way to prevent double-booking later.
A staff profile should include more than a name and phone number. To support rotation planning and correct booking:
Design choice: store skills as structured tags (with levels) so services can require “Skill: Color Level 2+” and your booking engine can filter eligible staff.
Create a single customer record that works across locations. Include:
This prevents duplicate records when someone books at a new branch and keeps reporting (repeat rate, lifetime value) accurate.
Define services as bookable items with:
If you treat services like a catalog—rather than free text—you’ll get cleaner bookings, fewer mistakes at the front desk, and reliable analytics.
Your booking engine is the “source of truth” for availability across locations, staff, rooms, and service rules. Treat the calendar UI as a view on top of that engine, not the engine itself.
Online booking and front-desk booking must hit the same API and rules. Otherwise, you’ll end up with two calendars that disagree.
At a minimum, availability should consider:
Define conflict rules clearly and apply them consistently:
To keep calendars accurate in real time, use optimistic concurrency (version numbers) or short-term holds (e.g., a 5–10 minute “pending” slot during checkout). This reduces race conditions when two people target the same time.
Buffers (prep/cleanup), breaks, and lunch should be first-class scheduling blocks—not notes. Service bundles (e.g., cut + color) should be a single booking that expands into multiple timed segments, potentially requiring different resources.
Avoid hard-coding policies. Store them as settings per location (and sometimes per service), such as:
When policies are data-driven, you can adjust them quickly without code changes—and keep behavior consistent across web, mobile, and front desk.
Rotation is where multi-location operations either feel fair and predictable—or messy and political. Treat scheduling as a set of clear rules plus a safe way to handle exceptions.
Most salons benefit from supporting multiple rotation “templates,” because one location may run like clockwork while another is demand-driven.
A practical approach is to store patterns as reusable schedules (e.g., “Downtown Week A”), then generate shifts for a date range instead of hand-building every week.
Fairness isn’t “everyone gets the same shifts.” It’s “the rules are visible and consistent.” Decide how you’ll distribute:
Bake these into your scheduling logic as soft goals (preferences) versus hard rules (constraints). For example: “Each stylist should get at least one prime slot per week” (goal) versus “Senior colorist must be present on Saturdays” (rule).
Your scheduler is only as smart as the constraints it understands. Common ones include:
Model these as structured data, not notes, so the system can warn you before a conflict is published.
Even the best plan needs exceptions. Provide tools for:
This keeps the schedule flexible without losing accountability—critical when disputes, payroll questions, or compliance checks happen later.
When you run multiple locations, “who can do what” becomes just as important as features like booking. Permissions protect customer privacy, reduce costly mistakes, and make it easier to trust your numbers—especially when managers, front-desk staff, and stylists all use the same system.
Start by deciding what each role can view and edit:
Then add cross-location rules. For example, a receptionist may book only for their own location, while an area manager can view calendars across all locations but cannot edit payroll.
Instead of one big “admin” permission, split by feature so you can be specific:
This keeps day-to-day work smooth while limiting sensitive actions to the right people.
Approvals are a straightforward way to prevent silent margin loss and schedule chaos. Common approval triggers:
Make approvals fast: show the reason, the impact (amount, affected appointment), and who must approve.
An audit log should answer: what changed, who changed it, when, and from where. Track edits to appointments, payouts/commission adjustments, refunds, and inventory changes. Add searchable filters by location, staff member, and date so owners can resolve disputes quickly without digging through messages.
Checkout is where scheduling turns into revenue, so it needs to be fast for the front desk and precise for reporting.
Start with a “services delivered” summary pulled from the appointment: services, duration, staff member(s), and location. Then let the receptionist add last‑minute items without leaving the screen: add-ons (treatments, upgrades), retail products, discounts (promo code or manual), tips, and taxes.
Keep the math predictable by defining an order of operations early (for example: discounts apply to services, tax applies after discounts, tips are post-tax). Whatever you choose, make it consistent across locations so reports stay comparable.
Decide what you’ll allow:
Also define partial-payment behavior: can an invoice be left open with a balance due, or must every appointment be fully settled the same day? If you allow balances, specify when the service is considered “paid” for commission and revenue reporting.
Refunds and voids should require reasons (dropdown + optional notes), record who performed the action, and keep an audit trail. Make a clear distinction:
Gate sensitive actions behind roles (see /blog/permissions-and-audit-logs) so staff can’t override rules casually.
Pick payment providers and receipt delivery (email/SMS) early because they influence your data model. Even if you don’t integrate accounting on day one, store clean financial records: invoice, line items, payment attempts, successful payments, tips, taxes, and refunds. That structure makes later exports and a reliable revenue analytics dashboard much easier.
Your analytics should answer two questions quickly: “How much did we make?” and “Why did it change?” Start with a small, consistent set of revenue metrics so every location reports the same way.
At minimum, standardize:
Decide how you’ll handle edge cases (split payments, partial refunds, gift cards, deposits) and document it so your dashboards don’t become a debate.
Make it easy to compare performance by:
A practical pattern is a top row of headline tiles (net sales, appointments, average ticket), followed by drill-down tables where you can click a location or staff member to see details.
Revenue is the result; operations are the levers. Include:
These KPIs help explain “why” without needing complicated analysis.
Keep filters simple and always visible: date range, location, staff, service. Avoid hiding essentials behind “advanced settings.”
Every report should be exportable to CSV with the same columns your on-screen table shows (plus IDs and timestamps). That makes it easy to share with accountants, payroll, or a BI tool later—without rebuilding the app.
Commissions are where trust is won or lost. Staff want to know the numbers are fair, managers need quick approvals, and owners need payroll-ready totals without spreadsheet chaos.
Start by supporting the most common rules and making them visible in service setup:
For multi-location teams, allow commission plans to be assigned by location, role, or individual. A stylist covering another branch might still be paid under their home plan—or under the branch plan—so the app should support either policy.
Keep payroll inputs simple but flexible:
This is also the right place to define whether commission is calculated on gross (before discounts) or net (after discounts), and how refunds are treated.
Real life creates edge cases: redo services, chargebacks, goodwill discounts, and manual bonuses. Add an Adjustment entry type that requires:
That audit trail reduces disputes and makes it easier to explain totals later.
Generate a statement that mirrors how staff think about their work:
Managers should get a summary view per location, with export options that feed payroll tools. If you’re planning POS integration, align statement categories with your checkout setup so reconciliation is straightforward (see /blog/build-salon-pos-payments).
Inventory is optional for some salons, but if you sell retail products (or want tighter control over consumables like color, developer, gloves, and disposables), basic stock tracking can prevent surprise outages and make revenue reporting cleaner.
Start with a simple product catalog that supports multiple locations. Each item should have: SKU/barcode (optional), name, category (retail vs consumable), cost, price, and current on-hand quantity per location. For consumables, consider a “not for sale” flag so they can be used internally without showing up in retail menus.
Multi-location salons need transfers. Keep it lightweight: select “From location,” “To location,” and quantities—then generate a transfer record so both locations update correctly.
For stock counts, support quick cycle counts (count a subset) and full counts (end of month). Store adjustments with a reason (count, damaged, expired) so owners can spot patterns.
Low-stock alerts should be per location. Let staff set a reorder threshold and optionally attach a preferred supplier and pack size. Avoid turning this into a full purchasing system—most salons only need “what’s low and where.”
Retail items must be sold through the same checkout flow as services so inventory and revenue stay consistent. When a product is added to a ticket, the system should:
This keeps reports aligned with reality without adding extra steps at the front desk.
A salon app lives or dies on speed at the counter and clarity on a phone. Aim for a small set of core screens that load quickly, look clean on touch devices, and keep staff focused on the next client.
Design navigation around what happens every hour:
Keep the rest one tap away, not in the main flow.
Front desk staff should be able to do three actions in under 10 seconds:
The calendar should default to a day view with big tap targets and minimal scrolling. Use a sticky header (date, location, filter) so staff never “gets lost.”
Statuses should communicate what to do next, not just state. A practical set is:
Color helps, but always include text labels for accessibility.
Busy teams mis-tap. Add gentle safety nets:
If you’re planning an MVP, prioritize these core flows before adding settings and advanced reports. For a clean rollout sequence, see /blog/rollout-plan-mvp-pilot-training.
A salon app lives or dies on reliability: bookings can’t lag, staff can’t lose access mid-shift, and owners need numbers they can trust. Start by choosing boring, proven tools your team can maintain.
Most multi-location salon management apps work well with a classic setup:
If you’ll process payments, choose a provider with strong docs and webhooks (e.g., Stripe) and design your system so payment events can be retried safely.
If you want to move faster on the first usable version (calendar + checkout + dashboards), a vibe-coding approach can help. For example, Koder.ai lets teams generate a React web app with a Go backend and PostgreSQL from a structured chat, use a dedicated planning mode before building, and export source code when you’re ready to take over engineering in-house.
Run three environments from the start. Staging should mirror production so booking and POS changes can be tested without risking live data.
Plan for:
If you’re using a platform workflow (including Koder.ai), prioritize features like snapshots and rollback so schedule and payment changes can be reverted quickly during peak hours.
Use TLS everywhere, encrypt sensitive data at rest, and store secrets in a managed vault (not in code). Enforce least-privilege access with role-based permissions, and prefer MFA for admins and owners. Add audit logs for actions like refunds, schedule edits, and permission changes.
Assume traffic spikes during lunch breaks and evenings. Use caching for read-heavy views (like dashboards), queues for slow tasks, and isolate reporting workloads so analytics doesn’t slow down booking and checkout.
Shipping a multi-location salon management app is less about one “big launch” and more about a controlled rollout that protects the front desk and keeps owners confident in the numbers.
Your first release should cover the daily loop end-to-end:
The MVP goal is speed and accuracy at the front desk—not perfect automation. If the calendar feels instant and the revenue totals match the register, people will adopt it.
If you’re under time pressure, consider prototyping the MVP on Koder.ai first, then iterating with stakeholders using short feedback cycles. The ability to deploy quickly, attach a custom domain, and roll back safely can be especially useful during pilots.
Run a pilot with a “champion” manager and a small group of receptionists and stylists. Keep the pilot short (2–4 weeks), and define success metrics upfront:
Avoid changing core rules mid-week. Instead, log issues and batch updates.
Provide role-based training: front desk, managers, stylists, and owners. Use short checklists and scenario practice (walk-in, late client, move to another staff member). A one-page “What to do when…” guide inside the app (e.g., /help/front-desk) reduces panic during peak hours.
Collect feedback weekly: front desk speed, schedule clarity, and report usefulness. Then prioritize upgrades in a visible roadmap:
This rhythm keeps the app improving without disrupting daily operations. If you publish your learnings, note that platforms like Koder.ai offer credit-earning programs for creating content or referrals—useful if you’re documenting your build in public while iterating on the product.
Start with 3–5 measurable outcomes and put numbers on them (e.g., no-shows from 12% → 7%). Use those metrics as MVP acceptance criteria.
Practical salon targets often include:
List each role and their daily tasks, then define what they must not be able to change.
Typical roles:
Treat multi-location as business rules, not just a “location” field.
Decide early:
These choices drive booking logic and reporting structure, so changing them later is expensive.
Model core entities as structured data (not free-text) so scheduling and reporting stay reliable:
Build a single availability engine and have every channel (front desk + online booking) use it.
At minimum, availability should account for:
To prevent race conditions, use (5–10 minutes) or when saving bookings.
Support reusable rotation templates and generate shifts for a date range, then allow controlled exceptions.
Good patterns to support:
Keep overrides safe with approvals and an audit trail for swaps and last-minute changes.
Use role-based permissions by location and by feature, then add approvals for high-impact actions.
Common approval triggers:
Also maintain searchable audit logs (who/what/when/from where) for refunds, schedule edits, and payroll-impact changes. For related guidance, see /blog/permissions-and-audit-logs.
Design checkout around a predictable invoice built from the appointment, then allow fast add-ons:
Define rules early for partial payments (allowed or not) and for void vs refund behavior, with required reasons and permission checks.
Standardize your definitions first so every location reports the same way.
Minimum consistent metrics:
Then add operational KPIs that explain changes:
Make commission rules explicit and auditable, and align them with checkout calculations.
Common models to support:
For multi-location teams, allow plans by , , or , and define whether commissions use (after discounts) and how refunds affect payouts. Provide staff statements with adjustments requiring reason + approval.
Make every report exportable to CSV with stable columns (plus IDs and timestamps).