This page is not a list of logos. It is a map of the kinds of servers unreel builds for, and how the bots fit into their actual flows: rivals, staff-heavy spaces, internal setups that treat Discord like critical infrastructure.
Each server gets its own flows. There is no default template it has to squeeze into.
Bots are designed to stay quiet unless they have something specific and useful to say.
Staff tools are shaped around how real people use Discord during late incidents.
This is not a catalogue; it is a way to think about the kinds of servers unreel tends to say yes to. Yours might sit between a few of these shapes.
These servers need bots to keep match flows, tickets and queue states tight. Players see clean surfaces. Staff see richer context hidden behind controlled entrypoints.
How staff see the system on a busy day: panels, commands and quick reads.
The central loop that the bot helps move forward without adding noise.
What needs to be remembered between events and how it is kept traceable.
What happens when something goes wrong and how staff can see that quickly.
These are not \"products\" with rigid menus. They are modules that get wired together differently based on what your server is trying to do.
Bots that keep tickets tidy rather than spraying threads across the server. One clear place to see what is open and who is on it.
Entry, routing and closure flows are designed to match how your staff already think about incidents.
No assumptions about categories or layouts. The system adapts to your structure instead of forcing a template.
Small surfaces where each action matters. The goal is to make a panel that a new staff member can learn in minutes.
Buttons are chosen based on real incidents, not generic admin tools. If it is rarely used, it might not need a button.
Panels are opinionated but adjustable as your team uses them and finds missing controls.
Carefully scoped automations that handle repetitive work without making the bot feel unpredictable or overpowered.
The automation is allowed to be smart, but not allowed to be mysterious. Staff should always feel in control.
Every automatic action should be explainable after the fact using logs or a simple trace.
Instead of drowning staff in charts, the bots send focused signals when something crosses a meaningful line.
Signals are contextual, pointing toward the next action rather than asking for a detailed investigation every time.
Most of the time, no alert is the best alert. Silence means the system is within expected ranges.
The exact code is different per project, but the mental model stays predictable: a few nodes passing responsibility between each other.
where the event first touches the bot
In each server, these conceptual nodes are backed by real code and storage, but the mental model stays the same. Events come in, they get routed, state updates, staff see a slim view, and a trace is kept behind the scenes.
The point of this shape is not visual complexity; it is being able to reason about the system on a busy day without opening an editor.
The conversation begins with real channels, real roles and real pain points. No imaginary perfect server, just the one you are actually running.
Together, you map what needs to occur when an incident or request appears. This becomes the backbone of what the bot will move forward.
Channels, buttons, panels and messages are decided early so nobody is surprised where the bot shows up.
The server gets a working version as soon as it is safe, then the details are tightened while it is under real traffic.
The goal is not to replace staff. It is to give them bots that handle repetition and state, while humans handle judgement and context.
A member raises an issue that needs staff attention.
Write short responses, close tickets, escalate when needed.
Guide entry, attach context, keep tickets visible and clean.
Something breaks, escalates or starts behaving strangely.
Use panels and logs to read what actually happened.
Record transitions, surface signals, keep one source of truth.
Players or members are waiting for something structured.
Oversee the flow, intervene when needed, adjust rules.
Keep the queue moving, enforce rules, reduce manual juggling.
Things that do not need live attention but must be tracked.
Check summaries, trigger occasional manual corrections.
Perform small repeated tasks, log outcomes, avoid surprises.
unreel’s work aims to feel premium on the outside, but the parts that matter most are the ones that are invisible until something breaks.
Bots are built so you can know up front what they will not do. Clear boundaries are part of the design.
Important actions leave behind enough detail that staff can reconstruct what happened without guessing.
When something fails, it does so in ways that keep your server safe rather than flooding channels with noise.
Staff are given ways to override or correct the system without fighting it, especially during incidents.
Sometimes a server has a moment that is just pure blehh. The bots cannot stop those. They just make sure the tools are sharp when it passes.
There is no public list of servers and no broadcast of metrics. If this page feels like the right level of obsessive, the next step is just a single DM.