I'm the only systems administrator at my company, and I'm drowning in requests for custom CRM workflows, unusual phone-system routing, third-party integrations, and highly specific reports. Every request is presented as urgent, but there's rarely any requirements gathering, testing, documentation, ownership, or discussion of long-term support.
Because the APIs and vendor platforms technically support many of these ideas, leadership assumes that "possible" means "the solo admin should build it." Once implemented, though, I become responsible for maintaining every custom workflow indefinitely, often while basic infrastructure, security, and documentation compete for the same limited time.
I'm trying to establish a practical boundary between "the system can do this" and "this is not sustainable for one person to build and support." Do other solo administrators use a formal intake, change-management, or prioritization process that leadership actually follows? How do you push back without having to reject every request individually?
One current example is a request for 50–100 individualized phone-system reports to be sent in bursts. The platform was not designed for that reporting pattern, and its current version only sends reports once per day rather than at configurable times. Meeting the request would require building custom software around a system that has no built-in job queue or useful error handling.
5 Answers
Start with a ticketing system and make the ticket the entry point for all work. Drive-by requests usually decrease once someone has to describe the request, its business impact, needed deadline, and who will validate the result. A simple rule like “no ticket, no scheduled work” creates a defensible process without making things overly bureaucratic.
Your manager needs to prioritize the work publicly. Explain that support, security, infrastructure maintenance, and custom projects cannot all be priority one. For each new project, show what maintenance will be delayed and estimate the ongoing support burden. If leadership wants more project work, the discussion may need to include additional staffing or a vendor. Keep documenting everything so the organization understands the real cost and someone else can take over if you eventually leave.
In a flat organization, write down the competing requests and ask the relevant leaders to choose the order. That turns conflicting verbal instructions into an explicit business decision instead of leaving you to absorb all the risk.
Use lightweight change management. You do not need a full enterprise framework, but every nontrivial change should include a business justification, the consequences of not doing it, expected users, testing requirements, documentation, support ownership, cost, and an approver who is not you. A small review group or manager approval step makes the business choose what is actually worth consuming your limited capacity.
Requiring the requester or department to participate is an effective filter. Once they have to provide details and commit to testing or ongoing ownership, many “urgent” ideas lose their urgency.
Have requesters collect related changes and attend a planning meeting. Listen carefully, then list everything their team must provide: queue names, user lists, report definitions, acceptance criteria, owners, and deadlines. Do not start until those inputs arrive. This keeps the responsibility from silently shifting to you and makes stalled requests visible.
Treat even “emergencies” as needing minimal intake and triage. A one-page form or short ticket can capture the problem, impact, deadline, requester, approver, rollback plan, testing, and long-term owner. Include the cost of maintenance in the proposal. If someone refuses to provide that information, the request may not be urgent enough to justify a custom system.
For the phone reports specifically, do not assume that adding a queue or scheduler is a small configuration change. If the vendor platform lacks those capabilities, present it as a separate software project with development, monitoring, failure handling, upgrades, and support requirements.
It also helps to ask people for the ticket number whenever they bring up a request verbally. If they never submit one, the request usually was not important enough to pursue.