Portal - Zamówienia Regionalnego Programu Operacyjnego Województwa Podkarpackiego

 

A.1. Cel dokumentu

                Celem dokumentu jest opis założeń związanych z wdrożeniem funkcjonalności systemu do wysyłania masowych wiadomości SMS, MMS i VMS dla klienta hurtowego i detalicznego.

Niniejszy dokument zawiera opis funkcjonalności zarówno od strony front-end oraz back-end. 

A.2. Responsive Web Design

Projekt musi być zgodny z aktualnymi trendami  w obszarze rozwiązań internetowych, dlatego też wymagamy wykorzystania technologii Responsive Web Design, co oznacza, że strona będzie elastyczna i skalowalna.

W zależności od wielkości ekranu urządzenia, na którym będzie przeglądany serwis, strona będzie wykorzystywać jego możliwości; zmieni się układ kolumn, nawigacja, linki, obrazki zostaną przeskalowane, zmieni się wielkość czcionek, dzięki czemu niezależnie od wielkości urządzenia, strona będzie wyświetlać się poprawnie, umożliwiając użytkownikom łatwe korzystanie z niej.

RWD zapewnia poprawne wyświetlanie strony zarówno na laptopach, komputerach stacjonarnych, a przede wszystkim w przeglądarkach telefonów komórkowych i tabletach, które zaczynają dominować przy pierwszym kontakcie klienta z firmą. Jest to również istotne ze względu na zmiany w algorytmie Panda 4.x jakie wprowadziła firma Google http://dzienwagencji.pl/google-promuje-strony-dostosowane-do-mobile/

Ze względu na poziom zaawansowania panelu administracyjnego i łatwość zarządzania kontem przez użytkowników dopuszczamy rozwiązanie polegające na wykorzystaniu technologii RWD w obszarze font-end’u dla klienta niezalogowanego, natomiast stawiamy na dowolność rozwiązania dla panelu dla klientów zalogowanych korzystających z platformy jak i panelu administracyjnego.

A.3. Prace projektowe

Projekt funkcjonalny ma zostać opracowany w metodologii projektowania zorientowanego na użytkownika: User-Centered Design. Projektowanie w oparciu o powyższą metodologię charakteryzuje się przede wszystkim uwzględnieniem rzeczywistych potrzeb użytkownika od samego początku opracowywania projektu. Pozwala to na zminimalizowanie kosztów wprowadzania poprawek w późniejszym czasie. Pomaga także zaoszczędzić czas oraz nakłady finansowe przeznaczane na tworzenie funkcjonalności, które w rzeczywistości nie są wykorzystywane przez użytkowników (a niekiedy samo ich istnienie utrudnia pracę z interfejsem).

Zastosowanie tej metodologii pozwala również zwiększyć satysfakcję jaką użytkownicy czerpią z korzystania z produktu już od samego początku jego funkcjonowania, co z kolei wpływa na kształtowanie się bardziej pozytywnych postaw wobec serwisu oraz zaufania do marki.

 

A.4. Jakość kodu

Podczas programowania w HTML muszą zostać zachowane standardy poprawnego kodowania W3C w celu uzyskiwania wyższych pozycji w google, w późniejszym procesie pozycjonowania. Szczególna uwaga zostanie zwrócona na generowane linki do podstron oraz użycie odpowiednich znaczników HTML do wybranych treści prezentowanych na stronie.

Kod interpretowany po stronie serwera powinien zostać zoptymalizowany na serwerze produkcyjnym w celu jak najszybszego ładowania strony co ma również przełożenie na osiągane wyniki w google.

A.5. Kultura realizacji projektu

Na każdym etapie realizowanych prac chcemy mieć dostęp do kolejnych elementów projektu oraz do kodu źródłowego.

Przewidujemy późniejszy rozwój oprogramowania w ramach własnych zasobów programistycznych, co za tym idzie do projektu musi zostać opracowana dokładna dokumentacja odnośnie kodu źródłowego.

Zasady jakie muszą zostać spełnione:

kod musi być na bieżąco aktualizowany w repozytorium SVN
repozytorium musi zostać zintegrowane z rozwiązaniem umożliwiającym automatyczną aktualizację (kompilację) kodu na serwerze testowym i produkcyjnym (Bamboo lub inny).

Rozwiązanie to ma ułatwić późniejszą aktualizację projektu i ewentualne przywrócenie poprzedniej działającej wersji w przypadku awarii.

kod nie może być obfuskowany/zaciemniony – ma być w pełni edytowalny
komunikacja z wykonawcą odbywać się będzie za pomocą systemu Jira lub innego podobnego

A.6. Płatności

Platforma musi być zintegrowana z systemem płatności online Blue Media lub Dotpay.

