Case Study 01

Slack Support Assistant

An AI-assisted workflow prototype exploring how incoming Slack support conversations could be triaged, routed to an available engineer, and answered faster — with a human always reviewing before anything is sent.

Repository: Private Status: Prototype Production Use: No

Problem

Manual triage doesn't scale, and it doesn't check who's actually around.

Support teams handling incoming Slack conversations often assign requests manually — whoever notices the message first, or whoever's turn it "feels like" it is. There's rarely a consistent check on whether the person being assigned is actually available before a new conversation lands in their queue. That gap is where response times slip.

Approach

Prototype the decision logic, not just the chat interface.

I designed a workflow where a new Slack conversation is detected automatically, routed to an available engineer using round-robin logic, and tracked through acknowledgement and response. AI assists the assigned engineer's response drafting — it does not communicate with the customer independently. I defined the problem, workflow, assignment logic, and testing scenarios; AI-assisted tooling helped build the implementation.

Workflow

From message to sent response, every state is tracked.

Scroll into this section and each stage lights up in the order it actually happens in the prototype. You can also replay it on demand below.

1Customer submits request in Slack
2Conversation created automatically
3Engineer availability checked (Slack presence)
4Round-robin assignment
5Customer acknowledgement sent
6Engineer reviews conversation
7AI-assisted response draft generated
8Engineer edits / regenerates / rejects
9Engineer approves → response sent as assigned engineer
10Conversation state tracked to close
Status: Idle

Availability Logic

Presence-aware routing, not just a static schedule.

Before assignment, the prototype checks each engineer's real-time Slack presence. Engineers marked away are excluded from that round's eligible pool — this is the specific piece of decision logic I was most interested in testing.

Prem
presence = active
→ eligible
Aditya
presence = away
→ excluded

Demo

The prototype, running end to end.

Screen recording of the flow above: a new conversation comes in, availability is checked, an AI-suggested reply is generated, and the engineer approves and sends it.

LIVE PROTOTYPE / DEMONSTRATION RECORDED
Slack Support Assistant demo — new conversation, availability check, AI-suggested reply, approve and send
slack-support-assistant-demo.gif · sanitized trial workspace
Round-robin assignment Presence-aware routing AI-assisted drafting

This is the actual prototype running in a sanitized trial Slack workspace — not a mockup. No real customer information, credentials, or internal URLs are shown.

System Output

What the backend actually reports.

Sanitized log excerpt from a test run — no real customer data, tokens, or credentials.

EXHIBIT Asystem.log
Engineer availability check:
Prem       presence=active   -> eligible
Aditya     presence=away     -> excluded

New Conversation
Assigned Engineer: Prem
Status: ASSIGNED

Conversation Acknowledged
Acknowledged By: Prem
Status: ACKNOWLEDGED

What I Learned

The decision logic is the hard part — not the AI generation step.

Building this clarified how much of "support automation" is really about designing decision logic: who's eligible, when to escalate, when to hand control back to a human. The AI drafting step is comparatively the easy part — keeping a human in the approval loop for every outbound message was the design decision that mattered most.

Limitations & Next Steps

An honest read on where this stands.

This is a personal prototype, not a production deployment — it hasn't been tested at scale, doesn't yet handle multi-channel routing, and the assignment logic is intentionally simple (round-robin, not load- or skill-based). Repository is private; implementation details available on request.