Development of a service website using 1C-Bitrix

Service Website Development on 1C-Bitrix

A service website has a different data architecture than an online store. No shopping cart, no inventory, no trade offers. Instead — service cards with custom fields (duration, price range, deliverables), online appointment booking, specialist profiles linked to service categories, and a CRM pipeline that captures every inquiry. Bitrix handles all of this, but the info block structure that works perfectly for product catalogs needs deliberate adaptation for services.

Info Block Architecture for a Service Catalog

The core entity is an info block with type services. Sections represent categories — "Legal Services", "Accounting", "Consulting". Elements are individual services — "LLC Registration", "Tax Audit", "Contract Review".

The property set differs significantly from a product catalog:

Sections get custom properties through UF fields: UF_SECTION_ICON for SVG icons, UF_SECTION_DESCRIPTION for extended SEO text. The built-in DESCRIPTION field for sections is too limited — no HTML support, no visual editor in versions prior to 23.x.

Nesting depth matters. A law firm needs one level: category to service. A medical center with ten departments and a hundred procedures needs two: department to subcategory to service. Bitrix supports unlimited section nesting, but catalog.section.list requires manual DEPTH_LEVEL configuration and a custom template to render correctly.

Service Card: Component Template and Structured Data

Service cards use bitrix:news.detail with a custom template — not catalog.element. The catalog module is overkill here; it pulls in trade offers, price types, and warehouse logic that a service site doesn't need.

The result_modifier.php file is where related data gets assembled:

• Specialists — CIBlockElement::GetList() filtered by IDs from the SPECIALISTS property. Photo, title, years of experience. Cached with tagged cache using the iblock_id_XX tag
• Related services — same section, excluding the current element, sorted by SORT, limited to 3-4 cards
• Portfolio cases — fetched from the "Portfolio" info block where the SERVICES property matches the current service ID

Schema.org Service markup goes into the component template. Minimum: name, description, provider (organization), areaServed. If a price range exists — add offers with priceSpecification. Google Search Console confirms recognition within 2-3 days of indexing.

Online Booking and Lead Capture Forms

Two architecturally different approaches.

The built-in form module (web forms). Forms are created in the admin panel with visual field configuration. The bitrix:form.result.new component renders the form. Submissions are stored in b_form_* tables. Advantages: fast setup, CSV export, email notifications. Limitations: no binding to a specific service without a hidden field, no date/time picker out of the box, no specialist calendar integration.

Custom booking form via info block + CRM. A dedicated info block "Appointments" with properties: service (element link), specialist (element link), date, time, client name, phone, status. The frontend form submits via AJAX through bitrix:main.ajax. The OnAfterIBlockElementAdd event handler creates a lead in Bitrix24 via REST API:

CRest::call('crm.lead.add', [
    'fields' => [
        'TITLE' => 'Booking: ' . $serviceName,
        'NAME' => $clientName,
        'PHONE' => [['VALUE' => $phone, 'VALUE_TYPE' => 'WORK']],
        'SOURCE_ID' => 'WEB',
        'UF_CRM_SERVICE_ID' => $serviceId,
    ]
]);

For a full calendar-based booking experience, integrate with the Bitrix24 calendar module. REST API calls — calendar.event.add to create events in a specialist's calendar, calendar.event.get to fetch available slots filtered by date and employee. This requires either self-hosted Bitrix24 or a cloud subscription.

The Deep Dive: Portfolio and Case Studies

This is where service sites diverge sharply from product catalogs. A portfolio section isn't a nice-to-have — for consulting, legal, design, and construction companies, it's the primary trust signal.

A separate info block portfolio holds case studies. Each element represents one project:

• CLIENT — client name (string or link to a "Clients" info block)
• SERVICES — link to service info blocks (multiple), enabling cross-filtering
• GALLERY — file property (multiple), project photo gallery
• RESULT_TEXT — HTML, describing the measurable outcome
• DURATION_PROJECT — string, project timeline
• TESTIMONIAL — HTML, client testimonial

The listing component bitrix:news.list with a custom template renders the grid or carousel. Filtering by service works in two contexts: on a service detail page, cases are loaded with PROPERTY_SERVICES = current service ID. On the main portfolio page, AJAX-driven filtering lets visitors browse by service category.

Image processing for the gallery uses CFile::ResizeImageGet() — generate 400x300 thumbnails for grid view and full-size images for the lightbox. WebP conversion happens through the BX_RESIZE_IMAGE_PROPORTIONAL_ALT parameter.

The relationship between portfolio and services is the most valuable navigation path on the site. A potential client reads about a service, scrolls to relevant case studies, sees results, and submits an inquiry. Breaking this chain — portfolio on a separate page with no service filter — reduces conversion. We build the cross-linking in result_modifier.php on both sides: service cards show related cases, case studies link back to the services involved.

