Please Consider the Following Before Creating/Commenting On a Ticket

Ticket Priorities Explained

Ticket priorities in the strictest sense are determined by your company's SLA, but generally fall into the following descriptions. Note that we make every effort to work on your issues in the most timely manner possible regardless of the priority level, but may increase or lower the ticket priority to accurately reflect this standard:

• Emergency

A critical error or failure by the Licensed Program is causing extreme, severe, and unreasonable difficulty to your company, depriving your company of all or virtually all production value and use of the Licensed Program.

• This pertains to PRODUCTION deployments that have already been successfully deployed that are now failing, and are past the primary configuration phase of implementation. Any process that is still being configured, whether for production or not, cannot be emergency level unless there is a prearranged agreement between your company and Urbancode, informing us of your production configuration deadlines, and that you would like extra resources available according to your services agreement, which could be subject to charge.

• High

A non-critical error or failure by the Licensed Program that does not deprive Customer of all or virtually all production value and use of the Licensed Program; but has a high impact on the operation of the Licensed Program and no work-around.

• Medium

An error, failure, or defect that does not have a significant impact on the operation of the Licensed Program; or a high-impact error, failure, or defect for which a work-around is in place.

• Low

A non-urgent request for information, training, licenses, or other issue that would be nice to have in a future release. This includes requests for behavior that is not currently intended in the version of the Licensed Program. Any action undertaken regarding feature requests, if any, will be at the sole discretion of Urbancode.

Consideration before filing a ticket

In order to provide an efficient resolution to your ticket, there a few basic things that should be taken into account before filing a ticket. Of course, not all of these apply universally to every ticket, but should serve as a guideline for what to include. Here are some dos and don'ts about making tickets:

Do:

• Let us know what you're trying to do
• Describe the error or question in depth
• Give what step in the process is failing
• Provide step output logs
• Provide the plugin and plugin version the step is from
• Provide the configuration for the step/uDeploy object
• Provide server logs
• Provide a start time for the deployment/time-frame you saw the error
• List steps taken to reproduce the error
• Strive to use the same terminology uDeploy uses

Don't:

• Post only the error in the description (this hardly ever enough information for us to help, as most error messages can be caused by many different things)
• Leave out basic information about the third party product you're interfacing with (We're way more familiar with uDeploy than we are with third party products here in support)
• Use the same ticket for a different problem unless it stems from the original issue (we use tickets for future troubleshooting. Please, no "oh by the way"s)
• Use the same priority for all tickets (If it's very time sensitive and/or detrimental to production, make it High. If not, it's probably medium or low. Check your SLAs. This helps us manage our work queue)

Web Meetings

We would always rather have a meeting to immediately address the issue and close the ticket, rather than having a long dialogue. Unfortunately, our workload often impedes this possibility barring dire circumstances. It's a simple matter of when on a meeting, one support specialist can help one customer at a time. When handling issues over tickets, one support specialist can help multiple customers simultaneously. Many tickets require reproduction or feedback that we could do or receive offline, and a meeting would be inefficient for these tasks. With that being said, if you've already configured production deployments and they have suddenly encountered errors, these types of ticket take priority and a web meeting will likely be arranged immediately if needed. If you have problems or questions about configuration, these meetings will need to be scheduled for when it will have the least impact on supporting other customers, and may not be scheduled immediately. If for some reason your configuration is under an urgent time constraint, every effort should be made to make Urbancode aware of your situation before it becomes urgent so that we can prepare resources beforehand to handle your needs. When creating your tickets, please adhere as closely to the above guidelines so that when we can't schedule a meeting, the dialogue over the ticket is kept to a minimum, and the issue is identified and resolved efficiently.

Requests for Enhancement

With the recent acquisition of Urbancode by IBM, the method used to request changes and enhancements has been upgraded. Customers are no longer required to use the support process as the go between for you and the development process for your request. These requests are now handled through the RFE (request for enhancement) community. Customers can now go to the link provided below to sign up for an account with the community and begin requesting enhancements. The account is free and easy to obtain. Simply click the register link at the top right, register, then click submit.

http://www.ibm.com/developerworks/rfe/?PROD_ID=947