Great topic, and one that I deal with every day. We are actively scanning Twitter and proactively reaching out to students who voice dissatisfaction about WiFi services.
As we all know, WiFi is a lot like weather. A specific condition at a specific time in a specific location. The location piece is a big part of that equation. You absolutely want to prevent public disclosure of private information - particularly the geolocation of a student. Therefore, we attempt to engage with them and endeavor to mutually follow each other on Twitter. By doing mutually following each other on Twitter, a private channel can then be established to talk about what's going on. Once that private channel is established - we ask the student a few quick triage questions [device/OS/location, etc.] We also ask them to use our WiFi onboarding tool, which seems to take care of a majority of the issues. We're currently using SecureW2 JoinNow for that task. It's been working very well for our needs. Once we have answers to the triage questions and have asked the student to run the onboarding tool - we create a service center incident and hand it off to them for further action. We make it clear to the student that follow-up will happen via e-mail. The service center incident is created using a template specific to information gained from social media. We include the initial complaint and conversation from Twitter in the work notes of the incident to give context and clarify next actions needed. We may reach out to the student again via Twitter to confirm resolution if the service center elicits no response or further communication via e-mail. *IMPORTANT!* Some students merely want to vent. Face it, we all want (and need) to do that sometimes! When trying to establish engagement - you may get different reactions. Many students are ecstatic that their complaint was noticed. Other students ignore any attempt to reach out to them. Fewer react negatively - and some realize that public tweets are actually seen and sometimes acted on. Hope that helps! [b] *brian cors* Client Experience Analyst University of Michigan | Information and Technology Services Communications Systems and Data Centers http://its.umich.edu/csdc On Thu, Apr 2, 2015 at 9:48 PM, Frank Sweetser <[email protected]> wrote: > As others have noticed, this is a pretty tough nut to crack. Due to some > odd quirk of human nature, many students will put quite a bit of effort > into complaining to their friends or on forums, but can't be bothered to > actually tell anyone who can make a difference. Here's the collection of > approaches we use: > > - Good predictive modelling, followed up by a site survey. Not much you > can do if you have gaps in your coverage or capacity. This plus a good > knowledge of where your clients clump up should give you a much stronger > starting point. > > - Know your wireless management platform, and which metrics correlate > with user visible problems. For example, high levels of channel > utilization, or a heavy noise floor point to problem areas you can attack. > > - Synthetic transactions are like your favorite user, the one who can > give you tons of objective metrics on both what went right and wrong. > We've had good luck with 7signal, though they're far from cheap. We have a > handful in key locations, and they keep running enough tests that we've > even been able to clearly identify several instances of systemic flakiness > that only affect a certain percentage of clients. > > I've also heard good things about Epitiro Streetwise, though we haven't > really looked into them, and NetBeez is also dipping their toes into the > wireless side as well. > > - We threw up a wireless complaints form, and then did a big publicity > push (digital signage, posters on move-in day, have our Service Desk push > it, etc). The extra bits of guidance compared to an email (prompt the user > with specific questions, some pull down lists for exact location) have > helped bump up the quality of the average complaint, with a good deal more > of them containing actionable complaints rather than "you guys suck!" > > - We use Cloudpath, which gives us several advantages. First it provides > users with a self-service onboarding mechanism via an unencrypted > walled-garden SSID. This eliminates a lot of the service calls right off > the bat. > > Second, we also recommend re-running Cloudpath as a first troubleshooting > step, both to users directly and for our service desk. It is capable of > checking for a lot of common issues (wrong date/time, wireless switch > disabled, certain missing patches, etc) and automatically fixing some of > the simpler ones. Again, even more service calls either eliminated, or at > least closed out in one relatively simple step. > > And thirdly, as Cloudpath runs, it takes a fairly detailed inventory of > the client system - operating system, patch level, wireless chipset, driver > version, etc. This quickly gives you a detailed view of what your user > base looks like, including all of your BYOD devices This can then inform > decisions like matching your advanced feature support to your client > capabilities, or where to invest support staff training. > > Okay, so that whole list ended up being even longer than I originally > intended. I guess if there's a summary, it's that unlike a wired > connection, wireless is an intermittent, temperamental, complicated mess > that you really do have to attack with a holistic measure-plan-improve > cycle. > > Frank Sweetser fs at wpi.edu | For every problem, there is a solution > that > Manager of Network Operations | is simple, elegant, and wrong. > Worcester Polytechnic Institute | - HL Mencken > > > On 4/2/2015 4:09 PM, Alexander, David wrote: > >> I’d like to know what other schools are doing to proactively troubleshoot >> wireless issues on your campus. >> >> Our network team does a great job of troubleshooting end user wireless >> connectivity issues when a customer calls the Service Desk to report an >> issue, >> but end users don’t like to call our Service Desk to report issues. >> Because >> of this, end users assume our network sucks or they try their own >> workarounds >> (eg. using cellular data, etc.). >> >> What level of success do you have with customers contacting your Service >> Desk >> about connectivity issues? Do you do anything to proactively find out if >> customers are having connectivity issues? >> >> It seems like a lot of the issues are on the client side (eg. updating >> Surface >> Pro drivers, applying a Mac fix, etc.). What approaches are you using to >> communicate about device specific issues? >> >> I’d appreciate any feedback you have on how you are approaching this >> issue on >> your campus to improve end user experience with your wireless network. >> >> Thanks, >> >> Dave >> >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
