DEV Community: jareer nauman

Writing Back to HubSpot, Salesforce, and Zoho Without Creating Duplicate Contacts

jareer nauman — Mon, 12 Oct 2026 09:25:32 +0000

Most "CRM automation" I get asked to fix is a form that emails the office, plus a person who pastes it into HubSpot. The CRM then reports whatever the last person typed. Ads, the website, the phone line, and the invoice system each tell a different story about the same customer.

The job of an integration is to make one record the source of truth. Which CRM you use matters less than whether the lead source, stage, and revenue survive from first touch to paid job.

Everything below goes through each platform's official API under OAuth. The difference between a fragile sync and one staff actually trust is not the API. It's how you use it.

The write-path: four steps, in order

A working integration does four things every time an event comes in:

Identify. Match on email, phone, or CRM id so you don't create a duplicate on every form submit.
Create or update. Map to the fields staff already use, including source, campaign, and landing page.
Advance. Move the stage when the real-world event happens (booked, quoted, invoiced), not whenever a zap fires.
Write back. Send the money event to ads or analytics, so bidding optimizes for jobs, not thank-you pages.

If staff still open the CRM to re-type the form, the automation didn't ship. It created a second inbox.

The examples below use a thin crm adapter. In practice there's one implementation per vendor (HubSpot, Salesforce, Zoho), each wrapping the official API. The logic around it stays the same across all three.

Step 0: make retries harmless

Form vendors, telephony providers, and payment webhooks all retry. If your handler isn't idempotent, one lead becomes three contacts.

import hashlib
import json

import redis

r = redis.Redis()

def idempotency_key(payload: dict) -> str:
    # Hash the fields that identify this submission, not the whole body.
    # Some vendors add a delivery timestamp on retry, which would change the hash.
    identity = {k: payload.get(k) for k in ("form_id", "email", "phone", "submitted_at")}
    raw = json.dumps(identity, sort_keys=True)
    return "lead:" + hashlib.sha256(raw.encode()).hexdigest()

def handle_lead(payload: dict, crm) -> str:
    key = idempotency_key(payload)

    # SET NX: only the first delivery claims the key.
    # 24 hours covers the retry window of most vendors.
    if not r.set(key, "processing", nx=True, ex=86400):
        return r.get(key).decode()  # already done, or in flight

    try:
        contact_id = upsert_contact(payload, crm)
    except Exception:
        r.delete(key)  # release so the next retry can try again
        raise

    r.set(key, contact_id, ex=86400)
    return contact_id

Step 1 and 2: identify, then upsert

Normalize before you match. John@Example.com and john@example.com are the same person, and so are three different phone formats.

import phonenumbers

def normalize_email(email: str | None) -> str | None:
    return email.strip().lower() if email else None

def normalize_phone(phone: str | None, region: str = "US") -> str | None:
    if not phone:
        return None
    try:
        parsed = phonenumbers.parse(phone, region)
        return phonenumbers.format_number(parsed, phonenumbers.PhoneNumberFormat.E164)
    except phonenumbers.NumberParseException:
        return None

def upsert_contact(payload: dict, crm) -> str:
    email = normalize_email(payload.get("email"))
    phone = normalize_phone(payload.get("phone"))

    existing = crm.find_contact(email=email) or crm.find_contact(phone=phone)
    incoming = map_fields(payload)  # vendor field names -> your CRM properties

    if existing is None:
        return crm.create_contact(incoming)

    update = build_update(existing, incoming)
    if update:
        crm.update_contact(existing["id"], update)
    return existing["id"]

Protect the source fields

This is the bug that quietly breaks reporting. A lead clicks a Google ad, books through the voice agent, and then a receptionist edits the record and sets the source to "phone." Last write wins, and the ad click is gone.

Phone is a channel. It isn't a campaign. Treat attribution fields as write-once:

WRITE_ONCE = {"lead_source", "utm_source", "utm_medium", "utm_campaign", "gclid", "landing_page"}

def build_update(existing: dict, incoming: dict) -> dict:
    update = {}
    for field, value in incoming.items():
        if value in (None, ""):
            continue  # never blank out a field with an empty value
        if field in WRITE_ONCE and existing.get(field):
            continue  # first touch wins
        if existing.get(field) == value:
            continue  # skip no-op writes, they burn rate limit
        update[field] = value
    return update

Most CRMs also let you make these properties read-only for regular users. Do both. The code protects against integrations, and the permissions protect against people.

Step 3: only move stages forward

Stage changes should follow real events, and they should never go backwards because events arrived out of order. A "booked" webhook that arrives late must not overwrite "invoiced."

STAGES = ["new", "booked", "quoted", "invoiced", "paid"]

def advance_stage(contact: dict, event_stage: str, crm) -> None:
    current = contact.get("stage", "new")
    if STAGES.index(event_stage) > STAGES.index(current):
        crm.update_contact(contact["id"], {"stage": event_stage})

The failure modes that wake you up

These are the ones I see most often in production:

Token refresh. Unattended integrations die on Monday because a token expired on Friday. Store expires_at, refresh before it lapses, and alert when a refresh fails, not when the next sync does.
Idempotency. Covered above. If you skip it, every retry becomes a duplicate.
Partial updates. A multi-step write fails halfway, and now a paid invoice sits on "new lead." Put each write in a queue with retries so a failed step gets retried instead of forgotten. An outbox table in Postgres works well for this.
Rate limits. Bulk imports and a sudden burst of form submissions need different designs. Queue writes and batch where the API allows it, rather than hitting the API once per event.
Human edits. Covered by the write-once fields above.

For a high-volume pipeline you also have to report on, don't treat the CRM's API as your database. Keep your own copy in Postgres, use Redis for idempotency and locks, and treat the CRM as the place where staff see the record.

Where voice agents fit

A voice agent that books after hours has to create or update the same lead a web form would, including source and campaign. Otherwise after-hours bookings become a pile the morning staff re-enters by hand, and the attribution is lost in the process.

In my experience this CRM write-back, not the voice itself, is what takes most of the effort in a voice agent build. Matching the right contact, catching duplicates, advancing the right pipeline stage, and handling failed bookings is where the time goes.

Stay on your CRM or build one?

If sales already lives in HubSpot, Salesforce, or Zoho, the work is usually OAuth, object mapping, and workflow triggers, not a rewrite. Custom objects, associations, and permission models are where generic zaps go quiet, so that's where an owned integration earns its keep.

