How to Build an AI SDR Workflow (Without an Integration Project)

An AI SDR workflow is not a model with a signature. It is a loop: pick a lead, personalize, send, log, track the reply, move the pipeline forward, repeat. Here is the whole loop, stage by stage, with the decisions that matter at each one.

Stage 1: The list is the strategy

Automation amplifies whatever you point it at. Before any AI touches anything, the working set should be a CRM list view with a clear definition, like "SQLs (sales-qualified leads) untouched for 14+ days" or "applications started, not finished." The workflow's job is to drain that list, and its progress should be measured against it. If you cannot name the list, you are not ready to automate it.

Stage 2: Templates with merge discipline

Personalization at volume is a template plus reliable merge data (the fields the template pulls in: first name, company, deal amount). Read those from the record itself, not a stale export. Two rules you cannot skip:

• A fallback for bad data. When the name field holds ";-," or a company name, the merge must fall back to something human, like "Hi there." Never ship the junk.
• Per-attempt templates. Touch two is not touch one with a different date. Map each attempt number to its own message, and let the system pick based on contact history.

Then A/B test the subject line and let reply rate, not taste, choose the winner.

Stage 3: Guardrails before speed

The guardrails are the workflow. Configure them before the first live send:

• Dry run: a full pass that fills everything and sends nothing. Watch it work three records; you'll trust it or fix it.
• Pacing: a randomized delay range between sends. A steady robotic rhythm is how domains get flagged.
• Dedupe window: skip anyone touched in the last N days, enforced on the server so it holds across devices and teammates.
• Opt-out compliance: read the CRM's own do-not-contact fields on every pass. This is the guardrail you never turn off.
• A daily cap that lives in a database, not a browser.

Stage 4: Execution in the CRM, not beside it

The biggest fork in the road (covered fully in the architecture guide): execute through API integrations for sales, where programs trade data through a service door, or execute browser-native inside the CRM session, on the same screens a rep uses. For most teams the in-session model wins on speed to value. There is no OAuth review (the formal app-approval process), no field-mapping project, and the agent inherits your org's real validation rules because it uses your org's real screens. The agent should log its work as it goes: the send, the note, the status change. The CRM record then tells the story without anyone typing it.

Stage 5: Reply tracking closes the loop

Without reply state, the loop is open and the automation is dangerous. Touch three goes to someone who already said yes to touch one. The workflow needs webhook email tracking. A webhook means the mail service pings you the moment something happens, instead of you checking on a timer. Each event is signature-verified, handling the same event twice changes nothing, and replies are matched to the exact outbound send by hidden email headers. That single piece of email synchronization for CRM is what lets the workflow decide "stop the sequence, a human takes it from here" in seconds instead of on the next timed check.

Stage 6: Let the pipeline update itself

Every send should move the record's stage one step along an order you define (attempt 1 → attempt 2 → application out). It should never move a record whose current stage is not in that order. This is the difference between automated sales outreach and automated pipeline chaos: one step forward, only on confirmed sends, with an audit trail.

Stage 7: Read the one honest metric

Opens over-count because mail apps pre-load images. Clicks mislead. Sends are vanity. Rank subjects, templates, and people by reply rate. If your tracking can't produce reply rate per template per person, go back to stage 5.

The build-vs-buy math

Everything above is buildable: an email API for sync, a Postgres database with row-level security for state (the database itself checks who owns each row), a browser extension for execution, and a webhook endpoint with HMAC verification (a tamper-proof signature check) for replies. Budget honestly. The reply-matching edge cases and CRM-layout drift are where the weeks go, and they never stop coming. The alternative is a product that ships the loop assembled.

Related: The architecture behind the modern AI SDR · AI CRM vs. CRM automation software