How to estimate and track new improvement and customer support for a legacy software

Several things stand out to me.

It's not clear why the "Customer Satisfaction Department" can demand that a problem needs to be solved quickly. Although it makes sense that they receive reports of issues with the product and can provide information about the frequency an issue is occurring and what the impact is to end-users, the product's Product Owner is ultimately responsible for managing the Product Backlog. Managing the Product Backlog includes ordering the potential changes to the product in a way that maximizes value for stakeholders. Ideally, we want to prevent defects from getting into the product in the first place, and quickly removing defects that are delivered. However, we don't live in an ideal world and sometimes delivering other changes is more valuable than fixing a known defect when we don't have the ability to do both.

The fact that a release is planned out for 3 or 4 Sprints is also somewhat concerning. In Scrum, a potentially releasable product Increment should be produced at least once per Sprint. This doesn't mean that it needs to be released, but that it can be if there is value. It may be true that it may take 3 or 4 Sprints to get to a state where the new functionality is fully ready for use, that doesn't eliminate the desire to ensure that the system is potentially releasable every Sprint and that release could include other changes (such as defect fixes).

I would suggest getting some data regarding how much time or effort is being spent on customer support tickets. Similar to how the team allocates time for Product Backlog Refinement each Sprint, the team can also reserve some time for customer support each Sprint. If the burden of support happens to be lower, it just means that more time can be spent on the new functionality. Understanding the capacity of the team plus the amount of time to be reserved for various tasks (like refinement and support) can be useful for Sprint Planning.

I'm not sure that I would recommend dropping Scrum's cadences just to get away from time-boxes. In my experience, it takes a lot more discipline on a team to work in a just-in-time fashion, especially when it comes to reflection and improvement through retrospectives (or similar events). The emphasis often shifts to moving work items through the process, rather than understanding customer needs and delivering valuable solutions.

I don't mean to say that Scrum is definitely the right solution to the context your team is working in. Perhaps it's not. At this point, though, I don't see any compelling reasons to make drastic changes. If you're interested in improving flow, one possible starting point would be to gather some more data. The flow metrics from Kanban - work-in-progress, work item aging, throughput, and cycle time - may be a good starting point. I'd recommend the Kanban Guide for Scrum Teams. Getting more information on flow can help you make more informed decisions about potential changes to the process.

Is there a clear Product Owner who is accountable for the value of this work, including any customer support, and is it all captured on a single Product Backlog?

You have two very good responses above if you are truly considering introducing the Scrum framework.  However, since you are a Project Manager you will have to make a lot of changes in your practices and the organization as a whole will have to change in order to provide an environment where the Scrum framework has a chance to be successful. You do not plan out releases for 3-4 Sprints when using the Scrum framework.  You plan a single Sprint, execute that Sprint to achieve the Sprint Goal, learn from what was done and how it was done, then start over again by planning a single Sprint.  You do not need immediate feedback, the Scrum Team needs feedback from the stakeholders.  In the situation you described the "Customer Satisfaction Department" would be stakeholder but they have say in how the Scrum team organizes it's work. 

My recommended practice, whether in the Scrum framework or a home grown "Agile" process is to treat all changes needed to the product equally.  There is no such thing as a bug.  That is just an opportunity discovered by the users of the product.  All opportunities are represented in the Product Backlog in the same manner. All changes should be ordered together by weighing the value and benefit of each body of work against the others. Notice I said ordered and not prioritized.  There can be situations where a lower priority item can deliver more value and take less time to do.  If an opportunity surfaces that warrants immediate attention, the team doing the work gets to decide how to take on that work and whether there is something already planned that needs to be moved back to the Product backlog. 

Anytime you work with an interrupt driven process you will have difficulties meeting goals, whether they be Sprint Goals as described in the Scrum Guide or milestones that exist in your Gantt Chart project plan. In this scenario, you should never plan or forecast based upon teams being solely focused on that work.  This goes beyond the standard practice of forecasting based upon 80% of a person's time being used for work. But you need to have some level of understanding on the effort expended over time on the unplanned opportunities.  

Thanks you very much for your rapid responses guys. 

You are right, the accountability of the PO is not as we desire, and also I am dealing with the information problem, at the beginning of my time in this company the info was not clear. So I had to dive deeper in the tickets of improvements and customer support in order to get more data and also build some labels and fields so I can make better filters. 

Now I have a clearer idea of how to steer a Sprint Planning, I consider as a PM - trying to get into the Scrum Framework - I have to support the PO managing the Prod Backlog and sort it out as it has to be. 

Anyway, I will take in account all the recommendations and points of view of you guys. 

Thanks a lot!

Best Regards