Sales Automation with OpenClaw: How We Built an AI-Operated Business Development Department
Sales automation can extend far beyond email sequences. At Stob.AI we treat it as an operating-system problem, combining OpenClaw, Make, Airtable, Apollo and Exa into one connected business development system.
Many sales automation projects begin and end with an email sequence.
A contact enters a campaign, several messages are scheduled, and a dashboard reports how many emails were opened or answered.
That can save time, but it leaves much of the real work untouched.
Someone still has to decide which companies are worth contacting. Someone has to research the account, find a relevant reason to approach it, identify the right person, check whether they already exist in the CRM, prepare the message, monitor replies, create the opportunity and assemble the report.
The expensive part of sales operations is often the movement of context between people, applications and documents.
At Stob.AI, we approached sales automation as an operating-system problem.
We built a connected business development system that brings together OpenClaw, Make, Airtable, Apollo, Exa, Instantly, HeyReach, Zoho CRM and Google Workspace.
The system supports a team of 17 people at Lumens. It handles prospect research, enrichment, campaign preparation, CRM synchronisation, reply processing, lead reactivation, reporting, event research and RFP standardisation.
The team remains responsible for strategy, approvals, relationships and commercial decisions. The system handles the repetitive movement of information.
Our simplest explanation is:
Make watches. OpenClaw works. Airtable remembers.
Why sales automation projects become fragmented
Business development teams rarely suffer from a complete lack of software.
They may already have a CRM, a sales intelligence platform, an email sequencer, a LinkedIn tool, shared spreadsheets, Drive folders and reporting dashboards.
Each product solves a specific problem. The fragmentation appears between them.
A salesperson finds a promising company in one system and copies it into another. They search the company website, check LinkedIn, look for a recent announcement and write a note explaining why the account may be relevant.
They then add a contact to an outreach platform, record some of the activity in the CRM and wait for a response.
If the prospect replies through another channel, the context may remain inside an inbox or LinkedIn conversation. A manager may only discover the opportunity when someone mentions it in a meeting.
Reporting then becomes a reconstruction exercise. The team has to compare the CRM, outbound platforms, inboxes and spreadsheets to understand what happened.
Each handoff creates three risks:
The first is delay. Work stops until someone manually moves the information.
The second is context loss. The reason an account was selected may never reach the person writing the message.
The third is inconsistency. Two people may process the same situation differently because the business rules live in their heads rather than inside the system.
A useful sales automation architecture has to address all three.
From isolated automations to a business operating system
A conventional automation follows a predefined sequence:
Trigger, filter, action, update.
That pattern is excellent for predictable work.
For example, when an approved Airtable contact has a work email and belongs to a particular campaign, Make can add that contact to Instantly.
The inputs are known. The conditions are known. The destination is known.
Other sales tasks are less predictable.
Consider this request:
Find a recent commercial signal for this company, determine whether the signal is relevant to our services, identify the appropriate contact, add the evidence to Airtable and prepare a personalised campaign record.
The goal is clear, but the route may vary.
The system may have to search several sources, inspect a company website, compare job titles, interpret an announcement and decide which information is credible enough to retain.
That requires an agentic layer alongside the deterministic workflow layer.
The operating model therefore becomes:
Instruction, rules, agent, actions, memory, reporting.
The instruction describes the desired outcome. Business rules define the boundaries. The agent performs the variable research or interpretation. Connected applications carry out the actions. Airtable records what happened. Reporting turns the activity into management information.
This model is central to the updated Stob.AI architecture.
The three layers of the Stob.AI sales automation system
The system has three main layers.
Make provides reliable execution
Make runs the predictable parts of the operation.
It watches for new records, receives webhooks, checks conditions, moves information between systems, creates or updates records, calls APIs and sends notifications.
Make describes its platform as a visual environment for building workflows and AI agents across thousands of applications. In this architecture, its most important contribution is controlled orchestration.
When an Instantly reply arrives, Make knows which stages must happen next.
When an eligible contact appears in Airtable, Make knows which campaign should receive it.
When an RFP is attached to an opportunity, Make knows which record to retrieve, where the file should be stored and which structured job should be sent to OpenClaw.
These are processes that should behave consistently every time.
OpenClaw and Codex provide agentic execution
OpenClaw is the gateway and conversational interface for the agent.
Its official documentation describes it as a self-hosted gateway that connects chat applications, including Google Chat and Slack, to AI agents. In our implementation, OpenClaw runs with Codex and has controlled access to the applications used by the business.
Codex provides the reasoning and execution capability. OpenClaw provides the persistent gateway, channels and tool access.
Together, they can research, interpret, personalise and take action across connected applications.
This agent layer has two distinct execution paths.
Airtable provides control and memory
Airtable is the central operational hub.
It contains the companies, contacts, campaigns, touchpoints, opportunities, owners, templates, prompts, exclusions and workflow statuses used by the system.
Airtable describes its platform as a digital operations environment for connecting data and workflows. That is how we use it here.
The team can see the state of the operation without entering every Make scenario or outbound platform.
They can approve records, change an owner, pause a contact, update a campaign, review an opportunity or override an automated decision through the Airtable interface.
The two ways OpenClaw operates inside the system
Understanding the two OpenClaw paths is essential because they serve different business needs.
Path one: OpenClaw as a promptable operator
In the first path, a person speaks directly to OpenClaw through Google Chat or Slack.
A business development manager might write:
Find a current buying signal for this company. Add the evidence and source to Airtable, identify the best contact and prepare a personalised outreach angle. Do not send the campaign.
OpenClaw interprets the instruction and chooses the appropriate tools.
It may use Exa to search and retrieve current web information. Exa provides search, crawling, content extraction and research capabilities designed for AI applications.
It may then use Apollo to find or enrich a relevant B2B contact. Apollo provides prospecting, sales intelligence and contact enrichment capabilities.
OpenClaw can compare the available contacts, add the selected person to Airtable, record the signal, save the source and create a concise personalisation note.
The user does not need to specify every API call or every field update. They describe the outcome and the guardrails.
This mode is most useful when a human initiates the work and the exact research path may vary.
Examples include:
- Investigating a company before a meeting
- Finding commercial signals across a target account list
- Preparing a campaign for review
- Identifying opportunities without a next action
- Producing an account summary
- Answering a management question across Drive and Airtable
The conversation is the interface. The connected systems remain the place where the work is recorded.
Path two: OpenClaw embedded inside a Make workflow
In the second path, OpenClaw operates as a component inside a larger automated process.
Make sends OpenClaw a structured job through HTTP. The payload contains the context, task, boundaries and expected output.
OpenClaw completes the work and returns the result to the workflow, often through a webhook.
This path is useful when the trigger and surrounding process are fixed, but one stage requires interpretation or flexible execution.
The RFP workflow is a clear example.
An RFP enters through an Airtable opportunity. Make retrieves the record, downloads the source file, places it in the correct Drive structure and prepares the job.
Make then sends OpenClaw a structured instruction. The instruction tells it which approved template to duplicate, which uploaded RFP to analyse, where the finished document must be stored and which webhook should receive the final document details.
OpenClaw reads the material, follows relevant links inside the source where necessary, flattens the inconsistent RFP into the approved company format and returns the completed document.
Make then attaches the standardised RFP to the Airtable opportunity and notifies the relevant owner by email and Google Chat.
The workflow remains deterministic around the agent.
Make controls the trigger, file movement, record updates and notifications. OpenClaw performs the part that requires document understanding and judgement.
Why both OpenClaw paths are needed
Prompted operation and workflow-embedded operation solve different problems.
Prompted operation gives people flexibility. A user can request a result without waiting for someone to design a new Make scenario for every variation.
Embedded operation gives the business repeatability. The agent becomes a controlled stage inside a process that runs whenever a defined event occurs.
A useful rule is:
Use prompted OpenClaw when the goal is known but the path may change. Use embedded OpenClaw when the surrounding process is fixed but one stage requires judgement.
This division allows the system to remain flexible without turning every activity into an unrestricted autonomous action.
Why Airtable is the business control room
The quality of the workflows depends heavily on the quality of the data model.
A sales automation system has to understand more than names and email addresses.
It needs to know whether a contact is new, active, replied, qualified, stale, excluded or opted out. It needs to know which campaign owns the contact, which person owns the relationship, which channels have been used and which actions have already occurred.
In practice, sales automation is partly a state-management problem.
Airtable stores that state.
A company can be linked to several contacts. A contact can be linked to a company, campaign, owner, touchpoints and opportunities. A campaign can hold the activity and performance data required for reporting.
Templates and AI prompts can also be stored centrally. This allows the team to update operational instructions without rebuilding the entire workflow.
Airtable therefore performs three functions at once.
It is the shared database.
It is the management interface.
It is the control surface for the automation.
The owner can influence workflow behaviour through statuses, campaign fields, approval values and exclusions rather than editing code. The updated design includes companies, contacts, campaigns, touchpoints, opportunities, users, templates, AI prompts, exclusions and system logs.
How the closed-loop sales automation works
The best way to understand the system is to follow one contact through it.
A contact or company enters the operation
New records can originate from Apollo, Zoho, LinkedIn, a web form, a manually selected account or a request made through OpenClaw.
When a new Apollo contact is detected, the system examines the associated company and carries out an initial background check.
It then searches Airtable to determine whether the company and contact already exist.
This matters because duplicates create conflicting ownership, repeated outreach and unreliable reporting.
The system updates an existing master record where appropriate or creates a new linked company and contact.
Research creates a reason to act
Contact data alone provides limited context.
A good record should answer why the company is relevant now.
Exa and OpenClaw can search for signals such as new events, expansion, hiring, product announcements, partnerships, funding, venue activity or other commercially relevant changes.
The research is retained with a source.
This helps the team distinguish between genuine evidence and generic AI-generated personalisation.
A useful personalisation field should therefore contain three things:
- The signal.
- The evidence.
- The relevance to the proposed outreach.
OpenClaw can prepare this information, but Airtable keeps it visible and reviewable.
Eligibility rules govern campaign entry
The system does not treat every contact as ready for outreach.
Before a record enters an Instantly or HeyReach campaign, Make evaluates the required conditions.
For example, the contact may need to have a "New" status, belong to the "Outbound" campaign and contain a valid work email.
Further controls can include exclusions, owner assignment, opt-out status, previous activity and approval fields.
The uploaded outbound scenario searches Airtable for contacts meeting specific campaign, status and email conditions before moving them forward.
This is an important distinction between automated activity and governed automation.
The system only moves a record when the data says it should move.
Outreach is prepared across email and LinkedIn
Eligible contacts can be sent to Instantly for email activity or HeyReach for LinkedIn activity.
The record carries the relevant context with it, including the contact name, company, owner, campaign and personalisation.
Email and LinkedIn are managed as connected channels rather than separate lists.
When a LinkedIn connection is accepted, the system can retrieve the lead details, check the available email and enrich the contact through Apollo where required.
The result returns to the same Airtable record.
This preserves a unified view of the relationship.
Replies become structured business events
Many outbound systems focus heavily on sending.
The reply process is where much of the commercial value appears.
When a reply arrives through Instantly or HeyReach, it enters Make through a webhook.
The incoming payload may be inconsistent. Email webhooks can contain several addresses, quoted messages, signatures, HTML and event metadata.
The workflow first normalises that information.
It distinguishes the external prospect from the internal sending account, extracts the reply, preserves the relevant identifiers and determines whether the event represents an outbound send or an inbound response.
The reply can then be classified as interested, neutral, not interested, opted out, out of office or bounced.
Once the meaning is known, the system writes the outcome back to Airtable.
The response becomes a touchpoint linked to the contact, company and campaign. The contact status is updated, and relevant information can also be synchronised with Zoho CRM.
When the reply indicates genuine interest, the workflow can create an opportunity and alert the appropriate manager.
A low-intent or negative reply still has value. It updates the contact history, prevents inappropriate follow-up and improves the quality of future reporting.
The email and LinkedIn reply workflows therefore turn loose inbox activity into structured follow-up.
The reporting loop closes the system
A closed-loop sales automation system needs to record outcomes as well as actions.
HeyReach campaign statistics are written back to the Airtable Campaigns table. The data model includes prospect counts, contacted counts, replies, reply rates, bounces, unsubscribes, completed contacts and total opportunities.
For Lumens, the Opportunities table acts as a commercial scoreboard.
A manager can see where the opportunity came from, which company and contact are involved, which campaign created it, who owns it and what has happened since.
OpenClaw also has access to Google Workspace through gog in this implementation.
That means a user can ask for a report through Google Chat or Slack, and OpenClaw can gather relevant context from Drive, calendars, campaigns and opportunities according to its permissions.
A management request might be:
Summarise this month's outbound activity, list the opportunities created, identify interested replies without a next action and prepare the management report in Drive.
This replaces the manual process of opening several platforms and reconciling the information.
Sales automation beyond outbound campaigns
Once the control layer exists, the same architecture can support processes outside conventional sales outreach.
The pattern remains consistent:
Trigger, gather context, interpret, standardise, update and notify.
RFP standardisation
RFPs arrive in different formats, with different terminology and different levels of detail.
The Lumens workflow converts that incoming material into an approved internal template.
The original document remains available, while the standardised version gives the team a consistent structure for review.
The workflow also creates or updates the relevant Drive folder, attaches the output to the opportunity and informs the owner.
This is an example of OpenClaw embedded inside a workflow rather than initiated by a human prompt.
Event website research
The event web-research workflow supports the production and event team.
A team member provides an event website through an Airtable record.
Make retrieves the page, and the system extracts information such as the event name, date, location and organiser details.
Missing information can be written back to Airtable. The workflow then selects the appropriate owner-specific template and AI prompt, drafts the email and records the output.
This removes a repetitive sequence of opening websites, copying fields, finding templates and rebuilding similar emails.
Lead reactivation
Existing CRM data often contains contacts that have not been approached recently.
The reactivation workflows retrieve stale Zoho leads and contacts, check their current Airtable status and return eligible records to a controlled reactivation campaign.
This creates a repeatable process for using existing data without ignoring opt-outs, qualified contacts or other exclusions.
Invoices and operational administration
The same architecture can also support invoice and finance-administration workflows.
Airtable provides the record and approval state. Make manages the fixed stages. OpenClaw handles document interpretation or irregular requests where appropriate.
The value comes from reusing the same control model rather than designing every department as a separate automation project.
What this changes for a 17-person team
The system is designed to support different roles without requiring everyone to work inside every application.
The sales team uses it for lead intake, enrichment, outbound activity, replies and reactivation.
The production and event team uses it for website research, missing-field completion and personalised communication.
Management uses the opportunity data, campaign reporting, Drive context and notifications to understand what requires attention.
The team reviews, approves, responds and closes.
The system performs research, handoffs, updates and reporting.
This creates leverage without removing human ownership.
The operating model and role allocation are reflected in the revised Lumens presentation.
Guardrails make capable automation usable
An agent that can read business data and act across applications needs defined boundaries.
OpenClaw should receive access according to role and need. A reporting agent may require read access across Drive and Airtable while having no authority to send a campaign.
Sensitive communications can remain in a draft or paused state until someone approves them.
Opt-outs and do-not-contact rules should be enforced centrally, not separately inside each outreach platform.
Every opportunity and exception should have a human owner.
Actions should be logged so the team can understand what happened and investigate unexpected outcomes.
The system should also have a clear exception path for missing data, failed API calls, ambiguous replies and unusual records.
More capable automation increases the importance of permissions, ownership and visibility.
How to begin building a sales automation system
The best starting point is usually one repeated handoff.
Look for a process where information moves between several tools and where the final outcome is easy to define.
Reply processing is often a strong candidate because the trigger is clear, the data already exists and the business outcome is valuable.
Lead enrichment, website research, CRM synchronisation, RFP intake and weekly reporting can also work well.
The first stage is to map the current process accurately.
Identify where information begins, who touches it, which decisions are made, where delays occur and what a completed result looks like.
The next stage is to define the central data structure.
Decide how companies, contacts, campaigns, touchpoints and opportunities relate to each other. Define the statuses and fields that control movement.
Then separate deterministic work from agentic work.
Use Make for steps that should always follow the same rules. Use OpenClaw where research, interpretation or a flexible sequence of actions is required.
Finally, build the return path.
Every action should write its result into the shared system so the next workflow and the next person have the correct context.
That return path is what turns several connected tools into a closed-loop operation.
The opportunity for business owners
Sales automation has developed far beyond scheduled email sequences.
A connected system can receive an instruction, apply business rules, conduct research, update records, prepare outreach, capture responses, create opportunities and maintain reporting.
The practical benefits are straightforward:
- Less time spent copying information.
- Faster movement from signal to action.
- More consistent follow-up.
- Better visibility for managers.
- More useful CRM data.
- Clearer ownership.
The tools already exist.
The more difficult work is designing the operating model, data structure, permissions, prompts and exception handling that allow them to function as one system.
That is the work we do at Stob.AI.
You can explore our AI automation services, view our automation case studies, browse our free automation resources, or read more practical guides on the Stob.AI blog.
For another practical OpenClaw implementation, see our guide to building a LinkedIn content engine with OpenClaw and Codex.
To see the sales system in action, see how we install it in 45 days.
Frequently asked questions
What is sales automation?
Sales automation uses software to complete repeated sales tasks, apply business rules, move data between applications and maintain records without requiring someone to perform each step manually.
Advanced sales automation can also use AI agents for research, interpretation, personalisation and flexible task execution.
What is OpenClaw?
OpenClaw is a self-hosted gateway that connects chat applications such as Google Chat and Slack to AI agents and connected tools.
In the Stob.AI implementation, OpenClaw runs with Codex and can work across Airtable, Exa, Apollo, Instantly, HeyReach and Google Workspace according to the permissions it has been given.
How does OpenClaw work with Make?
OpenClaw works with Make in two ways.
A person can prompt OpenClaw directly through Google Chat or Slack, allowing it to act across connected applications.
Make can also send OpenClaw a structured job through HTTP as part of a workflow. OpenClaw completes the agentic stage and returns the result so Make can continue the process.
Does OpenClaw replace Make?
They have different responsibilities.
Make runs deterministic processes based on triggers, filters and mapped actions.
OpenClaw handles tasks where the goal is defined but research, interpretation or flexible execution is required.
Using them together allows predictable processes to include bounded agentic work.
Does OpenClaw replace Airtable or a CRM?
OpenClaw acts as an interface and execution layer.
Airtable remains the central source of operational data, workflow controls, ownership and reporting. Zoho can remain synchronised where required.
The agent reads and updates those systems rather than replacing their structured records.
Can OpenClaw be used for sales prospecting?
OpenClaw can support account research, buying-signal discovery, contact selection, enrichment, personalisation and campaign preparation.
The quality of the result depends on the connected data sources, prompts, permissions and approval rules.
Can sales automation manage replies?
Email and LinkedIn replies can be received through webhooks, normalised, classified and linked to the correct contact.
Interested replies can create opportunities and manager notifications. Negative replies, opt-outs and out-of-office responses can update the contact state and follow-up logic.
Can the same system automate RFPs and reporting?
Yes.
The Lumens implementation uses a Make and OpenClaw workflow to convert inconsistent RFPs into a standard template.
OpenClaw can also access authorised Drive, calendar, campaign and opportunity information through gog to support reporting requests.