With ERP software, Service Level Agreements (SLA's) mostly define how your post-go-live support will be offered by your chosen vendor. While many of these are similar, there are things everyone looking at new software should know about their prospective vendors support and service before moving forward. Let's take a quick look into some of these.
Resolution Timelines
One of the main components of an SLA is the resolution timeline matrix (or narrative). This typically identifies high-level support scenarios and assigns them a severity level along with an estimated response time. This is the section most clients look at to try and get an idea of how long they would wait for assistance.
The times listed in these are typically an initial response, usually meaning that your ticket will be engaged by the vendor within this timeframe, not necessarily resolved. In other words, should you report a concern which has a 1-day response time, someone will likely reach out to you within 1 business day to gather additional information if needed and begin working on your issue. The complete resolution timeline is typically more dynamic and may be estimated by your support technician after some initial analysis, based on the severity of the issue or may not even be provided at all. A basic process question is going to typically be resolved while on the phone or email, while other tickets such as data or programmatic issues/errors or feature requests will require follow-up and can take much longer, or perhaps never implemented at all.
Some vendors may even have optional response level plans (i.e. Gold Level, Platinum Level) which they claim will reduce wait time for each of the base response times. Without having a good understanding of the base level of service for a specific vendor, it is tricky to know whether this is a value or not.
The key thing to know here is that tickets are typically categorized by the vendor so these SLA levels, regardless how well-defined, are mostly subjective to the classification process placed on each issue. We'll talk further down about a better way to analyze vendor response times.
Volume Limits
Look for volume limits in SLA's to determine how many tickets are included in your plan. Many vendors offer unlimited tickets for all users within your organization. Some vendors pricing may only include X number of tickets per month or year. This can also be based on hourly rates or a hybrid of the two.
When migrating from one vendor to another, your team will likely have a lot of questions in the first few months as scenarios arise which weren't replicated during the training period. Over time, the need for assistance can diminish greatly so keep this in mind when deciding on long-term options.
Methods of Request
When it's time to get assistance, having a simple and clearly identified method of doing so greatly relieves frustration among users. We have all had poor experiences waiting on hold to speak to someone at a call center and the thought of beginning this process can give users anxiety.
One of the best ways to help alleviate this is identifying the support channels in the SLA and making sure these are included in the end-user training.
Common Methods:
In-Application Form Submission - user presses a button or link and completes a short form with details. This request is placed in a support queue and is responded to in a manner of the requestors choosing (email, in-app messaging, phone).
Third-Party Ticketing System - user presses a button or link and is taken to a third-party online app to submit their ticket to the vendor.
In-Application Email - user presses a button or link which opens an email client with the support group email address filled-in.
External Email - user emails support group directly from email client
External Phone - user calls in to a support line, typically navigating a menu system to reach the correct team. User may be placed in an electronic queue or have their call answered immediately. If queued, the user may wait on hold or receive a callback when a support technician is available.
Each of these options can be beneficial to have available and use. Consider a situation where the application becomes inaccessible, for instance. Knowing that the vendor has easily accessible options available outside of the app or without the use of internet and knowing how to access them can mean the difference between a positive or negative outcome for the users in time of need.
Self-Service Ticket Management
Look for information in the SLA about self-service options to view submitted tickets, track updates, and run reports on them. Web-based CRM support ticketing software such as ZenDesk, MS Dynamics, Salesforce, FreshDesk, Zoho, etc., have capabilities to open a client-side self-service portal to review, get status updates, and notifications on submitted tickets.
Having this kind of access to tickets can allow internal application admins to gain better insight into the types of issues users are experiencing and also see patterns to identify when an implemented solution isn't configured correctly or not working for them in general.
A few other things to look for regarding ticketing systems:
Does the system used support user-levels for certain request types? For instance, can any user request assistance with security configuration issues or just an admin?
Can the system be used to submit all request types, including bugs and feature requests?
If bugs and feature requests can be submitted, does the system provide updates (approval status, time estimation, expected version, etc.) to the users on those requests?
Support Levels
Most SLA's will identify the support structure. There are two common structure types, each with their own pro's and con's:
Multi-Level support is typically defined as 2 to 3+ levels in an SLA, with level 1 being the most inexperienced team members and levels 3+ either being management or development. Vendors will have an escalation process identified to move tickets up through these levels until a level with sufficient experience can resolve the issue. This allows less experienced team members to work on a higher volume of calls, while more experienced ones can spend more time on fewer, more complex ones. One of the positive products of this method is that initial contact and resolution can be quicker for basic questions. Resolution to more complex issues can be expedited as well. However, the drawback to this model is that users can at times feel like they are being passed around from one person to the next. Also, for advanced users, they can feel like they are constantly wasting time being forced to explain complex issues with more inexperienced users who act as gatekeepers, knowing that their case needs to be escalated.
Single Contact support typically still has elements of a tiered, multi-level approach when issues need to be escalated to development or management, however the key difference is that the initial technician is usually more experienced and able to address a wider range of issues for the user. They also stay with the user until closure of the ticket, acting as a single point of contact. This can help the user build relationships with support staff and provide more continuity. One of the drawbacks to this process is that initial contact may take a bit more time if experienced support technicians are working on more common tickets, especially during peak seasonal times like common billing, year-end, or renewal seasons.
Some vendors may move staff into the department seasonally to assist with volume. It's worth asking the vendor what their peak seasons are and how they manage them. At the least, it can help you prepare in advance for these times. At best, it may help you separate two vendors from each other who check all of your other boxes.
Management Escalation
Ensure there is a clearly defined point of escalation to management in the SLA outside of the standard levels. Many vendors have mature and efficient support processes but all processes can break down. Having a contact in this case can be very helpful. This may be the support manager or even an account executive.
Integration Support
Integrations are software communications that occur between your ERP system and a third-party system such as a document management system, plan review system, or separate financial system, etc.
Some integrations between vendors are fully developed and widely utilized. Others are new or experimental.
In either case, make sure you know exactly which vendor is responsible for supporting the integration. Typically, the answer will simply be "both". The vendor who supplies the API usually supports the logic of the process once the service is called. The vendor who calls the API to post or get data from it supports the process of requesting, retrieving, then processing the results. Look for information defining this in the SLA so that it is clear who to contact when things stop working or requires updating.
Customization Support
One widely overlooked item in an SLA is how customizations are supported, for how long, and for what versions.
If you are paying for a customization to the base software to accommodate a unique requirement, be sure to have it identified in the SLA and also try to obtain information on how your customization will be knowledge-transferred to support teams so that they are able to assist your team properly when they place tickets.
Support teams that are involved to some extent in the QA process for development will perform better in this area as they will have background knowledge of how the customization works and its purpose. Otherwise, support teams will typically struggle to assist with these one-off features, tools, integrations, or processes customized during your implementation.
Make sure it is identified in the SLA or elsewhere how long the customization will be supported in terms of major or minor versions. While this can be difficult to predict, the last thing you want to do is pay for a major customization, only for it to be not supported shortly after a major update to the system.
Don't be afraid to ask the right questions and ensure that you will receive comparable support for your customizations that you do for base functionality.
Hours of Operation
SLA's should identify their support teams hours of operations as well as holidays. They should also identify what defines a day (business vs calendar) for response times.
The typical Monday-Friday 8-5 is common for Municipal ERP vendors but be sure to clarify how time zones are affected. A municipality on the east coast being served by a vendor located on the west coast may have to wait until 11am or 12pm for support. Some vendors offer nationwide (lower 48) coverage during these hours, meaning they are staffed from 8 or 9 in the morning until 7 or 8 in the evening. This should also be clarified in terms of how response times are calculated.
Also look at hours of operation within the context of each functional area. If a vendor is providing products that will be utilized by services such as police, fire, and public works who have staff working nights and weekends, be sure to understand when those users will be able to get assistance. It's probably not convenient for the police night shift users to wait until the day shift to get answers, for example. It's best to consider the entire user-base of all purchased applications when determining whether the given hours are acceptable.
Location
Most U.S. vendors provide U.S.-based support. However, there are vendors within the U.S. which are based in Canada or Europe and U.S. based vendors offering services oversees. Whether we like to admit it or not, language barriers can be one of the most frustrating aspects of working with a support technician. A dominantly French-speaking town in Canada communicating with an English-speaking vendor in the U.S. could be problematic, for instance. Written communication can often-times lower these barriers, however native vendor language and possibly translation services are areas to consider when choosing vendors since it contributes to overall user satisfaction.
Service Methods
An important question to ask and perhaps have identified in an SLA is the method of support provided.
It is recommended to learn what the common methods of service are used by the proposed vendor. Here are some common ones:
Help Docs - support responds with generic help docs, tutorials, or knowledge-base articles related to the inquiry
Template Response - support responds with template text responses via email, CRM queue, or in-app communication
Custom Written Response - support responds with a custom, typed response addressing the specifics of the users request via email, CRM, or in-app communication
Conversational AI - user communicates with a "Bot" in a chat box which attempts to answer basic questions or guides them to additional online or live technician resources
Live Support - user communicates via phone or chat with a live support technician
Remote Access - live support remotes in to users machine at some point along an escalation path using unattended software such as Team Viewer, Bomgar, Citrix, etc.
All of these methods have their own individual merit. We recommend that you look for a strong mixture of these options, the most important being access to live support one way or another. Support should also be willing to jump on a remote session and knock out a problem rather than spending too much time going back and forth with speculation on an issue. Don't hesitate to ask the vendor what the escalation point to remote access generally is for them. Also, don't forget to have them identify their remote access software/technology and make sure your IT team is comfortable allowing it to access your network. Most vendors have backup options for these cases. The best thing to do is ask up front so your project team can account for this variable in project planning.
Best Advice
While this information is intended to help you vet out good vendors from bad, none of the details matter if the vendor doesn't deliver. There may even be satisfaction guarantees and warranties in place, but nothing gets you your time and resources back should you not be happy so choosing the right software vendor to partner with is a big decision.
In our experience, here are some of the most critical things to do once you are happy with the SLA itself:
Don't Wait To Review the SLA - request a copy of the vendors SLA as early in the RFP/selection process as possible. You don't want to select a vendor only to find out their service levels don't work for your team.
Take all of your site visits - visit as many sites using the vendors software as possible. While you're there, talk to the end-users and not just management. Ask about support and ask for some specific examples of issues they've had and how they were handled by the vendor. Ask them what they least like about the service. Try not to stick to just the client sites provided by the vendor. Ask the Municipalities which you've been directed to point you to other municipalities in the area using the same vendor who may not have been on the curated list. Alternatively, some vendors take pride in their service and will provide an entire client list upon request, or even right on their website.
Request a Spontaneous Support Demo - when I worked on the vendor-side, I had so much confidence in our support teams response time that I would often challenge customers to call support on the spot and see how long it took to get a response and initiate a request. If this request makes your sales team nervous, dig deeper and find out why.
Request Statistics - some vendors may not have this data but it doesn't hurt to ask if you are left on the fence trying to decide between two good vendors. Ask for some data to back up their claims. Common KPI's for support can include:
Average Ticket Initial Response Time
Average Ticket Complete Resolution Time
Staff to Case Count Ratio
Staff to Client Site Ratio
Munivate can provide you a number of levels of experienced assistance with your procurement project to help you find the right vendor and get the most from them. Email us at info@munivate.com, message us using the chat box, or give us a call to have a chat about what you have going! We'd love to hear about it.