As we go into year 11, it’s good to mention how the support infrastructure works.
How we troubleshoot: Whenever a user reports a technical issue specific to that user (e.g. I can’t log in, but my password is correct; I can log in but I can’t see the content) we do two things:
- Look to see if other users are able to execute the action. Often we can just see how many people are watching the video or are logged in at a given moment. This will catch any system-wide issue.
- Take the action as the user (under their username) and see if we can do it on their behalf. This will catch anything specific to the user’s account configuration at Giza (vs. their computer system).
Determining the general locus of the issue: If we get a ‘no’ to #1 and a yes to #2, we’ve effectively demonstrated that a) the site is working as intended and b) the issue is local to the user’s system. Support’s troubleshooting is then complete. We inform the user of the outcome, but now that we’ve isolated the issue to their own system, the ball is back in their court to determine a precise cause or utilize a workaround. To get someone up and running quick, workarounds can include switching browsers or devices or simply opening a private/incognito window. That works 99% of the time. Again, the fact that not everyone has to do that, indicates the issue is localized to the user’s own system.
Determining the precise nature of the issue: We can’t actually troubleshoot a local computer, which is a service usually provided by a 3rd party. Things to look at for the user, user’s support provider, or local technician:
- an overactive security suite that silently blocks things it can’t understand and, since good security is about obfuscating things, ironically OUR security protocols which obscure certain privacy information may cause it to treat us as unknown and block by default. That overly aggressive behavior is exactly why every such tool comes with a feature to input exceptions. If they were perfect, there’d be no need for such a feature.
- a VPN with overactive security protocols that acts in a similar manner and also has provision for exceptions
- user error (Sometimes it’s something simple and obvious - e.g. the user believes he/she is typing in the correct password, but the caps lock is on, or the user is logging in with an email address but forgot that the one on the account doesn’t currently match the one they’re using)
- something has been added to the browser or device with or without the user realizing it and that something is interfering with the user’s use of the site. We often hear “Nothing has changed.” Everything connected to the internet is changing by the moment. And 9 times out of 10, you can prove this by opening an incognito/private window or switching browsers (chrome, firefox, safari) or devices (tablet, laptop, desktop, phone), or booting into safe mode if you know how, only to find it works in some mediums and not others. Again, if the user can pull it up on his/her tablet but not a laptop, the question is simple and twofold: a) is no one able to use a laptop? b) can we access the system with a laptop under the user’s name? If so, the site is working properly.
Occasionally someone will ask “if you think it’s a security tool, why don’t you do whatever is required to let that security tool be happy?” As we’ve said, that often requires LOWERING our security, which would then create additional problems. It’s ironic that security tools exist to obfuscate user behavior but don’t like platforms that obfuscate other user’s behavior. Besides, unless someone has information on exactly WHICH tool and exactly WHAT it wants, quite precisely, there’s no way to even consider it. Rather, the burden to deliver a usable experience is on the security suite and the person configuring it (ALL security suites are overactive and make portions of the web unusable without configuration - you can’t just drive a car forever without a tuneup).
The average person doesn’t know how to put exceptions into a firewall, etc. So if they fire up a firewall (or bought a computer that has one, but not the technical support package to troubleshoot it when it blocks something), they’re likely to run into something that, inexplicably, doesn’t work. It might be the shopping cart that hang when you try to check out, so that you think their website is broken, or it might be us.
That said, there are people here (in the forum) with those skills, and so users can ask around in the Giza Lounge or other categories if they need help, and someone might be able to shed light. Most often what we hear is “I have no idea what got into my safari browser (or other) but I switched to firefox (or other) and was able to access the content, log-in, etc. Weird.” And that, for us, has to be the end of the story unless someone brings us verifiable information that’s consistent across multiple tests on multiple systems. And even then, we might have to just document the issue, because we can’t control 3rd party tools.
The fact is, Giza has incredibly high uptime rates. Over 99%. The platform is working around the clock effectively and has been since February 13th, 2011. That’s right, a decade of ‘up and running’. And in that time the majority of users have never had to contact technical support to access their account or the content to which it leads. That’s a pretty sterling record. So as we get ready to go into year 11, surpassing 4,000 days of operation, be aware the support team has a highly-honed methodology that, if it can’t fix every situation, at least has a track record of consistently determining where to look for a solution.