Przewidujemy rozliczenia z klientami w trybie PostPaid oraz PrePaid. Dla klientów dokonujących zapłaty w trybie PrePaid system automatycznie będzie przeliczać wpłacone pieniądze na ilość wiadomości możliwych do wysłania, które później użytkownik będzie mógł wykorzystać na wysłanie odpowiednich typów wiadomości SMS, MMS i VMS z określonym limitem. W przypadku PostPaid klient podpisze z nami stałą umowę wówczas nie ma konieczności realizacji płatności online ponieważ rozliczenie będzie dokonywane na podstawie automatycznie wygenerowanej przez platformę faktury zgodnie z ilością wysłanych wiadomości. 

A.7. Ruch SMS

Platforma będzie realizować ruch SMS poprzez dwa kanały. Pierwszym kanałem będą bramki sprzętowe SMS 2N® VoiceBlue Next. Dokumentację techniczną niezbędną do integracji urządzeń z platformą można znaleźć na stronie producenta:

https://www.2n.cz/en_GB/products/telecommunications/2n-voiceblue-next#tab-2

jak również można zwrócić się do nas z prośbą o jej udostępnienie. Projekt zakłada integrację z kilkudziesięcioma urządzeniami tego typu.

Drugim kanałem ruchu SMS będzie zewnętrzny system Mobitex Telecom. Dokumentację techniczną API niezbędną do integracji z platformą można znaleźć na stronie:

https://smscenter.pl/specyfikacja-techniczna.html

jak również można zwrócić się do nas z prośbą o jej udostępnienie.

A.8. Ruch MMS

Ruch wiadomości MMS będzie realizowany poprzez integrację z systemem zewnętrznym Tide Software Sp. z o.o.

https://www.tidemobile.pl/pomoc/mms-api

Dokumentację techniczną API niezbędną do integracji z platformą można uzyskać zwracając się do nas z prośbą o jej udostępnienie.

A.9. Ruch VMS

Ruch wiadomości głosowych będzie realizowany z poprzez urządzenia SMS 2N® VoiceBlue Next oraz usługę Text-to-Speech. Dokumentację techniczną niezbędną do integracji urządzeń z platformą można znaleźć na stronie producenta:

https://www.2n.cz/en_GB/products/telecommunications/2n-voiceblue-next#tab-2

jak również można zwrócić się do nas z prośbą o jej udostępnienie.

W kwestii usługi Text-to-Speech dopuszczamy skorzystanie z gotowych rozwiązań jednak preferujemy takie które nie będą wiązały się z koniecznością ponoszenia dodatkowych kosztów.

A.10. Subkonta bankowe

Dla klientów typu postpaid przewidujemy indywidualne numery kont bankowych dla wpłat należności za wystawioną fakturę. Do tego celu użyty zostanie mechanizm SIMP (System identyfikacji masowych płatności) banku ING Bank Śląski SA.

Dokumentację techniczną niezbędną do zaimplementowania funkcjonalności można uzyskać zwracając się do nas z prośbą o jej udostępnienie.

A.11. Przewidywane etapy prac
1) Przygotowanie projektu architektury informacji
 

W oparciu o cele biznesowe i marketingowe zostanie dokonana analiza potrzeb
i wymagań użytkowników serwisu. Analiza serwisu będzie stanowiła punkt wyjścia do stworzenia architektury informacji oraz nawigacji po serwisie, panelu dla klienta zalogowane i panelu administratora.

Architektura informacji  w postaci drzewa nawigacji będzie odzwierciedlała pełną strukturę projektu oraz wszystkie ścieżki użycia realizowane przez użytkowników i administratora.

2) Przygotowanie makiet serwisu
 

W drugim etapie prac na podstawie koncepcji i architektury informacji powstaną makiety dla każdej podstrony serwisu. Każda makieta jest rysunkiem podstrony serwisu zawierającym wszystkie elementy graficzne, tekstowe oraz elementy interakcji. Makiety zawierają także opis funkcjonalny, określający rodzaje elementów, ich funkcje oraz możliwości interakcji.

3) Przygotowanie projektu graficznego

 

Na przygotowane makiety zaimplementowana zostanie grafika strony głównej oraz podstron serwisu wraz z opracowaniem styli.

Projekt graficzny systemu CMS, tj. panelu dla użytkowników zalogowanych oraz panelu administracyjnego będzie korespondował z szatą graficzną przewidzianą dla front’end’u.

4) Prace programistyczne

 

Na prace programistyczne składać się będą:
4.1. Analiza wymagań.

4.2. Projektowanie architektury systemu:
              4.2.1. Opis funkcjonalności.

4.3. Wybór technologii.

