Request for Proposal
for SMS Services
Tender Reference: 2004/7
December 2004
Contents
1
1.1
1.2
Introduction
Purpose and scope of this document
Background information
2
Requirements And Specifications
3
RFP Procedure
4
Instructions For Format And Contents Of Proposal
1
1.
Introduction
1.1
Purpose and scope of this document
The purpose of this Request for Proposal (hereafter "RFP") is to solicit proposals from
vendors for the following services that will enable the University to broaden its current
communication channels to students:
 A bulk SMS messaging service
 The ability to handle interactive messages in the form of service requests or other
“transactions” from students who will query or update existing databases in a secure
environment
 A comprehensive and customisable reporting function
The requirements for the services are stated in Section 2: Requirements and Specifications.
The RFP procedure and the instructions for the format of submissions are provided in section
3 and section 4 respectively.
1.2
Background information
Unisa is a dedicated distance education institution that offers university and technikon-type
programmes. A variety of teaching approaches are used and multiple entry and exit points
are available. The merger between Unisa and Technikon Southern Africa and the
incorporation of the Vista Distance Education Campus (Vudec) on 1 January 2004 lead to the
“new” University of South Africa which currently boasts approximately 200 000 students.
The demography of the Unisa student community is extremely diverse in terms of age,
language, culture and students are situated all over the world. The main medium to
communicate with students is still to send printed material through the postal system but email is increasingly used for students who have e-mail facilities and access to the Internet.
Since many Unisa students have cellular telephones, or access to mobile phones, the
University perceives SMS as a viable form of communication and has decided that this
technology should be used to improve the services to students and at the same time take
advantage of lower costs – for Unisa and its students. There are numerous functional
divisions who would be able to use this technology as an efficient means of direct
communication to our students. Examples of this would be our library (late book reminders),
exam department (dissemination of exam results), finance department (statements) etc.
The core IT systems at Unisa are an in-house developed Student Administration system,
using an Oracle database, and commercial applications for HR, Finance and the Library
(Oracle HR, Oracle Financials and Innopac from Innovative Interfaces). The Student
Administration system has been developed with AdvantageGen - a Computer Associates
applications development tool. It is foreseen that all these systems would need interfaces to
send and receive/process SMSs. These interfaces would by necessity need to be written by
Unisa to cater for this diverse mixture of technologies.
2
2
Requirements and specifications
2.1
Volume
Due to the fact that Unisa boasts approximately 200 000 students, it may be possible that we
would require as many SMSs to be sent at any one time. The envisioned functions that we
would be using SMS technology for are by nature not very accurate for predicting volumes at
any given juncture, but working on the premise that we will send each student ten SMSs in an
academic year, we are estimating a volume of about 2,000,000 SMSs per calendar year.
2.2
Transmission to an on-line service
The service provider must allow the requests for the transmission of SMS messages to be
transmitted to an on-line service. This would incorporate the transmission of the request file to
the service provider's system over an agreed medium. Once the request has been
transmitted, the SMS transmissions should begin immediately, with no human intervention.
The speed of the connection between the service provider and UNISA should be agreed upon
in the service level agreement (SLA). UNISA would prefer the network that will be utilised to
be the Internet, even with the understanding that a dedicated network provides better security
and speed.
2.3
Secure connection
An encrypted communications channel between UNISA and the service provider is required.
This should preferably be a Secure Shell (SSH) connection.
2.4
Communications protocol
The communications protocol, including issues such as file format, headers and footers, must
be agreed upon and may not change. The reason for this is that Unisa will be developing
automated systems and a fixed protocol will ensure that no system changes will have to be
made due to a change in the protocol.
2.5
Priority feedback mechanism
The service provider's system must be able to report failed transmissions immediately. When
bulk SMSs are requested, any immediate failures must be reported within a specified time as
per the SLA and via an agreed medium and protocol. This is to allow Unisa to use other
methods of communication to get the information to the relevant students.
2.6
Two-way communications
Students and prospective students should be able to send requests via SMS with a
keyword/code that will be processed by the University’s systems. Such messages or data
should be forwarded to UNISA to a system for processing. This implies that a script that is
controlled by UNISA will accept this message and dependent on its contents, either route it
(via email) to a responsible person, or activate another script to perform whatever task is
requested. An example of this is where a student sends an SMS with the code “RENEW”
followed by the student number and a library item number to UNISA. The system decodes the
request and replies to the student with an SMS message: Renewal request accepted. Item
“number” is now due on “date” or Item may not be renewed. Please return item “number”.
2.7
Reporting
The service provider should be able to provide detailed reports. The reports should be in
comma delimited (CSV) format, or exportable to CSV. Reporting should include:
 Itemised list of all numbers requested.
 Total of all numbers requested.
 Itemised list of numbers succeeded including cost.
3
 Total of numbers succeeded including cost.
 Itemised list of numbers failed.
 Total of numbers failed.
