Human overview · for understanding

Reply-Ops Automation

A robot that watches every cold-email reply, 24/7 — logs the wins, drafts the saves, waits for your tap · 2026-07-07

A robot that watches every cold-email reply, 24/7 — logs the wins, drafts the saves, waits for your tap

Master summary — the gist in 30 seconds

TL;DREvery 5 minutes it checks Instantly for Danubisoft, GLABS and K-X. A positive reply auto-fills the client's Google Sheet and emails the client. Any other reply becomes an AI-written 'win-them-back' draft posted to Slack — you tap Send or edit-and-send.

Input: new replies sitting in Instantly. Output: (a) hot leads logged + client notified automatically, (b) lukewarm/negative replies turned into a ready-to-send draft in your Slack, sent only when you tap.

Why this mattersYou already do this by hand for Danubisoft. This clones that proven loop, runs it for all 3 clients around the clock, and never lets a saveable reply die in the inbox — while never sending a lead anything without your finger on the button.
flowchart LR
  I["Instantly<br/>replies"] --> P{"Every<br/>5 min"}
  P --> C{"Positive?"}
  C -->|Yes| S["Sheet row +<br/>email client"]
  C -->|No| D["AI draft →<br/>Slack card"]
  D --> T["You tap<br/>Send"]
  T --> R["Reply goes<br/>to lead"]

1 · Where we are now

TL;DRDanubisoft already runs this loop — mostly by hand. GLABS and K-X don't have it at all.

Input: Danubisoft's existing process (classify reply → log positives → email Mihály). Output: a template we copy to the other two clients and automate fully.

Why it mattersWe're not inventing a system — we're photocopying one that already earns money and pointing it at three inboxes instead of one. Less risk, faster to trust.
flowchart TD
  D["Danubisoft:<br/>working loop"] -->|copy| G["GLABS"]
  D -->|copy| K["K-X"]
  D -.->|add new| N["AI-draft +<br/>Slack step"]

2 · The two lanes a reply can take

TL;DRPositive = automatic. Everything else = drafted for you to approve.

Input: one reply + its Instantly 'interest' label. Output: either a sheet row + client email (positive), or a Slack draft card (anything else, including replies nobody has labelled yet).

Why it mattersThe dividing line is Instantly's own label, not an AI guess — so a 'hot lead' is never faked. The AI only writes the rescue draft; it never decides who's interested.
flowchart TD
  R["Reply"] --> L{"Instantly<br/>label"}
  L -->|interested /<br/>meeting| A["AUTO: sheet<br/>+ client email"]
  L -->|wrong person /<br/>not interested /<br/>unlabelled| B["AI draft →<br/>Slack"]

3 · The Slack approval card

TL;DRYou see the incoming reply + a ready draft that copies the original greeting and sign-off. Two buttons: Send, or Edit & Send.

Input: a non-positive reply. Output: a Slack card in that client's channel showing the lead's message and your AI draft, with the send happening only on your click.

Why it mattersThis is the human gate — the one rule we never weaken. Nothing reaches a lead without your tap. Edit-inline means you can fix a word without leaving Slack.
flowchart LR
  C["Slack card:<br/>reply + draft"] --> S["Send"]
  C --> E["Edit &<br/>Send"]
  S --> X["Instantly<br/>sends via M365"]
  E --> M["Tweak text"] --> X

4 · How the reply actually leaves

TL;DRApproved replies go out through Instantly's reply endpoint — which uses the same Microsoft 365 inbox. M365-direct is the backup if that proves flaky.

Input: your approved draft. Output: an email in the real thread, from the same mailbox the lead already knows.

Why it mattersYou asked for the M365 route. Good news: Instantly already sends *through* your M365 inboxes, so we get the M365 outcome without weeks of per-tenant Azure setup. If it misbehaves, we fall back to talking to M365 directly.
flowchart LR
  A["Approved<br/>draft"] --> I["Instantly<br/>reply API"]
  I --> O["Same M365<br/>inbox"]
  O --> L["Lead"]
  I -.->|if flaky| F["M365 Graph<br/>direct (backup)"]

5 · Smarter drafts per client

TL;DREach client gets its own 'brain' built from its real campaign copy + research on what wins objections.

Input: all the cold-email copy we've sent for that client + a Sonnet research pass on objection-handling. Output: a per-client prompt so the AI drafts in the right voice with the right offer.

Why it mattersA K-X draft must never say 'fines' and must say 'feladatlista', not 'audit'. A generic bot can't know that. Feeding it the real copy + client rules is what makes a draft actually convert instead of annoy.
mindmap
  root((Reply KB))
    Danubisoft
      Kérdés copy
      Baksai persona
    GLABS
      HU variants
    K-X
      PPWR copy
      no-fines rule
    Research
      objection playbook

6 · Where it lives + what's left to confirm

TL;DRRuns on Modal (matyas workspace): a 5-min timer + a Slack button listener. A few technical facts get nailed down in the next planning step.

Input: this plan. Output: a Modal cron poller + Slack Socket-Mode backend, once Instance 2 confirms the interest-label source, the reply endpoint's reliability, and the Modal app location.

Why it mattersModal keeps it always-on so replies don't wait for your laptop. The open items are research questions, not guesses — we answer them with a Sonnet agent before writing a single line of the build checklist.
flowchart TD
  M["Modal<br/>(matyas)"] --> T["Cron: poll<br/>every 5 min"]
  M --> H["Socket Mode:<br/>Slack buttons"]
  Q["To confirm:<br/>label source ·<br/>reply API ·<br/>Modal app"] -.-> M
Full technical handoff (HANDOFF.md) →Copy-paste prompt for the next planning step →