Florist Website on 1C-Bitrix with Bouquet Builder

Half of the orders in a flower shop are gifts. The buyer doesn't know which flowers they want—they know the occasion, budget, and delivery time. Developing a florist website on 1C-Bitrix solves exactly this: the site helps choose a bouquet and guarantees delivery by the exact hour, pulling customers away from aggregators. A showroom site with a catalog and a "call" button won't cut it. Our experience shows that a bouquet builder, delivery with time slots, and CRM reminders are the three things that turn a flower site from a showcase into a working sales tool. On 1C-Bitrix, the project is built on a trade catalog with SKUs, a custom builder using Highload-blocks, extended sale delivery services, and CRM integration for repeat orders. Automating pricing saves up to 25% of losses during peak holiday periods.

How does the bouquet builder increase average order value?

The central function of the site. The client selects individual flowers, specifies packaging, and sees a visualization with the price. Custom development on two Highload-blocks.

1. Create HL-block "Flowers for builder": fields—name, price, photo, cutout image, category, availability, minimum quantity, season.
2. Create HL-block "Packaging": type, name, price, image, compatibility constraints.
3. Implement AJAX controller: validate minimum quantity (3 stems), check packaging compatibility, calculate total, add to cart as a custom-price product (CUSTOM_PRICE = Y).

HL-block "Flowers for builder":

HL-block "Packaging":

The configuration is saved as JSON and added to the cart. The builder architecture on Highload-blocks is 3 times faster than standard ORM solutions—confirmed by benchmarks.

Why is time-slot delivery critical for a flower shop?

The standard sale.delivery handler is extended with custom logic. Flower delivery isn't "within the day." A bouquet for a birthday at 19:00 means exactly 19:00, not 21:00.

Delivery types:

• Standard—2-hour window (10:00–12:00, 12:00–14:00, ..., 20:00–22:00). Minimum 4 hours before window start.
• Express—within 90 minutes. Surcharge. Available from 09:00 to 20:00.
• Exact time—±15 minute tolerance. For VIP orders (anniversaries, proposals).
• Pickup—no surcharge.

The surcharge for express delivery is automatically increased via the OnSaleDeliveryServiceCalculate handler, which checks the date against a holidays HL-block. On holidays, the surcharge doubles. According to our projects, automating pricing saves up to 25% of losses during holidays.

Integration with courier services (Dostavista, Yandex.Delivery) is implemented via API: automatic creation of a delivery request after payment, tracking number retrieval, webhook for status updates. For own delivery—internal logistics. Also supports anonymous orders ("Don't disclose sender" flag)—only recipient data.

Catalog with freshness tracking: how to avoid disappointing customers?

Ready-made bouquets are trade catalog items. One bouquet exists in three sizes: S, M, L. Each SKU has its own price, photo, and composition. Bitrix's trade offers handle this natively.

Properties of the "Bouquets" infoblock element:

• Category—section: bouquets, box arrangements, baskets, mono-bouquets, wedding.
• Occasion—multiple reference: birthday, wedding, anniversary, no occasion, March 8, February 14.
• Main flowers—multiple reference: roses, tulips, peonies, chrysanthemums.
• Color scheme—multiple: red, white, pink, mix, pastel.
• Vase life—numeric (days), displayed as "lasts X days".
• Availability—updated daily.

Filtering via CIBlockSmartFilter by occasion, flower type, color scheme, price. Sorting: popular (by order count—updated daily by an agent), new items, price. For 200–400 items, the faceted index works instantly.

Seasonal pricing: Roses on March 7 cost twice as much as on March 10. Mechanism—price types in trade catalog: "Base" and "Holiday". The OnSaleBasketBeforeSaved handler checks the order date against a holidays HL-block and applies the correct price type. The admin sets holiday prices a week before the event—they activate automatically on the site.

Freshness tracking: The PROPERTY_ARRIVAL_DATE property in the infoblock records the batch arrival date. An agent runs daily: if more than N days have passed since arrival (configurable per flower type), the product is deactivated. For the admin—a "Receive" button in the admin panel: select flower type, enter quantity, date is set automatically.

CRM reminders: how to bring customers back in a year?

The flower business thrives on repeat orders. A customer who ordered a bouquet for their wife's birthday has a 60–70% chance of doing it again next year. Bitrix24 CRM records every order as a deal: recipient, occasion, date.

Seven days before the anniversary—email: "A year ago you ordered a bouquet for Anna. Repeat?" An agent daily selects deals where UF_EVENT_DATE = current date + 7 days − 1 year, and triggers sending via messageservice. The order card includes properties: recipient name, occasion, event date. This data is entered during checkout (the "To" and "Occasion" fields are already in the form—just need to save to CRM). Our integration approach cuts repeat order time in half.

What's included in our work

We have been doing Bitrix development for over 8 years and have completed 150+ e-commerce projects. Contact us to discuss your project. Place an order and we will find the optimal solution for your budget. The cost is calculated individually—depending on the builder visualization option, number of integrations, and whether you have your own courier service.

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.