SLA tracking and reporting in Sugar similar to that offered by JIRA?

Question

Hi,

I have a questions about case management and SLAs, summarised basically as "Can we achieve SLA tracking and reporting in Sugar similar to that offered by a product like JIRA (www.atlassian.com/jira) ?"

Here is a little more context of what we want to do -

I'm customising Sugar on-demand for a company that provides managed network solutions. I'm after some guidance on creating SLA's with Sugars case management module. Essentially we need to be able to start and stop a timer based on the status change of a ticket so that we can report on SLAs and time spent working on tickets. Ideally we want multiple time captures - Eg total time ticket is opened and time tech actually works on a ticket.

We have looked at and played with JIRA (atlassian.com/jira). As a dedicated service management platform, it provides these sort of SLA features.

However we have a strong desire to keep case management within Sugar since the company captures a lot client information (such as equipment and contracts) that are imperative to the service delivery and needs to be available along with case information.

So basically my question is - can we achieve this with Sugar? I've searched this community, google and sugarcrm.com and found very little regarding SLA's and Sugar (only a couple of old posts and an old mention that it's been a feature request).

Thanks in advance,

Gary.

Gary Smart · Accepted Answer

Just an update with my own research and findings here. Out of the box, Sugar's Case Management is rather simplistic compared to a dedicated ticketing solution like JIRA. But Sugar's ease of extendibility to model the business requirements was a key in pursuing this an as option. After cutting a fair bit of code to implement SLA timers, here's an outline of the solution. For commercial reasons I cannot share the code. Requirement - We needed SLA and other timers on a case to know how long a case was open, how long until a first response by a tech, and how long a case was in certain statuses (for calculating SLA breaches). SLA timer thresholds were defined in a custom module 'Agreement'. There were six values relating to a case priority (1,2,3) and if a case resolution could be done on site or off site. If a case's SLA timer exceeded a threshold, it would go into a "Breach' state. Solution Outline - - Using Process Author or 3rd Party workflow solutions to update a field (eg no. minutes) was not granular enough or reliable for SLA timer calculations. We could not rely on the scheduler to run exactly every minute. Over many hours/days the time calculations would drift. - So we implemented a custom scheduler. It ran through all open cases each 5 minutes (thus giving cases a granularity of 5 minutes. We thought 1 minute might unnecessary load the server). I used a custom field on each case called something like 'last_schedule_run' to calculate the number of seconds since the scheduler last processed the case. That way irrespective of when the scheduler ran, we knew exactly how much to increase the SLA timer by. SierraCRM was used as a workflow solution where emailing and alerts relating to a case were required. For example emailing a manager if a case went into a breach. - Global javascript was used on a timer to colorise the rows of a case depending on it's priority and status. While I'd prefer to not use a timer based approach, is was the easiest in that one lot of code would colorise cases whether they were on a dashboard, a case list view or in another modules subpanel. Initially I tried extending record views, but it was just to many files with too much similar code to be practical. - Another scheduler was created to generate reports weekly and/or monthly for clients. It would find cases for the week/month period and email out a case report to each client. Reporting requirements were defined in the custom 'Agreement' module. - Custom modules were also created for Equipment and Customer Sites that can be covered by different agreements. I still love, recommend and use JIRA. It's was the ability to model Equipment, Agreements and Sites and link them all together that made Sugar shine! Dashboard. Cases are colored depending on their status and SLA Timer. An "Agreement" with SLA thresholds. An Agreement specifies support expectations for equipment, sites and services.