LoboAlerts SLA

2.1.1.2 “<span style=”line-height: 1.5;”>Will utilize departmental (local) IT contact for first level triage of incidents and service requests, when available;”</span>

Is there a triage document or some troubleshooting process local IT departments should follow? I’m not sure what I would tell an end user who was having trouble with LoboAlerts other than direct them to call 7-5757.

2.2.1 “<span style=”line-height: 1.5;”>Delivery times and delivery completion cannot be guaranteed due to differences among the carriers and an individual’s location and data coverage;”</span>

This is understandable. Notifications are sometimes confusing when they are sent out for stale events. It might be good to define text messages as the avenue for active events, and e-mail or some other channel for events that are reported 12-24 hours or more after the event.

“<span style=”line-height: 1.5;”>Service uptime guaranteed by Vendor at 99.90%, subject to scheduled updates and maintenance, to be monitored by UNM IT;”</span>

Is this boilerplate, or actual? Do we want more 9s for an emergency notification system?

3.1 Billing – again boilerplate language that may not apply to this service, or should be reworded to specify who is being billed?

Hi Elisha,

Thanks for taking the time to review and comment on this SLA.  Great comments!  My thoughts and responses below:
—

1.  “Is there a triage document or some troubleshooting process local IT departments should follow? I’m not sure what I would tell an end user who was having trouble with LoboAlerts other than direct them to call 7-5757.”
—

There are a number of FastInfo items on addressing LoboAlerts set-up, preferences and troubleshooting and there are also detailed step-by-steps on the LoboAlerts informational site at http://loboalerts.unm.edu/faq.html .  The idea of pointing users to local IT first is to ensure that any department specific, device specific, or other support triage by local IT can be considered on the front-end.  I want to make sure that is valid and provides value-add with this specific service, but also in general.  What are your thoughts?   Should we identify triage steps and resources more prominently, and/or should we have a section on local IT support that better defines the services that might be available at this level?  Given that different local IT groups might have different approaches, do you have ideas on how we might effectively address this important step?  I agree we want to be as clear as possible and I would love your ideas as well as others from the community.  Referring users to open a ticket or call 7-5757 would of course be reasonable when no other direct support from local IT is appropriate.  

—
2.  “Delivery times and delivery completion cannot be guaranteed due to differences among the carriers and an individual’s location and data coverage; This is understandable. Notifications are sometimes confusing when they are sent out for stale events. It might be good to define text messages as the avenue for active events, and e-mail or some other channel for events that are reported 12-24 hours or more after the event.”
—

Excellent point!  I know that Emergency Operations tries to differentiate the urgency of various notifications that are sent out by classifying them as:

LoboAlert – “Emergency Notification” – triggered by any significant emergency or dangerous situation that is currently occurring on or near the campus involving an imminently threat to the health or safety of students, staff, faculty and/or visitors.

LoboAdvisory – “Timely Warning” – triggered by crimes that have already occurred but represent an ongoing threat to students, staff, faculty and/or visitors. 

These are differentiated by the first word of the notification, but that may not be obvious to people receiving the message.  There is another category for LoboTest to differentiate testing of the system that occurs at the beginning of the semester.  I will share your suggestion on email versus text with the UNM Emergency Manager and let you know his thoughts.

—

3.  Service uptime guaranteed by Vendor at 99.90%, subject to scheduled updates and maintenance, to be monitored by UNM IT;  Is this boilerplate, or actual? Do we want more 9s for an emergency notification system?

—    

This is the actual uptime guaranteed by the vendor for this particular service.

—

4. Billing – again boilerplate language that may not apply to this service, or should be reworded to specify who is being billed?

—

Right you are!  I will make corrections to the language.  I know from your comment on this and conversation with folks at IT agents that we need some work on billing language so folks know what is billable and what is not.  Thank you!

With regard to having departmental support be the first line of defense for this service, I think that since there is little departmental IT can do to help, so having users contact us first is just going to frustrate them. We do include information on LoboAlerts during our orientation for the incoming law students and point them to the info on loboalerts.unm.edu. And in this case, there is a robust set of FAQs (IF they bother to read the page!).

I wanted to circle back and share actions on the comments to this SLA. In addition to the comments above (thanks Elisha and Cyndi), there was a good discussion at IT Agents about how the role of departmental IT could best be represented in SLAs given the departmental support of underlying components, as is frequently the case with workstations, among others. This is tough (as noted in other discussions) because of the varied role that departmental IT could play, and I expect that the conversation will continue. I will start a topic in the process section to facilitate this ongoing discussion since it relates to all SLAs. That being said, the agreements committee took a first stab at revising the template language for departmental IT support and the changes will be reflected in the LoboAlerts SLA. I also followed up with the UNM Emergency Manager. Here is the response, “I think you’ve summarized the difference appropriately. The issue isn’t that the incident is reported a significant amount of time after the fact, but rather that it poses an ongoing threat to the safety of students or employees. The University is required (Clery Act) to provide notice to the entire campus, as soon as pertinent information becomes available. Users are allowed to choose to receive text or email messages, or both. Since we are required to notify the entire campus, and we can’t determine who has selected which method, we have to send as broadly as possible” (Byron Piatt). I have updated the SLA to clarify how the messages are differentiated and also note more clearly how the service works in this regard. Finally, I removed the billing language from this SLA. The agreements committee will be posting the final version of the draft here that incorporates these updates shortly. Thank you so much for all the feedback!