Lynkme AI Sales Assistant Demo: From DMs to Booked Installs

We built a case-study demo for Lynkme that simulates an AI sales assistant turning Instagram inquiries into booked demos and paid installs. It qualifies, softens the hard pitch, and outputs draft-only email replies for review instead of live sending. This post documents what we scoped, how the demo works, and the path to production.

Definition: an AI sales-assistant demo is a controlled chat simulation that mirrors live lead handling without touching real messaging systems, so product and voice decisions can be tested safely.

Note on status: this was a proof-of-concept we built for Lynkme, not a live deployment. The founder expressed interest verbally. There are no production metrics.

What problem did the Lynkme demo solve?

The demo answered one question fast: can an assistant handle the first five minutes of a Lynkme conversation in a way that reduces founder load and still books demos or paid installs. For founder-sold SaaS with a hard pitch, inbound social traffic needed a human to convert. The demo shows a safe, reviewable path to automate the opener while preserving voice and control.

How does the Lynkme AI sales-assistant demo work?

At a high level: a lightweight chat frontend talks to a serverless orchestrator that enforces Lynkme's voice and qualification steps. All outbound messages are drafts for review. No direct posting to Instagram, SMS, or email occurs in the demo.

• Assistant brain: a structured prompt plus a small state store drives a predictable sequence: greet, qualify, disarm price, propose next step, draft follow-up.
• Draft-only comms: instead of sending anything live, the system writes drafts to a safe sink for review. In our demo plan every message went to an internal review inbox as a draft only.
• Deterministic rails: pricing gates and next-step logic live outside the model so quotes and call-to-action are consistent.
• Guardrails: white background, scoped deletes by conversation ID, a fresh sandbox instance, and no live integrations enabled.
• Path to production: swap the draft sink for real channels, add consent checks, booking calendar, and CRM write-back with duplicate protection.

Step-by-step: how we built the demo

1) Capture product, voice, and objection handling in one context file

We started by writing a structured context that encodes Lynkme's pitch, buyer types, common objections, tone, and disqualifiers. This becomes the single source of truth the assistant follows.

# demo/context.yaml
product:
  name: Lynkme
  one_liner: Digital business cards that actually get installed and used
  hard_pitch: true
voice:
  style: consultative, disarming, concise
  never: pressure, hype phrases, discounting first message
qualification:
  questions:
    - "What do you use today for sharing contact details at events or meetings?"
    - "Team size and where you'd use it?"
    - "Do you control devices or is it BYOD?"
  disqualifiers:
    - "no smartphone policy"
    - "procurement freeze with no pilot option"
next_steps:
  book_demo: "Offer a 15-minute install walkthrough"
  paid_install: "If they ask pricing and match ICP, present starter tier and installation timeline"
objections:
  pricing: "Anchor on install speed and real usage, defer line-item price until a demo slot is offered"
  data_security: "Outline local device settings and minimal data footprint"

Key gotcha: we keep all irreversible claims out of the context until the founder signs off. The assistant cannot promise features or discounts.

2) Model the conversation as a small state machine

A tiny state machine prevents rambles and keeps the opener on rails.

# demo/states.yaml
states:
  START: { on: { greet: QUALIFY } }
  QUALIFY: { on: { got_answers: DISARM, disqualify: DECLINE } }
  DISARM: { on: { ready_to_book: BOOK, asks_price: PRICE_HINT } }
  PRICE_HINT: { on: { accepts: BOOK, hesitates: NURTURE } }
  BOOK: { on: { booked: SUMMARY } }
  NURTURE: { on: { followup_sent: END } }
  DECLINE: { on: { sent: END } }

The assistant chooses actions, we advance the state, and we log every transition for later review.

3) Stand up a sandbox chat shell with a serverless orchestrator

A minimal chat shell talks to an API route that enforces context and state and returns assistant messages. The orchestrator owns guardrails: max turns, safe content filters, and draft-only behaviors.

// api/chat.ts
import { readFileSync } from "fs";
import path from "path";
 
const ctx = JSON.parse(JSON.stringify(readFileSync(path.join(process.cwd(), "demo/context.json"), "utf8")));
 
export async function POST(req: Request) {
  const { convoId, user, message } = await req.json();
  const state = await loadState(convoId);
  const prompt = buildPrompt(ctx, state, message);
  const ai = await runModel(prompt); // model call hidden behind adapter
  const next = reduceState(state, ai);
  await saveTurn(convoId, { user, message, ai, next });
  return new Response(JSON.stringify({ reply: ai.text, state: next.name }), { status: 200 });
}

Gotcha: keep model calls behind an adapter so future model swaps do not change orchestration code.

4) Generate booking and follow-up as drafts, not live sends