4.4. Panel administracyjny:
               4.4.1. Opracowanie układu funkcjonalnego/graficznego zgodnie z projektem  funkcjonalnym front-end’u.
               4.4.2. Dokładny opis wszystkich modułów i ich rozkładu oraz zależności między sobą.
               4.4.3. Przygotowanie diagramu relacji do ukazania logicznych powiązań i diagramu sekwencji do przedstawienia logiki działania.
               4.4.4. Analiza „usability” systemu.
               4.4.5. Opracowanie projektu bazy danych zgodnie z założeniami systemu.
4.5. Kodowanie front-end’u i spięcie z panelem administracyjnym CMS:
            4.5.1. Opracowanie ikonek, przycisków, układów list i komunikatów.
            4.5.2. Pocięcie elementów graficznych do css (metoda css sprites) i xhtml.
            4.5.3. Przygotowanie architektury systemu (lista klas i układ zależności modułów).
            4.5.4. Wdrożenie modelu MVC (model view controller) i integracja z wybraną architekturą.
            4.5.5. Przygotowanie procedur składowych do zapytań z bazy danych.
            4.5.6. Implementacja modułów ze specyfikacją.

4.6. Zaimplementowanie mechanizmów wydajnościowych:
            4.6.1. Cache’owanie zapytań z baz danych - optymalizacja w celu obsłużenia dużego ruchu na stronie
            4.6.2. Zaimplementowanie obfuskatora (zaciemnianie kodu) - optymalizacja ładowania strony.
            4.6.3. Pakowanie zasobów css i js metodaą gzip (kod zwracany do przeglądarki jest lżejszy średnio o 80%) - optymalizacja ładowania strony.
            4.6.4. Cache’owanie w całości wybranych stron przez, które użytkownicy będą trafiać do serwisu najczęściej i będą najczęściej odwiedzane: strona główna oraz główne podstrony z menu.

4.7. Testowanie poszczególnych funkcjonalności w serwisie z uwzględnieniem rożnych przeglądarek internetowych i urządzeń.

5) Bezpieczeństwo
            Serwis internetowy oraz system CMS zostaną wyposażone w następujące mechanizmy wzmacniające bezpieczeństwo korzystania:

5.1. Zabezpieczenie serwisów i CMS przed atakami typu SQL injection.

5.2. Zabezpieczenie serwisów i CMS przed atakami typu cross site scripting (XSS).

5.3. Przesyłanie formularzy za pomocą metody POST (nie GET).

5.4. Logowanie użytkowników za pośrednictwem protokołu HTTPS (SSL).

5.5. Odporność na włamania z wykorzystaniem spreparowanych plików COOKIES.

5.6. Odpowiedniej długości czas wygasania sesji użytkownika w CMS.

III. Projekt rozwiązania

Wybór nazwy dla serwisu w oparciu o dostępność domeny pod którą zostanie uruchomiony projekt.
Opracowanie logotypu i dobór palety kolorów w obszarze których będzie realizowany projekt graficzny.
 

A.      Front-end – strona projektu

Ogólna struktura serwisu:

1. Strona główna
2. O nas
3. Aktualności
4. Usługi
   1. Wysyłka SMS
   2. Kampanie SMS
   3. Odbiór SMS i MMS
   4. Numery Short Code
   5. Wysyłka MMS
   6. Sprawdzanie numerów w HLR
5. API
   1. Funkcjonalności
   2. Dokumentacja
6. Cennik
7. Kontakt
8. Rejestracja

W ramach realizacji strony wykonawca musi opracować treści oraz w ramach uruchomienia platformy dokonać pierwszego wprowadzenia w systemie CMS zgodnie z powyższą mapą serwisu. Do każdej jednej podstrony panel musi umożliwiać wprowadzanie treści tekstowych, graficznych oraz załączników (głównie pliki pdf). 

Przewidujemy możliwość pominięcia obsługi ze strony panelu CMS niektórych podstron, które okażą się bardzo niestandardowe graficznie po wcześniejszej konsultacji. 

Ad. a) Strona główna

Celem strony głównej jest zachęcenia użytkownika do pozostania na stronie oraz przetestowania usług serwisu i zapoznania się z jego ofertą. Chcemy, aby przede wszystkim postawić na powierzchnię banerową z wykorzystaniem RevolutionSlider za pomocą którego, będziemy użytkownikowi pokazywać korzyści wynikające z potencjału jaki tkwi w sms marketingu oraz jak może łatwo wykorzystać to narzędzie do uzyskania pozytywnych efektów w swoim biznesie. Należy przygotować 5 dynamicznych banerów i opracować odpowiednie teksty na zasadzie problem -> rozwiązanie -> korzyści.

