An Engineered Point of View: Improving Engineer Efficiency

by Eric Wikman on January 17, 2013

We asked Software Engineer, Jeremiah Goyette, to contribute to our blog and give some insight to the internal projects he’s been working on here at UpCurve Cloud. In this week’s mini-series, Jeremiah goes over the new process for creating internal support cases. UpCurve Cloud engineers receive dozens of client support requests each day, and with this new customization, we had a 75% decrease in the time spent creating support cases in our SugarCRM system.

Here is what Jeremiah had to say about the project:

After my initial training in Sugar development, one of my first projects at UpCurve Cloud was to create a customization for UpCurve Cloud's Sugar instance that helps speed up the process by which engineers create new support cases. Though the customization was hardly the most complex of those produced here at UpCurve Cloud, I found it to be rewarding for a couple of reasons: not only did it teach me some important things about the inner workings of Sugar (being that I was a PHP programmer new to Sugar), but it was the first project where I came to truly understand the spirit of customization.

Throughout the usual workday at UpCurve Cloud there are several engineers on call to handle support requests. Once a support ticket is picked up by an engineer, the first task is to create a support case for that account in the CRM, and to get it started. This can be a multistep process that involves finding the account, scrolling down and finding the open support project to which time should be billed, scrolling down and creating a new case from the project page, and then clicking a button to start the time clock (another customization produced by UpCurve Cloud). It may not seem that bad at first, but once you do this several times a day you realize fast that precious seconds are being lost.

The customization that I did essentially bottled up this routine into one button, which lies at the top of the accounts page. With this in place, all that an engineer has to do is find the appropriate account and click the button. Thus, what could take upwards to twenty seconds, now takes about five.

There are two parts to the customization. First, there is the button itself, which is html inserted via the smarty object in the view.detail.php file. Then there is the entrypoint to which the button links. When the button is clicked, we are first taken through the entrypoint, where the magic happens, and then redirected to the newly created case, all in the time of a regular page load.

The entrypoint takes the id of the account from the url passed by the button (using GET), and uses it to make a query to retrieve the support project associated to that account. Depending on the results of the query, the entrypoint either outputs an error, or it continues by creating beans for the account and the newly created case, as well as for a new worklog (for the timeclock). Once the proper relationships are made, the entrypoint redirects to the new case with the clock running.

This customization, albeit a relatively simple one, had a profound effect on my philosophy of Sugar customization. As I quickly came to see, not only is it about choosing the modules that best reflect the key components of the business model, but it’s just as much about tailoring the CRM to the mundane routines, carving out efficiency by consolidating common tasks into fewer steps.

If you have any questions about the projects discussed in this post, please contact us today.

Find similar articles in these categories:

PRODUCT: SugarCRM

AUDIENCES: Administrators End Users