TLDR: Get yourself a ticketing system if you don’t already have one, and use it to manage and document your tasks. All of them, no exceptions.

When I got my first post-college job as a software developer, it was with a Managed Services Provider (MSP). For those of you not in the know, MSPs are effectively outsourced IT for organizations that can’t or don’t want to maintain an internal IT staff of their own.

I happened to be the only developer on staff, the rest of my coworkers were various levels of Help Desk and equipment technicians. It was a small group of us, no more than a dozen people, but that was enough to support at least two dozen client companies.

Even operating independently from the technicians, I still had half a dozen regular clients I needed to provide development and support services to. This was the environment where I cut my teeth on actual customer support, and discovered the importance of having a ticketing system.

With a single client, you might be able to get away with email chains, hastily scribbled notecards, and a text file here and there with notes, but your performance will suffer and things are likely to start falling through the cracks simply because there is too much going on.

Once you scale up to working with multiple clients (which includes multiple users having issues within a single company), that sort of ad-hoc system will quickly become unusable. When you operate with many potential sources of tasks, you need to keep things organized in a more formal fashion.

This can be as simple as a Trello board, a self-hosted ticketing solution like FreeScout, or even a SaaS like JIRA. The important thing is that you need to have a single source of truth where task information lives.

Once you have that ticketing system, use it. If it isn’t in the ticketing system, it doesn’t exist and it never happened. If it isn’t important enough to make a ticket, it’s not important enough for you to work on.

Yes, this will take some time for everyone (including you!) to get used to and build up the proper habits. I deal with this regularly as new users come onboard at my clients, and they have to be trained to not try to message myself or other engineers directly. Instead, it all comes through the ticketing system.

While it might seem draconian to force everything into the ticketing system, the benefits I’ve seen to this approach are more than enough to justify it:

  • Issues and tasks never disappear into the void.
    • They might get shuffled to the bottom of the pile and forgotten amidst a flurry of other tickets, but they (and the precious information they hold) never completely go away. They’ll sit around until the higher priority tasks get completed, and then finally get worked on.
    • This will do wonders for your stress and anxiety. It’s awful to lay awake in bed at night wondering if you forgot an important task that someone asked you to do, but you can’t remember anything about who or what it was. If it all lives in the ticketing system, you’re no longer responsible for remembering it all.
  • Problems and solutions are documented and searchable.
    • There’s very little more frustrating than remembering that you solved a particular issue 5-6 months ago, but being unable to remember what you did to solve it. If you document it in the ticket as you work it, then all you need to do in the future is search for the appropriate keywords and then read the old ticket that pops up.
    • This also has benefits for CYA; as a professional, you always want to be documenting when a decision was made and by whom. If it’s always documented in the ticketing system, you’ve got far more power and protection than you would if it was just your word against an angry client swearing up and down that they “never said that!”
  • Prioritization is easier.
    • Instead of having a rough list of tasks that need to be done, you have a very clear list of what is on your plate, and what their priorities are.
    • When the client comes to you with an urgent new task, you can clearly show them the current list of tickets and ask where it should go in the priority list. This empowers the client to decide what should be worked on first, while also removing the always-frustrating cries of, “They’re all a priority!” that only set you up for failure.

Whether you’re supporting an entire team of 30+ developers, or just managing requests from a single client while trying to get their MVP up and running, a ticketing system is almost certainly going to improve your operations and reduce your stress level. That sounds like a win in my books.

p.s. A few nice-to-have features you’ll appreciate having:

  • An email connector so that you can auto-generate tickets from client emails. Yes, occasionally this will be an annoyance due to merging tickets. Yes, it’s still worth it for getting information into your ticketing system without having to manually copy it from emails and Slack DMs.
  • A distinction between internal notes that are attached to the ticket and client notes that the clients can see (and get email updates on). Very often you’ll want to document something specific to the ticket for later reference, but it’s completely irrelevant to the client (or would be taken badly). Regardless of the reason why, you’ll appreciate having the two different types of notes.