I forgot to give appropriate attribution to UC-Davis...though I changed it
quite a bit, my list started with one in an RFP posted to the ACUTA web site
by that campus. If you're looking for a sample RFP...
On 4/23/07 3:00 PM, "Mark Bruhn" <[log in to unmask]> wrote:
> Good list -- thanks -- good overlap, but you have some things there I will
> add to my working list! As well, some of mine are a bit more
> granular/operational, and of course some of these will need additional
> explanation as we place them in an RFP:
> * Web-based service must be hosted by the provider on their own equipment at
> their own premises, in an industry-standard data center facility
> * The service must provide an industry-standard level of security, including
> security of the data transmission/load, unique individual credentials for
> support staff, administrators, and end-contacts, stored data associated with
> the Universityıs use and configuration of the service, etc.; the Indiana
> University IT Security Officer will review and render an opinion as to the
> adequacy of any/all controls
> * Due to the geographic spread of the Indiana University system, the site
> hosting the service must be outside of the State of Indiana
> * The service must support an adequate number of contacts to satisfy the
> current University population, with allowance for reasonable growth
> * Service must allow for the initiation and delivery of any length
> pre-recorded or ad-hoc message to variety of broadcast mediums (e.g., voice,
> voicemail, PDAs, email, pagers, cell phones, facsimile, Internet instant
> messaging (IM), SMS, 2-way radio, etc.)
> * The service must allow for inclusion of an adequate number (~10) of
> broadcast methods for each contact entry.
> * The service must have accurate and clear text-to-speech capabilities.
> * The service must be able to deliver messages to multiple mediums for each
> recipient, simultaneously.
> * The service must allow for at least one, preferable multiple, ³global
> administrators² who can effect changes to any aspect of the Universityıs
> domain in the service, such as contact database, broadcast schedule,
> broadcasts, configuration settings, etc.
> * Service must allow for the definition by global administrators of
> administrator roles, allowing for the segmenting of the allowable targeted
> audience per each administrator, given criteria in the University-provided
> * Administrators must be able to effect changes within the scope of their
> authorization domain, such as edits to contact database, broadcast schedule,
> broadcasts, configuration settings, etc.
> * The service must have the ability to execute multiple notification
> requests simultaneously, initiated in the same session by a single
> administrator, or by multiple administrators in separate sessions
> * The service must allow an administrator to prioritize broadcasts within
> their own authorization domain
> * The service must allow global administrators to prioritize broadcasts
> across the entire spectrum of broadcasts attributed to the University
> * The service must have the ability to send scheduled call outs
> * The service must be able to notify and then join multiple contacts into a
> joint voice conference
> * The service must have the ability to send messages to single or multiple
> recipients, using multiple methods, based on a pre-determined schedule
> * The service must provide for a variety of default message templates
> * Administrators must be able to change or update stored messages prior to a
> broadcast, and also the ability to change messages during a broadcast and
> have that change reflected in the remaining messages delivered in that
> * Administrators must be able to pause or cancel a broadcast during an event
> * Messages must be storable for broadcast at a trigger date/time
> * Recipients must be able to respond to messages, and the response must
> account for a variety of information requested of the contacts, dependent on
> the particular broadcast
> * The system must allow the global administrators the option of defining
> ³contact changeable² self-service attributes (e.g., ability to add alternate
> contact information not loaded from University-provided data)
> * Service must provide for defining and targeting segments of the overall
> supplied population, using administrator-supplied criteria as compared with
> attributes in the University-provided data
> * The service must have the ability to accept securely transmitted (perhaps
> encrypted) data feeds from University authoritative databases (Indiana
> Universityıs student and personnel data are managed through Peoplesoft)
> * Ability to interface with Indiana Universityıs central authentication
> * Demonstrable secure data transmission, host, and database environments
> * The service must allow for ad-hoc and standard reports related to
> completed broadcast delivery and performance, including data items such as
> identifier information of the targeted contacts, time, date, response,
> number of attempts made, and status codes (line busy, message delivered,
> etc.), and performance information such as total broadcast start, finish,
> and elapsed time
> * The service must allow for access to broadcast reporting via multiple
> means, including via web-page (standard and mobile delivered), telephone,
> email, etc.
> * The service must allow administrators to monitor broadcast progress in
> real-time, including point-in-time successful and unsuccessful
> notifications, responses, etc.
> * The service must utilize a minimum of TWO completely distinct networks for
> voice and data
> * The service must be able to start broadcasts to specific contacts or sets
> of contacts given input from standard alarm systems (such as building,
> environmental, etc.)
> * The service must provide a means of allocating costs (to-be-set by the
> university) for broadcasts to appropriate administrator domains
> * The service must deliver assistance to University service support staff,
> administrators, and end-contacts (in accordance with their specific
> roles/needs) in a variety of ways, including email, phone, and online chat
> * The service provider will deliver training appropriate to University
> support staff and administrators, and to end-contacts as might be
> Mark S. Bruhn
> Associate Vice President for Information and Infrastructure Assurance
> Indiana University
> On 4/23/07 2:32 PM, "Barry R. Ribbeck" <[log in to unmask]> wrote:
>> As with most others who are reviewing their notification processes
>> and systems, some of my colleagues and I have been asking some questions
>> here that I thought I would share regarding any ASP providing services
>> for notifications. So take this for what it is worth (free consulting)
>> and you may wish to send back thoughts that you may have regarding
>> functions or requirements.
>> For any emergency events that may come up, a distributed ASP or
>> ASP/Local host hybrid design seems to fit the model for high probability
>> of delivery. So for ASPs in this area, here are some questions to ask
>> 1) Does the ASP have infrastructure that is redundant and distributed so
>> that local / regional event would not affect their viability to any
>> great extent?
>> 2) Does the ASP provide for bulk loading and management of the data?
>> You don't want to rely on a live feed as this could be disrupted.
>> 3) ASPs that provide the ability to send targeted messages, should
>> provide a way to bulk load the target groups/lists membership.
>> 4) We really need to carefully read the ASP data management policies to
>> see how they protect our student and staff personal information, and
>> what we allow them to do with it. The good ones will have 3rd party
>> audits of their data management processes that follow established standards.
>> 5) Does the ASP service allow for feedback? From the delivery system
>> (how many successes/failures). From the recipients (press 1 for I am OK)
>> 6) Chances are, if you get unlimited use, you will want to use it for
>> more than emergencies. This is where targeted groups come into their
>> own. For instance if you want the help desk or support person to be
>> able to send an SMS text or voice reminder for a service call. Need to
>> be careful about overuse and abuse.
>> 7) There have been a lot of companies spring up in the last 1-3 years,
>> if they have had customers in locations during events like Katrina, NY
>> Power outage, VT, Tsunami, then it would be good to know what their
>> statistics were from these different events on successful delivery,
>> response time etc.
>> 8) The ASP should be able to cover at least the following mechanisms
>> for communication SMS (Text), Land Line, Cell, Email, Text to Speech.
>> 9) They should have no limits or reasonable limits on the number of
>> phone numbers and email addresses per person for contacts.
>> 10) You can trigger a notification in multiple ways, Web , Phone call
>> etc... so you are not relying on Internet connectivity alone during an
>> 11) What is the rate of delivery for each service that they provide.
>> How long does it take them to deliver 1000 cell phone calls, emails,
>> text messages.
>> 12) Do they have any carrier limitations or restrictions? If the local
>> cell phone vendor gets 10,000 text message into their system from the
>> ASP how will they respond, treat it as spam and drop it? If it
>> overloads their systems do they shunt those messages or throttle delivery?
>> 13) Email deliveries via on campus systems should be able to always
>> deliver faster than those of the ASP but we don't want to rely on our
>> campus systems as they may be affected during an event. If it takes the
>> vendor an hour to deliver 10,000 email messages, is this sufficient?
>> 14) How do they charge, use based, flat fee per head, based on delivery
>> time requirements etc..
>> Participation and subscription information for this EDUCAUSE Constituent
>> discussion list can be found at http://www.educause.edu/groups/.
> Participation and subscription information for this EDUCAUSE Constituent Group
> discussion list can be found at http://www.educause.edu/groups/.
Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.