Sorry, Ambika.
Having correct bandwidth configured( 40 MB) on the interface will result in correct Bandwidth percentage calculation for the classes of all the sites & help in getting adequate/ correct response for them.
Completly disagree with you.
You might have missed the idea how QoS policies working.
The ашкые most important thing to discuss in this case - is a bandwidth of the priority class[es], as it's setting minimum and maximum warranted bandwidth for voice traffic. If value is lower that expected (294K vs. 800K), then CIR won't be warranted and customer could suffer.
We do not care about bandwidth per classes CONTROL, CRITICAL and etc., as bandwidth values are accounted relatively to other classes, so Class1=100K/Class2=200K is equal to Class1=1000K,Class2=2000K. If relative wieghts are good (aka scheduling), then queueing becomes second important thing.
Per site shaping is done under classes inside parent policy applied to the interface and it has no general shaper, but shaper per class only. So we need to understand how queuing will work in case of congestion (more than 40M)!
Actually, the interface is Fe or Gi, so it can send with 100M or 1000M. As a result it will be sending unless peer does some sort of push-back (but providers are not used to do such things). If you exceed 40M and you (actually ISP) have QoS defined on PE, then you could expect that provider will be dropping packets per your policy, if not then simple tail-drop will occur on some "stupid" L1/L2 device.
Queueing per site is done by shaper, but it's only makes us sure that remote (site's) link won't be overutilized.
So, going back to our discussing. Having bandwidth 40M on the physical interface has no use, as it won't affect overall bandwidth that could be used. Maximum allocation is defined by summ of shapers' CIR.
If to be polite, I'm not sure, how your LLQ works, as your design is not common. My concern is: priority queue from SITE_1 could compete with other classes of SITE_2 - in this case jitter will occur.
Per my understanding, you should be running policy like this:
policy-map WAN_OUT
class class-default
shape aver 37000000 370000 0
service-policy QOS_OUT
policy-map QOS_OUT
class RT-VOICE
priority percent 20
police ... ! would recommend to police here, as ISPs do not like voice traffic to burst over contracted bandwidth and hard-drop it.
class RT-VIDEO
bandwidth percent 25
class CONTROL
bandwidth percent 3
class CRITICAL
bandwidth percent 18
random-detect dscp-based
class IMPORTANT
bandwidth percent 16
random-detect dscp-based
class TRANSACTIONAL
bandwidth percent 14
random-detect dscp-based
class class-default
fair-queue
PS: if your ISP sells you 40M, you'ld better ask them how do they count it... it could be "bits on the wire" or L3 bytes count; 1M could be 2^20 or 1000000. ISPs used to sell bits on the wire (so per packet you need to add 18 bytes for L2 header), so for 40M I would configure shape average 37000000.
My investigation all started when 1 site out of 24 was getting slow responses on a certain application. The factory could not print packing labels fast enough to keep up with production. On investigation I found about 25% of the packets to this one site were being remarked from AF31 to 0. I have been working with the ISP on this and they say they do NOT remark packets. They monitored ingress from my Head ensd site and all packets were AF31, they cannot monitor egress at the remote site, so today they are coming out to monitor their Cisco ME3400 router on my site to see if the packets get remarked there. 
