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!