# Bitrix24 Outreach Automation *Outreach that sends itself is the easy version. This one waits for a person, then waits five minutes.* **Category:** AI SYSTEMS / CRM AUTOMATION **Status:** live **Period:** 2026 **Built by:** HM Ammar, Digital Architect & Head of IT, Kuala Lumpur **5 min** — between a person approving the draft and the email leaving **Stack:** Bitrix24 CRM, Bitrix local application, Bitrix REST API, Bitrix automation rules, Google Sheets, OpenAI API ## 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. ## The detail ### 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. ### 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. ### 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. ### 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. ### 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. --- [All work](https://hmammar.world/) · [HTML version](https://hmammar.world/work/bitrix-outreach.html)