How We Built Rialto Academy a Slack-to-ClickUp Support Pipeline With Claude in the Middle

The interesting work in AI right now is happening in places that look unglamorous from the outside. Support team workflows are one of those places. The Slack channel where customer questions land, the ticket system where the work gets tracked, and the internal knowledgebase that holds the institutional answers are three tools that rarely talk to each other, even though almost every operations team uses all three. Bridging them is where most teams find a multi-hour-per-week return on the AI investment without anyone having to learn a new tool.

This post walks through one of those bridges, currently running in production for a client we have worked with since 2018.

Meet the client

Rialto Academy is a continuing-education platform for real estate associations across the United States. The platform serves roughly 93,000 members across associations from Kansas City to Florida, with course delivery, member fees, event registration, and SSO all running on a custom stack we have built and maintained alongside the Rialto team since 2018. The Rialto Academy case study covers the broader engineering relationship.

When you operate a national platform that size with a small engineering team, the inbound support volume becomes a force in its own right. Whether the inbound message is a bug report on the class enrollment flow, a billing question about a member's pricing, or a feature request from an association director, it has to reach an engineer, get triaged, and get resolved before it eats the day.

Screenshot placeholder: The Rialto support channel in Slack with a few example incoming customer questions visible, redacted as needed.

The problem: two conversations, one ticket

Rialto's team had two tools for support work. Slack was where the conversations actually happened, because that is where the customer was already. ClickUp was where the work got tracked, because that is where the engineering roadmap lived. The two did not talk to each other.

A typical support request would arrive in the Slack channel, the team would discuss it in-channel, somebody would copy-paste the gist into a ClickUp ticket, and the conversation would split into two parallel threads. The Slack version stayed alive because the customer was still in it. The ClickUp version slowly drifted out of date because nobody wants to maintain two records of the same conversation. By the time an engineer picked up the ticket they had to scroll back through Slack to find the actual context, and half the institutional knowledge about each request lived in messages they had not seen.

This is the kind of friction every operations team eventually runs into. Most teams paper over it with discipline and templates, and the discipline-based fix works for a few months and then erodes.

The solution: a gateway, not a chatbot

Sal Yanez on our engineering team built what we call internally the "Rialto Tasks to ClickUp From Slack" pipeline. The name is intentionally boring because the work it does is intentionally boring. Every message in the designated Rialto support channel in Slack becomes a ticket in ClickUp automatically, and every comment on that ticket flows back to the Slack thread, and every reply in the Slack thread flows back to the ticket. The team has one conversation, accessible from whichever tool they happen to be in, and the ticket stays in sync.

The interesting part of the automation is what happens at the moment of ticket creation.

Claude reads the request, looks up the knowledgebase, and writes the brief

When a new support message lands in Slack, the pipeline fires three things in parallel.

First, the basic plumbing. The pipeline creates a ClickUp task containing the customer's message, links it back to the original Slack thread, and stands up the bidirectional sync so future replies in either tool propagate to the other.

Second, the analysis. The message goes to Claude with a prompt that asks "what is this person actually asking, and what category of work does it fall into" along with the engineer-facing tagging vocabulary we use internally. Claude returns a structured classification that drives the ticket's priority, owner, and tag set.

Third, and the part that matters most: a retrieval-augmented query against our internal knowledgebase. The knowledgebase lives in Supabase, with the documents stored alongside their vector embeddings, and the retrieval step looks for prior tickets, runbooks, internal docs, and code-reference materials that are semantically close to the new message. Claude synthesizes whatever comes back and writes a short brief that gets posted at the top of the ClickUp ticket. Something like "this looks like a member-type pricing question similar to ticket #1234 from March, the relevant code path is the seat-fee resolver in services/checkout, and here are the runbooks that have worked for similar issues in the past."

The engineer who picks up the ticket has real context before they read the customer's first message.

Screenshot placeholder: A ClickUp ticket that has been auto-created from a Slack message, with the Claude-generated brief at the top showing the classification, the related historical tickets, and the relevant runbook links.

The stack

The orchestration layer is n8n, running on our own infrastructure. n8n is the open-source workflow-automation tool we reach for when an automation has to handle real production traffic and we want every step to stay inspectable. The pipeline runs as a sequence of n8n nodes: a Slack webhook trigger fires when a new support message lands, a Claude API call handles the language analysis, a Supabase query pulls the relevant knowledgebase context, a ClickUp task gets created with the synthesized brief attached, and a final Slack thread reply confirms the handoff. The whole flow is visible in the n8n editor for debugging, and when something fails we know which step failed and why.

Claude (Anthropic's API) handles the language work. It reads the incoming request to identify what category of work it falls into, synthesizes the knowledgebase context into a short summary, and produces the engineer-facing brief that sits at the top of the ticket.

Supabase is the data layer. It holds both the structured task metadata (Slack message IDs, ClickUp task IDs, and the mapping records that keep the two systems in sync) and the unstructured knowledgebase content with its vector embeddings.

ClickUp and Slack are the surfaces the team actually works in. Neither was modified to accommodate the automation, and neither requires a custom UI to use the system. The engineers work in whichever tool they were already going to work in, and the pipeline keeps both views consistent.

Screenshot placeholder: The n8n workflow editor showing the pipeline as a chain of nodes from Slack webhook through Claude and Supabase to ClickUp, useful for showing the entire flow visually.

What the customer never sees

The customer never sees the AI. The synthesis runs once per ticket as a behind-the-scenes step, and the engineer is the one who reads the brief and responds in the Slack thread. There is no chat widget in the loop, no AI agent pretending to be a human, no point at which the model is generating customer-facing copy without human review. Claude does the kind of work Claude is good at, which is reading a request, pulling related context together, and producing a usable summary for the human about to do the actual work. The humans handle the conversation with the customer and the resolution of the underlying problem.

What other teams can take from this

The lesson we keep relearning on AI automation projects is that the highest-leverage work usually does not look like AI work from the outside. It looks like plumbing. The Rialto Slack-to-ClickUp pipeline is fundamentally a sync layer between two tools the team already used every day, and the AI piece sits inside that sync as a quiet enrichment step that runs once per ticket. The team did not have to learn a new tool, change their workflow, or remember to invoke anything. Tickets just started showing up with real context attached.

The other lesson is that observability matters more than cleverness. We picked n8n for the orchestration layer specifically because every step is inspectable. When a ticket gets miscategorized, we can replay the exact API call to Claude, see what the retrieval step pulled out of Supabase, and adjust the prompt or the embeddings before the next request comes in. A single closed-source automation tool with opaque internals would have made the same pipeline cheaper to build initially and impossible to debug at the moment when we needed to.

This pattern works for most operations teams that already use Slack and a ticket system and have an internal knowledgebase worth searching. The investment is not the AI piece. The investment is the plumbing that connects the tools the team already lives in, with the AI sitting inside that plumbing as a small, well-scoped enrichment step. Our AI and automation service page covers the broader scope of work we do in this area.

Working on a support workflow where the conversation lives in one tool and the work gets tracked in another? Start a conversation. We can usually scope an automation like this in the first call.