Chcemy, aby dwa przyciski się wyróżniały przede wszystkim do ,,Rejestracji” oraz „Wyślij wiadomość testową”. Po kliknięciu w drugi link użytkownik ma mieć możliwość wprowadzenia swojego numeru telefonu i wysłania wiadomości w trybie PRO, ECO oraz wysłania wiadomości graficznej i głosowej.

  Na stronie głównej powinny znaleźć się sekcje z informacjami liczbowymi w stylu 10 lat na rynku, 5mln sms na godzinę, itp. Przesuwalna liczba logotypów z firmami, które korzystają z naszej usługi.

Sekcja z najbardziej istotnymi informacjami ze strony marketingowej co powinno uwiarygodnić serwis oraz wpłynąć na podjęcie działań celem założenia konta – stawiamy na kreatywność projektanta ze strony wykonawcy.

Na stronie głównej mają się znaleźć ikony prowadzące do serwisów społecznościowych, tj.:

1. Facebook
2. Google+
3. Twitter
4. Youtube

Ad. b) O nas

Chcemy mieć możliwość tworzenia podstron w tym obszarze w postaci kolejnych zakładek rozwijanych w menu. W miarę rozwoju i życia projektu pojawią się tutaj takie podstrony jak ,,Media o nas”, ,,Nagrody i wyróżnienia” natomiast w pierwszej odsłonie trzeba zaprojektować stronę z opisem firmy oraz „Gwarancja jakości i bezpieczeństwa”.

Ad. c) Aktualności

                Tradycyjny moduł z aktualnościami. W panelu administracyjnym powinna być możliwość wprowadzania kolejnych notek z uwzględnieniem następujących pól:

1. Aktywność
2. Data
3. Data publikacji + godzina
4. Tytuł
5. Opis krótki (zajawka)
6. Zdjęcie

Ad. d) Usługi

                Poza stroną główną najważniejszy element serwisu. Usługi mają zostać podzielone na podstrony:

1. Wysyłka SMS – po co? Dlaczego? Jakie korzyści?
2. Kampanie SMS – skupienie się na pokazaniu obszaru zastosowań dla poszczególnych branż
3. Odbiór SMS i MMS – skupienie się na możliwości prowadzenia dialogu z klientem
4. Numery Short Code – konkursy, loterie, ankiety
5. Wysyłka MMS – obraz potrafi zastąpić tysiąc słów – budowa wizerunku marki
6. Sprawdzanie numerów w HLR – informacje o przynależności numeru dodanego operatora, korzyści wynikające z posiadania takich informacji.

Głównym celem podstron w ramach Usług jest pokazanie szerokiego wachlarza zastosowań dla naszych usług. Biorąc pod uwagę bardzo szeroką grupę docelową i branże w ramach, których sms’y mogą być stosowane należy podejść marketingowo do treści prezentowanych poprzez studium przypadków i wskazywania mnogości rozwiązań, które potencjalny klient może dopasować do siebie.

Te strony rzadko będą się zmieniać więc tutaj możemy pominąć pełną obsługę ze strony panelu administracyjnego.

Ad. e) API

                Użytkownik na stronie musi znaleźć pełną dokumentację odnośnie możliwości jakie daje API w celu integracji z zewnętrznymi systemami informatycznymi.

                Dokładny opis funkcjonalności jakie przewidujemy w API zostanie opisane w dalszej części dokumentacji przy rozpisywaniu funkcjonalności panelu administracyjnego. Ważne, żeby w ramach dokumentacji były zamieszczone przykładowe fragmenty kodu dla języków programowania:

1. PHP
2. C#
3. JAVA

oraz gotowe biblioteki do pobrania w celu późniejszej implementacji w zewnętrznych systemach.

Ad. f) Cennik

                Musimy mieć możliwość ustalenia cen na zasadzie pakietów sms. Wartości te powinny mieć odzwierciedlenie w konfiguracji systemu CMS w module do rozliczeń. Zmiana wartości w panelu administracyjnym powinna dokonać zmian na stronie z cennikiem jak również odpowiednio generować faktury dla klientów. 

Ad. g) Kontakt

Na stronie kontaktowej znajdą się dane kontaktowe do firmy oraz formularz do przesyłania zapytań z polami:

1. Imię i nazwisko
2. Numer telefonu
3. Adres e-mail
4. Treść wiadomości

Wszystkie wiadomości wysłane przez formularz mają zostać wysłane na wskazany adres e-mail.

Ad. h) Rejestracja

W procesie rejestracji użytkownik musi podać następujące dane:

1. E-mail
2. Hasło
3. Imię i nazwisko
4. Nr telefonu
5. Kod promocyjny – X darmowych sms na start...
6. Numer osoby polecającej – program lojalnościowy

