From IT Ticket to AI Chatbot:

From IT Ticket to AI Chatbot: How a Supply Chain Request Sparked a RAG Pipeline

This isn't a technical manual — just an honest walkthrough of how a single IT ticket turned into a working AI powered chat assistant. For anyone curious about the finer details, feel free to reach out!

It Started With a Ticket

The title said it all: "Google Cloud GPT Chatbot for SKU Tracking."

The description: "Can I use Google Cloud services to build a GPT-powered chatbot that acts as a SKU tracker? My goal is to use it as the foundation for future AI and automation projects."

The request came from a friend on the supply chain team. After a quick meeting, his real motivation became clear — the team was drowning in manual lookups and needed a friendly, effective tool that could surface information quickly. No dashboards, no tickets, just a conversational interface they could actually use.

Strip away the jargon and the ask was straightforward: pull data from a source the team couldn't easily access, and deliver it somewhere they already lived. That's honestly the name of the game for most IT problems. The harder questions are always: How do you keep the blast radius small? And what does scalability and maintenance look like six months from now?

The Stack

Here's what the stack looked like after ~20 hours of tinkering — and eating shit along the way.

Server Hosting

Proxmox VE VM running Ubuntu 24.04.4 LTS, bumped from 8GB to 16GB RAM to ensure enough headroom
Multi-use server; the existing N8N instance already lived here, which simplified networking considerably

Google Workspace

Initial data source: a CSV file nested inside a shared Google Drive folder
Access is handled through a dedicated "service" account — not a traditional GCP service account, but a standard Workspace account treated like one, with Content Manager permissions on the parent shared drive

Google Cloud Platform

A new GCP project was created to enable the Generative Language API and Google Drive API, along with the necessary API keys

Qdrant (Vector Store)

A vector store is essentially a database optimized for storing and searching AI generated embeddings. Think of it as the memory that lets the chatbot find relevant information rather than scanning everything blindly
Deployed via Docker on the host server
One key gotcha: the vector dimension size needed to be set to 3072. Something that becomes obvious pretty fast when testing text embedding models in N8N

N8N (Workflow Automation)

Credentials configured: Slack Socket API, Google Drive API, Gemini API, Qdrant API
Two workflows built:

Ingestion pipeline — downloads the file, cleans and splits the data, and pushes it into Qdrant. Triggers automatically on any change in the monitored Drive folder (add, replace, or edit)

Chatbot workflow — listens for Slack mentions, queries the vector store via HTTP, passes results through Gemini for cleanup, and returns a clean answer to the channel

Slack

A Slack app was created via the API console and added to the workspace
Connected to N8N using Socket Mode — avoiding any exposed ports, which would've been the case with a standard webhook trigger

Testing: What It Took to Ship

Getting to a confident "hell yes, this works!" happened in stages:

Can the file download from Google Drive and land cleanly in Qdrant? ✅
Can a Slack mention trigger a successful N8N execution? ✅
Does a response actually come back to Slack? ✅
Are the answers truthful and accurate? The test dataset was around 1,000 rows of dates, PO numbers, destinations, SKUs, origins, and other data simple enough to cross-validate manually. ✅

With the core functionality confirmed, the last hurdle was response time. Early runs were taking anywhere from 40 seconds to 2 minutes, definitely not production-ready.

The fix came from a key insight: instead of sending raw data to the language model and letting it sort through the noise, a JavaScript preprocessing step was added to strip irrelevant data before it ever touched Gemini.

Token usage dropped from 100k+ to ~2k per request, and response time came down to roughly 15 seconds. That single optimization made the difference between a demo and something actually worth handing off.

The Cost Question

By the end of testing, the API logs showed approximately 10,000 requests at a total cost of $8. Whether that's cheap or steep really depends on usage patterns at scale — real user traffic will answer that question quickly. Personally, I don't think we will be breaking the bank. For now atleast.

For anyone who's built something similar, or approached this differently — what did that look like? Shoot your thoughts over, so I can steal your ideas, haha.

From IT Ticket to AI Chatbot:

Contents