Beauty Salon Website Development on 1C-Bitrix

A beauty salon loses up to 30% of potential bookings if the website lacks a working appointment scheduling system. With an average ticket of $60 and 100 leads per month, that's $1,800 in monthly missed revenue — equating to $21,600 annually. Clients search for services at 11 PM, see a beautiful landing page, but can't book — they leave for competitors with a working "Book now" button. Our solution on 1C-Bitrix fixes this: a service catalog with live prices, real-time slot calculation, and automatic reminders. According to Software Advice Industry Report, conversion rates for scheduling-enabled sites are 3-4 times higher than those without. With over 40 projects and 8 years of experience.

Why Online Booking Boosts Salon Revenue

Conversion rate for a salon site without appointment scheduling is 1-2%; with it, 5-8%. That's 3-4 times more leads. The reservation system works as a 24/7 reception: the client chooses a master and time without waiting for a phone answer. During peak hours (evenings, weekends) this solves the overloaded administrator problem. Implementation statistics show a 40-60% increase in bookings within the first 3 months.

Service Catalog: Infoblock Structure

Services are organized in an infoblock with section hierarchy: "Hairdressing", "Manicure & Pedicure", "Cosmetology", "Massage". Each section has subsections — "Haircuts", "Coloring", "Treatments". For a typical salon, the number of services ranges from 30 to 80.

Properties of the "Services" infoblock element:

The "price from" is a deliberate choice. In salons, price depends on the master's category (trainee, stylist, top stylist). The exact price is calculated after selecting a master — this requires an intermediate table "master — service — price". It's implemented via a Highload-block MasterServicePrice with fields: UF_MASTER_ID, UF_SERVICE_ID, UF_PRICE. When selecting a service on the front end, all masters with their prices are fetched via DataManager::getList().

How to Organize Booking Without Slot Duplication

This is the core functionality of the site and the most complex to implement. The client expects a simple interface: select a service, select a master, see free slots, click "Book". Behind this simplicity lies multi-level availability calculation logic.

Step 1: Service selection. The client selects from the catalog. The system determines the duration (DURATION_MIN) and the list of masters who provide this service (MASTER_LINK).

Step 2: Master selection or "any available". If the client chooses a specific master — work with their schedule. If "any" — iterate over all masters of the service and show a combined set of slots.

Step 3: Free slot calculation. Here begins the engineering part.

Data for calculation is stored in three Highload-blocks:

• MasterSchedule — master's work schedule: UF_MASTER_ID, UF_DATE, UF_WORK_START, UF_WORK_END, UF_BREAK_START, UF_BREAK_END.
• MasterBooking — existing bookings: UF_MASTER_ID, UF_DATE, UF_TIME_START, UF_TIME_END, UF_CLIENT_ID, UF_SERVICE_ID, UF_STATUS.
• MasterDayOff — vacation, sick leave, days off.

Algorithm for calculating free slots for a specific master on a specific date:

1. Get the work schedule from MasterSchedule. If no record or the date is in MasterDayOff — master is unavailable.
2. Build an array of working minutes: from UF_WORK_START to UF_WORK_END, excluding the break.
3. Get all records from MasterBooking with status confirmed or pending.
4. Subtract occupied intervals from working minutes.
5. In the remaining free intervals, find windows with duration >= DURATION_MIN of the service.
6. Split these windows into slots with a step of 15 or 30 minutes (configurable).

$freeIntervals = subtractIntervals($workIntervals, $bookedIntervals);
$slots = [];
foreach ($freeIntervals as $interval) {
    $start = $interval['start'];
    while ($start + $serviceDuration <= $interval['end']) {
        $slots[] = $start;
        $start += $stepMinutes;
    }
}

Buffer between bookings. Between procedures, a technical break is often needed — 5-15 minutes for cleaning or tool preparation. The buffer is added to DURATION_MIN during slot calculation but not shown to the client.

