AI CRM
Use an AI SDR with Salesforce today: three patterns
By Asen Levov, co-founder of Sellinger. Published . Last updated . 8 minute read.
Sellinger does not have a built in Salesforce connector yet. Salesforce, Pipedrive and Zoho are shown as coming soon on the integrations page, with no date, and HubSpot is the CRM with two way sync today. You can still use an AI SDR with Salesforce. There are three ways, and each trades effort for control.
This post describes them plainly, including what each one cannot do, so that you can choose one without waiting for a connector.
What is the starting point?
Sellinger has its own CRM: contacts, deals and the full conversation history across channels. The agent researches each prospect, writes the first message and every follow up, answers the replies and books the meeting. A campaign can run in approval mode, where every message waits for a person to approve it.
Salesforce, in most teams, holds accounts, opportunities and the sales process after a meeting is booked. The question is how a meeting booked by the agent gets there, and how much of the conversation travels with it.
Pattern 1: split the roles and hand over by a routine
How it works. Sellinger owns everything up to a booked meeting. Salesforce owns everything after. Once a week, or each morning, someone reviews the meetings booked in Sellinger and creates or updates the Salesforce records by hand, pasting in the context that matters: who they are, what they asked, what was agreed.
Good for. Small teams, a pilot, and anyone who wants to see the work before automating it.
Cost. A few minutes per meeting. It does not scale past a few dozen meetings a month.
Limits. The handover depends on a person. Write a short checklist for it: company, contact, source channel, first reply, what they asked, the booked time.
When to choose it. When you are testing whether the AI SDR produces meetings you want. Do not build an integration before you know.
Pattern 2: push booked meetings with the REST API and webhooks
How it works. Sellinger has a REST API with webhooks from the Full Stack bundle up. A small service of your own receives the event when something changes, for example a meeting is booked, and writes a record into Salesforce using Salesforce's REST API. API keys on the Sellinger side are stored only as hashes, can be revoked or set to expire, and carry per minute and per day limits.
Good for. Teams with a developer or an automation specialist and a clear idea of which fields matter.
Cost. Build time, plus maintenance when either side changes. You choose the mapping, the duplicate rule (match on email, or on company and name) and what to do when a record already exists.
Limits.
- Check the webhook documentation for the events that exist today; do not assume an event for every change.
- A webhook can fail or arrive twice. Your service should be able to repeat safely, so a repeated event does not create a second record.
- Decide who owns a lead that already exists in Salesforce as a customer or an open opportunity. An outreach agent should not message an existing customer by accident. Keep an exclusion list and import it as suppression.
When to choose it. When you have a steady volume of meetings and the handover has become the slow part.
Pattern 3: review through an assistant and update by hand
How it works. The hosted MCP connector exposes 43 tools to Claude and ChatGPT. A person asks the assistant in plain language: which meetings were booked this week, what did each person say, which replies need a decision. The person then updates Salesforce with what they decide. The assistant saves the digging and the summary, and a person remains the one who writes to the system of record.
Good for. Sales managers who want a weekly review, and who prefer to decide what enters Salesforce.
Cost. Low. No development.
Limits. It is not automation: nothing flows into Salesforce by itself. Check what the connector can change before you connect it, and prefer the narrowest access that does the job. See MCP server vs API for the trade off.
When to choose it. When the question is "what happened?" more than "make the record appear".
Which pattern fits which team?
| Situation | Pattern |
|---|---|
| A pilot with fewer than 30 meetings a month | 1 |
| Steady volume, a developer available | 2 |
| A manager who reviews weekly and decides what to log | 3 |
| You already use HubSpot as well | Consider the HubSpot sync as the CRM for outreach |
If you run HubSpot alongside Salesforce, the two way HubSpot connection is the only built in one today. How HubSpot and Salesforce work together is a matter for HubSpot's documentation, and we do not describe it here.
What should you not do?
- Do not wait for a connector. It is listed as coming soon, with no date.
- Do not copy the whole conversation into Salesforce. Put in the summary and a link, not every message.
- Do not let two systems send. Salesforce flows that email prospects and an AI SDR that messages the same people will collide. Decide which one speaks.
- Do not skip opt outs. When someone opts out in Sellinger, the contact goes on the suppression list and the agent stops. Make sure the opt out reaches Salesforce, so no one in sales writes to them by hand.
A first month plan
- Week 1: pattern 1. Write the handover checklist and use it each morning.
- Week 2 and 3: note how long the handover takes and which fields you actually use.
- Week 4: if the handover is the bottleneck, scope pattern 2 around those fields only.
- At any point: use pattern 3 for the weekly review.
You do not need a native connector to start. You need to know which meetings you want, where they should go and who is responsible when the two systems disagree. When a native Salesforce connector ships, the habits above still apply, and what you learned about the fields will make setting it up faster. See can AI replace Salesforce or your CRM for the bigger question.
What does a good handover record contain?
Whichever pattern you use, decide the fields before you start. A handover that carries too little makes sales ask again, and one that carries everything gets ignored. Seven fields cover most teams.
- Person and company, with the LinkedIn address or email so the record can be matched later.
- Source channel, so you can see which channel produced the meeting.
- First reply, in one or two lines, in the person's own words where you can.
- What they asked, for example price, timing or a feature.
- What was agreed, including the booked time and time zone.
- Owner, the person in sales who takes it from here.
- Link back to the conversation in Sellinger, so anyone can read the full thread.
Add one rule for conflicts: if the person already exists in Salesforce as an open opportunity or a customer, the record goes to the account owner for a decision and the outreach stops. That single rule prevents the most embarrassing mistake, which is a cold message to someone your colleague spoke to yesterday.
How do you measure whether the setup works?
Count two things each week: meetings booked in Sellinger and meetings that appear in Salesforce with the right owner. The gap between the two is your handover loss. If it is zero, leave it alone. If it is more than a few percent, the cause is usually a missing owner or a duplicate rule, not the AI SDR.
Common questions
Does Sellinger integrate with Salesforce?
Which CRM does Sellinger connect to now?
What is the safest first step?
Do I need a developer for pattern 2?
Will a native Salesforce connector come?
How Sellinger helps
Read how it works on See Sellinger integrations, or see a real campaign in Read the Sellinger case study.