Po wypełnieniu formularza do rejestracji na adres e-mail przychodzi wiadomość z potwierdzeniem natomiast na numer telefonu zostanie wysłany kod, który ma zostać użyty przy pierwszym logowaniu do systemu – numer telefonu i e-mail muszą być powiązane z klientem. Wszystkie dodatkowe dane odnośnie nazwy firmy, umów, systemu rozliczeń zostaną wprowadzone już w późniejszym etapie co zostanie opisane w „Back-end – klient zalogowany”.

A.      Back-end – klient zalogowany

Logowanie do panelu administracyjnego powinno odbywać się po protokole szyfrującym ssl. Po zalogowaniu użytkownik może w pełni zarządzać wysyłaniem kampanii SMS/MMS/VMS zgodnie ze swoim pakietem i umowami oraz uzupełnić dodatkowe dane odnośnie prowadzonej przez siebie działalności. 

W momencie rejestracji każdemu klientowi musi zostać nadany unikatowy identyfikator, który będzie wykorzystywany w programie lojalnościowym. Numer klienta nie może odzwierciedlać realnej liczby klientów (id z bazy, autoincrement od 1 do n), ma to być losowy numer w stylu xp23434 – za pomocą tego identyfikatora będzie prowadzona komunikacja z klientem, reklamacje, kontakt telefoniczny – konkurencja nie może realnie wiedzieć na jaki etapie rozwoju jesteśmy.

1)     Dokonaj płatność

W tym module klient ma mieć możliwość dokonania płatności przy użyciu przelewu online, karty płatniczej lub za pomocą przelewu bankowego – opcja PrePaid. Po dokonaniu płatności system przeliczy wpłaconą kwotę na ilość możliwych do wysłania wiadomości SMS/MMS/VMS zgodnie z cennikiem.  Cennik musi być ruchomy w zależności od kwoty wpłaconej przez klienta, im wyższa kwota tym niższe ceny za SMS.

Dla klientów z którymi będą zawarte umowy PostPaid ta funkcjonalność zostaje wyłączona. Ważne, żeby mieć możliwość w każdej chwili przełączyć klienta z trybu PostPaid na PrePaid i odwrotnie.

W tym miejscu musi wyświetlać się dokładny cennik z opcjami.

2)     Faktury i płatności

W przypadku opcji PrePaid klient w tym miejscu ma możliwość pobrania faktury zgodnie z przelaną kwotą dla płatności online.

Dla klientów z opcją PostPaid system automatycznie po północy ostatniego dnia miesiąca ma wyliczyć oraz wystawić fakturę zgodnie z ilością wysłanych wiadomości i cennika. Dla ułatwienia przyjmujemy, że jeśli cennik zmienił się w połowie miesiąca to pomijamy rozliczenia dla klientów, którzy od 1 dnia do daty zmiany byli w innym przedziale cenowym.

W dowolnym momencie gdy zostanie wystawiona faktura ma zostać automatycznie wysłana na adres e-mail klienta.

3)     Dane klienta

W tym module klient ma mieć możliwość wprowadzenia takich danych jak:

1. Nazwa firmy
2. Nip
3. Adres
4. Kod pocztowy
5. Miasto
6. Numer telefonu

 

4)     Status konta

W module tym mają się znaleźć szczegółowe informacje na temat możliwych ilości wiadomości do wysłania zgodnie z aktualnym cennikiem oraz lista kuponów rabatowych wykorzystanych przez klienta.

5)     Wprowadź kupon rabatowy

W module tym klient musi mieć możliwość wprowadzenia kuponu rabatowego, który uzyska, np. w ramach przeprowadzanych kampanii marketingowych. Może to być cały czas widoczny mały formularz lub otwierany pop-up.

6)     Program lojalnościowy / poleć nasz serwis

Klient ma mieć możliwość wpisania adresów e-mail osób, którym chce polecić serwis. Platforma automatycznie wyśle wiadomość na wskazane przez klienta adresy e-mail o treści polecającej usługę wraz z kodem polecającym. W sytuacji gdy osoba polecana użyje do rejestracji adresu e-mail oraz użyje kodu polecającego i dokona płatności wówczas do polecającego zostanie wysłana wiadomość e-mail z wygenerowanym kuponem rabatowym na dodatkowe wiadomości SMS/MMS/VMS.

7)     Wiadomości SMS/MMS/VMS

Sekcja ta ma mieć możliwość wysyłania wiadomości zgodnie z podziałem na typy:

1. SMS
2. MMS
3. VMS

W ramach konfiguracji wiadomości do wysyłki należy przewidzieć następujące opcje:

