There is a major issue with having a lot of branches (and features) waiting for approval by clients. Mainly if clients do not test immediately and accept the work, the branches will not be merged into the main branch. This is a problem because other features will want to depend on this work and merging branches will become a real drama when your branches diverse for too long. Overall this sounds like a failing strategy.
I would try to keep just one test branch in which all features are merged continuously. Now to let clients test their requested feature I would suggest to try feature toggles. For each users you enable a feature with a toggle. Now the client can test the feature and when accepted you enable the feature for all users and you prepare it for deployment. This by either removing the feature toggle totally or by just enabling it for some users.
Do keep in mind that feature toggles are essential technical debt. You need to remove them as soon as possible or make them part of a right-system if you want do not want to enable this feature for 100% of the users.
Now having only one branch with all the finished work simplifies everything a lot, certainly when you have a lot of features that need accepting. Experience learns clients do not make time to accept work, maybe you can skip the test phase all together and just push changes into production by using feature toggles and remove them after you confirm the client is happy. My personal goal is deliver continuously, each commit should go into production to get the fastest feedback as you can. Unless you build life or dead applications, maybe testing in production is not such a good idea then.
Do think about what is the simplest thing possible and keeping the flow optimised so that developers can keep building on their previous work even if it is not yet accepted. Try to keep the number of open feature branches as low as possible at all times, since this will make the life of developers so much easier.