Case study

The user guide nobody would read: building a Teams support agent with n8n and Claude

We wrote perfect documentation for a new system, then accepted the truth that nobody reads documentation. So we turned it into something you can talk to.

By Chinmay Bandekar · Hasso Plattner Foundation · 2026

Two weeks before go-live

The foundation was about to launch DIMS, a new Salesforce-based grant management system, and I was handling the system administration side of the rollout: onboarding 18 users across the whole foundation, configuring access, and preparing everything for launch. As part of that preparation we had written a fully fledged user guide covering every user level, from everyday users to system administrators. It was complete, accurate, and well structured.

And we knew, honestly, that almost nobody would read it.

That is not a criticism of the team. It is just how people work with documentation everywhere: when someone is blocked in the middle of a task, they do not open a long guide and search through chapters. They ask a colleague, or they try random clicks until something works, or they ping the admin. With go-live two weeks away, I could see my own future clearly: I was about to become a human FAQ.

The idea: an AI agent living directly in Microsoft Teams, where everyone already spends their day, loaded with the full knowledge of how DIMS works at every user level. If someone is blocked, they ask the bot. If the bot can resolve it, done in seconds. If it cannot, it creates a support ticket for a human automatically. Nobody stays stuck, and nobody has to read a manual.

Why n8n won

Our user guide lived in Notion, and that single fact decided the architecture. The obvious first candidate was Microsoft's own Copilot Studio, since we are an M365 organization and a Teams bot from a Microsoft tool sounds like the natural path. But there was no workable way to connect Notion as the knowledge source. Our source of truth could not reach the bot, which made the natural path a dead end.

n8n solved this in one workflow. It has an AI Agent node where you can attach memory, connect any LLM you want, and hand the agent tools, including Notion as a live knowledge source. Instead of exporting and syncing documentation into a separate bot platform, the agent reads from the same Notion pages the team maintains. When the guide updates, the bot's knowledge updates with it. No second copy of the truth to keep in sync.

The rest of the stack fell into place around that: Anthropic's Claude as the reasoning model, n8n's native Microsoft Teams trigger for receiving and answering messages, and Asana for the escalation path.

The escalation design: knowing when to hand over

A support bot that pretends to know everything is worse than no bot at all, especially in the first weeks of a new system when trust is fragile. So the agent is designed to be honest about its limits. When a question falls outside its knowledge scope, it says so directly. And after answering, it checks whether the answer actually helped.

If the user is not satisfied, or the question is beyond what the documentation covers, the agent offers to escalate, and upon the user's confirmation it automatically creates an Asana ticket for the admin team to review. The user confirms with one message and gets a guaranteed human follow-up. That confirmation step matters: the user stays in control, no ticket spam is generated from casual questions, and every escalated ticket represents a real gap worth a human's attention.

There is a quiet second benefit here. Every escalation is a signal about what the documentation does not cover. The bot's failures became a to-do list for improving the guide itself.

The bot that talked to itself

The hardest problems were not the AI parts. The hardest problem was a loop.

The Microsoft Teams trigger in n8n listens to messages in the chat. The bot's own replies are also messages in the chat. You can see where this is going: the bot answers a question, the trigger fires on the bot's own answer, the bot answers its own answer, and suddenly you have an agent having an enthusiastic conversation with itself. Configuring the trigger with an exception so the agent ignores its own replies took real fiddling, and it is exactly the kind of unglamorous production detail that no tutorial prepares you for.

The second challenge was softer but just as important: tuning the agent's language and problem-solving behavior. Out of the box, an LLM answers like an LLM. A support agent for non-technical colleagues needs to answer like a patient coworker: short, concrete, step by step, in the vocabulary of the system the person is actually looking at. Getting the prompt and agent behavior to that point was an iteration loop of its own.

Two weeks, start to shipped

The whole agent went from idea to working in two weeks, in time for the go-live it was built to support. All 18 DIMS users across the foundation can ask it anything about the system, at any user level, directly in Teams. Questions that would have been a ping to the admin or fifteen minutes of trial and error are now a chat message. And when the bot cannot help, a human is automatically in the loop through Asana, so no question ever just dies.

The takeaway

Documentation does not fail because it is badly written. It fails because it sits somewhere people do not look, in a format people do not use. The lesson from this project: do not fight that behavior, design for it. Meet people in the tool they already have open, answer in seconds, and be honest about what you do not know. The best user guide is the one that answers back.