1. SMS/MMS ECO i PRO (ECO to losowy 9 znakowy numer nadawcy a PRO to zdefiniowane pole nadawcy składające się z maksymalnie 11 znaków alfanumerycznych) oraz wiadomości ECO 2-way (możliwość odczytu wiadomości odebranych).
2. SMS zaszyfrowany (odczyt wiadomości przez odbiorcę możliwy tylko poprzez aplikację mobilną)
3. Dla wiadomości MMS dodanie pliku graficznego, dźwiękowego, video, zgodnie ze standardami GSM
4. Dla wiadomości VMS dodanie komunikatu do odczytu przez mechanizm Text-to-Speech lub dodanie gotowego pliku audio do odtworzenia.
5. Definiowanie pola nadawcy
6. Odczyt wiadomości odebranych
7. Lista odbiorców
   1. Możliwość wybrania wcześniej zdefiniowanej grupy
   2. Możliwość wprowadzenia numerów oddzielonych przecinkiem lub spacją (system musi automatycznie walidować poprawność każdego jednego numeru opcja z +48, 48, ..)
8. Treść wiadomości z możliwością zastąpienia wybranych znaczników odpowiednimi wartościami w celu personalizacji SMS, dodatkowe pola muszą być możliwe do dodania na etapie importu bazy lub ręcznego wprowadzenia
9. Możliwość wysłania spersonalizowanych wiadomości wcześniej przygotowanych i obrobionych na zasadzie, np. „+48727999909”,”Witaj Kasiu, przesylam...”, ,,+48788222333”,”Witaj Bartku...”
10. Czasowe ograniczenia wysyłki w określonych godzinach
11. Zdefiniowanie innej daty wysyłki
12. Zastąpienia znaków specjalnych (ę,ą,ł na e,a,l)
13. Możliwość zastosowania „wołacza” dla imion zgodnie z pulą imion dostępnych w bazie http://www.bazy.hoga.pl/baza_imion.asp
14. System automatycznie powinien informować o wykrytych nieprawidłowych numerach zaimportowanych lub wprowadzonych przez użytkownika
15. Powinna być możliwość tworzenia wiadomości roboczych

 

B.      Panel administratora (system CMS)

Logowanie do panelu administracyjnego CMS ma się odbywać po protokole szyfrowanym ssl. Wszystkie logowania do systemu mają być zapisywane w logach. Chcemy, aby w logach były zapisywanie wszystkie zdarzenia dotyczące logowania jakie będą miały miejsce w trakcie obsługi panelu.

1)     Zarządzanie kontami użytkowników

System ma umożliwiać ręczne dodawanie kont przez administratora systemu jak również modyfikacje danych, które zostały wprowadzone na etapie rejestracji przez użytkowników platformy oraz dodatkowe  pola widoczne tylko w systemie CMS, tj.:

- data założenia konta
                - data ostatniego logowania wraz z adresem IP
                - historia płatności klienta oraz rodzaj posiadanego konta PREPAID/POSTAPID – historia zmian

Administrator ma mieć możliwość zablokowania wybranego konta poprzez włączenie i wyłączenie aktywności.

Administrator ma mieć możliwość nadania nowego hasła dla konta.

Lista użytkowników musi posiadać filtry umożliwiające wyświetlanie klientów zgodnie z poniższymi założeniami:
                - filtrowanie po dacie rejestracji

- filtrowanie po nazwie i loginie
                - filtrowanie użytkowników po typie (prepaid/postaid)

- filtrowanie po statusie konta (aktywny/nieaktywny)

2)     Cenniki

Platforma musi umożliwić definiowanie cenników postpaid i prepaid. Dla nowych klientów rejestrujących się w usłudze platforma automatycznie przypisuje domyślny cennik. Administrator ma jednak możliwość utworzenia cennika indywidualnego dla każdego klienta. Zakres przedziałów ilości wysyłanych wiadomości będzie niezmienny, np.

Ilość SMS w miesiącu

1 - 10 000

10 001 - 25 000

25 001 - 50 000

 

3)     Faktury i płatności

System ma umożliwiać podgląd wszystkich płatności jakie zostały zrealizowane
w ramach platformy oraz automatycznie wystawiać faktury dla klientów z umowami POSTAPID – przyjmujemy, że dla tych kont wystawianie faktur ma następować w ostatni dzień danego miesiąca. Faktury mają automatycznie być wysyłane na adres e-mail podany przy rejestracji konta.

Dla płatności zrealizowanych przez system płatności online system automatycznie wystawia faktury w momencie pomyślnego zakończenia procesu płacenia.