A custom CRM makes sense when the workflow is the product. One example is a trades business that needs lead scoring, a job board, quotes, invoices, and ads attribution in one tenanted system. Stacking three SaaS tools to get there often costs more over two years than building it.

A sequence you can start with

List the money events: form, call, chat, quote sent, invoice paid.
Pick one system of record for each object. One, not three.
Map every field, including source. If source is optional, it will end up empty.
Use official OAuth for both the CRM and ads. Unofficial scrapers and connectors break during verification and can get accounts banned.
Turn off the duplicate path (the "also email the office" zap) once you trust the write-path.
Review weekly: ad spend vs booked jobs vs paid invoices.

I originally wrote this for the KeenCraft blog. If you want the attribution side in more depth, how to carry gclid and UTMs from the ad click to a booked job, that's covered in attribution tracking that ties ad spend to real bookings.

What's the worst duplicate-contact or overwritten-source bug you've run into? I'd like to hear how other people handled it.

How Much Does a Voice AI Agent Cost per Minute? A Calculator for Vapi, Retell, and LiveKit

jareer nauman — Thu, 08 Oct 2026 08:16:14 +0000

Every AI voice call is five services billed at once. Here's the per-layer math, a small calculator, and when owning the stack on LiveKit pays off.

The price on a voice AI platform's homepage is rarely the price on the invoice. That's because every call is five services billing at the same time, and platforms usually advertise only one of them.

I lead development on three live voice AI platforms (VoiceCake, Rawk.ai, and Dynaris), and this is the math I walk through whenever someone asks what an agent will cost to run. Rates below are US list prices I checked in September 2026. Providers change them often, so verify before you quote anyone.

The five layers of a voice call

Layer	What it does	Example provider	Cost per minute
Telephony	Connects the agent to a phone number	Twilio	~$0.0085 inbound, ~$0.014 outbound
Speech-to-text	Transcribes the caller in real time	Deepgram Nova-3	~$0.0077 streaming (list; $0.0048 promo)
LLM	Decides what to say and which tool to call	OpenAI, Anthropic, Google	~$0.003 to $0.16, by model
Text-to-speech	Speaks the reply	Cartesia, ElevenLabs	~$0.015 standard, ~$0.04 ElevenLabs
Orchestration	Runs the loop: turn-taking, interruptions, tool calls	Vapi, Retell, LiveKit Cloud	$0.05 Vapi, $0.055 Retell, $0.01 LiveKit

Two layers dominate the bill: the voice and the model. A premium voice costs nearly three times a standard one, and a frontier model can cost many times a small fast one. For appointment booking, a fast mid-size model is usually the right call. Callers notice a slow reply long before they notice a slightly less clever sentence.

The orchestration layer is where platform choice shows up. Vapi and Retell charge about five cents a minute to run the conversation loop. LiveKit Cloud charges about one cent per agent-session minute once you're past your plan's included minutes, because you're running the agent code yourself.

A calculator you can run

Plug in your own rates and call volume:

# Per-minute rates, US list prices checked September 2026. Verify before use.
LAYERS = {
    "telephony": 0.0085,  # Twilio US inbound
    "stt": 0.0077,        # Deepgram Nova-3 streaming, regular list price
    "llm": 0.03,          # fast mid-size model (illustrative; varies widely)
    "tts": 0.015,         # standard voice
}

ORCHESTRATION = {
    "vapi": 0.05,
    "retell": 0.055,
    "livekit_cloud": 0.01,  # after the plan's included agent minutes
}


def per_minute(platform: str) -> float:
    return sum(LAYERS.values()) + ORCHESTRATION[platform]


def monthly(platform: str, minutes: int) -> float:
    return per_minute(platform) * minutes


def payback_months(extra_build_cost: float, minutes: int,
                   managed: str = "retell", owned: str = "livekit_cloud") -> float:
    """Months for orchestration savings alone to cover the extra cost of owning the stack."""
    saving = (ORCHESTRATION[managed] - ORCHESTRATION[owned]) * minutes
    return extra_build_cost / saving if saving > 0 else float("inf")


for name in ORCHESTRATION:
    print(f"{name:<14} ${per_minute(name):.4f}/min")
# vapi           $0.1112/min
# retell         $0.1162/min
# livekit_cloud  $0.0712/min

for minutes in (2_000, 10_000, 50_000):
    print(f"{minutes:>6,} min/mo: Retell ${monthly('retell', minutes):,.0f} "
          f"vs LiveKit ${monthly('livekit_cloud', minutes):,.0f}")
#  2,000 min/mo: Retell $232 vs LiveKit $142
# 10,000 min/mo: Retell $1,162 vs LiveKit $712
# 50,000 min/mo: Retell $5,810 vs LiveKit $3,560

print(f"{payback_months(5_000, 10_000):.1f} months")  # 11.1 months
print(f"{payback_months(5_000, 2_000):.1f} months")   # 55.6 months

A few things this simple model leaves out on purpose: LiveKit's plan fee and included minutes, Vapi's and Retell's concurrency limits, and phone number fees. Add them for your own case.

When Vapi or Retell is the cheaper choice

The payback numbers tell the story. At 2,000 minutes a month, orchestration savings take over four years to pay back a $5,000 difference in build cost. At that volume, a managed platform is the honest recommendation: you skip the engineering, launch in days, and the platform fee is small.

At 10,000 minutes, the same difference pays back in about 11 months, and at 50,000 minutes it's measured in weeks. That's where owning the stack starts to make financial sense.

Cost isn't the only reason to own it, though. On Rawk.ai, owning the pipeline is what let us cut end-to-end response time from about 900ms to about 320ms. You also keep control of call data, choose each provider independently, and don't have to rebuild if a platform changes its pricing.

Costs that show up on the first invoice

The per-minute math is never the whole bill. Budget 15 to 20 percent extra for the first couple of months because of:

Test calls. Every test call bills like a real one. Tuning an agent before launch can burn hundreds of minutes.
Calls that go nowhere. Voicemails, hang-ups, and spam still use telephony, speech-to-text, and orchestration.
Transfers. A warm transfer keeps two call legs open, so telephony roughly doubles for those minutes.
Monitoring. Recordings, transcripts, and observability are often billed separately, commonly around $0.01 per minute.
Concurrency. Vapi includes 10 concurrent lines, then about $10 a month per extra line. Retell includes 20. A busy hour can hit the cap.
Compliance. On Vapi, HIPAA is a published add-on at $2,000 a month on top of usage, which changes the math for clinical calls.

