Who Handles Support? Giza Support is managed by the Business Developer for the Giza Death Star community. Dr. Farrell does not directly handle support – so, for efficient processing of your case, and to reduce the burden of forwarding messages for Dr. Farrell, please use the established support process.
Support Process: To obtain optimal support from Giza Support, please utilize the following process:
- Check the Support FAQ on the web site. Most repetitive issues are addressed there.
- Try on another browser (e.g. Chrome, Firefox, Safari). Often an issue is browser specific, due to clutter, cache, plugin, or configuration settings in a browser.
- Try on another computer (e.g. work/home/office/friend). Of an issue is computer specific, due to clutter, cache, software, or configuration settings on a computer.
- Submit a support ticket via the web site. If the above steps do not resolve the problem, utilize the support ticket system to request support, providing any relevant info (e.g. exact error message, etc.)
How We Handle Support Tickets
- ASSIGN CATEGORY: We categorize the issue as to the type and degree of support we can provide.
- DETERMINE SCOPE: If it’s an appropriate issue for Giza Support, we try to reproduce the issue.
- If we cannot reproduce the issue, and functionality is verified for all other users, we refer the member to their local technical person (or suggest trying a different browser, computer, etc).
- If we can reproduce the issue, and failure is verified for other users, we troubleshoot the issue with the aim to resolve.
- SET PRIORITY: We assign the issue a priority based on whether it is affecting all users, some, or only one, and whether there is already an initial resolution attempt in progress (e.g. a scheduled connection re-attempt or a call into a third party). Issues with a scheduled first resolution attempt in place do not retain the highest priority.
- REPORT RESOLUTION OR PROGRESS: We usually report either a final resolution, a tentative resolution, an initial working theory, or our planned next steps within 24-48hrs of receiving a ticket.
How We Categorize Support Results:
- Addressed in FAQ: if the issue is already addressed in the Support FAQ, we refer the member to the Support FAQ.
- Payment/Bank Issue: if the issue involves suspended Paypal payments, we refer the member to Paypal Support, because we have no access to their payment information in Paypal. We advise that the issue could be mismatching contact info in Paypal or with the credit card company, or out of date card expiration info, or out of date bank info in Paypal. Any issues with users’ confidential payment info must be resolved between the user and Paypal.
- Local Support Issue: if we cannot reproduce the issue, and functionality is verified for a representative sample of other site users (i.e. no one else is reporting the same problem), we refer the member to their local technical person (or suggest trying a different browser, computer, etc). It could be a temporary fluke with their internet connection, a browser plugin issue, or any number of other issues that Giza Support cannot troubleshoot on an individual basis. If it’s working for everyone else and for us, it’s working, and the issue is member specific and should be addressed at a local level by the user’s normal technical resource.
- Internal Web Site Issue: if we can reproduce the issue (if it’s being experienced by everyone, this is obvious) and we can detect a cause on the web site, we troubleshoot the issue, with an aim to resolve the issue internally.
- 3rd Party Resource Issue: if we can reproduce the issue (if it’s being experienced by everyone, this is obvious) and we can detect a cause on a 3rd party tool implemented by the web site, we pass the issue along the chain of support to the 3rd party.
Effective Support depends on Giza Support following certain general principles:
- SUPPORT PROFESSIONALISM: We don’t get emotional. It doesn’t reflect lack of concern or feeling, but letting emotion guide technical thinking and professional conduct reduces effectiveness. It’s important to a professional process that we neither take on the emotions of others, nor make emotion the substance of the content we convey during the support process. A methodical process is applied to *every* support ticket, regardless of the priority we assign it, rather than subjecting it to whim.
- SUPPORT PROCESS: We focus on efficiency. In order to support a large community and a wide array of technical resources, in a timely manner, we continually augment the support process to reduce the support burden. This means using tools like an established/documented support process, a Support FAQ, support notices, and a support ticket system. We don’t make personal e-mails the basis of our support, and skip the process, because this ultimately means sacrificing support for the whole community. We stick to the process.
- SCOPE OF SUPPORT: We don’t take on everything. The internet is a network, which is a lot of different computers and devices talking to one another. If we determine that the device gone astray is your local computer, we refer it to your local technician, rather than try to do a remote mind meld with the device. If it’s a 3rd party system or module, we refer the issue to the 3rd party. If it’s a payment issue, it is (by law) something to which we have limited or no access, and we refer members to the payment processor or bank, because only they can access that system on their network. By keeping the *scope* of support narrow and focused, we are able to maintain effective support, limiting our responsibility to that over which we have actual control.
- SUPPORT PRIORITIES: We prioritize. Everything can seem like an emergency to the person affected, but effective support requires that a) we prioritize issues according to what type they are, b) whether we have direct access to the affected sphere of influence, c) we place overall site functionality above any one individual’s temporary experience, and d) we have human lives and take care of the normal things those require (health, relationships, other business, etc), so that support can continue to be provided by human beings rather than automated systems. Not every issue will get maximum priority status, but the average support time overall has been far better than 24hrs since Giza Support has existed, which suggests a highly efficient support structure and methodology in place.
- EQUITY OF SUPPORT: We don’t play favorites. Issues affecting only one person, even if that person has been a member since the beginning, or is a big donor, do not get assigned highest priority, or result in a special, different support process for just that person. Every member gets the most effective and efficient support we can generate, using the established process and tools for consistency, and ticket/issue priorities are established based on the issue rather than the person. This helps us deliver the best experience for the most users overall.