Divisions Inc. provides property management services to customers across the United States. Responding to requests for maintenance services is integrated with their installation of Microsoft CRM.
Their customers currently submit helpdesk tickets using ZenDesk. This is later captured by Divisions' CSRs and a case is created in CRM to address the customers request.
Divisions recognized a need to enhance services by providing a way for their customers to monitor the status of service requests submitted through their helpdesk system.
Our goals were to streamline communication with customers, reduce call center support, improve the overall quality of services provided, and plan for future enhancements.
Red Hawk Technologies developed a custom web portal, providing a view into Microsoft CRM, which empowers customers by allowing them to monitor open and completed cases. In addition to monitoring cases in CRM, customers can view a summary of all helpdesk entries, including those that have not been converted to cases in CRM.
The current helpdesk provider is ZenDesk, chosen for use because it is web-based and provides a powerful API. The web-portal was designed so that ZenDesk can be replaced with minimal effort if the need arises. It's possible a CRM-based custom entity will be developed at a future date.
The system performance was slow until paging and ASP.Net data caching was implemented. Without paging, the data transmitted to the web browser was 85 KB, and would grow as the cases and helpdesk tickets were added. Paging would lock the amount of data transmitted to around 32 KB every time when 10 records for each section were displayed. We also used a little jQuery magic to lock down the more wordy pieces of data with a tooltip-like feature, helping to limit the vertical growth of the site.
We set the cache timeout to 10 minutes. This means that the data displayed on the site could be up to 10 minutes old. The client was comfortable with that number. Before caching, a page of data took around 7-10 seconds to render. After caching, the page was loading in under a second. Paging between the three sections was also slow prior to caching (because it was pulling all the data all the time), and it benefited in the same way after the caching was implemented. The same could be said of sorting. One trick that we implemented was to pre-cache the data once the logon page was loaded. When a user hit the logon page and typed their username, we waited until they focused on the password input. Once that happened (while they typed their password), we would use the username to get the data caches primed with that users' data. It eliminated the initial load after logon because the data was already there. In the future, we hope to add a mechanism that will automatically detect when the cache is going to expire and keep it fresh if there is still activity on the site. That should eliminate the occasional 10 second load every 10 minutes.