The buffer usually shrinks after launch, once testing stops and prompts settle.

The takeaway

Under a few thousand minutes a month: use Vapi or Retell.
Around 10,000 minutes and up: run the payback math for owning the stack on LiveKit.
Either way: budget for the voice and the model first, because those two layers decide most of the bill.

The full version, including build-cost ranges and what moves them, is on keencraft.tech.

Fast in the Demo, Slow in Production: Fixing Latency with Postgres, Redis and Parallel Pipelines

jareer nauman — Wed, 07 Oct 2026 09:53:21 +0000

The demo works. One user, a warm laptop, and a presenter who already knows which button to press.

Then the first week of real traffic hits, and the same product waits, times out, or returns a stale answer. People call that a scaling problem. It's usually a path problem: the request was designed for an audience of one.

I lead development on a few production platforms, including Rawk.ai, a voice agent builder where we cut end-to-end response time from roughly 900ms to roughly 320ms. None of that came from a smarter prompt or a bigger server. It came from fixing the path. This post covers where the time actually goes and the fixes that hold up under load.

Load is a tail, not an average

A product can look healthy on average and still lose the people who hit the slow path. Voice callers hang up. Checkout users retry and double-charge themselves. Staff refresh a CRM and act on yesterday's data.

The number that matters is the slow tail (p95, p99), and whether the answer is still correct when it finally arrives. Three things to watch:

Speed: time to first useful response, not time until a spinner disappears.
Correctness: a fast stale cache is a bug with better graphs.
Cost: a path that calls a model or vendor API on every keystroke gets expensive before it gets slow.

If you can't name the request you're timing, you're not ready to optimize. "The app feels slow" is a complaint. "Time to first audio on a live call" is a job.

What the Rawk.ai latency pass actually changed

Callers don't forgive a 900ms gap after every sentence. They talk over the agent, the agent talks over them, and the call collapses.

The drop to ~320ms came from the pipeline:

Streaming speech-to-text instead of waiting for a final transcript
Streaming the LLM output instead of buffering a full paragraph
Starting audio on the first clause
Prefetching tool results before the agent needed them
Colocating services so no turn crossed extra regions

The voice-specific version of that budget is in how to build an AI voice agent that actually books appointments. But the same failure modes show up in products that never place a phone call.

Where the time actually goes

Most slow products are a chain of reasonable steps that were never allowed to overlap.

1. Sequential I/O

The page waits for the user, then the permissions, then the list, then the counts. Each call is fine on its own. The sum is the demo that died.

If the calls don't depend on each other, run them concurrently:

import asyncio

# Before: four round trips, one after another
user = await get_user(user_id)
perms = await get_permissions(user_id)
items = await get_items(workspace_id)
counts = await get_counts(workspace_id)

# After: independent calls run at the same time
user, perms, items, counts = await asyncio.gather(
    get_user(user_id),
    get_permissions(user_id),
    get_items(workspace_id),
    get_counts(workspace_id),
)

The request now takes about as long as the slowest call instead of the sum of all four. Before you do this, map the dependencies honestly. If get_items needs perms, keep that pair sequential and parallelize the rest.

2. A cache that's missing, or lying

PostgreSQL stays the system of record. Redis sits in front of reads that are hot, identical across requests, and safe to serve twice.

The design work is the boundary: which keys exist, how long they live, and which writes delete them. A cache without an invalidation rule is how a paid invoice keeps showing "new lead" in the UI staff trusts.

import json
from redis.asyncio import Redis

redis = Redis()
HOURS_TTL = 300  # seconds; a safety net, not the invalidation strategy

async def get_location_hours(location_id: str) -> dict:
    key = f"location:{location_id}:hours"
    cached = await redis.get(key)
    if cached:
        return json.loads(cached)

    hours = await db.fetch_location_hours(location_id)
    await redis.set(key, json.dumps(hours), ex=HOURS_TTL)
    return hours

async def update_location_hours(location_id: str, hours: dict) -> None:
    await db.update_location_hours(location_id, hours)
    # The write owns the invalidation. Delete, don't wait for the TTL.
    await redis.delete(f"location:{location_id}:hours")

The TTL is there to limit damage if an invalidation is ever missed. The real rule is that every write path for that data deletes the key.

3. Queries that scan because nobody indexed the access pattern

Postgres will answer. It'll just answer late, and later every week as the table grows. Check the query the slow request actually runs:

EXPLAIN ANALYZE
SELECT id, name, stage, created_at
FROM leads
WHERE workspace_id = 'ws_123' AND stage = 'new'
ORDER BY created_at DESC
LIMIT 50;

If the plan shows a Seq Scan on a large table, the index doesn't match how you read the data. Build one that does, matching the filter columns and the sort:

CREATE INDEX CONCURRENTLY idx_leads_workspace_stage_created
ON leads (workspace_id, stage, created_at DESC);

Run EXPLAIN ANALYZE again and confirm the plan switched to an index scan. CONCURRENTLY avoids locking writes on a live table while the index builds.

4. Retrieval on every request

Embeddings, vector search, and a model call for a question the last hundred users already asked. Pinecone or pgvector belongs in the path only when the answer actually depends on search. If the fact is already a column, read the column.

When repeated questions are common, cache the answer, but scope the key so one tenant can never see another's result:

import hashlib

def answer_cache_key(workspace_id: str, question: str) -> str:
    normalized = " ".join(question.lower().split())
    digest = hashlib.sha256(normalized.encode()).hexdigest()
    return f"answer:{workspace_id}:{digest}"

The workspace_id in the key is the important part. A shared answer cache across tenants is a data leak waiting for the right question.

5. Cross-region hops

Each vendor defaulted to a different cloud, so every request crosses regions. That's tens of milliseconds per hop, on every turn, and no amount of prompt or query tuning buys it back. Colocate the services that talk on every request. Leave the rare admin job wherever it is.

Audit the live path before proposing a rebuild

When a product already has users, the instinct is often to rewrite it. Usually that's wrong. Measure first, then change the smallest layer that moves the tail:

Name the one request users feel. Time it on production-like data, including the slow tail.
List every downstream call on that request, in order, with what each returns.
Mark which results are identical across users and which must never be shared.
Cache only the identical, safe reads, with an explicit delete on write.
Colocate the services that talk on every request.
Re-measure the same request. If the tail didn't move, the cache wasn't the bottleneck.

