All work AI SYSTEMS / CRM AUTOMATION live

02  /  AI SYSTEMS / CRM AUTOMATION

Bitrix24 Outreach Automation

Lead to first email.
Without leaving the CRM.

Research, qualification, drafting and sending run as one chain inside Bitrix24. It stops twice, and both times for a person.

A case study by HM Ammar — Digital Architect & Head of IT, Kuala Lumpur

2026Bitrix24 CRMBitrix local applicationBitrix REST APIBitrix automation rulesGoogle SheetsOpenAI API
5 minbetween a person approving the draft and the email leaving

The challenge

A startup raising a round has to reach investors personally, and each first email has to read as though it were written for that fund. Finding a name is easy; the first personalised email is where outreach stalls. Normally the work is spread across a research tool, a spreadsheet, the CRM and an inbox, with a person carrying every prospect between them. Automated badly it is worse than doing it by hand, because a wrong detail reaches a real investor and cannot be recalled.

What I built

I built the chain end to end, and Bitrix24 runs it from the deal onward. An automation researches investors who fund startups and writes what it finds into a Google Sheet; a person checks the details there and moves the rows that pass into a separate sheet wired to the CRM, where arrival creates the deal and its contact card. From there Bitrix does the rest: an AI step researches the prospect through the OpenAI API and writes a personalised first draft, which is read and approved on the card itself, inside a local application I built into the portal. Five minutes after approval the email is sent, the deal moves to the next stage, and the tasks that follow a first email are created for the humans.

How it works

AUTOMATED HUMAN HUMAN Researchfinds investors, writes a sheet The sheet gatedetails checked, rows moved Deal createdarrival makes the card AI draftsOpenAI writes the email On the carda person approves Five minutes to change your mind Then: sent, stage advanced, follow-up tasks raised consequences of the send, not buttons anyone presses
The mechanism, drawn from the build.

The detail

01

The sheet gate

Everything upstream of the CRM is research, and research is where the mistakes are. So I made the sheet the automation writes into deliberately separate from the sheet that feeds Bitrix. A person reads the rows there, corrects what is wrong, and moves across only what passes. Crossing that line is the instruction: arrival in the connected sheet creates the deal and its contact card, without anyone opening the CRM to type it in. What reaches the pipeline is a prospect somebody has agreed to.

02

On the card

The review surface is not a separate tool with a link back to the CRM. I built it as a Bitrix local application, registered to the portal and rendered in place on the record, so the draft is read beside the prospect it was written about. A reviewer opens a deal and the email is there. The sheet is the facts: are the details right. The card is the words: is this the email we want this prospect to receive. Everything between them runs without anyone watching it.

03

The five minutes

Approval does not send. Five minutes pass first, and the delay is the point. It keeps the decision and the irreversible act apart rather than letting the same click do both, and I put it there precisely because the rest of the path is fast enough to leave no other place to stand. A window for someone who approved and then thought again. The quietest checkpoint, and the cheapest one to keep.

04

After the send

A first email is not the end of anything. The deal moves itself to the next stage as the message goes, and the work that has to happen afterwards is raised as tasks for the people who have to do it. Neither is a button someone remembers to press; both are consequences of the send. The system does not only send, it hands back.

05

Undocumented behaviour

Bitrix's REST API is documented in outline and undocumented where it matters, and I have spent a long time at that edge. A greater-than-or-equal filter on the update timestamp is accepted and then quietly ignored, so a query that reads like it is narrowing returns everything. A boolean field written as a number stores the negative of what was intended, without complaining. Records that share a timestamp cannot be told apart by it at all. I established each of those by running against a real portal and reading what came back, because the alternative is building on an assumption that fails silently.

The outcome

It is live, sending real emails to real prospects for a startup raising a round. What changed is the shape of the work rather than a figure anyone measured. From finding a prospect to sending the first personalised email, nobody carries a record between systems by hand. A deal exists because a row crossed a boundary. A draft exists because a model read the prospect, and the email leaves because a person read the draft. I have the CRM automated up to the first stage, and the human steps that remain are the judgement ones: checking the research, reading the draft, saying yes. A voice agent is the next piece I want to build, so more of the process can run the same way. That part is planned, not built.