Pre-Bid Queries for Providing & Implementing of Bulk SMS Solution/Service

Transcription

1 1 Page 11 Point 11 Bidder should have tie up/ arrangements with multiple service providers for outbound messages. ICSI will not enter into any agreement with any other service provider (other than L1 vendor) For operator this should not be valid as we have POI(Point of interconnect) with all telco s, we need un-interruptible services 2 Page 12 Point 23 There should be facility to save a sent message automatically for a predefined time period, which the user should be able to forward. Input - Need more clarity on this. we need for the scheduling of the message 3 Page 11 Point 1 The solution should be able to accept messages through HTTP requests from other applications of ICSI and MIS of such messages should appear under different categories in MIS. Client would be required HTTP and web application, both services will have separate features Real time MIS for HTTP service is also required. 4 Page 11 Point 2 Test sms for approval feature is optional. Client would be required HTTP and web application, both services will have separate features 5 Page 11 Point 6 Automate delete option for duplicate numbers in the list. Automate delete options during file submission, is this will only for web or HTTP as well because we do not have this feature for HTTP Prior to send any Bulk SMS to check the test message. For Bulk Message it should eliminate duplicate mobile no.s. For HTTP request it s should be configurable. 6 Page 11 Point 7 The tenderer(s) / bidder(s) has to provide services for sending Bulk SMS from 6:00 p.m. to 12:00 a.m. on week days and from 9:00 a.m. to 11:00 p.m. on weekends and holidays, if required. Transactional messages could be send any time however Promotional message would be send between 9AM till 9PM only. This is fine as per TRAI regulation.

2 7 Page 11 Point 8 The system should have HTTP / HTTPS / FTP Purging of DND is available at Vf service however This is fine. / SMPP Interface, Back up for Push invalid number would be failed at Operator messaging, Black listing and Purging/Filtering of Lists of Invalid Numbers, DND Numbers. 8 Page 11 Point 9 The system must offer a retry as well as rerouting mechanism. Operator retry is available in case of network failure This is fine. Also service provider is retried in case of SMS inbox Full/absent 9 Page 11 Point 12 Bidder should able to send Short URL and getting and acting based on the response received. inbuilt short url feature available in web app, however for HTTP client need to integrate VF tiny API This is fine.api and the required documentation has to be send by the bidder 11 Page 11 Point 14 The system should provide the authentication functionalities (multi-factor authentication, if, necessary) and create, modify and send messages to the group/groups according to the Permission level. Multiple user id based System along with parentmaster relationship. 12 Page 12 Point 16/17 There should be provision of assigning administrative rights to select users depending upon their hierarchy for managing users in lower hierarchy. The administrative rights include setting SMS sending limit, readjusting SMS sending limit of users in hierarchical order. ICSI requires Sendsmart master panel Yes We Required.

3 Detailed MIS view for each ICSI user depending upon its hierarchy giving details such as number of messages sent in summary form or in detailed form. The user should be able to view number of messages sent month wise in a financial year through MIS. 13 Page 12 Point 18 There should be online real-time MIS available for different feature as desired by ICSI (like checking number of messages delivered, number of messages pending for delivery etc.). Further drill-down of figures should be possible in the same MIS. Downloading Options for all the Reports in different formats (like CSV, excel etc.) should be available DLR will be available on MIS panel after 15 min delay, in case of real time DLR update client need to integrate HTTP DLR API. For web application, DLR will be available onto MIS panel only For Http we need to integrate DLR API provided by bidder. For Manual System Automate MIS Available 14 Page 12 Point 19 The successful bidder shall provide the MIS reports for all the bulk SMS date wise in a prescribed format on a monthly/ between dates basis. Whenever required by ICSI, successful bidder should be able to provide additional reports in a prespecified format. Logs will be available at Vf API till 45 days, ICSI shall fetch the logs, logs will be available in the standard MIS format as mentioned below As per RFP 15 Page 12 Point 23: There should be facility to save a sent message automatically for a predefined time period, which the user should be able to forward., if it is scheduling then OK we need to schedule the message for future

4 16 Page 12 Point It is preferable to have both Unicode and 26: binary text messaging in the solution. Unicode is feasible however need to check whether binary facility is also available, to whom client will send the binary message This is required for the notification of the status of servers 17 Page 12 Point 27 Any SMS which is being sent could be logged into ICSI database with appropriate timestamp with details of messages sent and successful deliveries. The vendor should provide an interface for extraction of any kind of MIS reports based on the information logged. Client need to integrate VF DLR API to insert the delivery report in real time basis. MIS portal is available whereby client can fetch the logs. For Http we need to integrate DLR API provided by bidder. 18 Page 12 Point 28 The solution should be able to integrate so as to send messages generated from other application of ICSI. SMS API Integration would be handled by ICSI team, ValueFirst will help the client dev team and share the suggestions basis on VF API Integration doc This is Fine 19 Page 12 Point 29 The solution should be able to send scheduled alerts by fetching data from different databases to different category of recipients. Scheduled message should be sent to the selected groups manually through webapplication and for HTTP separate code is to be written. Sample code and req. documentation to be provided by the bidder

5 20 Page 12 Point VF shall share the separate accounts for Trans and 30 Promo use cases Depending upon the TRAI guidelines, the application should be able to classify the messages into promotional or transactional. Necessary changes in user interface or in MIS need to be done by vendor as per instructions by ICSI. Promotional / Transactional Messages will be identified by The ICSI. Ref. page no:15 of RFP 21 Page 12 Point 31 Successful Vendor should put in place a mechanism for regular intimation of deprovisioned/erroneous numbers which can then be eliminated from the list of recipients, thereby increasing the percentage of accurate deliveries VF shall share the logs of Absent Failure no's of every previous day campaign. List will be available in the panel 22 Page 12 Point 35 Event Based Triggered SMS: Automatic SMS based on certain trigger using APIs 23 general overall What will be the volume for overall project? 24 general overall Commercials need to define on the basis of submission or delivery of the sms? This is with ref. to HTTP/HTTPS based Application SMS Count - Average of 27 months: Commercials needs to define on the basis of successful delivery