Put the support queue inside the system
The short answer
When a business system goes live, the work does not stop. Questions, problems, and ideas keep coming. On a current client build, a telecom company that runs its operations on a custom platform Opero built and runs, we put the queue for all of that inside the system itself. Anyone can raise a request from the page they are on, everyone can see where it stands, and the company owns the whole record.
The problem after go-live
The day a system goes live, a new kind of work begins. Someone cannot find a field. A report looks wrong. A manager has an idea that would save her team an hour a day.
Those arrive by email, by text, in a call, in a comment walking past a desk. Nothing is tracked in one place. The person who asked does not know what happened to it. Leadership cannot see what is being worked on or why. And the builder's own to-do list lives somewhere else again, in a project tool nobody else opens.
None of this is anyone's fault. It is what happens when there is no obvious place to put the request.
The idea: a Requests area inside the system
We built a Requests area into the system staff already use every day.
From any page, anyone can submit a question, a problem, or an idea. The system records the page they were on, so "the numbers on this screen look off" arrives with the screen attached. They choose an urgency: low, normal, or urgent.
They do not choose priority. Urgency is how much it matters to the person asking. Priority is a decision about everything competing for the same time, so the person running the system ranks the queue. That same queue holds the builder's own planned work. There is one ordered list of what happens next, and everyone can see it.
This is separate from customer support tickets. Those are about the company's customers. This queue is about the system.
Conversation on the record
Each request has its own comment thread with @mentions. Questions, answers, screenshots, and decisions all stay on the request instead of scattered across inboxes.
One small detail matters more than you would expect. Notification emails come from the person who wrote the comment, not from a no-reply address. When I answer a request, the email reads like a colleague replying, because it is one.
Who sees what
Visibility follows permissions:
- Staff see their own requests.
- Leadership sees everything, so they know what is being worked on and why.
- The person running the system manages everything: triage, priority, and status.
Measured from day one
Every request tracks two numbers: time to first response and time to resolution.
That turns "support has been good" into evidence. It shows what support actually looks like, which kinds of requests take longest, and where the system needs attention. It is also the basis for a support agreement with real response times instead of guesses on either side.
Built for AI-assisted work
Every request has a stable number and full API access. That means an AI coding agent like Claude Code can read the queue, pick up an item, make the change, link the code change back to the request, and close it.
Every request traces to the change that resolved it. Six months later, when someone asks why a screen works the way it does, the answer is one click away: the request, the conversation, and the change.
This fits a bigger shift in how I build systems. AI is the new admin console: configuration and changes are made by describing them, not by clicking through setup screens. The request queue is where those descriptions start.
Security is part of the feature
Requests carry screenshots and files, and those can hold sensitive information. So attachments are stored privately, scanned for malware before anyone can open them, and every download is logged. Permissions are enforced on the server, not just hidden in the screens.
A support queue is an easy place to leak data if it is treated as an afterthought. It is not one here.
The company owns the record
The queue and its history live in the client's own system, which the client owns. It is not in my tool.
That matters more than it sounds. Over a few years, the request history becomes the record of every decision and change made to the system. If the client ever changes providers, all of it stays with them. The next person can read exactly what was asked, what was decided, and what was changed.
One list from the start
On this project, the build tasks that had been tracked in a separate project tool were migrated into the queue. From then on there was one list: planned work, bugs, questions, and ideas, in one place, in one order.
Where this fits in how Opero works
Opero engagements move through three phases. Build gets the system live. Evolve keeps extending it once people are using it. Operate keeps it healthy for the long run.
The request queue is where Evolve and Operate actually happen, day to day. It is also where the client can see them happening: what came in, what was done, and how fast.
Part of a pattern
This is one of three ideas I now build into every system:
- Help built in. The system explains itself.
- AI as the admin interface. Changes are described, not clicked through setup screens.
- The request queue inside the system. One place to ask questions and raise ideas, one ordered list of what happens next, and a record the company owns.
Together they make a system that explains itself, improves in the open, and does not depend on anyone's memory, including mine.
Where Opero fits
Opero designs, builds, and operates custom business systems, and stays on after launch to keep improving them. See how the service works, or start with a free review.
Common questions
Is this the same as a customer support ticketing system?
No. Customer support tickets are about your customers. This queue is about the system itself: questions from staff, problems, and ideas for improvement.
Who decides what gets worked on first?
Users set urgency when they submit a request. The person running the system sets priority and ranks the queue, which also holds the builder's own planned work, so there is one ordered list of what happens next.
Why not use Jira or another separate tool?
A separate tool is one more login staff will not use, and it usually belongs to the consultant, not the client. Inside the system, requests are submitted from the page in question, and the full history stays with the company that owns the system.
How does this work with AI coding tools?
Every request has a stable number and API access, so an AI coding agent can read the queue, work an item, link the code change to the request, and close it. Each request traces to the change that resolved it.
Founder of Opero. Building software since 1998 and consulting since 2008, designing, building, and operating business systems.