If you are using eight classes, then you are probably overthinking it. You want most traffic to be in the default class, protect real-time traffic with a priority class and policing, make sure that things like bulk transfers cannot hog your links, have a class for control traffic, and, possibly, a class for special applications. Once you hit six classes, you are probably trying too hard, and anything beyond that needs to be rethought. You can start with four (maybe five) basic classes, then, in the future, add a class for something special if it really needs it.
QoS is all about fairness, as you need it for your network. Only you can really determine the percentages required to implement your QoS fairness policy, and you should do that from a position of knowledge about how the traffic is actually using the network. Look at things like NetFlow reports, calculate packet overhead (VoIP has a lot of very small packets with a lot of overhead, but other traffic has much less overhead because the packets are larger). Also, remember that, by default, you cannot use 100% of the interface bandwidth.
Whatever percentages you start with, be prepared to tweak them as you get your reports after implementing QoS. This process will need to be closely monitored for a while after you implement it, and then checked periodically afterwards as things change in the network.
Be sure to mark your traffic as close to the source as possible, e.g. on the access switch where the traffic enters the network, so that it can be treated in the entire network. You should be able to trust marking from VoIP phones, and do not make the mistake that many people do about marking everything on a VoIP VLAN as
EF because the VoIP data and control traffic should already be properly marked, and the VoIP control traffic should not be marked
EF. Also, remember that your QoS markings and policies will not be honored on the public Internet. You can treat outbound traffic from a device, but inbound traffic has already used the incoming bandwidth by the time you see it. Shape outbound and police inbound. TCP will react to the inbound policing, but UDP will not. You can also use techniques like WRED.
Simply designing classes and percentages without studying the actual network traffic is a rookie mistake that can lead to chaos on your network. Find where there is congestion, and why there is congestion there, then design the QoS markings and policies to allow under-served traffic the necessary percentage, but balance it so that you do not under-serve other important traffic. Remember that QoS is not a substitute for proper bandwidth. QoS can help you use your existing bandwidth more fairly (as you see it), but you may need more bandwidth to actually do what you want.