Dla klientów typu postpaid chcemy aby platforma przypisywała indywidualne numery kont bankowych w celu łatwiejszego rozliczania i identyfikacji płatności. Platforma musi umożliwiać import listy transakcji bankowych w postaci pliku i musi poprawnie go zinterpretować, tj. rozpoznać numer subkonta, kwotę wpłaty oraz numer faktury i oznaczyć w systemie status płatności za wystawioną wcześniej fakturę.

Dla faktur przeterminowanych system ma automatycznie wysyłać powiadomienia SMS:

- w dniu w którym mija termin zapłaty
                - 7 dni po terminie zapłaty
                - 14 dni po terminie zapłaty
                Treści smsów zostaną zdefiniowane na etapie przygotowywania tekstów przez copywriter’ów.

System ma umożliwiać zebranie wszystkich wygenerowanych faktur w poprzednim miesiącu i pobranie ich w formie archiwum ZIP.

4)     Mailing

System musi posiadać moduł do rozsyłania wiadomości poprzez listę mailingową, przewidujemy możliwość integracji platformy z gotowymi platformami poprzez API, np. mailchimp. Integracja dotyczyłaby przekazywania adresu e-mail użytkownika i jego danych identyfikacyjnych.

5)     Raporty SMS

Moduł ten ma umożliwiać administratorowi podgląd pracy systemu odnośnie kolejek SMS do wysłania, raportować o błędach jakie wystąpiły na etapie wysyłania wiadomości, co jest najważniejsze w przypadku błędów wynikających z komunikacją z operatorem ma mieć możliwość ponowienia wysyłki. Ma również zliczać aktualną liczbę SMS do wysłania.

6)     Zarządzanie black listami

                Administrator ma mieć możliwość wprowadzenia numerów telefonów na które nie będzie możliwości wysyłania wiadomości.

7)     Moduł reseller

                W panelu administracyjnym musi być możliwość włączenia dla wybranego konta (lub tworzenia konta typu reseller) opcji programu lojalnościowego dla sprzedawców/resellerów.

Konto tego typu będzie służyć rozszerzeniu możliwości pozyskiwania nowych klientów poprzez sprzedawców działających na terenie całego kraju. Powinno umożliwić definiowanie poprzez resellera indywidualnego cennika wszystkich usług dla jego klientów ale stawki nie mogą być niższe niż te z cennika podstawowego/głównego. Konto resellera musi uwzględniać również stronę internetową (front-end - strona projektu) z inną szatą graficzną, różniącą się od podstawowej, działającą na innej nazwie domenowej. Strona internetowa dla konta typu reseller powinna być oparta o szablon, taki sam dla wszystkich kont tego typu. Musi być możliwość dostosowania wyglądu strony internetowej resellera w zakresie zmiany logotypu, konfiguracji nazwy domeny i kolorystyki. Konto typu reseller będzie umożliwiało sprzedawcy utworzenie konta typu post-paid. Rozliczenie i fakturowanie klientów resellera będzie odbywało się automatycznie a na fakturze jako sprzedawca będą widoczne dane resellera. Rozliczenie resellera z nami będzie odbywało się automatycznie na podstawie ruchu wygenerowanego w poszczególnych usługach w danym miesiącu na podstawie cennika obowiązującego dla resellera.

8)     Wiadomości odebrane

System musi umożliwić odbiór wiadomości SMS z urządzeń 2N® VoiceBlue Next i odpowiednio zinterpretować i przypisać do danego klienta, który realizował wysyłkę typu 2-way.

9)     Kupony rabatowe

Platforma musi posiadać mechanizm generowania i interpretacji kuponów rabatowych. Generator kuponów powinien umożliwiać zdefiniowanie nazwy pakietu kuponów, liczby darmowych SMS ECO i PRO przyznawanych w ramach użycia kuponu, zakres dat w których kupony będą aktywne, liczbę kuponów wygenerowanych w ramach pakietu. Każdy wygenerowany kupon jest jednorazowy i po użyciu staje się nieaktywny.

10) Baza imion

System musi umożliwić dodawanie bazy imion które będą wykorzystywane do realizacji wysyłek personalizowanych SMS. Baza musi zawierać imię w mianowniku oraz wołaczu. Aktualizacja bazy będzie możliwa poprzez dodanie piku przez panel administratora w postaci csv lub xlsx, xls.

11)  Router SMS

Moduł umożliwiający zarządzanie ruchem SMS. Funkcjonalność musi zapewnić możliwość włączania/wyłączania bramek 2N® VoiceBlue Next, włączanie/wyłączanie kanału Mobitex Telecom dla ruchu SMS ECO i SMS ECO 2-way, sprawdzanie poprawności połączenia kanałów i urządzeń 2N w postaci kontrolki statusu.

