Chairlyo CRM
Running a busy salon floor and a multi-branch business from one system.
Chairlyo is an operations platform for beauty salons and studios in Nepal. I designed the full product, from the platform owner’s console to the front desk: a live view of who is waiting and in session, billing with partial payments and local payment methods, loyalty and memberships, expenses, reports, and branch-level settings and permissions.
- Role
- Product Designer
- Platform
- Web & mobile app
- Timeline
- 3 months
- Team
- 5 developers, 2 QA
- Tools
- Figma
What I owned: design system, super-admin console, live studio operations, billing, loyalty, catalogue, analytics, settings and permissions.
Context
Salons and studios typically run on notebooks, WhatsApp and spreadsheets. Walk-ins, appointments, staff performance, dues and loyalty promises are tracked from memory.
Payments are local: cash, Fonepay QR and online transfer, in rupees. A salon chain also needs separate branches with their own staff, settings and login URLs.
The problem
Owners couldn’t see what was happening on the floor or in the numbers, and the front desk couldn’t run the day without juggling several tools.
Staff need real-time visibility of waiting, active and unpaid customers.
Partial payments, untracked dues and unrecorded expenses.
Stamps, memberships and packages are promised, not recorded.
Roles, per-branch settings, and a way for the platform team to manage clients, trials and limits.
Users & goals
Check customers in, build orders and take payments fast, without missing customer context.
Branch performance, revenue, staff and expenses in one place.
Their own sessions and performance, clearly.
Organisations, plans, trials, suspensions and limits.
Goals
- Give the front desk a real-time view of the floor
- Make every sale, due and expense traceable
- Reward repeat customers automatically
- Support multiple branches and roles
- Let the platform team manage client organisations
Constraints: local payments (Fonepay QR, cash, card, transfer); staff working fast on a busy floor, so key flows had to be quick and forgiving; a multi-tenant structure of organisation then branch; and WhatsApp-based customer communication.
Three layers, three views
I split the product into three layers. Each has its own navigation, dashboard and permissions, so every role only sees what it needs.
Key design decisions
Floor work needs speed and glanceability. Back-office work needs depth and filters. Most decisions came from keeping those two apart.
One real-time Live Studio view
Waiting area, active sessions, and billing and payment sit side by side in one screen. The front desk sees who is waiting, who is in a chair and who still has to pay, without switching pages.
An order builder that shows savings as you go
Add services and products with the staff member, and see estimated time, totals and savings from the customer’s active membership and packages in one panel, with expiry dates right beside the order.
Billing that separates total, paid and due
Every bill shows what’s owed at a glance. Payment history is broken down by method, and Fonepay QR is built into invoices because that’s how customers in Nepal actually pay.
Loyalty as a real product feature
Loyalty stamps, memberships with service and product discounts, packages with duration and price, subscriber lists and redemption history, all tied to the customer profile.
Expenses and reports that add up to profit
Expenses link to vendors with bank details, QR codes and dues, and feed an expense report with net profit. Reports cover revenue, payment methods, staff, services and products, with filters, export and print.
A console for the business behind the product
Organisations, plans, trial dates, limits and expiring subscriptions in one place, plus clear trial-ended and plan-expired screens at login, so billing issues are handled before they become support calls.
System & edge cases
A shared set of components (sidebar, top bar with greeting and date, stat cards, tables, order summary, status tags and dialogs) kept 30+ screens consistent across all three layers.
States I designed for
- Empty states for customers, staff, sessions, bills and reports
- No-results search states
- Permanent-delete warnings that list what will be removed
- Trial-ended and plan-expired login screens
- Under-review and in-progress order states
- Role- and permission-limited views
More screens
Billing history, memberships and redemptions for one customer.
Branch statistics, branch admin and a login URL per branch.
Services and products with categories and stock batches.
Branding, invoice, booking, users and page-level permissions.
WhatsApp templates and webhooks for booking alerts, explained in plain language.
A complete operations system, now used by 25 salons across Nepal.
What I learned
- Real-time floor work and back-office reporting need different designs: the first favours speed and glanceability, the second depth and filters.
- Designing for local payments means designing for partial ones. “Due” deserved as much visual weight as “Paid”.
- I researched which reports people actually use before designing more of them. Early on, different users asked for different reports, and I started designing each request as it came. After a certain point the Reports section turned messy: overlapping numbers, too many screens, and some reports that nobody really needed. I paused, ran a quick round of research to find the reports people open and trust, then added what was missing and removed what was not. The final Reports section has fewer screens than my first version, and it is easier to read and use.