Developing sales scripts for Bitrix24 CRM

Developing Sales Scripts for Bitrix24 CRM

A sales script in CRM is not a PDF with phrases attached to a deal. It is an interactive tool embedded in the manager's workflow: prompts appear at the right moment, the next step depends on the customer's response, and the card is filled in during the conversation. The difference in conversion rate between a "PDF script" and an embedded script is 15–25% based on real implementation data.

Bitrix24 has no native sales script builder, but a combination of several platform tools makes it possible to build a fully functional system.

Script System Architecture

Built-in Bitrix24 functionality is sufficient for simple scenarios. Complex scenarios require custom development. Choose an approach based on your requirements:

Implementation with Built-in Tools

Business processes as a script. Create a BP that triggers when a deal is moved to the "Call" stage:

1. Shows a notification to the manager with a greeting text and key questions
2. Waits for the manager's action (filling in fields)
3. Based on the filled-in data, advances to the next stage or creates a task

Limitation: Bitrix24 business processes are poorly suited for interactive branching scripts — the UX is too cumbersome.

Card with embedded prompts. Configure the deal card so that fields are arranged in the order of the conversation, with helper phrases in the field descriptions. Technically this is card customization in CRM → Settings → Card Configuration.

Custom Development: Embedded REST Application

A fully interactive script is implemented as a REST application with an embedded page (placement) in the deal card's side panel.

Registering the placement:

CRest::call('placement.bind', [
    'PLACEMENT' => 'CRM_DEAL_DETAIL_TAB',
    'HANDLER'   => 'https://yourapp.com/script-player/',
    'TITLE'     => 'Sales Script',
    'DESCRIPTION' => 'Interactive call script',
]);

The user sees a "Sales Script" tab in the deal card. When opened, your application loads and:

• Retrieves deal data via the Bitrix24 JS SDK
• Displays the appropriate script (based on stage, product type, history)
• When the customer responds, the manager clicks "Yes/No/Thinking" — the script advances to the next branch
• Upon completion, automatically fills deal fields via BX24.callMethod('crm.deal.update', ...)

Script data structure (JSON):

{
  "id": "cold_call_b2b",
  "steps": [
    {
      "id": "greeting",
      "text": "Good afternoon, {contact_name}! My name is {manager_name}, TechnoLab. Is this a good time to talk?",
      "options": [
        {"label": "Yes, go ahead", "next": "pain_discovery"},
        {"label": "No, call back later", "next": "schedule_callback", "action": "create_task"}
      ]
    },
    {
      "id": "pain_discovery",
      "text": "Tell me, how are you currently handling warehouse automation?",
      "fill_field": "COMMENTS",
      "options": [...]
    }
  ]
}

Variables {contact_name}, {manager_name} are substituted from deal data via the JS SDK at render time.

Case Study: Script for a SaaS Company

Task: a team of 12 managers selling B2B SaaS subscriptions. Initial call conversion rate — 8%. Problem: new managers do not know how to handle common objections; experienced managers skip qualification questions.

Implemented solution:

A script with 4 blocks:

1. Qualification (5 questions) → required CRM fields (team size, budget, timeline)
2. Presentation → adapts based on qualification responses (different content for small/medium/large businesses)
3. Objection handling → 12 common objections with recommended responses
4. Closing → next step options with automatic task creation

Script analytics — every step is logged in a custom table linked to the deal. After 6 weeks it becomes clear at which step customers most often drop off and which objection responses work best.

Result after 3 months: initial call conversion rate rose from 8% to 13.5%, onboarding time for new managers dropped from 6 weeks to 2 weeks.

Script Versioning and A/B Testing

Scripts need to be updated — the market changes, arguments become outdated. Implement versioning:

• Each script is stored with a version number and activation date
• Old versions are not deleted — for analysis of which script produced better conversion
• A/B test: half the deals use script v1, half use v2 — compare conversion rates

Without analytics, a script becomes a ritual: "it's written this way, so it must be correct." With analytics, it becomes a living tool that continuously improves based on real data.