12) Baza HLR

                System ma mieć możliwość definiowania zakresów numeracji (prefiksów) dla sieci GSM i przypisywaniem ich do właściwego operatora GSM zgodnie z informacjami zawartymi na stronie UKE:

https://bip.uke.gov.pl/numeracja/wykazy-i-tablice-numeracji,1.html

Platforma realizując wysyłkę wiadomości SMS/MMS/VMS musi zapisywać w bazie właściwą nazwę operatora GSM do którego aktualnie należy numer odbiorczy wiadomości.

Numery przeniesione również muszą być właściwie przypisane do aktualnego operatora. Zapewniamy dostarczanie listy numerów przeniesionych w postaci pliku csv aktualizowanego raz dziennie na serwerze FTP.

 

C.      API

                Moduł ten ma umożliwiać wszystkim klientom integracje z dowolnymi systemami informatycznymi poprzez gotowy kanał komunikacji. Cała komunikacja ma się odbywać po protokole szyfrującym SSL.

                Funkcje dostępne w API mają umożliwiać:

1)     Filtrowanie adresu IP

W panelu administracyjnym użytkownik zalogowany ma mieć możliwość zdefiniowania listy adresów IP z których może następować wysyłanie wiadomości SMS. Musi być również możliwość ustawienia zakresu adresów przy wykorzystaniu przedziału od... do lub przy zastosowanie n.n.n.*

2)     Wysyłanie pojedyńczych SMS’ów

 Wysyłanie wiadomości SMS ma się odbywać poprzez wywołanie odpowiedniego adresu strony: https://..../smsdo

Lista parametrów jakie muszą być obsługiwane:
- username – nazwa użytkownika
- password – zakodowane hasło
- to – odbiorca
- message – treść wiadomości
- from – możliwość wyboru typu SMS: ECO, PRO, 2WAY)
- encoding – typ kodowania znaków
- date – termin wysłania wiadomości

Należy przewidzieć dodatkowe parametry zgodnie z opisaną funkcjonalnością, powyższe parametry określają schemat podejścia.

3)     Wysyłanie SMS-a o zaplanowanej godzinie/dacie

API ma umożliwiać wysyłanie wiadomości o określonej dacie/godzinie, aż do wysłania ostatniej wiadomości lub wysyłać w określonym przedziale czasowym. Jeśli nie uda się wysłać w określonym przedziale czasowym, a zakres dat jest większy niczym 1 doba to ma nastąpić ponowne wysyłanie wiadomości z godziną początkowa dnia kolejnego.

4)     Wysyłanie masowe SMS’ów

API ma umożliwiać wysyłanie masowe do grupy odbiorców na zasadzie przekazania numerów w parametrze „to” jak również przy wykorzystaniu grup zdefiniowanych przez użytkownik w panelu do zarządzania kontem.

5)     Wysyłanie spersonalizowanych SMS’ów

API ma mieć możliwość definiowania tag’ów, które będą podmieniane na etapie wysyłania SMS’ów za konkretne dane. Np. użycie w treści SMS [wolacz] ma zmienić  imię na formę –Marek/Marku. 

6)     Wysyłanie wiadomości z wykorzystanie szablonu

Użytkownik ma mieć możliwość wysłana wiadomości używając id szablonu zdefiniowanego w panelu użytkownika.

7)     Wysyłanie SMS za pomocą e-mail

Musi zostać utworzony adres e-mail na który użytkownicy będą mogli wysłać wiadomość e-mail na podstawie, którego zostanie przesłany SMS na wybrany numer telefonu.

1. Wysyłanie wiadomości MMS i VMS

API ma umożliwiać wysyłanie wiadomości z graficznych i głosowych.

D.     SMS szyfrowany i aplikacja mobilna

Platforma musi zapewnić możliwość wysyłania widomości SMS w postaci zaszyfrowanej. Odczyt wiadomości przez odbiorcę możliwy będzie tylko poprzez użycie aplikacji mobilnej, która będzie posiadać mechanizm deszyfrowania wiadomości.

Musi zatem powstać aplikacja mobilna dla platform Google Android w wersji 4.0 lub nowszej, Apple iOS w wersji 10.0 lub nowszej, Windows 10 Mobile. Aplikacje będą dostępne nieodpłatnie, za pośrednictwem mechanizmów dystrybucji charakterystycznych dla danej platformy: Google Play dla Android, Apple App Store dla iOS, Sklep Windows dla Windows. Za umieszczenie aplikacji w sklepach w naszym imieniu odpowiada wykonawca.

 

Dodatkowe warunki

System powinien zostać wykonany w technologii JAVA gwarantującej stabilność i bezpieczeństwo przechowywanych informacji. Technologia powinna pozwalać na łatwe modyfikowanie i rozbudowę rozwiązania w przyszłości.