preamble

848 views
772 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
848
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

preamble

  1. 1. Purchasing Services Request for Proposal No. MP8-040(PLe) Automated Notification System: Mass Notification to People in the Event of a Crisis Déc. 2007 McGill REQUEST FOR PROPOSAL Project Title: Automated Notification System Project No.: MP8-040(PLe) Closing Time: December 21, 2007 at 3:00PM (EST) Issued on: November 28, 2007 Page 1 of 37
  2. 2. Purchasing Services Request for Proposal No. MP8-040(PLe) TABLE OF CONTENTS 1.0 PREAMBLE............................................................................................................................................................4 1.1 PURPOSE.............................................................................................................................................................4 1.2 MCGILL BACKGROUND.........................................................................................................................................4 2.0 INFORMATION AND INSTRUCTIONS TO BIDDERS..................................................................................4 2.1 ISSUING OFFICE.....................................................................................................................................................4 2.2 DEFINITIONS .......................................................................................................................................................4 2.3 KEY DATES..........................................................................................................................................................5 2.4 AGREEMENT........................................................................................................................................................5 2.5 PRICING..............................................................................................................................................................5 2.6 QUANTITIES.........................................................................................................................................................5 2.7 INQUIRIES............................................................................................................................................................5 2.8 INFORMAL COMMUNICATIONS...................................................................................................................................6 2.9 FORMAL COMMUNICATIONS.....................................................................................................................................6 2.10 PROPOSAL SUBMISSION.........................................................................................................................................6 2.11 OPENING OF PROPOSALS.......................................................................................................................................7 2.12 TERM OF OFFER..................................................................................................................................................7 2.13 EVALUATION BY COMMITTEE.................................................................................................................................7 2.14 SELECTION CRITERIA............................................................................................................................................7 2.15 ADDITIONAL INFORMATION....................................................................................................................................8 2.16 SYSTEM DEMONSTRATION.....................................................................................................................................8 2.17 ETHICS.............................................................................................................................................................8 2.18 ACCEPTANCE AND AWARD....................................................................................................................................8 3.0 BIDDER PROFILE, EXPERIENCE AND REFERENCE................................................................................9 3.1 BIDDER PROFILE...................................................................................................................................................9 3.2 EXPERIENCE AND REFERENCE INFORMATION................................................................................................................9 3.3 PROJECT MANAGER..............................................................................................................................................9 4.0 SERVICE CAPABILITY DECLARATION......................................................................................................11 4.1. ARCHITECTURE AND LICENSING (ON PREMISE)...............................................................................11 4.2. DEVICE ADDRESSING, LISTING CAPABILITIES AND LIMITATIONS............................................14 4.3. ADMINISTRATION AND SECURITY CONTROLS..................................................................................18 4.4. SYSTEM FEATURES, PROPERTIES & CAPABILITIES.........................................................................20 4.5. DATA MANAGEMENT AND REPORTING FEATURES.........................................................................24 4.6. CONTACT DATABASE ATTRIBUTES........................................................................................................26 4.7. ADDITIONAL PRODUCT FEATURES........................................................................................................27 5.0 SERVICE PROVIDER’S DEPLOYMENT AND TRAINING PLAN............................................................28 6.0 GENERAL TERMS AND CONDITIONS.........................................................................................................28 6.1 PERFORMANCE GUARANTEE..................................................................................................................................28 6.2 BILLING PROCESS ................................................................................................................................................28 6.3 INSURANCE........................................................................................................................................................28 6.4 CONFIDENTIALITY...............................................................................................................................................29 6.5 SOURCE CODE...................................................................................................................................................29 6.6 INDEMNITY AND PATENT INFRINGEMENT..................................................................................................................29 6.7 ASSIGNMENT OF AGREEMENT................................................................................................................................30 Page 2 of 37
  3. 3. Purchasing Services Request for Proposal No. MP8-040(PLe) 6.8 INDEPENDENT CONTRACTOR...................................................................................................................................30 6.9 DEFAULT..........................................................................................................................................................30 6.10 TERMINATION...................................................................................................................................................30 6.11 FORCE MAJEURE..............................................................................................................................................31 6.12 INSOLVENCY....................................................................................................................................................31 6.13 PRESENCE ON THE UNIVERSITY’S PREMISES ............................................................................................................31 6.14 LICENSES AND PERMITS......................................................................................................................................32 6.15 NOTICES.........................................................................................................................................................32 6.16 PUBLICITY.......................................................................................................................................................32 6.17 GOVERNING LAWS.............................................................................................................................................32 6.18 DOCUMENTS BE DRAWN UP IN ENGLISH.................................................................................................................32 7.0 FORM OF TENDER...........................................................................................................................................33 Page 3 of 37
  4. 4. Purchasing Services Request for Proposal No. MP8-040(PLe) 1.0 PREAMBLE 1.1 Purpose McGill University is soliciting Proposals in accordance with the terms and conditions of this Request for Proposal document, from prospective entities that specialize in providing an Automated Notification System. The purpose for such system is twofold. First and foremost, it is to be used for mass notification of students and staff in the event of a crisis affecting the University Campuses. Secondly, the system is to be used for lower scale notification for respondents to departmental or sectarian crisis or disasters. Proposals will be accepted for three distinct modes of operation: Hosted (SAAS or ASP), On Premise (McGill owned and operated) and Hybrid (McGill owned with SAAS providing communications channels). If accepted, this Request for Proposal will become a binding contractual obligation. 1.2 McGill Background McGill University is Canada's leading research-intensive university and has earned an international reputation for scholarly achievement and scientific discovery. Founded in 1821, McGill has 21 faculties and professional schools which offer more than 300 programs from the undergraduate to the doctoral level. McGill attracts renowned professors and researchers from around the world and top students from more than 150 countries, creating one of the most dynamic and diverse education environments in North America. There are approximately 23,000 undergraduate students and 7,000 graduate students. It is one of two Canadian members of the American Association of Universities. McGill's two campuses in Montreal, Canada are:  Downtown Campus (includes 120 properties)  MacDonald Campus (includes 90 properties) 2.0 INFORMATION AND INSTRUCTIONS TO BIDDERS 2.1 Issuing office Purchasing Services McGill University 3465 Durocher Room 101 Montreal, Quebec, Canada H2X 2C6 Senior Buyer: Pierre LeBlanc Telephone: (514) 398-7225 Facsimile: (514) 398-1885 Email: pierre.leblanc@mcgill.ca 2.2 Definitions  McGill University will hereinafter be referred to as the "University" or “McGill”  The Request for Proposal document will hereinafter be referred to as the "RFP";  The vendors invited to submit a Proposal under this RFP will be referred to as the Bidder; Page 4 of 37
  5. 5. Purchasing Services Request for Proposal No. MP8-040(PLe)  All responses to this RFP received from Bidders will hereinafter be referred to as “Proposal(s)” or “Bidder’s Proposal”;  The contract(s) awarded as a result of this RFP will be referred to as the “Resulting Agreement(s) or “Agreement(s)”;  The firm selected, if any, to provide the requested products and/or services to the University will be referred to as the "Supplier"; 2.3 Key dates 2.3.1 Listed below are the important events and the target dates and times by which the events are expected to be completed: • Issue of RFP November 28, 2007 • Bidders’ conference call December 3, 2007, 4:00 PM EST) • Inquiries (by 4:00PM (EST)) Up to December 7, 2007 • RFP closing date (by 3:00PM (EST) December 21, 2007 2.3.2 Bidders must furnish complete Proposals based on the information presented in this Request for Proposal. Responses to this Request for Proposal together with Form of Tender (Section 7.0) duly signed by the Bidder’s authorized representatives, must be received by the Issuing Office no later than 3:00PM (EST) December 21, 2007 2.4 Agreement The result of this process is for McGill to award an Agreement based upon the terms and conditions of this RFP document and the specifications and service requirements indicated herein. This RFP and resulting Agreement constitutes the entire agreement between the parties and would supersede all previous discussions or agreements between the parties and/or any or all conditions listed in the Bidder’s catalogues and publications. 2.5 Pricing Any pricing submitted as part of this RFP shall be “FOB: Destination” and include separately GST (Goods and Service Tax) and QST (Quebec Sales Tax) unless Bidder is located outside Canada and isn’t registered to charge these taxes. 2.5.1 The prices quoted shall be firm 120 calendar days from the closing date of this RFP. Please specify the currency 2.5.2 Pricing shall include all shipping charges, transit insurance, custom clearance and all applicable duties. Pricing shall also include installation. 2.6 Quantities Any reference in this RFP to past and current volume is provided solely for the purposes of providing the Bidder with information and should not be considered as a guarantee of volume of business. 2.7 Inquiries 2.7.1 The Bidder may inquire into and clarify any requirements of this RFP. Inquiries must be in writing, mailed, faxed or emailed to the Issuing Office to the attention of the aforementioned buyer in Section 2.1. A conference call will be held on December 3, 2007 at 4:00 pm EST, where bidders can also formulate their questions. Bidders wishing to participate to this conference call must contact the Issuing Office in advance (by December 3, 2007 at 12:00 pm EST at the latest) for the coordinates of the call. 2.7.2 The Issuing Office reserves the right to circulate copies of all queries and related responses Page 5 of 37
  6. 6. Purchasing Services Request for Proposal No. MP8-040(PLe) to all Bidders, as addenda to the RFP document, in order to maintain a level playing field through equal access to information. No verbal queries will be accepted. 2.7.3 Any additions or corrections to the RFP document will be issued as written addenda to all Bidders who shall list in their Proposals all the addenda that were considered when the Proposal was prepared. 2.7.4 McGill will not be responsible for oral interpretations or clarification issued, other than by the Issuing Office. 2.8 Informal communications From the date of receipt of this RFP by each Bidder until it is awarded to the successful Bidder, if any, informal communications regarding this procurement shall cease. Bidders are allowed to continue their normal business with McGill (if applicable). Informal communications shall include, but are not limited to:  Requests to the Bidder(s) soliciting information, comments, speculation, etc. from any department or employee of McGill with the exception of Ms. Kathy Zendehbad (Associate Director, Purchasing and Customs &Traffic) and Mr. Pierre LeBlanc. 2.9 Formal communications From the date of receipt of this RFP by each Bidder until the successful Bidder (s) and all other Bidders have been notified, or when McGill rejects all Proposals, all communications between McGill and all Bidder(s) regarding this procurement will be formal. This will not prevent the Bidder from continuing its normal business with McGill (if applicable). Any failure to adhere to the provisions set fourth regarding informal and formal communications may result in the rejection of any Bidder’s Proposal or cancellation of this RFP. 2.10 Proposal submission 2.10.1 Bidder’s submission must include: • Form of Tender (Section 7.0) duly completed and signed. • Tables 1 to 7 duly completed • Two (2) signed copies of the Pricing Proposal (one original and one copy). • One (1) CD version of the Proposal. • Any non-conformity to the RFP. • Any additional charges or liability that would be at McGill’s expense (if applicable). • Financial statements (if not already submitted in the last year) • References. • All other requirements and information requested in the RFP. 2.10.2 The Issuing Office must receive the Proposals on or before the closing date. The Issuing Office will not accept Proposals submitted via facsimile transmission. Proposals will not be accepted after the closing date and time. 2.10.3 Proposals shall be originally and irrevocably signed by an authorized representative of the Bidder when submitted. Upon award (if any), the successful Bidder will be required to supply proof satisfactory to McGill of appropriate authorization to bind the Bidder. 2.10.4 In the event the Bidder cannot comply with any term, condition, or requirement of this RFP, such non-compliance must be clearly noted on the Bidders’ letterhead and submitted with the Proposal. No other changes to any section of the Proposal will be acknowledged after the submission of the Proposals. Bidders are cautioned that such non-compliance may result in disqualification of the Bidder’s Proposal, at the sole discretion of McGill. Failure of any Bidder to provide in its Proposal any information requested in the RFP may result in disqualification of the Proposal. Page 6 of 37
  7. 7. Purchasing Services Request for Proposal No. MP8-040(PLe) 2.10.5 The laws of the Province of Quebec shall apply to this RFP and any Agreements resulting of this RFP and the Courts of Quebec shall have exclusive jurisdiction. 2.10.6 Bidders may not make modifications to their Proposals after the closing date and time. McGill will not be obligated in any way by the Bidder’s response to the RFP. The Bidder's Proposal and all supporting documents become the property of McGill. The Issuing Office may reproduce all such documentation, provided that such reproduction is made solely for internal use or for any purpose required by law. 2.10.7 The envelope containing the Proposal must be sealed and clearly marked as to its contents and shall display on the outside front, the Bidder's name, return address, telephone number and RFP number. 2.10.8 The cost of preparation and delivery of any RFP and Proposal is the responsibility of the Bidder. 2.10.9 Bidders that have or are in the process of filing a petition for bankruptcy, or any arrangement for reorganization or assignment for the benefit of its creditors pursuant to any bankruptcy or insolvency law are not eligible to submit a Proposal. 2.11 Opening of proposals The opening of Proposals will be restricted to and witnessed by members of Purchasing Services. Bidders are not invited to be present. 2.12 Term of offer The Bidder's response to this RFP constitutes an offer by the Bidder, which shall be open and irrevocable for a period of one hundred and twenty (120) days from the closing date of this RFP. 2.13 Evaluation by committee A committee comprised of members from the Office of the CIO, IST (Information Systems and Technology) Customer Services, Network and Communications Services, Information Systems and Resources, Safety and Security, and Purchasing Services will evaluate the Proposals. 2.14 Selection criteria The committee will determine the most advantageous proposal based on the information provided by the Bidder in its proposal upon the following criteria: 2.14.1 Proposal responsiveness, proposal requirements, demonstrated ability to provide and deliver the proposed technical services. 2.14.2 Reference and representation among higher education and public agencies. 2.14.3 Quality of and advanced nature of proposed technology, completeness of product and client installations. 2.14.4 Extent of Bidder’s management of all product elements and components related to the product offered. 2.14.5 Demonstrated degree of control and security for the proposed technical services provided by the Bidder. 2.14.6 Proposed system functionality, additional options and demonstrated ease of use for all aspects of the proposed system. 2.14.7 Completeness and clarity of the Proposal and demonstrated understanding of the scope of McGill’s required project. 2.14.8 Demonstrated ability to provide system and services which will satisfy all other specifications requested within this document. Page 7 of 37
  8. 8. Purchasing Services Request for Proposal No. MP8-040(PLe) 2.14.9 Extent proposal demonstrates focus and appropriateness tailored to McGill requirements and specifications in this RFP document. 2.14.10 Number of years in business under current ownership, relevant experience and success in providing services to the Bidder’s client base. 2.14.11 Evidence of the Bidder’s financial stability. 2.14.12 Qualifications and availability of staff to be assigned to the planning, implementation and ongoing support of McGill System. 2.14.13 Demonstrated ability to maintain the proposed system at required service levels. 2.14.14 Available optional or additional services which could be considered advantageous to McGill. 2.14.15 Warranty offered 2.14.16 Training offered 2.14.17 Any other criteria deemed to be in the interest of McGill. 2.15 Additional information The Selection Committee reserves the right, at the time of evaluation of any Proposal to request any additional information that it deems necessary in order to make a decision on any Proposal. 2.16 System demonstration The Selection Committee reserves the right, at the time of evaluation to invite a short list of Bidders to perform a presentation of their proposed System at the University. Not all Bidders may be invited. 2.17 Ethics Bidders who submit bids in this RFP process recognize and agree that the Supplier who is awarded the Agreement(s) for the services requested in this RFP will be McGill University’s Supplier of these services. The University recognizes its responsibility to encourage and promote the use of the awarded Agreement(s) according to its/their terms and conditions. Bidders who submit a Bid agree to be bound by the terms of this RFP and to respect the terms of the awarded Agreement(s). Any actions, including solicitation by an unsuccessful Bidder, which have the effect of undermining the effectiveness or violating the terms of the awarded Agreement(s), shall constitute a violation of this RFP for which such unsuccessful Bidder will be held responsible for any damages and claims that may result. 2.18 Acceptance and award 2.18.1 McGill intends to award a contract to the Bidder whose Proposal offers the best value to McGill, based upon the terms and conditions of this RFP document and the specifications and service requirements indicated herein. However, McGill is under no obligation to award any contract in whole or in part and McGill reserves the right in its sole discretion to cancel this RFP process at any time before or after closing without providing reasons for such cancellation. Rejection of all Proposals will mean that the University, in its own best interest at this time, has determined not to pursue this issue. 2.18.2 The lowest cost Proposal or any other Proposal may not necessarily be accepted. 2.18.3 In order to obtain the most advantageous offer for McGill, McGill reserves the right in its sole discretion: • To waive irregularities and/or minor non-compliance by any Bidder with the requirements of the RFP; • To request clarification and/or further information from one or more Bidders after closing Page 8 of 37
  9. 9. Purchasing Services Request for Proposal No. MP8-040(PLe) without becoming obligated to offer the same opportunity to all Bidders; and • To enter into negotiations with one or more Bidders without being obligated to negotiate with, or, offer the same opportunity to all Bidders. 2.18.4 Bidders are advised however to submit a complete offer as their bid. Any waiver, clarification or negotiation will not be considered as an opportunity for Bidders to correct errors in their bids. 3.0 BIDDER PROFILE, EXPERIENCE AND REFERENCE 3.1 Bidder profile 3.1.1 Unless Bidder has already provided similar information in another McGill RFP less than one year ago, Bidder is required to provide one copy of financial and organizational data that demonstrates the size, scope and capability to handle McGill’s specific requirements specified in this RFP. Annual reports must be included in your response. 3.1.2 Unless Bidder has already provided similar information in another McGill RFP less than one year ago, Bidder is required to identify all organizational components and other companies or organizations with which it is affiliated. Include subsidiary and other company addresses. Explain any company relationships that could be construed to be a conflict of interest in doing business with McGill now or in the future. Indicate any significant past or pending lawsuits or malpractice claims against Bidder 3.1.3 Unless Bidder has already provided similar information in another McGill RFP less than one year ago, Bidder must submit independently audited financial statements (one copy only) including its statement of financial position, statement of operations, and statements of cash flows for at least the past three (3) years. Include most recently available interim statements. Such financial information will be treated in strict confidence. Financial information should be submitted, under separate cover, directly to the Issuing Office to the attention of the aforementioned buyer in Section 2.1. 3.2 Experience and reference information 3.2.1 The successful Bidder shall be an organization that has an excellent record as an external provider of the services in the type and scope detailed in this RFP. Accordingly, Bidders are to state in their Proposals their qualifications to meet the RFP requirements in terms of past and current experience. At the very least, Bidder must have minimum three (3) years experience providing the proposed System to an institution or business of equivalent size and dollar volume. 3.2.2 All potential Bidders are to provide the names of all university clients, addresses, contact names and titles, with the telephone numbers, which have Systems comparable to what is described herein. 3.3 Project Manager McGill prefers a specific project manager and team for implementation and ongoing support to be assigned to McGill. If this is the case, please designate individuals, state their qualifications and also their experience. List their hours of support and include a toll-free number, if available. Also, advise if an experienced technical (system) person will be assigned to our account to streamline project implementation and to aid program maintenance. Page 9 of 37
  10. 10. Purchasing Services Request for Proposal No. MP8-040(PLe) Page 10 of 37
  11. 11. Purchasing Services Request for Proposal No. MP8-040(PLe) 4.0 SERVICE CAPABILITY DECLARATION. Please provide a response in the format requested relative to the Service Provider’s ability to successfully provide each of the Capability Items in the tabular format provided below. Capabilities or features presented in grey shaded boxes are considered essential to the system behaviour desired for Mass Notification. 4.1. ARCHITECTURE AND LICENSING (ON PREMISE) In the context of an On Premise solution, the McGill preferred topology relies on two redundant servers, configured in a cluster environment, with load balancing and automatic failover between them (see Figure 1). McGill’s preference is for IBM Entreprise Servers (Series X), or a virtual server environment using VMware ESX Entreprise. The backend database would be Oracle 10i on an Oracle Cluster (ORAC). All servers and Database will be provided by McGill, as per Bidder’s specifications (Table 1-a). PBX interfaces will be provided or recommended by vendor. FIGURE 1 AUTOMATED NOTIFICATION SYSTEM SERVER 1 SERVER 2 INTERNET ORACLE DATABASE 1 Gbps 1 Gbps McGill Network IP/T1 GATEWAY IP/T1 GATEWAY 2 T1 ISDN 2 T1 ISDN NORTEL OPTION 81 PBX PSTN NORTEL OPTION 51 PBX MAIN CAMPUS MACDONALD CAMPUS The preferred connectivity to McGill’s PBX’s would be ISDN PRI (T1), but other technologies like analog Trunks, Digital Set Emulation and IP trunking (SIP or H323) availability will be considered. Regardless of the technology used, McGill requires a minimum of 46 ports to each PBX. Bidders shall propose proven gateways for their application. Gateways shall connect over IP to the Application servers. Gateways are the only hardware to be included in the bidders’ proposals. Page 11 of 37
  12. 12. Purchasing Services Request for Proposal No. MP8-040(PLe) PBX’s in service are Nortel Meridian 1 systems. Phone numbers on the PBX’s can be 4 to 7 digit extensions, and can be in any digit sequence, including leading digit zero (examples: 1234, 01234, etc). The system must support authentication against LDAP or Microsoft AD, and contact information must be updatable automatically from the same source. McGill plans to have an unlimited number of Recipients of notification with multiple Contact information, an unlimited (or very large) number of notification Initiators, and an unlimited (or very large) number of system Administrators. Please provide pricing information in Schedule 1. Table 1 – Architecture and Licensing # Capability Item Response Type Response or Comment Recommended minimum server 1 Describe characteristics. 2 Supported Operating Systems. Describe If you have multiple products that 3 can deliver the application, specify Describe which product is proposed, and why. Base License Type (enterprise, per Describe and price 4 user, per Initiator, etc). in Schedule 1 Describe Annual maintenance/licensing costs. maintenance plan 5 What are the days and hours of and price in coverage? Schedule 1 Are software upgrades included in 6 maintenance? What is the typical Yes or No frequency of upgrades? Describe and price 7 Integration through analog lines. hardware required in Schedule 1 Describe and price 8 Integration through T1 (ISDN). hardware required in Schedule 1 Describe and price 9 Integration through IP Trunking. in Schedule 1 Describe and price Integration through Nortel Digital 10 hardware required Set Emulation. in Schedule 1 Yes or No Oracle backend database support (on 11 Describe versions an Oracle Cluster). supported 12 VM (Virtual Machine) support. Yes or No 13 Windows clustering support. Yes or No Load balancing support between two 14 Yes or No cluster nodes. 15 Automatic Failover support between Yes or No Page 12 of 37
  13. 13. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 1 – Architecture and Licensing # Capability Item Response Type Response or Comment two nodes. Authentication against LDAP or AD 16 Yes or No (for Administrators and Contacts). If LDAP/AD authentication is not supported, please describe how 17 Describe usernames, passwords and PIN’s are created and managed. System supports client-free web- based access (no special clients or virtual machines required for web browser). All aspects of the system Yes or No 18 can be used from a web browser to Specify supported create scenarios, templates or scripts, browsers manage application configuration, initiate notifications or update user information. Does your system require Active X, Java Web Start, Flash or other similar client or agent-type code Yes or No 19 extensions? If so, please describe Describe the capabilities that would NOT be available to MAC users. System can be migrated from vendor hosted SAAS model to Entreprise System running locally on a customer provided infrastructure. In such scenario, where is the SAAS system located, how would the Yes or No 20 contact information be migrated to Describe McGill’s system, and what guaranties can be provided that the information will be permanently removed from the SAAS’s system after the migration? System can be deployed in a Hybrid mode, where the application resides on a customer owned infrastructure, Yes or No 21 but utilizes SAAS’s communications Describe ports (telephone and Internet). Please describe how Text Messages are delivered. In a Hybrid mode, where is your communications server located (the 22 Describe one that would hold McGill contact information). Page 13 of 37
  14. 14. Purchasing Services Request for Proposal No. MP8-040(PLe) 4.2. DEVICE ADDRESSING, LISTING CAPABILITIES AND LIMITATIONS The proposed system must be able to deliver notifications to any type and any quantity of phone device, PDA device, e-Mail accounts, IM and TM devices. It must able to interact through an API with other types of notification systems to deliver or post messages on WEB sites, portals, Public Address systems, etc. Please identify any particular numeric limits or otherwise list as “unlimited.” Describe system behaviour where requested. Notification Initiators must be able to launch notifications from pre-determined scenarios, modifiable on the fly, or as ad hoc notifications. Launching of notification must be possible from a WEB site or from a telephone line. Capability to launch notifications automatically in response to triggers generated electronically (SNMP traps, SNIPS Alerts, Security system alerts, Environmental Control system alerts), and capability to launch notifications from a PDA or Blackberry or from an email add significant value to the proposal. Table 2 - Device Addressing, Listing Capabilities and Limitations # Capability Item Response Type Response System supports simultaneous 1 delivery of notification to all types Yes or No of devices. System allows notifications to be Yes or No securely initiated from various 2 List devices and devices (DTMF phones, WEB, limitations PDA, Blackberry, eMail). System supports delivery to unlimited number of telephone Yes or 3 devices (landline phones, cellular Limitation per phones, PBX phones, Pagers of all device type kind). System supports delivery to 4 unlimited number of e-Mail Yes or Limitation accounts. System supports delivery to unlimited number of Text Messaging (TM) devices, directly or Yes or Limitation 5 through a third party aggregator. Describe Furthermore, how is the notification delivered? Single email, multiple emails, single emails with a list? System supports delivery to 6 unlimited number of Instant Yes or Limitation Messaging (IM) devices. System supports delivery to 7 unlimited number of 2-way Alpha- Yes or Limitation Numeric Pager. System supports delivery to Public 8 Yes or No, and how Address systems. Page 14 of 37
  15. 15. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 2 - Device Addressing, Listing Capabilities and Limitations # Capability Item Response Type Response System supports delivery to other Describe and 9 types of devices (ex: TDD/TTY). provide Limitations System supports scheduled delivery 10 of notification, for single events and Yes or No for recurring events. System supports granting priority to 11 new notifications over queued Yes or No notifications. Escalation to different devices. System supports defined calling order strategies using broadcast messaging to specific Recipients 12 Yes or No persisting in contact attempts using consecutive escalation paths until the event reaches a time limit or the Recipient provides a response. Escalation to alternates. System supports a number of user- defined alternates that can be listed for automatic escalation of Yes or No 13 notification to alternates if primary Number of alternates Recipients do not respond to the notification after a period of time or number of attempts. System supports the ability to assign a limit to the number of 14 attempts made to reach individuals Yes or No and specify the wait time between attempts. System supports interruption, suspension or cancellation of a notification. In such case, does the Yes or No 15 system provide the capability of Describe launching a corrective notification to Recipients already notified? System supports FIFO (First In First 16 Out) in the case of multiple related Yes or No notifications. Yes or No Delivery of voice notifications from Describe the 17 a recorded voice file. mechanism for acquisition voice file Yes or No Delivery of voice notification from Describe the 18 a text original (through Text-to- mechanism for Speech). acquisition of text notifications Page 15 of 37
  16. 16. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 2 - Device Addressing, Listing Capabilities and Limitations # Capability Item Response Type Response Languages supported for Text-to- Speech conversion. If you support Describe and specify 19 multiple languages, can you do price in Schedule 1 multiple language conversions if optional within same notification? Other types of devices supported for 20 Describe notification. System supports ad-hoc (on the fly) 21 Yes or No creation of notification. System supports ad-hoc (on the fly) modification to content or 22 Yes or No procedures of a scripted notification scenario. What are the response options available for Recipients per Describe type of 23 notification type (phone, e-Mail, responses PDA, TM, IM)? Maximum number of unique 24 Number responses the system can process. In the case of a Hosted or Hybrid solution, and a typical 15 seconds Number and 25 notification, how many telephone Limitations calls per hour can your system deliver? In the case of an On Premise solution, given the configuration described in Section 1 (47 B Number and 26 channels), and a typical 15 seconds Limitations notification, how many telephone calls per hour can your system deliver? Given the configuration described in Section 1, and a typical 60 words Number and 27 notification, how many e-mail Limitations messages per hour can your system deliver? Given the configuration described in Section 1, a typical 140 characters notification, and no third party Number and 28 involved in the process, how many Limitations Text Messaging (SMS) notifications per hour can your system deliver? Given the configuration described in Section 1, and a typical 30 words Number and 29 notification, how many Instant Limitations Messaging notifications per hour can your system deliver? Page 16 of 37
  17. 17. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 2 - Device Addressing, Listing Capabilities and Limitations # Capability Item Response Type Response System supports simultaneous notification of a 140 characters Text Yes or No 30 Message and a 60 words (or more) Describe email notification as part of the same event notification. System supports multi-modal communications with a specific device (i.e. voice, email, and text to Yes or No, and 31 different devices for same alert) Limitations where the user specifies device priority and order of message delivery. Page 17 of 37
  18. 18. Purchasing Services Request for Proposal No. MP8-040(PLe) 4.3. ADMINISTRATION AND SECURITY CONTROLS McGill is looking for an Enterprise System that can be deployed to numerous Faculties and Department, and be managed by these entities like if they each had their individual notification system. Please validate the particular Administration and Security element of your Notification System offering. Table 3 – Administration and Security Controls # Capability Item Response Type Response System uses organizational hierarchies to allow System Administrators to segregate lower 1 level Administrators, contacts, Yes or No groups/teams and objects from an interface illustrating ownership by organizational groups. Maximum number of contacts or 2 users (Recipients) the system can Number support. Maximum number of System Number and 3 Administrators with varying roles describe hierarchy and levels of access. Maximum number of organizations, Number and 4 groups, divisions or sub-divisions describe hierarchy that the system can support. Recipients can be granted roles in 5 Yes or No membership groups. Can roles be associated to AD 6 Yes or No groups? Recipients have the ability to 7 become members of multiple Yes or No groups/teams. If a Recipient is a member of 2 different teams and that these 2 8 teams are assigned as Recipients of 1 or 2 a notification, will this Recipient receive one or two notifications? System allows Administrator and group/team member to be granted a Yes or No 9 unique combination of privileges Describe privileges (such as Send, View, Cancel, Create, Edit, Delete). System uses Secure Socket Layer 10 Yes or No (SSL) for encrypting Web traffic. 11 System supports use of a custom Yes or No name/alias to be associated with each named device (such as Mobile Page 18 of 37
  19. 19. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 3 – Administration and Security Controls # Capability Item Response Type Response Phone) to mask actual device numbers/addresses in GUI and reports. System supports use of a PIN for actions like triggering responses, Yes or No 12 accepting deliveries or retrieving List actions notifications. System attempts to identify inbound 13 callers based on caller ID when Yes or No available. System requires each user/contact to 14 have an individual Login ID and Yes or No Password. System records a time and date 15 stamp for all message delivery Yes or No attempts including all retries. Page 19 of 37
  20. 20. Purchasing Services Request for Proposal No. MP8-040(PLe) 4.4. SYSTEM FEATURES, PROPERTIES & CAPABILITIES Table 4 lists system features that are either REQUIRED (shaded grey) for mass notification, or DESIRABLE for other types of notification. Please confirm the particular capabilities and/or limitation of the proposed Notification System. Table 4 - System Features, Properties & Capabilities # Capability Item Response Type Response or Comment System supports the option of allowing Recipients to be transferred directly into a live 1 Yes or No customer owned conference bridge (without requiring the meeting ID/Pin number dialling). System can distinguish between a live person, answering 2 Yes or No machine/voicemail, or busy signal when delivering notifications. System supports the message Initiator opting to allow or prevent 3 Yes or No notifications to be left on voicemail/ answering machine. System supports the ability to customize and save scenarios (or Yes or No 4 templates) for use in more than one Number of scenarios notification and response event. System supports saving scenarios Yes or No 5 (or templates) directly associated Number of scenarios with a particular group/team. System supports dynamic groups/teams creation before or 6 during activation by searching for Yes or No contacts based on certain contact attributes or keywords. System supports on-call scheduling 7 and rotations to determine contact Yes or No order and device priority. System supports vacation scheduling override of standard user schedule based on date range 8 Yes or No including customization of notification devices, device preference and device order. System supports import and update Yes or No 9 of vacation schedules from foreign Describe attendance programs. 10 Supports time phased n-level Yes or No response escalation based on lack of Page 20 of 37
  21. 21. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 4 - System Features, Properties & Capabilities # Capability Item Response Type Response or Comment a successful lower n-level response. System supports automatically launching notifications in response to triggers from other system (ex: Yes or No 11 SMTP traps, alerts from Security Describe how System, alerts from Environment control system) using provided API. System supports pushing information to external web based 12 Yes or No applications (example: Post a notification to the McGill Portal). System supports use of an API to identify specific Recipients and their contact information from a central database, to include in a Yes or No 13 specific notification (example: Describe how Notifying all students scheduled to have a course in building X tomorrow that courses are cancelled due to a pipe burst). System supports a self-maintenance mode by sending periodic survey- 14 type notifications to contacts Yes or No reminding them to update their contact data. System supports defined calling order strategies based on response count calling out to a specified 15 number of Recipients until a Yes or No successful fill count is reached halting further contact attempts (quorum). Yes or No System supports attachments to 16 Number in MB and eMail notifications. type of attachment System supports complex distribution of unique or multiple messaging to individuals or groups 17 from a single initiation event Yes or No including separate and distinct response options, call bridging and cascading events. 18 System supports survey or polling Yes or No type notifications accompanied by a series of interactive questions and responses for collecting Page 21 of 37
  22. 22. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 4 - System Features, Properties & Capabilities # Capability Item Response Type Response or Comment information. System supports definition of customized user-selected device 19 Yes or No preference associated with location or personal schedule. System supports user location update via DTMF where contacts dial in to the system using any 20 Yes or No telephony devices and using the keypad (DTMF) to update their location. System supports Recipient response confirmation where Initiators can 21 specify if they want to be notified of Yes or No who answered with what response to a notification. System supports user-defined time and date-based device escalations Yes or No 22 (i.e. - Business Hours, After Hours, Number Weekend Hours, etc). System supports unique user- defined device-by-device escalation order to specify which devices are 23 contacted in what order (i.e. - Yes or No Monday during business hours use ..., Wednesday after business hours use ..., etc). System supports Recipient response confirmation where Initiators can 24 specify if they want to be notified of Yes or No who answered with what response to a notification. System supports cascading notification responses triggers 25 allowing a specific response Yes or No selection to trigger follow-up notifications. System supports authorized user or Administrator override of Recipient’s device priorities by 26 Yes or No Initiator to send on demand device specific and location specific notifications. Page 22 of 37
  23. 23. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 4 - System Features, Properties & Capabilities # Capability Item Response Type Response or Comment System supports user defined device 27 prioritization (i.e. 1st - Office #, 2nd Yes or No - Mobile #, 3rd Blackberry, etc). Support use of a report screen to enable rapid re-launch of 28 notifications to non-responsive Yes or No Recipients or those whose response was undesirable. System supports an inbound telephone number that contacts can 29 Yes or No call to retrieve and respond to notifications. System supports the capability for the System Administrator to change 30 the system prompts (to eliminate Yes or No name branding, and personalize the system). Page 23 of 37
  24. 24. Purchasing Services Request for Proposal No. MP8-040(PLe) 4.5. DATA MANAGEMENT AND REPORTING FEATURES Please identify which reporting and system maintenance functionality will be provided as part of the Notification System. Table 5 - Data Management and Reporting Features # Capability Item Response Type Response 1 System supports OBDC. Yes or No System supports accented character 2 Yes or No sets and their transmission. Supports storage and management of recorded voice files allowing Administrators to search, delete and add new voice files based on 3 Yes or No attributes (creator, language, date- time, and type) to be used with any outgoing notification to a telephony device. Supports group searches where Recipient groups can be found by 4 Yes or No name or by group member first or last names. Supports saved notification searching using title, message 5 content, response option text, Yes or No Recipient names and other notification attributes. System supports contact look-up by attribute (i.e. Last Name, First 6 Yes or No Name, Group, login ID, title, building, floor, etc). System supports Comma Separated 7 Value (CSV) file Import and Export Yes or No of Contact and Devices information. System supports detailed reporting in a raw data formats, such as CSV 8 Yes or No files, for export, analysis, and printed reporting generation. System supports automatic acknowledgement giving Initiator or Recipient the option to be notified 9 when a message is answered and the Yes or No event is closed including the Recipient that closed the event and the chosen response. 10 System supports recording details Yes or No relative to message retrieval distinguishing between messages Page 24 of 37
  25. 25. Purchasing Services Request for Proposal No. MP8-040(PLe) Table 5 - Data Management and Reporting Features # Capability Item Response Type Response listened to by a live person, answering machine, voice mail or other device. System supports reporting of detailed real-time statistics about a particular notification campaign 11 including the number of emails, Yes or No SMS messages, phone calls, summary results of the campaign, etc, without any browser refresh. System supports reporting to event 12 Initiator via e-mail upon completion Yes or No of a notification campaign. System supports web-based audit trail of all past notifications with the 13 Yes or No ability to review and move through previously issued notifications. System supports reporting of status, 14 usage and system configuration Yes or No status via web-based reports. System reporting can list all 15 Yes or No contacts including their devices. System reporting can list all 16 contacts who do not have any Yes or No devices configured. System reporting can list all 17 contacts who have configured/not Yes or No configured a specified device types. System supports generation of 18 Yes or No custom reports using SQL queries. Page 25 of 37
  26. 26. Purchasing Services Request for Proposal No. MP8-040(PLe) 4.6. CONTACT DATABASE ATTRIBUTES Please identify the database attributes per user that are or can be provided as part of the Notification System. Attribute naming does not need to be an exact match. Provide a separate clarification note in the Vendor’s response identifying any group of attribute fields that may be concatenated into a single field. Also provide a clarifying note if a particular attribute is not currently provided but can be added through the utilization of customizable fields. Table 6 - Contact Database Attributes # Database Item Format Length Comment 1 master person ID 2 last name 3 first name 4 title 5 work phone number 6 home phone number 7 cell phone number 8 pager phone number 9 fax phone number 10 alternate phone number 11 e-mail address 12 alternate e-mail address 13 supervisor 14 organization 15 language choice 16 alternates 17 18 19 20 customizable fields Page 26 of 37
  27. 27. Purchasing Services Request for Proposal No. MP8-040(PLe) 4.7. ADDITIONAL PRODUCT FEATURES Please list any additional distinct Capabilities or features not listed above either in detail or in concept. Please do not repeat a capability listed above unless the described functionality represents a materially superior method of achieving gains in productivity and/or more rapid adaptability to the product. Table 7 - Additional Product Features # Feature Item 1 2 3 4 5 6 7 Page 27 of 37
  28. 28. Purchasing Services Request for Proposal No. MP8-040(PLe) 5.0 SERVICE PROVIDER’S DEPLOYMENT AND TRAINING PLAN Please provide a description of the system administration training and any end-user training to be provided as part of the system deployment: • Describe the typical timeframe necessary to provision the solution and have it ready to begin adding Contact data. • How long has it taken the average client to have the system configured for their needs? • Describe the type of training that is required to use your system? • Describe how you propose to furnish initial and follow-up training? • Describe the documentation and tutorials that will be provided. 6.0 GENERAL TERMS AND CONDITIONS 6.1 Performance Guarantee 6.1.1 The University requires that the goods supplied under the resulting Agreement are free from defects in material, workmanship and design, suitable for the purposes intended implied, in compliance with all applicable specifications and free from liens or encumbrance on title. All services are required to be performed in accordance with current, sound and generally accepted industry practices by qualified personnel trained and experienced in the appropriate fields. 6.1.2 Any warranty will begin upon final written acceptance by the authorized representative of McGill of the complete system. 6.2 Billing process 6.2.1 The University billing address is: McGill University Accounts Payable 3465 Durocher 2nd Floor Montreal, Quebec, Canada H2X 2C6 6.3 Insurance 6.3.1 The Supplier shall furnish McGill, at the signing of the contract, with proof of insurance in the form of certificates evidencing the following insurance coverage: 6.3.2 Comprehensive General Liability Insurance, including but not limited to products liability, professional liability, contractual liability and non-owned automobile liability, covering the legal liability of the Supplier(s) for injuries to or death of persons and/or damage of property of others for limits of not less than two million dollars ($2,000,000.00) per occurrence for bodily injury and property damage. Such insurance shall name McGill as a named insured and shall contain Cross Liability coverage and preclude subrogation claims by the insurer against McGill. 6.3.3 Automobile Liability Insurance covering the legal liability of the Supplier(s) for injuries to or death of persons and/or damage to property of others for limits of not less than two million dollars ($2,000,000.00) per occurrence. 6.3.4 The insurance policies referred to herein shall contain an endorsement to provide McGill with thirty (90) days prior notice in writing of any material changes or cancellations to any Page 28 of 37
  29. 29. Purchasing Services Request for Proposal No. MP8-040(PLe) of the above policies. 6.3.5 Evidence of insurance satisfactory to the University shall be provided with the Form of Tender Offer if in place at the time of submission or prior to the commencement of the Agreement period. 6.4 Confidentiality 6.4.1 In the performance of the services, the Supplier and its subcontractors, if any, may have access to confidential information (hereinafter referred to as the "Confidential Information") which McGill must protect from disclosure pursuant to the Act respecting access to documents held by Public Bodies and the protection of personal information R.S.Q. c. A-2.1. 6.4.2 The Supplier undertakes to hold all of the Confidential Information it receives in strict confidence and neither to disclose nor release in any manner such Confidential Information to any third party nor to use such Confidential Information for any other purpose than the one for which McGill has disclosed same; to disclose Confidential Information only to those of its employees or agents who need to know such Confidential Information for the said purpose. The Supplier warrants that such employees or subcontractors are obligated to and will hold Confidential Information in strict confidence and to take all reasonable measures to ensure that confidentiality is respected. 6.5 Source Code The Supplier shall, at its expense, hold the source code for the software in escrow for the entirety of the resulting Agreement in the case of insolvency or bankruptcy of the Supplier. The source code shall be delivered within five (5) days after the earliest occurrence of: • The Supplier announcing its determination to cease providing support services to McGill for the software without arranging for any third party to provide such services; • The Supplier becoming unable to meet its debts or become a party to any procedure under federal or provincial bankruptcy laws and regulations for the settlement of its debts; • The Supplier's failure to affect corrections or replacements to the software. 6.6 Indemnity and Patent Infringement 6.6.1 The Supplier shall indemnify and save harmless the University, their Board of Governors, officers, their employees, and agents against all claims, losses and expenses from whatever source, and of whatever nature and kind arising out of the Supplier’s performance of the Agreement or the work or the rendering of any services contemplated hereunder by the Supplier or any of its employees or agents. 6.6.2 The University shall not be held responsible for any injury sustained by the Supplier, its employees or any person on the University’s premises nor will the University be responsible for any loss, including lost profits or damage caused to the goods of the Supplier, its employees or any other person, including damage to cars and their contents, while these goods are on the University premises. 6.6.3 Supplier shall indemnify and hold McGill harmless of any claim that the use of the goods by McGill, its employees, agents, students or any of its successors and assigns infringes any copyright, trademark or patent and shall be responsible for any cost (including the costs of legal representation), expense, damage or loss incurred in any manner by McGill on account of any such alleged infringement. Page 29 of 37
  30. 30. Purchasing Services Request for Proposal No. MP8-040(PLe) 6.7 Assignment of Agreement 6.7.1 The resulting Agreement may not be assigned, encumbered or otherwise pledged by the Supplier without the express written consent from the Authorized Representative of the University. 6.7.2 The Agreement will remain valid and in effect, until the conclusion of its term by any successor company to the Supplier; however, the University will have the right to review the Agreement in the event of a successor company and exercise its option of termination. 6.8 Independent contractor 6.8.1 Supplier shall perform all of its obligations under the resulting Agreement as an independent contractor and shall discharge all its liabilities as such. No acts performed or representations made, whether oral or written, by the Supplier with respect to third parties shall be binding on the University. 6.8.2 The Supplier shall keep informed and shall faithfully observe all laws, ordinances and regulations affecting its responsibility to the University. All products must conform and comply to current Federal and Provincial standards where applicable. McGill University will not be held responsible or liable for failure by the Bidder to comply with existing standards. 6.8.3 The Supplier shall throughout the duration of the finalized agreement, at its expense, obtain and maintain in force all necessary licenses and permits required for the completion of any Agreement resulting from this Request for Proposal. 6.8.4 The Supplier and all of its subcontractors shall be licensed to do business in the Province of Quebec. 6.9 Default 6.9.1 Either the Supplier or the University will be in default of its obligations under the resulting Agreement if any of the following events occur, namely:  such party is adjudged bankrupt or insolvent by a court of competent jurisdiction, or otherwise becomes insolvent, as evidenced by its inability to pay its debts generally as and when they become due; or  such party is in default of its obligations hereunder and fails to cure such default within thirty days of written notice from the other party, or if such default cannot be cured within thirty days, within such longer period as may be reasonable, provided the defaulting party commences promptly and diligently proceeds with curing the default. 6.9.2 Upon the occurrence of any of the above events, the party not in default may, by written notice to the defaulting party, terminate the Agreement without prejudice to any other right or remedy available to it at law and without liability for such termination. Neither the Supplier nor McGill shall be liable to the other for indirect damages, for loss of profit or for damages arising from loss of use or production. 6.9.3 Any notice to correct a breach or notice to terminate the Agreement shall be sent to:  McGill University: Associate Director, Purchasing Services, Vice-Principal (Administration & Finance);  The Supplier: Business Account Manager, Regional Manager and President. 6.10 Termination 6.10.1 The obligations of the parties will terminate on the date specified in the resulting Agreement. 6.10.2 Notwithstanding, McGill may also terminate or suspend the Agreement in whole or in part in which case, McGill shall provide the Supplier with written notice specifying the extent to Page 30 of 37
  31. 31. Purchasing Services Request for Proposal No. MP8-040(PLe) which performance and/or the deliveries of goods and services under the Agreement is terminated and/or suspended and the date upon which such action shall become effective. In the event of such action, McGill shall pay Supplier for the goods and services satisfactorily provided by the Supplier to the effective date of termination or suspension. 6.10.3 The termination of the Agreement shall discharge any further obligations of either party unless as provided for in the Resulting Agreement. 6.11 Force Majeure 6.11.1 The University and/or the Supplier shall not be considered in default of performance of their respective obligations under any resulting Agreement to the extent that performance of such obligations is delayed, hindered, or prevented by Force Majeure. Force Majeure shall be defined as any cause beyond the control of the University and/or the Supplier which could not reasonably have been foreseen and guarded against. Force Majeure in the case of the Supplier is understood not to include:  financial problems of the Supplier, its agents or suppliers, leading to failure to deliver;  a failure of the Supplier, its agents or suppliers, to maintain adequate supplies under Agreement;  a failure to maintain adequate number of appropriate trained service personnel. 6.11.2 To ensure that the University and/or the Supplier can make alternate arrangements, the party relying on a Force Majeure should provide a notice of the existence of a Force Majeure as soon as reasonably practicable. The suspension of the obligation to perform is temporary and the terms of the Agreement will be reestablished as soon as the Force Majeure no longer exists or the problem is remedied. 6.12 Insolvency The University shall have the right to terminate the Agreement at any time in the event that the Supplier files a petition in bankruptcy, or is adjudicated bankrupt; or if a petition of bankruptcy is filed against the Supplier and not discharged within thirty (30) days; or if the Supplier becomes insolvent or makes an assignment for the benefit of its creditors or an arrangement pursuant to any bankruptcy law; or if a receiver is appointed for the Supplier or its business. 6.13 Presence on the University’s premises The Supplier agrees that all persons working for or on its behalf whose duties bring them onto the University’s premises shall be governed by the rules and regulations that are established by the University and shall comply with the reasonable directions of the University authorized representative. Parking on the University property by the Supplier’s employees shall be governed by the rules and regulations of Parking Services, and subject to the prevailing rates. 6.13.1 The Supplier shall be responsible for the acts of its employees and representatives while they are on the University’s premises. Accordingly, the Supplier agrees to take all necessary measures to prevent injury and loss to persons or property located on the University’s premises. The Supplier shall be responsible for all damages to persons or property caused by its employees or representatives, either through negligence or willful damage. 6.13.2 The Supplier shall perform its activities on the University’s premises in such a way as to cause minimal disruption to the activities of the University’s faculty, students, staff and visitors. The Supplier shall be responsible for all damages to persons or property of any kind however caused by its employees or representatives. 6.13.3 All Suppliers’ employees working on the University premises shall wear appropriate Page 31 of 37
  32. 32. Purchasing Services Request for Proposal No. MP8-040(PLe) uniforms, and valid identification cards. 6.13.4 The Supplier shall ensure that its employees respect the University’s non-smoking environment. 6.14 Licenses and permits The Supplier shall throughout the duration of the finalized Agreement, at its expense, obtain and maintain in force all necessary licenses and permits required for the completion of any contract resulting from this RFP document. 6.15 Notices Every request and notice provided for in this Agreement and required to be given to the University shall be in writing and delivered, either personally or by registered mail, to the attention of the following person: Associate Director Purchasing Services McGill University 3465 Durocher, Room 101 Montreal, Quebec, H2X 2C6 6.16 Publicity Neither the University nor the Supplier may use the name of the other in publicity, solicitations, news releases or advertising without the express written consent of the other. However, nothing shall preclude the Supplier from listing the University on its routine client list as a matter of reference. 6.17 Governing laws The resulting Agreement shall be governed and interpreted according to the laws of the Province of Quebec. 6.18 Documents be drawn up in English The parties hereby confirm that they each required this document and notices in connection therewith be drawn up in English. Les parties reconnaissent par les présentes que chacune d'entre elles a exigé que cette convention et tout document ou avis y afférent soient rédigés en anglais. Page 32 of 37
  33. 33. Purchasing Services Request for Proposal No. MP8-040(PLe) 7.0 FORM OF TENDER I/We have examined the RFP document for the supply of a Automated Notification System, Project No. MP8-040(PLe) and hereby offer to supply McGill University the goods and services listed herein and at the prices set out therefore. I/We agree that this offer will remain in effect for one hundred and twenty days (120) following the closing time of Tender. This Proposal consists of: ____________pages. Official name and address of the Bidder: Company name: __________________________ Address: ________________________________ Signature of authorized officer: _________________________ Title: _________________________ Name (please print): _________________________ Telephone number: _________________________ Facsimile number: _________________________ Page 33 of 37
  34. 34. Purchasing Services Request for Proposal No. MP8-040(PLe) SCHEDULE 1 PRICING A) ON PREMISE SOLUTION DESCRIPTION PRICE Software and licenses Integration hardware Installation Training Maintenance year 1 Maintenance year 2 Maintenance year 3 Other B) HOSTED SOLUTION DESCRIPTION PRICE Monthly basic fee Cost per phone call completed or per minute Cost per email delivered Cost per TM delivered Other C) HYBRID SOLUTION DESCRIPTION PRICE Monthly basic fee Cost per phone call completed or per minute Cost per email delivered Cost per TM delivered Other Page 34 of 37
  35. 35. Purchasing Services Request for Proposal No. MP8-040(PLe) SCHEDULE 2 Glossary of Terms Term Definition AD Microsoft Active Directory A user or contact with elevated privileges allowing for the creation, Administrator modification and elimination or groups and/or privileges at permission levels below the Administrator API Application Programming Interface ASP or SAAS Application Service Provider or Software As A Service The process of positively identifying a user / contact through the Authenticate use of a combination of personal identity factors such as username, password, PIN, etc. Broadcast A notification issued to more than one contact or user The process of joining two or more telephone call into a single Call Bridging multi-caller conference The process and/or practice of triggering follow-on notifications Cascade based on response results or a particular lack of response Cellular or Mobile Any type of addressable mobile telephone handset or network CLI Command Line Interface A conference calling system that is internally operated and Conference Bridge maintained by an organization and which is usually tied in to the operation of the organization’s PBX or telephone switching system Contact order The order in which a particular Recipient’s devices are notified CSV Comma Separated Values A physically or logically addressable mechanism that can deliver Device audibly or display visually the content of notification (i.e. a telephone, pager, fax, Blackberry, e-mail account, etc) A user / contact’s selection of devices on which they prefer to be Device Priority notified relative to a given time or place DTMF Dual-Tone-Multi-Frequency (also known as Touch Tone) The process of moving to the next defined Escalation Tier once all Dynamic Escalation responses for that tier have been processed (overriding Maximum Response Time set for a particular tier) An e-mail address listed as an attribute of an active user / contact eMail account account within the system Encryption The process of coding data so that it cannot be easily read without the use a decryption key Enterprise System Notification System is installed behind customer firewall (not hosted) The process and/or practice of automating successive notifications Escalation Tier to the next tier(s) based on a lack of response or particular response from a previous tier Page 35 of 37
  36. 36. Purchasing Services Request for Proposal No. MP8-040(PLe) Glossary of Terms Term Definition Notification System is installed behind customer firewall, but utilizes Hybrid System hosted communication ports A user or contact account that has triggered a notification from the Initiator system IVR Interactive Voice Recognition A software-based virtual machine coding language originally Java developed by Sun Microsystems used regularly in the development of platform agnostic web applications LDAP Lightweight Directory Access Protocol A named virtual tag for use in identifying multiple sets of device Location preferences associated with a particular user / contact A schedule associated with a particular user / contact that allows Location schedule for varied device preferences and device priorities based on a schedule Typically an alphanumeric plus special character string known only to a particular user / contact and the system used for Login Password authenticating a user / contact at Login or for ID verification to execute certain high-level system functions A multi-modal device is one that can accept more than one type of Multi-modal notification such as a Blackberry that can communicate using voice, eMail and text (SMS) message types Notification A message sent by the system OS Operating System With respect to notifications, a notification that has been issued by Outbound the system is an outbound communication PIN Personal Identification Number A listing of the database attributes associated with a particular user Profile / contact account including all contact information, devices, device preferences, device priority, personal schedules, etc. PSTN Public Switched Telephone Network A user or contact account that has received or is scheduled to Recipient receive a notification from the system Contacts or users responding to an system issued notification via Respondent any device Membership in a group or team that has been granted specific access and functionality permissions specifically associated with Role the group or team for the manipulation of notification system settings and data in the system Role Based Access A method of granting permissions and privileges based on a particular user / contact’s individual or collective roles resulting from membership in particular group / team such as System Administrators being members of a particular Systems Page 36 of 37
  37. 37. Purchasing Services Request for Proposal No. MP8-040(PLe) Glossary of Terms Term Definition Administration group / team where have been granted elevated access The process by which specific groups / teams and/or specific users Rotation Schedule / contacts are scheduled for notification based on a recurring (OnCall) schedule A pre-defined notification or series of notifications that can include Scenario or Template actions to be executed if and when a designated response is received SMS Short Message Service SMTP Simple Mail Transfer Protocol SSL Secure Sockets Layer TDD/TTY Telecommunications Device for the Deaf/TeleTypewriter TTS Text-to-Speech A unique name with a one-to-one association with an active user / Username contact account within the system VXML Voice eXtensible Markup Language Page 37 of 37

×