A caching tier or one fixed pipeline is often the whole job. A rewrite is what you propose after that pass can't hit the bar.

And write it down: an architecture overview and the API behavior your team will need when the person who tuned it isn't in the room. Undocumented speed is a demo you'll fail to repeat.

I work on production voice AI and backend systems at KeenCraft. This post was originally published on the KeenCraft blog.

Multi-Location Voice Agents: Bind the Call to a Location Before Any Tool Runs cross sites.

jareer nauman — Tue, 06 Oct 2026 13:00:00 +0000

The caller wanted 2 p.m. at the south office. The agent found 2 p.m. and booked it. The event landed on the north office calendar, because that was the calendar the demo used. The model pronounced the time perfectly.

That bug is the whole problem with multi-location voice agents. A single-location agent assumes one number, one set of hours, one staff list, and one calendar. Adding a second site doesn't add a setting. It breaks that assumption everywhere.

I lead development on Dynaris, a live AI front desk where each workspace's tools are isolated so one location can't book another's calendar. This post covers the patterns that make that work. The code below is a simplified illustration of the pattern, not production source.

The four failures that show up in week one

Right time, wrong office. The slot exists. It exists somewhere else.
Wrong hours. A shared hours string quotes the flagship's 5 p.m. close for a site open until 7.
Shared provider double-booked. A clinician works mornings at one site and afternoons at another. Each site's calendar looks free at 2 p.m.
Records leaking across sites. A phone-number lookup returns another office's contact, notes, or mailbox, and the agent can read it out loud.

All four have the same root cause: the location was treated as context in a prompt instead of a boundary in the system.

Rule 1: bind the call to a location before any tool runs

The location has to be resolved before the agent can touch a calendar or a record. There are three ways a call maps to a location:

Routing	How location is resolved	What breaks
One number per location	The dialed number is the location	Callers who dial the wrong office
One central number	The agent asks, or matches an existing record	Guessing, or defaulting to one calendar
Hybrid	Local numbers skip the question; the central line asks	Two paths writing location differently

With one number per location, binding is a lookup at call setup:

LOCATION_BY_NUMBER = {
    "+15125550101": "loc_south",
    "+15125550102": "loc_north",
}

def bind_call(dialed_number: str) -> str | None:
    """Resolve the location before the agent gets any tools."""
    return LOCATION_BY_NUMBER.get(dialed_number)

If it returns None (a central line), the agent's first job is to resolve the location by asking or by matching a record. Until it does, it gets no booking tools at all. What it must never do is fall back to a default calendar. That fallback is exactly how the north office fills up with south office patients.

Rule 2: the location is not a tool parameter

Here's the mistake that causes failure #1: giving the model a book_appointment(location_id, slot) tool and trusting the prompt to pass the right location_id. The prompt is not a permission. Eventually the model passes the wrong one.

Instead, build the tools after binding, with the location closed over, so the model can't choose it:

from dataclasses import dataclass
from datetime import date, datetime

@dataclass
class Slot:
    start: datetime
    end: datetime

def overlaps(a: Slot, b: Slot) -> bool:
    return a.start < b.end and b.start < a.end

def build_tools(location_id: str, calendars, availability):
    """Tools scoped to one location. location_id is not an argument."""

    async def list_open_slots(service: str, provider_id: str, day: date) -> list[Slot]:
        open_slots = await calendars.open_slots(location_id, service, provider_id, day)
        busy = await availability.busy_blocks(
            provider_id, day, exclude_location=location_id
        )
        return [s for s in open_slots if not any(overlaps(s, b) for b in busy)]

    async def book(slot: Slot, provider_id: str, contact_id: str, idempotency_key: str):
        # Re-check at write time: the slot can be taken between offer and confirm.
        busy = await availability.busy_blocks(
            provider_id, slot.start.date(), exclude_location=location_id
        )
        if any(overlaps(slot, b) for b in busy):
            raise SlotTaken(slot)
        return await calendars.create_event(
            location_id, slot, provider_id, contact_id, idempotency_key
        )

    return [list_open_slots, book]

Two details matter here. The re-check inside book() handles the race between offering a time and confirming it, which is common when two sites share a provider. And the idempotency_key means a retry after a timeout doesn't create a second appointment.

On Dynaris this boundary goes further than a closure: each workspace runs its own MCP tool servers, so the agent serving one location is connected only to that location's calendar, mailbox, and records. A closure is the in-process version of the same idea. Either way, isolation is enforced by what the agent is connected to, not by what it's told.

Rule 3: shared staff need a busy/free service, not shared calendars

Failure #3 is where people undo their own isolation. To check a shared provider's other site, the tempting fix is to give site A's agent read access to site B's calendar. That brings failure #4 straight back, because now site A's agent can see site B's patients.

The fix is a small service that answers one question, "is this person busy?", and returns nothing else:

from fastapi import FastAPI

app = FastAPI()

@app.get("/providers/{provider_id}/busy")
async def busy_blocks(provider_id: str, day: date, exclude_location: str):
    blocks = await store.provider_blocks(provider_id, day)
    return [
        {"start": b.start.isoformat(), "end": b.end.isoformat()}
        for b in blocks
        if b.location_id != exclude_location
    ]

No patient name, no reason for visit, no notes. Just occupied intervals. Booking site A then becomes two reads and one write:

Read site A's open slots for that provider.
Read the provider's busy blocks everywhere else.
Offer only the overlap that is free at both.
Write the appointment to site A's calendar only.

Rule 4: one person, many appointments

The location owns the appointment. The person can exist once for the whole group. Match on phone or email before creating a contact, so a patient seen at two offices ends up as one person with two appointments, each carrying its own location field. The two duplicates that actually hurt are two contacts for one person, and one appointment written onto the other office's calendar.

Reporting: one row per location

Leadership needs a cross-location view, but it should count outcomes, not hand anyone another site's records. Report the same metrics per location (answer rate, booked rate, transfers, after-hours bookings, missed-call recovery) side by side. A group average hides the site that never books.

Rolling it out

Turning on every site at once multiplies the wrong-office bug by the number of calendars. Pilot one location in parallel with the front desk, verify every booking lands on the right calendar with the right provider, then add locations one at a time, each as its own workspace with its own tools.

The full version, including routing tradeoffs for central numbers, urgent-call escalation per location, and when a vertical product is the better buy, is on keencraft.tech.

Capturing gclid and UTMs First-Party: Attribution That Survives to the CRM

jareer nauman — Fri, 02 Oct 2026 07:34:08 +0000

