A customer service platform with AI built into the workflow.
I’ve spent years working with customer service tools, and I kept seeing the same problems. Agents had to search for answers across different systems, piece together customer context, and write escalations manually. Meanwhile, team leads had limited visibility into what was happening across calls.
I built CS Co-pilot to explore a different approach: give agents relevant guidance while they’re talking to customers, then use the same conversation data to help team leads understand what happened.
In the demo, Slack is used as the example company, with real articles from the Slack Help Center
Most of the tools I had used were built around an inbox. AI was something added on top, rather than something the workflow was designed around.
I wanted to see what would change if the system could identify a customer’s problem, find the relevant troubleshooting guide, prepare a checklist and bring up the right account information while the conversation was still happening.
The other half of the problem was quality assurance. Team leads can’t manually review every call, which makes it difficult to spot recurring issues, understand why conversations go unresolved, or identify where customers are getting frustrated.
So I built both sides: live assistance for agents and automatic analysis for team leads after a call.
A shared inbox for chats and calls, with assignment, tags, views and conversation history. When a customer describes a problem, the system suggests a relevant troubleshooting article, opens it at the appropriate section and turns the recommended fix into a checklist.
It also brings relevant customer information into the conversation and prepares escalation drafts for handover.
Audio is streamed to the server and transcribed in real time, with the agent and customer identified separately. As the conversation develops, the suggested guide and checklist update so the agent can prepare while the customer is explaining the issue.
After a call, the system categorises and scores the conversation, including whether it was resolved, how sentiment changed, and whether the customer had to repeat themselves or was transferred.
Team leads can review the results, correct the AI’s assessments and use the aggregated data to identify patterns across conversations.
One problem I wanted to solve was finding the right troubleshooting article when the customer’s wording was very different from the article title.
A customer might say, “Nobody can hear me when I talk in a call,”
while the relevant article is called “Troubleshoot huddle audio issues.”
The system first uses sentence embeddings to retrieve the six most relevant articles by meaning.
A classification model then compares those candidates using the conversation as context and selects the best match.
The result includes a confidence estimate. If confidence falls below the configured threshold, the interface signals uncertainty and shows the runner-up rather than presenting the result as definitive.
I used 29 real troubleshooting articles from the Slack Help Center as the knowledge base, with deliberately varied test phrases to check whether the system could match problems without relying on shared keywords.
I built the application with Python, FastAPI, PostgreSQL, React and TypeScript. The system includes a shared real-time inbox, WebSocket connections, background jobs, call transcription and workspace-level data isolation.
I wrote the tests before relying on the external services. The test suite uses deterministic fakes for the AI model, transcription service and authentication provider, allowing the core behaviour to be tested without network dependencies.
The build includes approximately 495 Python tests, around 100 React tests and a Playwright end-to-end run in a real browser.
The biggest challenge was balancing retrieval quality with confidence. Embeddings made it possible to search a larger knowledge base efficiently, while the second-stage classifier narrowed the decision down to a manageable set of candidates.
I also learned how much of a real-time application is about handling things going wrong: expired sessions, dropped connections, delayed jobs and concurrent authentication requests.
Most importantly, I wanted the system to show uncertainty rather than hide it. In customer service, an answer that looks confident but is wrong can create more work than no answer at all.