Alan Hirsch
Product Support Director, Claims Workstation, Policy STAR® and FAB Billing Systems
StoneRiver
Customer Service departments vary widely in their scope, services, and client interaction. Some departments work directly alongside their professional service teams as an installation project progresses. Others begin working with the client only when a project is completed. It’s best to understand and contract specifically for the support level you believe is necessary for the installed software.
Outlined below are a few tips and suggestions to consider as you plan your support requirements and interact with the vendor’s Services staff.
Before software installation or go-live
As a rule of thumb, the more mission-critical the application, the sooner you’ll want the vendor’s Customer Service involvement. While this may cost more than minimal support, it could easily provide positive paybacks. It ensures that the Services group fully understands your specific configuration and unique needs, helping to improve their responsiveness and issue resolution.
Inquire about the Service group’s processes when they receive a trouble ticket. What will they do first, second, third, etc.? For example:
- Who will analyze the issue?
- Who will validate the solution against the base product, and how will they perform this validation?
- Who will develop the solution for testing?
- Who will test it, and how will they test it?
The more educated you can be on these processes, the greater confidence you’ll have in the results.
Interacting with the Services team
Determine specifically how to submit a trouble-ticket, and what needs to be submitted with that ticket. The Service group may use an automated application that enables you to self-summit and track a ticket. They may also have checklists, documentation or artifacts you can use to ensure you submit a ticket that best matches the group’s needs.
Typically, the Service group will request some or all of the following:
- A brief headline for the reported issue – no more than five to ten words.
- A non-technical, business description of the problem and its impact.
- Details about the product version and system configuration used when the issue surfaced.
- The data used or entered when the issue surfaced.
- Specific steps to follow that consistently recreate the issue.
- Screen prints or shots that follow the steps to recreate the issue.
- When (time of day) the issue occurred.
- Any ancillary processing that might be running concurrent to the issue.
- The volume of accounts, policies or records impacted by the issue.
- Additional information relevant to the issue.
What other tips or best practices do you have when working with a vendor before going live with software or interacting with the vendor’s Services team? Next week, we’ll discuss some behind-the-scenes processes the vendor typically goes through when addressing the issues you report and what to do after you receive the issue correction.