I encourage you to collectively think about a different strategy for framing the problem. Rather than talk about BB, and then forever looping back and try to explain why it is important to non-network folks, develop a tool (or a skin for an existing tool) that estimates the suitability of a link to carry video conferencing and gamer traffic, using the language from those communities (e.g. "lag").
No explanation is needed to tell a gamer why lag is bad.
No explanation is needed to tell a musician why lag is bad for a distributed ensemble.
Very little explanation is needed to tell a VC user why lag is bad, since these days everybody has experienced it.
Keep the up front the language at the application layer, but down inside reveal that the largest culprit is often excess network queueing delay under load, AKA buffer bloat.
Although a well framed tool could have high impact, you would get even more bang for your buck to have a semi-standard jitter metric that could be grafted into any real time application. The goal would be to connect the observed (and measured) application lag to the underlying network jitter, queueing delay and bufferbloat.
Thanks,
--MM--
The best way to predict the future is to create it. - Alan Kay
We must not tolerate intolerance;
however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of control;
too weak risks being mistaken for tacit approval.