Policies you apply for outbound traffic, will provide most anything you want for outbound management.
Policies you apply for inbound traffic, might "influence" bandwidth consumption, coming to you, and cannot control traffic prioritization for the inbound traffic. You can, though, further limit what bandwidth your downstream clients receive.
Perhaps to make this clear, consider we have four clients, each send us, outbound, 100 Mbps, but we only have the 300 Mbps link. As we control that outbound 300 Mbps, we can manage what happens to the 100 Mbps excess, and further decide how to prioritize the clients usage of the, now congested, 300 Mbps.
However, now consider the converse, your four clients attempt to pull down 100 Mbps each. It will also congest on the far side's egress, but how is excess managed? How can some traffic be prioritized? Basically, we control neither, as we don't manage the far side's egress. (Usually, your far side service provider will just let your four clients' traffic battle it out, among themselves, using a FIFO and BE "rules" (which, on average, would probably account for about a 25% drop rate on each client's 100 Mbps stream).
Once we receive the 300 Mbps (with potentially 25% dropped from each client's stream) what do you want to do? You can, certainly shape/police each client's stream to whatever max rate they are entitled to. Let's say, we police all four clients to 50 Mbps each. Okay, we then only forward, locally, 200 Mbps, which fits well into our overall 300 Mbps. Yet, does that immediately, reduce our overall received rate to 200 Mbps? No, it does not. Does that, immediately, reduce the far side's 400 Mbps to 200 Mbps. No, it does not. However, if this traffic is TCP, the drops both on the far side egress, and our policed drops, will both get the TCP sender's to slow such that the drops stop happening. However, TCP, once the drops stop happening, will start to increase transmission rate, until drops happen again.
BTW, actually, the just described overate happens on our side too. The difference is, turn around time to inform sender, on our side, is faster; we selectively queue, allowing transient bursts (far side queuing setup?); we can selectively drop traffic from some flows and not others (far side?); and we can prioritize when traffic is congested (far side?).
Yes, we can, often, "influence" traffic coming to us, but the granularity of effective traffic management, is hugely different between managing inbound vs. outbound traffic.
Years ago, I was in a situation with a campus of about 2,000 users with a pair of Internet connected T-3s (45 Mbps each), which were being totally overwhelmed by bandwidth demand. There was much I could do, and did, to deal with outbound traffic, but for inbound, I even went to the extent of shaping returning ACKs. All I can say, my efforts went from making Internet usage from useless, to horrible. We very much needed more bandwidth, or management on far side, which SP, wouldn't provide (they very seldom do, more profitable to "sell" you more bandwidth). We got more bandwidth, problem solved.
Your 300 Mbps, hopefully, isn't being hammered. Most of the time, I suspect, your companies, will get the bandwidth they expect. However, again, unless you control the far side, you cannot truly guarantee, inbound bandwidth.
Again, let's say you policed all your 20 customer companies to 10 Mbps, i.e. 300 Mbps not exceeded. True, every customer company will not get more than their 10 Mbps, but as the far side can congest with traffic beyond 300 Mbps, what happens then?
Also true, if TCP traffic, the aforementioned policers should, cause TCP to average near 10 Mbps, but TCP transmission rate will, for a bit of time, exceed the 10 Mbps.
As most traffic uses TCP, effectively managing it, requires understanding it. Not knowing how well you understand TCP, I've provided two references. The first has a nice animation in it too.
https://witestlab.poly.edu/blog/tcp-congestion-control-basics/
https://courses.cs.washington.edu/courses/cse550/16au/notes/lect16.pdf
