How Aloware Built a Zoom Transcript Agent That Logs CRM Deals in One Emoji
How Aloware used Runbear to build a Zoom Transcript Agent that turns call transcripts into pre-filled HubSpot deals, approved in Slack with a single emoji.
How Aloware Built a Zoom Transcript Agent That Logs CRM Deals in One Emoji
Originally published on the Aloware blog. Republished here with permission.
Aloware is an AI-powered contact center platform used by more than 1,000 B2B sales and support teams. Their reps live in calls. On a typical demo day, a single sales rep might run five back-to-back Zoom sessions — each one generating follow-up tasks, account notes, and CRM entries that need to be logged before the next call starts.
The problem: that logging almost never happened.
The Manual CRM Problem
Sales reps at Aloware were expected to log each demo call in HubSpot — deal name, stage, contract details, attendees, pain points, action items. The full picture.
In practice, after a long demo day, nobody wanted to open HubSpot and fill in eight fields from memory. Calls went unlogged. Deals were created late, or not at all. Duplicate records appeared because reps couldn't tell if a deal already existed. Pipeline reports became unreliable.
The obvious answer was better process: remind reps to log, make it easier, add a template. Aloware had tried variations of this. The behavior didn't change — not because reps were lazy, but because the task was genuinely annoying to do after an hour-long call.
The real problem wasn't discipline. It was that logging a call manually is the hardest thing to do right after you've finished one.
This maps to a pattern we've written about before — the Actions Gap: the gap between having the information and actually executing the update. AI can draft the entry in seconds. But without a system that takes that last step, the draft lives in a chat window and the CRM stays empty.
What They Built
Aloware built a Zoom Transcript Agent on Runbear. The flow:
- A Zoom call ends and a transcript is generated automatically
- The agent processes the transcript — extracting deal name, contact, pipeline stage, contract term, account type, rep name, and a structured summary of attendees, pain points, and action items
- The agent checks HubSpot for existing deals to avoid duplicates
- Within minutes of the call ending, the rep receives a pre-filled CRM deal proposal directly in Slack
No new app. No context switch. The information appears where the rep already is.
The entire build ran on Runbear — no custom code required.
| Step | What Happens | Who Acts |
| 1. Zoom call ends | Transcript generated automatically | Zoom (automated) |
| 2. Agent parses transcript | Extracts 8 HubSpot fields + summary | Runbear (automated) |
| 3. Duplicate check | Searches HubSpot for existing deals | Runbear (automated) |
| 4. Slack proposal sent | Pre-filled deal card delivered to rep | Runbear (automated) |
| 5. Rep approves | One emoji — deal created in HubSpot | Rep (~5 seconds) |
The Approval Loop
The Slack message isn't just a notification. It's a complete decision interface.
The rep sees the proposed deal — all 8 fields pre-filled — and responds with a single emoji:
- Approve — deal created in HubSpot exactly as proposed
- Edit — the rep types a correction in plain English and the agent updates the draft and resubmits
- Reject — no action taken, nothing created

The correction loop is important. The agent doesn't need to be perfect. It needs to be close enough that fixing it takes five seconds instead of five minutes. In practice, most proposals go through without edits. When a rep does correct something, the agent learns the pattern for next time.
The whole interaction takes roughly five seconds. Compare that to the alternative: opening HubSpot, finding the right contact, creating a deal record, filling in eight fields from memory while the details of the call are fading.
This is what we mean when we describe ops automation that doesn't create bottlenecks: the human stays in the loop, but the loop takes seconds instead of minutes.
Smart Routing: Sales vs. Support
Not every call needs a CRM deal entry. Aloware's customer experience and support teams also run Zoom calls — but a support session doesn't belong in the deal pipeline.
The agent handles this with smart routing:
- Sales calls — full CRM flow (8-field deal proposal in Slack)
- CX/Support calls — structured summary only (attendees, issues discussed, follow-ups)
The routing logic reads context from the transcript and the caller's role. Support teams get useful summaries without cluttering the sales pipeline.
Results
The numbers are straightforward:
| Metric | Before | After |
| CRM entries logged per demo | Inconsistent — many missed | Near 100% — auto-processed |
| Fields filled per entry | 0–8 (manual recall) | 8 fields — auto-extracted |
| Time per rep on CRM logging | 5–10 min per call | ~5 seconds (emoji tap) |
| Duplicate deals | Common (reps create blindly) | Eliminated (HubSpot check before creation) |
| Pipeline data reliability | Unreliable — missing records | High — manager confidence restored |
The deeper change is behavioral. Reps no longer think about CRM logging as a task. It happens automatically, and they spend five seconds approving it. Sales managers now have reliable pipeline data without having to chase down incomplete records or deduplicate entries at the end of the week.
As one Aloware sales rep put it:
Before this, logging a call was the last thing anyone wanted to do after long demo days. Now the bot sends me everything in Slack already filled in — I tap one emoji and it's done.
Key Design Decisions
A few things Aloware got right that made this work:
Human-in-the-loop by default. The agent never writes to HubSpot without approval. This isn't a limitation — it's a trust mechanism. Reps adopted the tool quickly because they knew nothing would be created without their say-so.
Conservative AI extraction. The agent extracts only what it can confirm from the transcript. If a field is ambiguous, it flags it rather than guessing. This keeps the correction rate low and prevents bad data from entering the pipeline.
Plain English corrections. The edit flow doesn't require reps to navigate fields or click through a form. They type what they want changed, the same way they'd tell a colleague. This removes the last friction point in the loop.
No custom code. The entire agent was built on Runbear without engineering involvement. The operations team configured it, tested it, and shipped it.
These decisions connect to a broader principle: the three types of ops requests. Type 1 is pure information retrieval. Type 2 is synthesis — pulling context from multiple sources into a structured output. The Zoom Transcript Agent is a Type 2 workflow: read the transcript, look up the CRM, produce a proposal. These are exactly the workflows where AI adds the most value, and where the human-in-the-loop model makes the most sense.
How It Works on Runbear
Runbear is a Slack-native AI platform that connects to your tools and lets you build agents that work inside your existing workflows. For Aloware, that meant connecting Zoom transcripts, HubSpot, and Slack — and configuring the logic that routes between them.
Setup took about 10 minutes. No code, no integration engineering, no new app for the sales team to learn.
The Zoom Transcript Agent is one example of what becomes possible when Slack becomes the interface for every workflow — not just messaging, but approvals, updates, and data entry. By the time a rep reads the notification, the work is already done.
If your team runs demos and struggles with CRM hygiene, this pattern is worth replicating. The transcript is already there. The only question is whether you're using it.
Learn more about building agents on Runbear at runbear.io.
