Here are two things we do. They aren't really a solution to lower than realworld SpeedTest.net exactly, BUT they do help.
1) One of the things we did was to have our own speedtest written which saves the results into a database locally. We encourage people to use not only SpeedTest.net, but also to use Fast.com and SpeakEasy and TestMy.net and BandwidthPlacecom as well as our SpeedTest program. We tell them that only our local SpeedTest script will be the only one which accurately tests their connection and our network, and which doesn't put ''the internet'' between us and some remote testing server 1/2 way around the world into the mix.
Then, when someone reports ''even your speedtest only showed 3.6 Mbit last night!!!'' we can go back and see by their IP how many times they've tested and what results were shown on their screen for each test. Sometimes that's 1 test per week for some cleints, but sometimes that's 20 tests per day. And since they don't know we store the results in a database, if that 20 times per day tester chooses to report his one 3.6 Mbit result, and fails to mention the 10 Mbit results that he got 60 seconds before and after... then we know he's a hypochondriac. It's nice to have the data to say... "OK, I see you got a 3.6 Mbit results at 8:06 PM... I also see you got 10.0 Mbit at 8:05 PM and 8:07 PM and 8:11 PM and 8:14 PM....".
2) The other thing we use is our ePMP Chrome Extension - which shows real time Throughput on the AP for them and for all connected clients. That way, we can see what they are using right while they run a test ( and see what else in their house is TX/RXing data at the same time) and we can also see what else the AP and the rest of the clients are doing. Of course, ePMP does a really really good job of sharing airtime fairly, but at the end of the day, there is only so much to go around. So, maybe he really IS having a performance issue caused by packet retry or caused by other users doing more than expeted at that same time too.
http://community.cambiumnetworks.com/t5/ePMP-2000-and-1000/Real-Time-Throughput-amp-Packet-info-for-ePMP/m-p/53178#U53178
So - neither of those two things really solves a situation where SpeedTest.net's results are inaccurately lower than they really should be. BUT, it's something to tell the the clients to show that you do know what's going on on your network.