The demo must never message a real prospect. We route booking and email outputs into a drafts queue that a human reviews.

// lib/drafts.ts
type Draft = { to: string; subject: string; body: string; meta?: any };
 
export async function writeDraft(d: Draft) {
  const row = { id: crypto.randomUUID(), ...d, at: new Date().toISOString() };
  await appendRow(process.env.DRAFTS_SINK_URL as string, row); // sheet, db, or file sink
  return row.id;
}
 
export async function maybeCreateBookingDraft(convoId: string, summary: any) {
  const email = {
    to: "review-inbox@example.com", // demo-only sink
    subject: `Lynkme demo: booking request for ${summary.company}`,
    body: renderSummaryEmail(summary)
  };
  return writeDraft(email);
}

Guardrail: drafts never auto-send. The sink is auditable and easy to wipe after the demo.

5) Keep pricing and next-step math outside the model

We codify simple pricing hints so the assistant never hallucinates numbers.

// lib/pricing.ts
export function priceHint(teamSize: number) {
  if (teamSize <= 5) return { tier: "Starter", note: "fastest to install for small teams" };
  if (teamSize <= 50) return { tier: "Team", note: "centralized rollout options" };
  return { tier: "Enterprise", note: "SAML and device controls available" };
}

Key idea: the model describes value and sequencing. Deterministic code proposes the tier.

6) Implement scoped deletes and a clean reset

Demo sessions should be easy to clean without touching unrelated data.

-- demo/sql/scoped_deletes.sql
DELETE FROM demo_turns WHERE conversation_id = $1;
DELETE FROM demo_drafts WHERE conversation_id = $1;

Decision: we kept the demo on a fresh instance with white background and a simple admin Reset button that calls these deletes.

Where this gets complicated

• Human founder voice: disarming a hard pitch without neutering it takes more than a generic tone toggle. We encode examples in the context and test the first five turns repeatedly.
• Consent and channel rules: production messaging on platforms like Instagram requires strict consent and rate handling. The demo avoids live channels entirely. The production path adds consent logging and pacing.
• Booking collisions: once live, double-booking and time zone drift appear. We plan a read-verify-hold pattern before confirming slots, with idempotent holds and a rescue message if conflicts arise.
• Duplicate leads: CRM write-back needs deterministic dedup keys and stateful retries. The demo skips the CRM path on purpose. Production adds a dedup ledger.
• Safety vs speed: short replies are fast, but some objections need a longer, founder-signed treatment. We route those to drafts by rule, not by model mood.

What this actually changes

For a founder-sold SaaS like Lynkme, the first five minutes decide whether a DM becomes a demo. An assistant that replies instantly, qualifies, and proposes a clear next step means fewer messages that stall waiting for the founder. Harvard Business Review reports that firms responding within one hour are nearly seven times as likely to qualify a lead as those taking longer (source: https://hbr.org/2011/03/the-short-life-of-online-sales-leads).

In the Lynkme demo, all messaging remained drafts in a safe sink, so we could iterate on voice and objection handling without platform risk. The path to production then becomes swapping the sink for real channels, adding consent and calendar checks, and wiring a CRM ledger for idempotency.

Frequently asked questions

Was this a live deployment?

No. This was a case-study demo we built for Lynkme. It ran in a sandbox with no live messaging and draft-only outputs. The founder expressed interest verbally. There are no production metrics attached to this demo.

How do you prevent the assistant from over-promising features or price?

We keep all numbers and promises in deterministic code or configuration outside the model. The model handles tone and sequencing. Pricing hints and next-step rules live in code so the assistant cannot invent them.

How would this connect to Instagram or email in production?

The demo intentionally avoided live channels. In production we use an integration layer that respects each platform's consent and rate rules, with idempotent retries and an audit log. The assistant continues to produce drafts for sensitive replies until a human confirms.

How do you avoid duplicate CRM records?

By using a dedup ledger keyed on stable identifiers and writing idempotent upserts. The demo did not write to a CRM. The production plan includes a state store that records pushes and prevents repeats even on retries.

What about calendars and double-bookings?

We implement a read-verify-hold sequence before confirming. Holds expire, confirmations include the verified slot in the message, and any conflict triggers an alternate-slot reply with a one-click confirm.

Can the assistant handle security or procurement objections?

Yes, but longer answers route to drafts. We keep short, accurate talking points in the context and instruct the assistant to offer a follow-up doc or a quick call rather than arguing in chat.

If founder-dependent sales are capping your growth and you want an assistant that turns social traffic into demos without risking platform bans, start with a sandbox like this. See how we approach AI sales outreach, read our related guide on automate Instagram DM responses, and when you are ready, book a 15-minute call.