jareer nauman

Oct 2

Capturing gclid and UTMs First-Party: Attribution That Survives to the CRM

#javascript #webdev #analytics #tutorial

6 min read

Capturing gclid and UTMs First-Party: Attribution That Survives to the CRM

jareer nauman — Fri, 02 Oct 2026 07:24:43 +0000

A service business can spend five figures a month on Google Ads and still not know which campaign paid for which job. The form says "contact us." The phone rings from a missed-call widget. The invoice gets raised three weeks later in a different tool. Analytics reports a conversion, the CRM reports a job, and the two numbers never match.

I've hit this on a parking marketplace rebuild and again on a multi-tenant CRM for trades businesses. This post is the pattern we ship: capture attribution on landing, store it first-party, carry it onto the CRM record, and send the real outcome back to Google Ads.

Why last-click lies for service businesses

Last-click works fine for a SaaS checkout on the same domain as the ad's landing page. It breaks when:

The customer researches on mobile, then books on desktop by typing the brand name
The conversion is a phone call, not a form submit
The sale closes in a CRM days or weeks after the first visit
Staff create the booking by hand and leave the source field blank

Direct traffic then absorbs credit it didn't earn, and budget decisions get made on that fiction.

The fix is last non-direct-click: ignore pure direct visits when a known campaign or referrer already exists for that person. If someone clicks an ad on Tuesday, comes back via bookmark on Thursday, and books on Thursday, the booking still belongs to the ad.

What to capture on every landing

utm_source, utm_medium, utm_campaign, utm_content, utm_term
gclid, wbraid, gbraid (Google Ads click identifiers)
The external referrer when there are no UTMs (organic, partners, marketplaces)
The landing page path

The rule that makes the whole thing work: the CRM record is the source of truth for revenue, and the ad platform is the source of truth for spend. You need both IDs on the same record.

The landing capture

Two details here matter more than they look:

Ignore same-site referrers. If this runs on every page, internal navigation sets document.referrer to your own domain and overwrites the campaign. Payment redirects (Stripe, PayPal) do the same thing on the way back from checkout.
Separate reading from persisting. Reading the URL is fine immediately, because a query string isn't a cookie. Writing the 90-day cookie has to wait for consent.

const ATTR_KEYS = [
  "utm_source", "utm_medium", "utm_campaign", "utm_content", "utm_term",
  "gclid", "wbraid", "gbraid",
];
const COOKIE = "kc_attr";
const MAX_AGE_SECONDS = 60 * 60 * 24 * 90;
const IGNORED_REFERRER_HOSTS = ["stripe.com", "paypal.com"];

function readCookie() {
  const raw = document.cookie
    .split("; ")
    .find((row) => row.startsWith(COOKIE + "="));
  if (!raw) return null;
  try {
    return JSON.parse(decodeURIComponent(raw.slice(COOKIE.length + 1)));
  } catch {
    return null;
  }
}

function externalReferrer() {
  if (!document.referrer) return null;
  try {
    const host = new URL(document.referrer).hostname;
    if (host === location.hostname) return null;
    const ignored = IGNORED_REFERRER_HOSTS.some(
      (h) => host === h || host.endsWith("." + h)
    );
    return ignored ? null : document.referrer;
  } catch {
    return null;
  }
}

// Pure read: safe to call before consent.
function readTouch() {
  const params = new URLSearchParams(location.search);
  const touch = {
    landing_page: location.pathname,
    landed_at: new Date().toISOString(),
  };
  for (const key of ATTR_KEYS) {
    const value = params.get(key);
    if (value) touch[key] = value;
  }
  const hasCampaignParams = ATTR_KEYS.some((k) => touch[k]);
  if (!hasCampaignParams) {
    const ref = externalReferrer();
    if (ref) touch.referrer = ref;
  }
  return touch;
}

function isNonDirect(touch) {
  return Boolean(
    touch.utm_source || touch.gclid || touch.wbraid || touch.gbraid || touch.referrer
  );
}

// Last non-direct-click: a direct visit never replaces a stored campaign.
function resolveTouch(current) {
  const existing = readCookie();
  return !isNonDirect(current) && existing ? existing : current;
}

// Call only after Consent Mode grants ad_storage.
function persistTouch(touch) {
  document.cookie =
    COOKIE + "=" + encodeURIComponent(JSON.stringify(touch)) +
    "; Max-Age=" + MAX_AGE_SECONDS +
    "; Path=/; SameSite=Lax; Secure";
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: "attribution_captured", ...touch });
}

const currentTouch = resolveTouch(readTouch());

// Attach attribution to the booking payload. Falls back to this page
// load's URL data if consent hasn't allowed the cookie yet, so a
// same-visit booking still carries its source without persisting it.
function withAttribution(payload) {
  const stored = readCookie();
  return { ...payload, attribution: stored || currentTouch };
}

Wire persistTouch(currentTouch) into your consent banner's "granted" callback for ad_storage. Then on submit:

fetch("/api/bookings", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(
    withAttribution({ service: "drain-clear", slot: "2026-09-30T14:00:00" })
  ),
});

Production note: this sample reads the cookie in the browser so it fits in one file. The stronger version sets the same value server-side on the landing response as an HttpOnly cookie and has the booking handler read it there, so the click ID never travels through a hidden form field. The dataLayer push is for Tag Manager; the CRM write doesn't depend on it.

Consent Mode v2 rules

The four signals are ad_storage, analytics_storage, ad_user_data, and ad_personalization. Default them to denied and let the banner update them.

Read the URL immediately.
Write the 90-day cookie only after ad_storage is granted.
If the visitor books on the same page load before consenting, attach the URL data to that one request and don't persist it.
Send hashed customer data to Google only when ad_user_data is granted.

A banner that gets ignored while the script sets the cookie anyway is the setup that fails a review later.

Getting it into the CRM

The attribution fields have to be copied onto the lead record on create, not re-typed by staff later. That applies to forms, chat, and voice agents equally. If a voice agent books from an advertised number, pass the tracking number or call-source parameter into the agent's context and persist it on the appointment. A receptionist edit that replaces the campaign with "phone" erases the ad.

When the invoice is paid, revenue is attributed to the stored source, not to whoever last edited the record.

Sending offline conversions back to Google Ads

Once the CRM source field is trusted, upload the real outcome so Smart Bidding optimizes for booked jobs instead of form fills. Two mechanisms cover it:

Click ID upload: send the gclid stored at landing (or gbraid / wbraid when that's what you have). Send at most one click ID per conversion.
Enhanced conversions for leads: send hashed email or phone when the click ID is missing, such as a call, a second device, or a visit where consent blocked the cookie.

Fire it when the job is booked or the invoice is paid, never on the form fill.

import { createHash } from "node:crypto";

const sha256 = (value) => createHash("sha256").update(value).digest("hex");

function buildConversion({ lead, invoice, adUserDataGranted }) {
  const attr = lead.attribution || {};

  const conversion = {
    conversionAction: "customers/1234567890/conversionActions/9876543210",
    // Account timezone, with offset, inside your configured conversion window.
    conversionDateTime: "2026-09-29 14:05:00-05:00",
    conversionValue: invoice.total,
    currencyCode: "USD",
    orderId: invoice.id, // makes retries idempotent
    consent: { adUserData: adUserDataGranted ? "GRANTED" : "DENIED" },
  };

  // At most one click identifier per conversion.
  if (attr.gclid) conversion.gclid = attr.gclid;
  else if (attr.gbraid) conversion.gbraid = attr.gbraid;
  else if (attr.wbraid) conversion.wbraid = attr.wbraid;

  // Enhanced conversions for leads: hashed identifiers, consent-gated.
  if (adUserDataGranted) {
    const ids = [];
    if (lead.email) {
      ids.push({ hashedEmail: sha256(lead.email.trim().toLowerCase()) });
    }
    if (lead.phoneE164) {
      ids.push({ hashedPhoneNumber: sha256(lead.phoneE164) });
    }
    if (ids.length) conversion.userIdentifiers = ids;
  }

  return conversion;
}

Send the result through the Google Ads API's uploadClickConversions with partialFailure: true, under an OAuth app that has gone through Google's official verification. Unofficial connectors are how these integrations break during review.

Two gotchas:

If the click is older than the conversion window, the upload is rejected. Match the window (often 90 days) to your sales cycle and your cookie lifetime.
Normalize before hashing: email trimmed and lowercased, phone in E.164. Hashing an unnormalized value silently produces a non-match.

Checklist

Inventory the money events: form, call, chat, in-person booking, invoice paid.
Capture UTMs, external referrer, and click IDs on every public page, ignoring same-site and payment-gateway referrers.
Gate the cookie on ad_storage and hashed data on ad_user_data.
Copy attribution onto the CRM record on create, including calls from tracking numbers.
Report last non-direct-click for paid search, with last-click as a secondary view.
Upload offline conversions only for booked jobs or paid invoices.
Review weekly: spend vs booked jobs vs paid invoices.

The full version, with how this played out on a parking marketplace and a trades CRM, is on keencraft.tech.

Why Your AI Demo Is Fast and Production Is Slow (and the 4 Fixes That Worked)

jareer nauman — Tue, 29 Sep 2026 08:05:01 +0000

The demo was fast. Production was not.

In a typical AI demo, one request comes back in about 400ms. It feels instant. Then real users arrive, and the same endpoint takes 3 to 4 seconds at p95 during peak hours, with occasional timeouts.

Nothing is broken. The code does exactly what it did in the demo. The demo just never asked it to do that work under real traffic.

After hardening a few AI products that hit this wall, including the backends behind the voice platforms I lead development on, I keep finding the same four causes:

Sequential calls that should run in parallel
A cache that is cold, or does not exist
A database that was never asked to serve real traffic
Retrieval that is fast in testing and slow (or wrong) at scale

Here is each one, with the code change that fixed it. Examples are Python with FastAPI, Redis, and Postgres, but the patterns carry to any stack.

Fix 1: Stop waiting in line

The most common demo pattern is a chain of awaits. Each one is fine alone. Together they add up.

python
# Before: three independent calls, run one after another
async def build_context(user_id: str, query: str):
    profile = await crm.get_contact(user_id)      # ~250ms
    history = await db.get_recent_calls(user_id)  # ~180ms
    docs = await retriever.search(query)          # ~300ms
    return profile, history, docs                 # total: ~730ms

None of those calls depends on the others. So run them together, and put a timeout on the whole group so one slow service cannot hold every request hostage.

python
import asyncio

# After: the same calls, concurrently, with a ceiling
async def build_context(user_id: str, query: str):
    profile, history, docs = await asyncio.wait_for(
        asyncio.gather(
            crm.get_contact(user_id),
            db.get_recent_calls(user_id),
            retriever.search(query),
        ),
        timeout=1.5,
    )
    return profile, history, docs                 # total: ~300ms, the slowest call

The latency drops from the sum of the calls to the slowest single call. In a voice agent, where every extra 100ms is a pause the caller hears, this one change often matters more than switching models.

One caution: parallel calls multiply load on your downstream services. If three endpoints each fan out to the CRM, check its rate limits before you ship.

Fix 2: Warm the cache (or build one)

In a demo you hit the same few records over and over, so everything feels cached even when nothing is. In production, thousands of users each ask for different data, and every request goes all the way to the source.

A read-through cache in Redis handles the data that changes rarely but gets read constantly: business hours, service lists, agent configs, calendar availability windows.

python
import json
import redis.asyncio as redis

cache = redis.Redis(host="localhost", port=6379, decode_responses=True)

async def get_agent_config(workspace_id: str) -> dict:
    key = f"agent_config:{workspace_id}"
    cached = await cache.get(key)
    if cached:
        return json.loads(cached)

    config = await db.fetch_agent_config(workspace_id)
    await cache.set(key, json.dumps(config), ex=300)  # 5-minute TTL
    return config

async def update_agent_config(workspace_id: str, data: dict):
    await db.save_agent_config(workspace_id, data)
    await cache.delete(f"agent_config:{workspace_id}")  # invalidate on write

Two details matter more than the cache itself. First, invalidate on write, so an owner who changes their hours does not see the agent quote the old ones for five minutes. Second, key everything by workspace or tenant. A cache key without the tenant in it is how one client's config ends up in another client's call.

After launch, warm the cache for your busiest tenants on deploy, so the first callers after a release do not pay the cold-start penalty.

Fix 3: Ask the database what it is actually doing

With 200 demo rows, a full table scan takes a millisecond. With 2 million rows, the same query takes seconds, and it runs on every call. The query did not get worse. The table got bigger.

Start with EXPLAIN ANALYZE on your slowest endpoint's queries:

sql

EXPLAIN ANALYZE
SELECT id, caller_phone, outcome, created_at
FROM calls
WHERE workspace_id = 'ws_123'
ORDER BY created_at DESC
LIMIT 20;

-- Seq Scan on calls ... (actual time=0.02..1843.207 rows=...)

A Seq Scan on a large table in a hot path is the signal. A composite index that matches both the filter and the sort fixes this query shape:

sql

CREATE INDEX CONCURRENTLY idx_calls_workspace_created
ON calls (workspace_id, created_at DESC);

CONCURRENTLY lets you add it to a live table without locking writes.

The second database problem is connections. A demo opens one. Production opens one per request, and Postgres starts refusing them at peak. Use a pool and size it deliberately:

python

import asyncpg

pool = await asyncpg.create_pool(
    dsn=DATABASE_URL,
    min_size=5,
    max_size=20,   # stay well under Postgres max_connections, across all workers
    command_timeout=5,
)

async def get_recent_calls(workspace_id: str):
    async with pool.acquire() as conn:
        return await conn.fetch(
            "SELECT id, caller_phone, outcome, created_at FROM calls "
            "WHERE workspace_id = $1 ORDER BY created_at DESC LIMIT 20",
            workspace_id,
        )

Remember the multiplier: 4 workers with a pool of 20 each is 80 connections. If you run more services against the same database, put PgBouncer in front of it.

Fix 4: Retrieval that stays fast and correct

The demo knowledge base had 30 documents. Production has 30,000, across dozens of tenants, and two things go wrong at once: vector search gets slower, and it starts returning the wrong tenant's content.

With pgvector, the fix for both is the same query shape: filter by tenant first, and give the vector column an approximate index so it stops scanning everything.

sql
CREATE INDEX idx_chunks_embedding
ON doc_chunks USING hnsw (embedding vector_cosine_ops);

CREATE INDEX idx_chunks_workspace ON doc_chunks (workspace_id);
python

async def search(workspace_id: str, query_embedding: list[float], k: int = 5):
    async with pool.acquire() as conn:
        return await conn.fetch(
            """
            SELECT id, content, embedding <=> $2 AS distance
            FROM doc_chunks
            WHERE workspace_id = $1
            ORDER BY embedding <=> $2
            LIMIT $3
            """,
            workspace_id, query_embedding, k,
        )

The WHERE workspace_id line is not an optimization. It is a correctness rule. Never rely on a prompt instruction like "only use documents for location A." If the data can reach the model, eventually it will.

Two more things keep retrieval fast in practice. Cache embeddings for repeated questions (callers ask "what are your hours" constantly), and keep chunks small enough that you send the model 3 to 5 relevant passages, not a wall of text it has to read on every turn.

Find out before your users do

Every fix above is easy once you know where the time goes. The hard part is finding out before launch day. A short Locust script against a staging copy with production-sized data does that:

python

from locust import HttpUser, task, between

class Caller(HttpUser):
    wait_time = between(1, 3)

    @task
    def build_context(self):
        self.client.post("/agent/context", json={
            "user_id": "test_user",
            "query": "what time do you open tomorrow",
        })

Run it at your expected peak, then double it, and watch p95 latency rather than the average. Averages hide the callers who waited four seconds.

As a rough picture of what to expect: on an endpoint like the one above, these four fixes together commonly take p95 from around 3 seconds to under 800ms at a couple of hundred concurrent users. Your numbers will depend on your data and providers, but the direction is reliable. None of it requires a new model or a bigger server, just asking the system to do real work before real users do.

I build production voice agents and backends at KeenCraft, and lead development on VoiceCake, Rawk.ai, and Dynaris. Happy to answer questions about any of these fixes in the comments.

An AI front desk that is more than a phone agent

jareer nauman — Wed, 23 Sep 2026 08:45:00 +0000

The caller already emailed. The email already has the location, the service, and a photo of the problem. Then they call, and the agent asks for their name as if the business has never heard of them. That is not a voice-model failure. It is a front desk that only exists on the phone.

An AI front desk owns the customer across voice, chat, and email. It is not a phone bot with a separate inbox beside it. We built that pattern on Dynaris for multi-location businesses: inbound coverage, booking, and follow-up, with tools isolated per workspace and Gmail on the same thread as the call.

A production AI voice agent still has to book. The checklist for latency, barge-in, and calendar writes is in how we ship production voice agents. This post is about the next question: what happens to the customer who does not stay on that one call.

Operators do not experience channels

Staff experience one person who emailed, called, and then typed into the website chat because nobody confirmed the slot. Three tools each store a fragment. The fragment that wins is whichever inbox a person opens first. Attribution, medical history, and the job address get retyped until one of them is wrong.

Voice books a slot the email thread already cancelled.
Chat promises a callback the phone agent does not know about.
The CRM row says "phone" because a human overwrote the campaign when they pasted the message.

Takeaway: If a second channel cannot see the first channel's outcome, you did not add coverage. You added a second place for the booking to be wrong.

What Dynaris actually runs

Dynaris is a live AI front desk built for multi-location operations. Inbound coverage, booking, follow-up, and alerts share one customer thread across voice, chat, and email. Gmail is connected through Composio, so a mailbox is not a side system the agent is forbidden to know about.

The execution layer is multi-agent, with session-level checkpointing, graph caching, and persistent workflow state. A long task can stop and resume without a human reconstructing what the last step wrote. That is what makes follow-up auditable: the next action is a continuation, not a new guess.

VoiceCake is the inbound phone proof for dental, healthcare, fitness, and mortgage clients: real appointments on the live schedule. Dynaris is the proof that the phone is not the whole desk. A practice that only needs nights covered should start with an after-hours receptionist. A business whose customers already cross channels should not stop at the handset.

Isolation is how multi-location stays correct

Multi-location systems fail when workspace A can call workspace B's calendar or read workspace B's mailbox. Dynaris runs voice agents and tools as separate MCP-based services so each workspace has its own tool servers. That isolation is a security and correctness requirement. A shared tool process with a location id in the prompt will eventually book the wrong site.

The same rule applies to the CRM write. Source, location, and channel are fields, not a sentence in a note. How those fields survive into HubSpot, Salesforce, Zoho, or a custom system is covered in CRM automation that writes back. The front desk's job is to put them on the thread before a person has to.

What the front desk is allowed to finish

Answer on the channel the customer already used, with the prior channel's outcome in context.
Book, reschedule, or cancel against the location's real calendar, not a shared spreadsheet.
Continue a stuck call as chat or email without asking the customer to start over.
Hand an urgent or out-of-policy case to a human with the thread attached, not a one-line voicemail.
Refuse work that belongs to another location. Isolation is a feature the caller should feel as "we have your site," not as a transfer loop.

When a phone agent is still the right scope

Build the phone agent when one number, one calendar, and one outcome (book or take a message) describe the business. Adding chat and email before that write path works will spread a broken booking across more inboxes. Fix the appointment first. Then attach the channels customers already use.

Originally published on the KeenCraft blog. I write there about production voice AI, multi-agent workflows, and CRM integrations. Happy to answer questions about the MCP isolation setup in the comments.

How I build AI voice agents that actually book appointments (not just talk)

jareer nauman — Tue, 22 Sep 2026 09:22:11 +0000

A production AI voice agent is not a chatbot with a microphone. It's a phone system that transcribes the caller, reasons with an LLM, speaks back fast enough to feel human, and writes the outcome into a calendar or CRM. I build these for dental, healthcare, fitness, and mortgage businesses, including agents that book real appointments after hours.

Most people evaluate a voice agent the wrong way. They listen to a two-minute demo, hear a pleasant voice, and assume the hard part is the model. The hard part is everything around the model: the phone network, the speech pipeline, the calendar, the CRM, and the half-second of silence that makes a caller hang up.

I work on more than ten live AI platforms, including VoiceCake, Rawk.ai, and Dynaris. This is the production checklist I use before an agent is allowed to sit on a real phone number.

What a production voice agent actually is

An inbound agent answers a missed or after-hours call, identifies intent, collects the facts it needs, and either completes the job or hands off cleanly. An outbound agent places follow-up or reminder calls with the same discipline. Both are phone systems first. The LLM is one component.

A working stack usually looks like this:

Telephony: Twilio or a comparable SIP/PSTN layer for a real number, recording policy, and failover path.
Speech-to-text: Deepgram or equivalent, tuned for the accent mix and vocabulary of the business, provider names, insurance terms, and service codes.
Reasoning: an LLM behind LangChain or LangGraph, so the conversation can branch, retry, and recover instead of following a rigid tree.
Text-to-speech: ElevenLabs or similar, with a barge-in so the caller can interrupt.
Orchestration: Vapi or Retell AI when they fit, custom glue when they don't.
Systems of record: the calendar, CRM, and notification tools the staff already trusts.

If the agent can't write a confirmed appointment into the same calendar a human receptionist uses, it's not a booking agent. It's a voicemail with extra steps.

The latency budget is the product.

Callers don't forgive lag the way chat users do. A 900ms gap after every sentence feels like a bad connection. People talk over the agent, the agent talks over them, and the call collapses into noise.

On Rawk.ai, a live voice-agent builder platform, I led a latency pass that dropped end-to-end response time from roughly 900ms to roughly 320ms. That's not a marketing number. It's the difference between a call that feels robotic and one that feels human.

A practical budget, measured from the end of the caller's utterance to the start of audible speech:

STT partials and endpointing: keep streaming, don't wait for a perfect transcript before thinking.
LLM time-to-first-token: stream the reply, never buffer a full paragraph.
TTS time-to-first-byte: start audio as soon as the first clause is ready.
Tool calls: prefetch calendar availability before you need it, cache what doesn't change mid-call.
Network: colocate STT, LLM, and TTS as close as the providers allow, extra regions add tens of milliseconds you can't buy back with a better prompt.

Sub-400ms is the range I aim for on client builds. You won't hit it on day one if the agent is running three sequential tool calls against a cold calendar API. That's an architecture problem, not a prompt problem.

Conversation design that survives a real caller

Production callers don't follow the happy path. They give a date without a time. They change their name spelling twice. They ask a question the prompt never mentioned. There's a crying child in the background.

Collect facts in a stable order. For appointment booking, the agent needs a small, explicit slot list: who's calling, what service, which location if there's more than one, preferred window, and a reachable callback number. Confirm each high-stakes field out loud before writing it. Don't invent a slot the calendar didn't offer.

Define failure, not just success. Every agent needs an escape hatch: transfer to a human, take a message, or schedule a callback. Infinite retry loops are how callers decide the business is closed forever. On Dynaris, the front desk isn't voice-only, chat and email sit in the same customer thread, so a failed call can continue as a message without losing context.

Isolate tools per workspace. Multi-location and multi-tenant systems can't share tool servers casually. Dynaris runs voice agents and tools as separate MCP-based services so each workspace has its own tool surface. That's a security and correctness requirement, not a nice-to-have.

CRM and calendar wiring is the booking

VoiceCake is a live 24/7 inbound platform for dental, healthcare, fitness, and mortgage clients. The proof that matters isn't that the agent can talk. It's that a dental engagement books real appointments. That only happens when the agent can read open slots, write the booking, and trigger the same confirmation the staff already sends.

Read availability from the system of record, not from a spreadsheet export.
Write the appointment with the same fields a receptionist would: patient, provider, duration, notes, source.
Send confirmation on the channel the business already uses, SMS, email, or both.
Log the call outcome even when nothing was booked, so follow-up isn't guesswork.

If the CRM is HubSpot, Salesforce, Zoho, or something custom, the same rule applies. This work exists because a voice agent that can't write a record just creates a second, worse inbox.

A ship checklist I actually use

Latency on live PSTN, not a browser demo: measure p50 and p95 of time-to-first-audio.
Barge-in: the caller can interrupt without the agent finishing a paragraph.
Booking write-path: create, reschedule, and cancel against the real calendar.
Identity: name, phone, and location disambiguation when two records look similar.
Handoff: warm transfer or a complete message, never a dead air drop.
After-hours vs in-hours behavior: different prompts, same system of record.
Recording and retention matched to the industry. Healthcare work, like OptimateMD.health, needs data-handling designed in from architecture, not bolted on.
Observability: transcripts, tool-call traces, and a way to replay a failed call without guessing.

When you shouldn't build one yet

If the business has no calendar of record, no one who owns the front desk process, or a phone tree that already loses callers before a human answers, a voice agent will amplify the mess. Fix the workflow, then automate it. Same stance I take on custom software generally: ship the smallest system that owns the outcome.

If you do have missed calls, after-hours demand, or a receptionist drowning in routine booking, a production voice agent is one of the few AI products that shows up on the P&L in weeks rather than quarters.

Originally published at keencraft.tech/blog/production-ai-voice-agents