I'm the only sysadmin at my company, and management constantly sends over "quick" requests for custom CRM workflows, unusual phone-system routing, reports, and third-party integrations. Since many of these ideas are technically possible through an API or webhook, the expectation is usually that I should just make them work.
The problem is that every one-off solution creates permanent support debt. There is rarely any requirements gathering, testing, documentation, ownership, or maintenance plan, and I'm the person who gets stuck supporting the custom workflow when it fails—often while more important infrastructure and security work is waiting.
I'm trying to establish a reasonable boundary between "the vendor technically supports this" and "this is custom software that a single administrator cannot safely maintain." How do other solo IT administrators handle these requests? Do you use a formal intake, change-management, or prioritization process, or do you push back one request at a time?
One current example involves generating highly detailed phone-system reports. The system appears to handle scheduled reports poorly when many are sent at once, and its newer version only sends them once per day instead of at selected times. Fixing that would require building custom job handling around a system that has no native queue or error-state support.
4 Answers
Have leadership rank the work instead of labeling everything as high priority. Explain that routine support, infrastructure maintenance, security, and custom projects all compete for the same limited hours. If they want a new customization treated as urgent, they should explicitly identify what existing work gets delayed. It is also worth documenting the maintenance burden and using that evidence to justify additional staff or a decision not to build unsupported features.
For the phone reporting issue specifically, a queue or scheduled job could help only if the phone platform actually supports it. If it does not, describe the proposed workaround as custom software with development, testing, monitoring, and failure-handling requirements—not as a simple configuration change.
Use lightweight change management rather than trying to implement a huge framework. Require a business justification, the benefit of doing the change, the consequences of not doing it, expected cost, testing requirements, ongoing support needs, and a named business owner. Have at least one other leader review and approve it so you are not the sole person deciding whether the request is worth the risk. Even a small amount of intentional friction filters out a lot of bad ideas.
Put every request through a ticketing system, and make the requester provide enough detail for someone else to understand the work. A simple rule like “no ticket, no work” eliminates most drive-by requests because people usually decide the idea is not important enough to document.
That’s the direction I’m leaning. I can ask people for the ticket number before discussing the work, and a surprising number of requests may disappear before they get that far.
Gather related requests and schedule a planning meeting instead of accepting them individually. Ask the requesting team to supply concrete details such as users, queues, report definitions, acceptance criteria, and someone available for testing. If they cannot provide those basics, the work is not ready to start. This also makes it clear that the requester owns part of the project rather than handing you an undefined problem.
Once requesters have to explain the value and participate in the decision, the supposedly urgent changes tend to become much less urgent.