Some projects start with an idea. Others evolve from a problem you keep trying to solve better. OpsOnTab is one of those projects.
Years ago, I started building small tools in Microsoft Access to organize operational work. They weren’t intended to become commercial software. They were practical solutions to problems that needed to be fixed.
As the technology available to me changed, so did the solutions.
I later built help desk and ticketing workflows using Microsoft Forms, Power Automate, and SharePoint Lists. Eventually, those solutions evolved into more structured applications backed by SQL and built with Power Apps.
The implementations changed, but I kept running into the same underlying problem.
Organizations have procedures in one place, tasks somewhere else, tickets in another system, and conversations happening through email or chat. Each individual tool may work perfectly well, but the relationship between the work can easily get lost.
That experience eventually became the idea behind OpsOnTab.
Connecting the work, not just tracking it
OpsOnTab is a Microsoft Teams application built around a simple workflow:
SOP → Task → Ticket → Done.
An SOP shouldn’t necessarily be a document someone reads once and forgets about.
It can define how work should be performed. That work can become a task. A task can contain processes, phases, and individual steps. When one of those steps requires attention or an issue needs to be addressed, a ticket can be created while maintaining the connection to the original work.
The goal isn’t to add another system people have to remember to check.
The goal is to put operational work inside Microsoft Teams, where many organizations are already communicating and collaborating every day.
More than a help desk
Although ticketing is part of OpsOnTab, I don’t see it simply as another help desk application.
The application currently brings together SOPs, tasks, tickets, reporting, approvals, notifications, and access controls so that operational knowledge and operational work can live closer together.
For example, an organization can create and publish an SOP, control its audience and approval process, turn that procedure into assigned work, and create tickets when something within that work needs attention.
That connection is the part I’ve wanted to solve for a long time.
Built for Microsoft Teams
OpsOnTab runs directly within Microsoft Teams and can be deployed privately to an organization’s Microsoft 365 tenant as a custom application.
That private deployment model is important. Microsoft supports organization-specific Teams apps that are distributed within a tenant without being publicly listed in the Teams Store, with administrators controlling their availability.
OpsOnTab is ready for this type of private deployment today.
I’m also working toward making it available through the public Microsoft Teams Store, which will make discovery and deployment easier for organizations that don’t want to manage a custom application package.
A long time coming
What’s most interesting to me about OpsOnTab isn’t necessarily any individual feature.
It’s seeing an idea that started with an Access database years ago evolve through several generations of technology and finally become a complete application inside Microsoft Teams.
Along the way, I’ve learned that solving operational problems isn’t usually about finding the newest technology.
It’s about understanding the problem, building something useful, seeing where it falls short, and continuing to improve it.
That’s the philosophy behind OpsOnTab: use technology to solve real operational problems.
If your organization is interested in trying OpsOnTab, it’s available for private Microsoft 365 tenant deployment now.
I’d be glad to discuss your use case, help get it set up, and hear your feedback.
Learn more at opsontab.com