A board you draw
A trigger, then steps in series or in parallel, connected with arrows. Every step can use what the earlier ones produced, for example the transcript or the caller's number.
Applications
Operations agent
An operations agent does not talk to people. It runs a flow of actions when something happens: a call ended on your PBX, a webhook arrived, a schedule fired, or you pressed Run. You draw the flow on a board, and every finished call of your voice agents can start it.
What it does
What does an operations agent do?
It turns a finished call into a transcript, a summary and an analysis, delivers them by email and to your systems, and does it reliably: every step is saved, every failure is retried, and every run is visible with what it received and produced.
Transcription of the recording
Downloads the recording your PBX linked, turns it into text with speaker turns, detects the language, and can render it in more languages.
Summary in the style you want
A few sentences, a detailed account or bullet points, in the language you choose, with instructions on what to focus on: orders, complaints, follow-ups.
Insights from your own questions
Prepare the questions that matter to you, such as whether a price was quoted or the customer was satisfied. Each call is answered against them, in an online report and an Excel workbook.
Email reports
Sends your message with the values filled in: the summary in the body, the transcript inline or attached, the report answers and the workbook.
Webhooks to your systems
Posts JSON to a URL of yours at any point of the flow, signed with a secret, with an idempotency key so a duplicate can be dropped. Your endpoint confirms with a 2xx.
The dispatcher
One call can start several agents at once: a router hands the same call to specialised agents and to several webhook addresses, each doing its own job.
Retries you do not have to think about
A remote endpoint that does not answer is tried 24 times, once an hour, until it does. Runs survive restarts: every step is saved as it completes, and a failed step can be retried by hand.
How does a run happen?
A trigger starts the run, the steps execute in order with every result saved, and the run appears under Runs with each step, what it received and produced, and what it cost.
-
Something triggers it
A call ends on the connected PBX, a webhook arrives on the agent's own address, a schedule fires (every hour, every morning, on weekdays, or your own cron expression), another agent calls it, or you press Run.
-
The steps run, in series or in parallel
Several arrows out of one step run together; a step with several arrows in waits for all of them. A condition step continues on the yes or the no branch.
-
Failures wait and retry
A step that fails with attempts left waits for its next attempt and the run continues on its own; the steps after it wait too. A step that used up its attempts is marked failed and can be retried from the run page.
-
You see everything
Every run lists each step on a timeline: how long it ran, the JSON it received and produced, what a remote endpoint answered when it failed, the report and the workbook download.
What is it used for?
Everything that used to happen by hand after a call, and the scheduled housekeeping around it.
Transcript and summary of every call
After each call on your PBX, the front desk receives the transcript and a short summary by email, and the call journal keeps them with the recording.
Quality and compliance checks
Was the customer greeted, was the price stated, was the follow-up promised? Your questions are answered for every call and collected in a workbook.
Feeding your CRM and ticketing
The transcript, the summary and the caller's details are posted to your CRM, your helpdesk or your data warehouse the moment the call ends.
One call, several jobs
A router agent sends the same call to a sales agent, a support agent and a compliance agent; each does its own analysis and delivery.
Scheduled reports
Every morning at 09:00, a run collects yesterday's calls, produces the daily report and emails it to the managers.
Routing by content
A condition checks the summary or the caller's number and sends complaints to one team and orders to another.
Two examples
Example 1
The call ends, the report arrives
A customer calls the sales line on a Yeastar cloud PBX. When the call ends, the PBX journals it and the operations agent starts: it downloads the recording, transcribes it, writes a brief summary, answers three prepared questions (was a quote given, was a callback promised, was the customer satisfied), emails the transcript and the summary to the sales manager with the workbook attached, and posts the transcript as JSON to the company's CRM.
The CRM is down for maintenance. The webhook step retries once an hour until the CRM answers 2xx; the email had already gone out. The run shows both steps, the CRM's own error answer, and the moment it finally succeeded.
Example 2
One call, three specialised agents
A router agent has a Call ended trigger and a dispatcher with three targets: a sales agent that scores the lead and posts it to HubSpot, a support agent that opens a ticket when a complaint is detected, and a compliance agent that checks whether the recording notice was read.
Each target runs as its own agent with its own retries and its own run history, and the router's run shows which targets were delivered. When the sales agent is disabled for the weekend, the other two keep running.
Current integrations
Operations agents start from incoming webhooks and from a Yeastar cloud PBX, and deliver to email, to any HTTP endpoint and to each other.
Yeastar P-Series Cloud PBX
Connected once per project. Every call the PBX journals starts the enabled agents that have a Call ended trigger, with the recording link, the numbers and the duration in the trigger data.
Incoming webhooks
Every agent has its own webhook address. Any system that can post JSON can start a run, and the payload is available to every step.
Schedules
Hourly, daily, weekdays, monthly or a cron expression of your own, in your timezone, with your choice of what happens when the previous run is still going.
Reports and transcripts to up to ten recipients per step, with the workbook and the transcript attached when you ask for them.
Any HTTP endpoint
Webhooks and the dispatcher post signed JSON to your CRM, helpdesk, data warehouse or automation platform, with the retry policy you set.
API and console
Agents, boards, runs, usage and manual retries are all available through the API, and the Runs page shows the same data.
How it works with the other applications
The operations agent is what happens after the conversation. The voice agent and the PBX give it calls to work on, the Contacts application keeps what it finds, and the Calendar can be read and written from a run through the API.
Voice and chat agent
Every finished call of your voice agents, and every call journalled by the PBX, can start operations agents that transcribe, summarise and analyse it.
Contacts
The trigger carries the caller's number; the run can look the contact up, and the call journal keeps the recording next to the person who called.
Calendar
A scheduled run can send tomorrow's appointment list, and a webhook step can create or move bookings through the Calendar API.
See a run on your own recording
Send us a recording and the questions you want answered, and we will show you the transcript, the summary and the report the agent produces from it.