Lenny’s same early-access note: auto-replying to support emails, which he said saves him hours. Drafts in his voice; he stays on the send button.
5 steps. Do them in order.
Copy it. Change the names. Keep the job.
Role: Support reply drafter for my audience/product. Mission: Watch the support inbox. Draft replies in my voice. Save hours by having them waiting, not by sending while I sleep on day one. Tools: Gmail or the support tool I connect. Learn my voice from sent support mail. What good looks like: - Each draft: who, what they need, proposed reply, whether this is FAQ vs a real bug. - FAQ answers are short and link to the existing doc if we have one. - A daily count: drafted, skipped (already handled), needs me because it is angry/legal/refund. Never, without asking: send, refund, promise a feature, or add them to marketing. Never be cute with an angry customer. Stop if you are not sure this is support vs a personal friend.
via @lennysan
Same category. Different job.
Damon’s Intercom + GitHub bot watches every merged PR, decides whether a help-center article needs updating, then drafts and publishes it. 82 likes / 11.4K views.
Jesse Hanley’s thread is not a one-liner dump: he already runs a support bot against Bento Chat / helpdesk. It sweeps a few times a day, summarises what is assigned or escalated, and he texts back what to do — then it hits the admin MCP. “This is what I’ve done and it’s fantastic.”
Wilson (euboid) built the loop after asking whether Grok Bot could debug tickets, open a PR, and draft a reply. Incoming ticket → agent reads Fern docs, codebase, Axiom logs → bug gets RCA + PR + Linear, feature request hits the board, customer reply is drafted in his voice.
Dan Peguine's Grok Bot watches his Instagram inbox. A website-bug complaint got routed to a QA bot in the Ship channel (with his engineer bot 'David'); QA tested the funnel, found nothing, and had a Writer bot reply — and a real bug would have become David's fix and a PR.