Concurrent access. Two clients see the same free slot simultaneously. The first clicks "Book" — the slot is locked. The second gets a message "time taken, choose another". Locking is implemented via a transaction: INSERT into MasterBooking + check for no overlaps in the same transaction.

Booking confirmation. After booking, the client receives SMS (module messageservice) and email. A reminder is sent a day before the visit via Bitrix agent. If the client doesn't confirm, the booking moves to status unconfirmed, and the administrator decides whether to free the slot.

What to Do If YCLIENTS Is Unavailable?

Most salons already use an accounting system. The two most common:

• YCLIENTS. Cloud platform with REST API. Main endpoints: /api/v1/book_record/ (create booking), /api/v1/book_dates/ (available dates), /api/v1/book_times/ (available slots). When integrating with YCLIENTS, the Bitrix site doesn't calculate slots itself — it requests them via API. Highload-blocks MasterSchedule and MasterBooking are not needed: YCLIENTS is the master system. Downside: dependency on third-party API. If YCLIENTS is down, the site has no booking. Solution: caching the last known schedule and a fallback to a "leave a request" form.
• 1C:Salon Beauty. Exchange via 1C HTTP services or file exchange (XML). Synchronization of masters, services, bookings. Usually works with a 5-15 minute delay — not real-time.

Masters' Portfolio

Infoblock "Portfolio" linked to master and service. Key properties:

• PHOTO_BEFORE / PHOTO_AFTER — file properties
• MASTER_LINK — link to master
• SERVICE_LINK — link to service
• DESCRIPTION — what was done

On the master's page, portfolio is filtered by MASTER_LINK. On the service page, by SERVICE_LINK. Before/after photos are displayed with a slider with a divider — a popular pattern in the beauty industry.

Important: Portfolio photos must be compressed. Salon clients often visit from mobile — 10 photos at 5 MB each will kill conversion. Bitrix can resize via CFile::ResizeImageGet(), but it's better to configure WebP conversion at the nginx level or via the OnFileSave event handler.

Gift Certificates and Promotions

Gift certificates are implemented via the sale module. A certificate is a product in the catalog with a nominal value. Upon purchase, a unique code is generated and saved in the order properties (\Bitrix\Sale\Order → propertyCollection). The code is sent to the buyer via email as a PDF. When using the certificate in the salon, the code is entered during checkout — the discount coupon from the sale.discount module is triggered. The certificate balance decreases by the service amount.

Promotions are simpler: a separate infoblock with start/end dates, link to services, and terms text. Displayed on the main page and catalog via filter <=DATE_ACTIVE_FROM / >=DATE_ACTIVE_TO.

Loyalty Program

Bonus points can be implemented in two ways:

• Via sale.discount. The module supports cumulative discounts and rules based on total purchases. Limitation: no flexible point accrual for specific actions (refer a friend, review, birthday).
• Via a custom module. Highload-block LoyaltyBalance with fields UF_USER_ID, UF_POINTS, UF_HISTORY (serialized operation log). Each payment triggers the OnSaleOrderPaid handler to accrue points using a formula (usually 3-10% of the amount). When spending, balance is checked and the order amount is reduced.

Implementation Timeline

What's Included in the Work

As a result, you receive:

• A working website on 1C-Bitrix with full functionality (catalog, booking, portfolio, certificates)
• Integration with selected external systems (YCLIENTS, 1C)
• Administration documentation
• Staff training (up to 2 hours)
• Access to source code and admin panel
• Support for 3 months after launch

Key Considerations

Catalog page load speed is critical — clients compare several salons and leave if the page loads more than 2 seconds. Caching Bitrix components ('CACHE_TIME' => 3600) is mandatory for the catalog and portfolio. The online booking page cannot be cached — slot data must be up-to-date. We use Redis for caching master schedules to reduce database load, ensuring 95%+ SMS reminder delivery success.

Contact us to discuss your project. We'll evaluate the task and offer the best turnkey solution. Request development of your beauty salon website on 1C-Bitrix and gain a competitive advantage within 6-8 weeks.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.