2.8
International communications
The service provider must cater for international communications as UNISA has many
students that reside outside the borders of South Africa. A list of the countries to/from which
the service provider is able to send/receive messages should be provided.
2.9
Hardware and software requirements
Please state the hardware and/or software that is required at Unisa to implement the solution.
2.10
Implementation
Please state a guaranteed exact implementation date or the number of days from the signing
of an agreement, for the implementation of the solution.
Please state the type of expertise/assistance that you offer with the implementation of the
service and/or integration with the Unisa systems.
2.11
Service Level Agreement
A formal Service Level Agreement (SLA) that should include at least the following needs to be
instituted:
Aspect
Requirement
Connection speed
Unisa expects a throughput to the service provider of 8 Kbits per
second. The service provider will need to ensure that its connection to
the Internet is of sufficient bandwidth to provide this speed at any time
of day.
Availability
UNISA expects 99% availability over any one year period. Business
continuity, backup and disaster recovery procedures should be
specified.
Throughput
UNISA expects to be able to send 200 000 SMSs within one hour of
transmitting the request.
Error report
If a batch of SMSs is requested, any failure/s must be reported to
UNISA within one hour of commencement of the start of the batch
transmission.
NB!
2.12
A draft Service Level Agreement should form part of the proposal.
Contract/business options and issues
The University will consider agreements for a maximum period of one year with a renewal
option.
The Service Provider should present a draft agreement that covers order, billing, price,
payment, reporting and service level issues. See also 2.11 regarding the Service Level
Agreement.
The University prefers to pay for services rendered based on invoices/statements – in other
words not to purchase credits that may be forfeited if not used within a certain time period.
4
3
RFP Procedure
3.1
Sealed Tenders, including the Vendor application form, must be submitted into the official
Tender box located in the OR Tambo Administration Building, Room 6-16, Pretoria Campus
or into the official Tender box located in the reception area on the ground floor of the
Administration Building, Florida Campus. Please quote the tender reference number on the
sealed envelope.
3.2
The closing date for submissions is 12:00 on Thursday 20 January 2005.
3.3
All communications and inquiries of a technical nature should be directed per electronic mail
to smstender@unisa.ac.za. Replies relating to the received inquiries will be made available
for viewing by suppliers at http://www.tsa.ac.za.purchase/index.htm (SMS Services).
3.4
Each candidate will be notified in writing of the result.
3.5
Unisa will treat all information as confidential until the selection process had been completed.
In no event shall Unisa be liable for any breach of confidentiality.
3.6
The bidder must certify that the proposal, including prices, are binding, and will remain in
effect until 1 April 2005.
3.7
Proposals submitted may be withdrawn at any time up to the submission date and time by
submitting a written request signed by an authorized representative of the information
provider to the designated Unisa contact person.
3.8
Unisa expressly reserves the right to reject any and all proposals without penalty, to waive all
technicalities and irregularities and deviations of information provided and to be the final
judge in the selection process.
3.9
Unisa will not be liable for any errors or omissions in the proposals. Unisa reserves the right
to make corrections or amendments due to minor errors (typing, transposition, or any other
obvious error) in the submitted information identified by Unisa or the candidate.
3.10
The cost for preparing the proposals will be borne by the candidates. Unisa is not liable for
any costs incurred by candidates in the preparation and presentation of information and
demonstrations submitted in response to this RFP, or for travel costs for site visits to Unisa.
3.11
Please take note that all tender documents, as well as all annexures, must be signed by a
properly authorised signatory of the tenderer and the tenderer must confirm that its signatory
has the authority of the legal entity to sign the applicable documents, by attaching a certified
copy of the relevant resolution of the legal entity.
3.12
Timelines for Tender Process
Date
Action
20 January 2005
Tender Closing Date
21 Jan - 28 Feb 2005
Tender Working Committee to evaluate tender submissions
1 March 2005
Report to be Submitted to the Tender Committee Secretary
14 March 2005
Tender Committee Meeting decide on recommendation
29 March 2005
Management Committee Meeting make final decision
5
3.13
Evaluation Criteria
The following criteria will be used during the selection process:
Criteria
Sub-criteria
Vendor Profile
BEE
Financial stability
Technical expertise of support staff
Costs/Price
Setup cost (hardware, software, consulting)
Annual maintenance/license fees
Price per message sent
Price per message received
Price per reply message sent
Technical aspects As per requirements
Other aspects
Implementation plan and timeline
Completeness and acceptability of draft agreements and contract
Format and completeness of proposal
6
4
Instructions for Format and Contents of Proposals
PROPOSALS SHOULD BE FORMATTED AND
STRUCTURED AS OUTLINED BELOW
1.
Covering letter
2.
Proposal
Your proposal should be structured as follows:
Response to the requirements
Supply information in the same order as stated in Section 2: Requirements.
Cost Schedule
Provide the following cost information (VAT inclusive) in Rand (where applicable):
Setup cost
Hardware
Software
Consulting for implementation
Training
Keyword or code for Mobile Originating messages
Operating costs Annual maintenance/license fees (including cost for keywords/codes)
Price(s) per local message sent according to expected annual volumes
Price per international message sent
Price per message received (cost to Unisa)
Price per reply message sent
Other costs
3.
Please specify
Vendor Information
The University’s Policy on Purchasing requires all prospective suppliers to apply to be
registered on UNISA's supplier database of products and services on the prescribed form.
All prospective service providers should complete the attached application form (Form F25)
and submit the form and other required documents with the proposal.
Please direct enquiries about the application form to one of the Purchasing Offices:
Pretoria campus: (012) 429-2640 or 429-2573
Florida campus: (011) 471- 2812 or 471-2130
4.
Additional information (optional)
Provide any relevant information that you consider necessary to add that is not explicitly
required by the request or covered in the supplier application form.
7
8