Frequently Sprint scope changes

Do you have a vision for the Product and a clear understanding of the value you need to maximize?

The scope - the body of work selected for the Sprint - is not fixed. The commitment that the team makes is not to the body of work, but to the Sprint Goal. As long as the Sprint Goal remains intact and achievable, the team may choose to change the body of work for the Sprint.

If the team is performing support work that may come up during the Sprint, they should consider the likelihood of having to take on this unplanned work during Sprint Planning and adjust their Sprint Goal accordingly. If the unplanned work doesn't materialize, there's always a Product Backlog of refined work that the team can choose from, in addition to being able to dedicate time to building skills or improving the tools and processes used by the team.

A primary responsibility of the Product Owner is to maximize the value being delivered by the team every sprint.

• Do you believe frequent additions to sprint scope help or hurt the team's ability to deliver value? 
• Does the team have a say in whether the new customer request can be accommodated in the current sprint, or what might need to be shelved to make room for it?   
• Does accommodating the new request jeopardize the Sprint Goal?

sprint scope that always changes with new client demands or new hotfix

Those are 2 completely different issues.  Hotfix is a support issue and it indicates that there could be quality problems with the work being done.  Every hotfix should lead to a discussion on why it was required and how to prevent them in the future.  That will help to mitigate the risk and remove an impediment to the team's ability to deliver on their Sprint Goal.

The "new client demands" are something that you, as Product Owner, have some ability to influence.  If the client is constantly demanding new work or changes, it is your responsibility to manage that and protect the Developers from the impact.  How many of these "demands" really had to interrupt a Sprint and be addressed in a month or less (suggested max duration of a Sprint is 1 month).   Could it be that these "demands" are fueling the hotfix situation?  Is the "demand" understood well enough for the Developers to start addressing or could some further refinement help to improve the solution? 

If you are having as much turmoil as you make it seem, it sounds to me that the Scrum Team may be moving too fast to deliver things and are not fully understanding the stakeholders' needs before starting work.  

So have you any process to apply when facing this type of situation?

Yes, I do.  It is called empiricism.  Do something, inspect the results, adapt if necessary.  Has your team put effort into inspecting what is happening and how it could be prevented?  I'm not talking superficial things like "the customer demanded something new so we had to quit working on what we were trying to do".  The real questions are "why is the costumer constantly demanding new things?", "Why do we have so many hotfixes?", "What could we do differently than dropping everything to react?", "What can be done other than complain?".  Have the team be critical but not of each other or the customers.  They need to be critical about how they work, how information is given, received, and processed.     

You should think about retraining your client.  You've gotten them into the habit of expecting you to react immediately.  

Try super short sprints - and then tell them "I'll do what you're asking, just wait until we finish this sprint".  

I've been able to do this with 1 week sprints.

If you don't say no some time, you will not be able to do anything strategic.