You are missing processes, not tools. Specifically, you are missing a formal change-management process that handles your bugs, content updates, and other important tasks in a controlled fashion.
At a basic level, change management can be thought of as a process for identifying, controlling, and tracking changes within a system. Currently, your change management process is ill-defined because:
- It consists of a pool of emails, which isn't easy to search, manage, or prioritize.
- It's hard to enforce administrative controls like formal sign-offs via email.
- It's unclear from your post who (if anyone) is responsible for email intake, prioritization, resource allocation, assignment, or sign-off. These things may not even be formally defined within your organization at all.
- Your current process makes no distinction between bugs and new work.
Change management, and to a lesser extent bug-tracking and feature planning, should be formal processes that are well-documented and consistently applied. Even an email-based queue could theoretically work just fine if the process itself was properly defined, documented, and followed within your organization.
Recommendations for Improving Your Process
First, apply CodeGnome's Law:
"Define your process, then automate it."
That means documenting your as-is processes and procedures for managing bugs, new content, or client change requests. It's generally best to document what people are really doing, rather than what they ought to be doing, but either will give you a baseline. This can be time-consuming, but it an essential starting point.
Next, determine where your as-is process is not being followed (often a sign of processes that hinder rather than help), or where following the process actually provides poor results. This will help you evaluate the design- and operational-effectiveness of your current processes, and identify areas that could be improved through process engineering.
Then, define your to-be processes and procedures. For example, define the new intake process for content change requests, including the roles required by the process and the procedures that task-performers will need to follow to process the change requests properly. These new processes will form the backbone of your new-and-improved workflow, and should be simple, clear, and repeatable. Ideally, they should be things you can do with paper and pencil; automation comes later.
Finally, once you have a process that is designed to address your organization's specific needs and a set of procedures to implement those processes in a traceable and repeatable fashion, then and only then should you automate those processes. Doing it the other way around will pretty much ensure that your organization will contort itself to fit within the constraints of a generic tool, rather than automating its unique processes.