Team Section with Service Binding

The "Specialists" info block stores elements with properties: photo, name, title, years of experience, bio, certifications (multiple file). Binding to services is bidirectional: the service card shows its specialists, the specialist profile shows their services.

Implementation: the SPECIALISTS property in the services info block links to specialist elements. The reverse query uses CIBlockElement::GetList() with filter PROPERTY_SPECIALISTS = specialist ID. Caching is mandatory — without it, a team page with 20 specialists and their services generates 21 database queries.

For medical and beauty sites, the specialist profile page with a schedule is critical. The schedule either comes from Bitrix24 (REST API calendar.event.get) or from a custom "Schedule" info block with slot elements. The second option is simpler to implement but requires manual schedule management.

SEO Configuration for Service Pages

Every service gets unique title, description, and keywords through info block META templates:

• {=this.Name} — service name
• {=this.PreviewText} — summary
• {=parent.Name} — section (category) name

Title template for a service: {=this.Name} — {=parent.Name} | Company. For sections: {=this.Name} — Service Catalog | Company. Per-element overrides use ELEMENT_META_TITLE and ELEMENT_META_DESCRIPTION fields.

Human-readable URLs — configured in the info block settings: URL_SECTION = /services/#SECTION_CODE#/, URL_DETAIL = /services/#SECTION_CODE#/#ELEMENT_CODE#/. Symbolic codes are transliterated from names. Uniqueness must be verified — duplicate codes break routing.

Breadcrumbs — bitrix:breadcrumb builds the chain from the info block section structure automatically. For JSON-LD BreadcrumbList markup, add the script in the component's result_modifier.php.

Cost Estimator Widgets

For repair, construction, and cleaning companies, calculators are the primary lead generation tool.

Client-side calculator — a React or Vue component with calculation logic on the frontend. Parameters (unit prices, coefficients) are stored in a Highload block and loaded via REST API or an AJAX controller. The calculation result is submitted as a CRM lead. Advantage: instant feedback. Disadvantage: the pricing formula is visible in source code.

Server-side calculator — each parameter change triggers a server request via Bitrix\Main\Engine\Controller. The formula stays hidden. Better suited for complex calculations with dependencies (room area to surface type to material quantity to labor cost).

Multi-Branch Support

A company with offices in multiple cities needs a "Branches" info block: address, phone, coordinates, business hours, photos. Services are linked to branches via the BRANCHES property — not every service is available at every location.

On the frontend, city detection uses IP geolocation via ipgeobase or bitrix:main.site.selector. The news.list component filters services by PROPERTY_BRANCHES = current branch ID. The selected city persists in a cookie or session.

Branch maps use bitrix:map.yandex.view for Yandex Maps or a custom Google Maps API integration. Coordinates are stored in the "Map binding" property type.

CRM Integration Pipeline

Every form on the site is a potential lead. Integration with Bitrix24 CRM via REST API:

• Service inquiry → crm.lead.add with source WEB, service binding via a UF field
• Appointment booking → crm.lead.add + calendar.event.add
• Calculator result → crm.lead.add with the calculation in the comment field
• Callback request → crm.lead.add flagged for callback

UTM parameters from the URL pass into the lead via UTM_SOURCE, UTM_MEDIUM, UTM_CAMPAIGN fields — tracking which ad channel brought the client.

Cloud Bitrix24 authenticates via OAuth 2.0 or incoming webhooks. Self-hosted — through the crm module with direct API access on the same server.

Development Stages

1. Analysis and planning (1-2 weeks) — audit of the existing site (if any), service structure, user scenarios, wireframes for key pages
2. Design (1-3 weeks) — UI kit, responsive page layouts, service card design, booking form, calculator
3. Backend development (2-4 weeks) — info blocks, components, CRM integration, forms, calculator logic
4. Frontend development (2-3 weeks) — template markup, interactive components, responsive behavior
5. Content and SEO (1-2 weeks) — content population, META templates, sitemap, robots.txt
6. Testing and launch (1 week) — functional testing, form verification, cross-browser checks

Mistakes We Encounter on Service Sites

• Services as static pages instead of info block elements. Each service is a standalone page in the site structure. No filtering, no sorting, no automated catalog generation. Migration means moving content into an info block and setting up 301 redirects for every URL
• Forms without CRM integration. Submissions land in email and get lost. The sales team has no communication history per client. CRM integration takes 2-3 days of development but pays for itself within a week
• Identical META tags across all services. Search engines treat this as duplicate content. META templates with service name and section substitution are baseline hygiene that's routinely overlooked