4.2.5 Preverjanje pravilnosti vpisanih podatkov
Ker kljub navodilom uporabniki lahko vpisujejo kakšne nepravilne podatke moramo pred vpisom v tabele narediti preverbo vpisanih podatkov. V aplikaciji se ob kliku na gumb »Pošlji SMS« najprej naredi preverba teh podatkov. Naredimo preverbo, da je dolžina številke MSISDN, na katerega se pošlje sporočilo res 11 znakov, ter da se začne s 386. V kolikor se dolžina številke MSISDN ne ujema, ali se začne drugače kot s 386 aplikacija javi (kot je prikazano na sliki 15), da je podatek nepravilen, ter niti ne poskusi s pošiljanjem sporočila SMS.
27 Slika 15: Opozorilo, da številka ni prave dolžine oziroma se ne začne s 386 [(vir slike: lastni)]
Preverja pa se tudi, da številka na katero pošiljamo sporočilo SMS ni fiksna številka, saj le - te, ne morejo prejeti sporočila SMS. To preverbo naredimo s klicem že obstoječe funkcije na podatkovno bazo, ki preverja ali se gre za fiksno ali mobilno številko. Funkcija preverja ali se gre za fiksno ali mobilno številko na podlagi tega, pri katerem operaterju se nahaja številka. Ta podatek pa pridobimo iz baze za prenos številk med operaterji (NP – number portability), saj je v sistemu CRM izveden tudi prenos številk med operaterji. V kolikor se nahaja številka pri fiksnem operaterju in ne mobilnem dobimo opozorilo, kot je prikazano na sliki 16.
Slika 16: Opozorilo da številka ni v pravem formatu [(vir slike: lastni)]
Naredili smo tudi preverbo po dolžini zapisa v polju, kjer se nahaja vsebina za pošiljanje sporočila. Če je vsebina dolžine 0, pomeni, da je polje prazno in sporočilo najverjetneje ni bilo mišljeno za pošiljanje, zato se izpiše obvestilo kot je prikazano na sliki 17.
Slika 17: Opozorilo »prazen tekst« [(vir slike: lastni)]
V primeru, da smo za zapis v zgodovino izbrali podatek »line_username« ali pa davčna številka, in je le - ta na formi prazen se nam izpiše obvestilo, kot je prikazano na sliki 18.
Slika 18: Opozorilo, da manjka podatek oziroma ni pravilen [(vir slike: lastni)]
Če pa so vsi ti podatki pravilni, pa aplikacija sporoči, da je bilo sporočilo SMS uspešno poslano, ter se naredi zapis v zgodovino stranke, kar je razvidno iz slike 19.
Slika 19: Obvestilo da je bilo sporočilo SMS uspešno poslano stranki, ter narejen zapis v zgodovino stranke [(vir slike: lastni)]
4.2.6 Zapis v zgodovino stranke
V sistemu CRM se ob tem, ko odpremo stranko avtomatsko pokaže tudi zgodovina stranke za zadnje tri mesece. Če želimo videti večje časovno obdobje le - to lahko prikažemo tako, da izberemo večje časovno obdobje. Krajše avtomatsko trimesečno obdobje se sicer prikaže zaradi manjšega obremenjevanja podatkovne baze. Prikaz zgodovine stranke je namenjen, da se vidi kaj točno je stranka delala v preteklosti. Tu se beležijo vse morebitne spremembe ali vklopi raznih opcij na stranki, ki jih stranka naredi sama preko portala, preko SMS sprememb, ali pa agentje te spremembe opravijo v sistemu CRM na podlagi zahteve stranke. Beležijo se tudi morebitne nove vezave, klici v klicni center, odprte tehnične pritožbe stranke, obvestila o novih ponudbah ter obvestila o spremembi pogojev. Večino zapisov se dodaja avtomatsko ob spremembi, vpis pa je možen tudi ročno s strani agenta. Uporabniki sistema CRM imajo tako celoten vpogled nad zgodovino stranke. Prikaz teh podatkov je pomemben predvsem v primeru reševanja reklamacij s strani strank, ali pa na primer pri preprečitve podvajanja dela.
Zapis v zgodovino se lahko naredi na več nivojih:
Na nivoju naročnika,
številke MSISDN,
29
uporabniškega imena ter,
na nivoju davčne številke.
V kolikor se naredi zapis na nivoju davčne številke, se le - to vidi v zgodovini vseh strank (številk MSISDN), ki imajo zabeleženo to davčno številko. V kolikor se naredi na nivoju naročnika, se zgodovina pokaže samo pri tej konkretni stranki. V to zgodovino naredi zapis (prikazan na sliki 20) tudi naša aplikacija za pošiljanje sporočila SMS. V aplikaciji nam tudi ponudi izbiro na kateri nivo se bo dodajal zapis, torej na nivo naročnika ali pa davčne številke.
Privzeto se v zgodovino stranke naredi zapis, da je bilo stranki poslano sporočilo SMS, ter njegova vsebina. Lahko pa namesto vsebine sporočila zapišemo tudi kak drug poljuben tekst.
V aplikaciji imamo namreč možnost vpisa v zgodovino poleg teksta za sms tudi poljuben tekst.
V aplikaciji se nato v primeru, da je tekst za zgodovino prazen, naredi zapis v podatkovno bazo z vsebino sporočila SMS, v nasprotnem primeru pa se naredi zapis z obema podatkoma. V zgodovino se vpišejo tudi podatki o času vpisa v zgodovino, o uporabniku, ki je delal zapis, ter podatek o naročniku, in nivo vpisa, ki pove ali se gre za vpis na davčno ali naročnika. Vpiše pa se tudi podatek, za kateri tip zapisa se gre v zgodovini. Zapis naredimo pod tipom »SMS Obvestilo«.
Slika 20: Izgled zapisa v zgodovini stranke v sistemu CRM [(vir slike: lastni)]
4.2.7 Postopek pošiljanja sporočila SMS
Ker imamo v sistemu CRM že podprta nekatera avtomatska pošiljanja sporočil SMS obstoječe funkcionalnosti izkoristimo tudi sami. Za potrebe pošiljanja sporočil moramo narediti vpis v obstoječo tabelo z imenom »SMS_LIST«. V tabelo in v polje »text« zapišemo podatke o vsebini sporočila, številko MSISDN stranke v polje »MSISDN«, podatek o času kreacije zapisa v tabelo naredimo v polje »REQ_DATE, vpišemo pa podatek »sysdate«, ki pomeni, da se vpiše trenuten čas in datum. V polje »STATE« zapišemo status sporočila, v našem primeru
1, kar pomeni da sporočilo SMS še ni bilo poslano. Podatek o tem kateri uporabnik je poslal sporočilo stranki se zapiše v polje »USERNAME«, kako pa se aplikacija kot pošiljatelj predstavi stranki, pa zapišemo v polje »FROM_ADDR«. V našem primeru se pošlje sporočilo SMS stranki z naslova »A1.si«. Podatek, kdo je pošiljatelj namreč ni nujno številka MSISDN, lahko se uporabijo tudi t.i. kratke številke ali pa krajše besedilo.
Aplikacija ob pritisku na gumb »Pošlji SMS« naredi zapis v to tabelo na podatkovni bazi.
Slika 21 prikazuje primer zapisa podatkov v bazo.
Slika 21: Ukaz za vpis podatkov v tabelo »SMS_LIST« [(vir slike: lastni)]
V tej tabeli nato zapis prebere procedura z imenom »PosljiSMS«, ki s HTTP zahtevo tudi izvede pošiljanje sporočila SMS. Procedura se izvaja vsaki 2 minuti, poganja pa jo »job« oz.
avtomatsko opravilo, ki je nastavljeno, da zažene proceduro na določen čas. V našem primeru na dve minuti, kar je narejeno z ukazom SYSDATE+2/1440. SYSDATE je trenutni čas, kateremu prištejemo dve minuti tako, da delimo 2 z številom minut v dnevu kar je 1440. Job se naredi s spodnjo komando, kar prikazuje slika 22.
Slika 22: Ukaz s katerim naredimo avtomatsko opravilo [(vir slike: lastni)]
Pošiljanje oziroma kreacijo HTTP komande naredi procedura, ki smo jo poimenovali
»PosljiSMS«. Procedura s pomočjo SELECT stavka iz tabele SMS_LIST prebere vse zapise, ki imajo v polju STATE zapis 1. Status 1 v našem primeru pomeni, da sporočilo SMS še ni bil poslan. Pošiljanje na SMS center se opravi s HTTP klicem na Web Service. V kolikor je odgovor »OK« se postavi procedura z »UPDATE« stavkom, zapis v naši tabeli v status 2, ki pomeni da je bilo sporočilo SMS uspešno poslano, v kolikor pa je odgovor drugačen od »OK«
pa se postavi status na 3, kar pomeni, da sporočilo SMS ni bil dostavljeno. Procedura sicer
31 sproži HTTP zahtevek s pomočjo sistemskega objekta, ki je del podatkovne baze Oracle, imenuje pa se Package UTP_HTTP. V Package-u se kliče funkcija z imenom »request«, z vhodnim parametrom »url«. Sporočilo SMS se pošlje na podoben način kot se vpiše URL naslov v brskalnik, torej z metodo GET. Navodila za obliko URL-ja v našem primeru najdemo na spletni strani A1.si, kjer so navodila javno dostopna. URL je sestavljen iz dveh delov, prvi del so podatki o strežniku, ki jih moramo pridobiti od ponudnika SMS centra in poleg protokola vsebujejo še podatke o omrežnem naslovu oziroma IP-ju, ter vrata in pot na strežniku. Drugi del pa so dinamični parametri »to« v katerem navedemo prejemnika, »from« kjer navedemo pošiljatelja ter tekst sporočila v parametru »text«. Stranka pa prejme SMS od »A1.si« (primer sporočila SMS na sliki 23).
Slika 23: Zajem slike zaslona prejetega sporočila SMS na mobilnem aparatu [(vir slike:
lastni)]
4.3 Navodila uporabnikom
Uporabnikom na koncu tudi pripravimo kratka navodila za uporabo. Ta navodila smo priložili v prilogo. Pojasnimo jim, da se aplikacija nahaja v sistemu CRM, ki ga uporabniki že poznajo, tako da jim v navodilih podamo samo podatke o uporabi aplikacije za pošiljanje sporočil SMS.
Na priloženih slikah jim tudi označimo kje najdejo to aplikacijo in povemo kakšno je osnovno delovanje aplikacije. Pokažemo kako izberejo vnaprej definiran tekst oziroma vpišejo poljuben tekst, pojasnimo postopek zapisa v zgodovino stranke, kje nato najdejo ta zapis, ter v kakšni obliki mora biti napisana številka MSISDN. Opišemo tudi kaj se zgodi, ko kliknemo
gumb »Pošlji SMS«. V tem primeru se namreč sproži preverba pravilnosti vpisanih podatkov, če pa je vse v redu, pa se stranki pošlje sporočilo SMS, ki pride z naslova »A1.si«. Pojasnimo jim tudi, da če bi želeli dodatne pred definirane tekste, naj nam to sporočijo nadrejeni.
33
5 Rezultati
V nadaljevanju predstavljamo naslednje rezultate:
Koliko sporočil SMS pošlje naša aplikacija,
primerjava poslanih sporočil SMS po četrtletjih,
prihranek časa in denarja,
število napak,
vpliv na zadovoljstvo strank.
5.1 Število poslanih sporočil SMS
Analizo števila poslanih sporočil SMS smo izvedli eno leto po izvedbi produkta. S pomočjo poizvedbe v podatkovno bazo smo naredili povprečje poslanih sporočil v zadnjih treh mesecih.
Na ta način smo prišli smo do podatka, da je mesečno v povprečju z aplikacijo poslanih 10332 sporočil oziroma skoraj 344 dnevno. Od tega je vnaprej definiranih tekstov 8920, 1412 pa je takšnih kjer agentje tekst napišejo sami. Tu lahko ločimo še poslana sporočila SMS, ki so jih poslali agentje iz klicnega centra, tehnične pomoči, ki so sporočila pošiljali že do sedaj, ter zaposleni na prodajnih mestih, ki do sedaj tovrstne aplikacije niso uporabljali. Le - ti so do sedaj svoje stranke obveščali bodisi preko klica ali pa s pošiljanjem sporočila s telefona.
5.2 Primerjava števila poslanih sporočil SMS po četrtletjih
Spodnji graf prikazuje primerjavo števila poslanih sporočil SMS iz aplikacije po četrtletjih v zadnjih dveh letih odkar je bila aplikacija izvedena. Naj povemo tudi, da smo aplikacijo izvedli šele v sredini maja 2019, tako da je časovno obdobje pri prvem podatku (drugo četrtletje 2019) krajše. Iz podatkov pa je razvidno, da se je vsaj v začetku uporaba aplikacije povečevala, v zadnjih četrtletjih pa stabilizirala.
Graf 1: Število poslanih sporočil SMS po četrtletjih
5.3 Prihranek na času in denarju
Preden smo v naš sistem CRM uvedli aplikacijo za pošiljanje sporočil SMS, so uporabniki pošiljali sporočila SMS iz druge temu namenjene aplikacije. Vnaprej definirane tekste so imeli agentje shranjene v Excelovi datoteki, ki so jo imeli shranjeno na skupnem disku. Ob tem, so vedno morali narediti še zapis v zgodovino stranke. Postopek je bil tako zamudnejši. Glede na meritve, ki smo jih opravili je uporabnik za postopek pošiljanja sporočila, brez pisanja teksta, porabil v povprečju 25 sekund. V ta čas je všteto iskanje aplikacije na namizju in odpiranje ter uporabo aplikacije, v kar je vključeno tudi pisanje mobilne številke. Poleg tega je za zapis v zgodovino povprečno porabil še dodatnih 20 sekund. Z novo aplikacijo je skupen povprečen čas 15 sekund. Torej je prihranek pri enem samem sporočilu kar 30 sekund. Takšnih sporočil pa je v povprečju 1412 na mesec, kar pomeni da je prihranek na mesečni ravni 11,76 ur. Na letni ravni to znaša 140 ur. Še večja razlika pa je pri poslanih sporočilih SMS, kjer je tekst vnaprej definiran. Tu je število sporočil SMS višje, poleg tega pa je potrebno poiskati tekst v Excel datoteki. Če predpostavljamo, da imajo uporabniki Excel datoteko v 30 odstotkih primerov že odprto na namizju, ter jim jo ni potrebno iskati v skupni mapi, je skupen povprečen čas samo za iskanje teksta 20 sekund. Povprečen čas iskanja teksta v aplikaciji pa je 5 sekund.
Torej smo pri tekstu prihranili 15 sekund na sporočilo SMS. Če dodamo še dodatnih 30 sekund prihranka pri uporabi stare aplikacije za pošiljanje sporočil SMS v ter vpisu v zgodovino, lahko
4715
35 ob predpostavki, da je mesečno takšnih sporočil 8920, preračunamo, da je mesečni prihranek na času: 111,5 ure, kar letno znaša 1338 ur.
Če torej seštejemo vse skupaj letno prihranimo na času 1478 ur. Malo manj kot delovni čas enega uporabnika, ki je v letu 2020 povprečno opravil 1620 ur [20]. V naš izračun pa seveda niso všteti primeri, kjer uporabniki pred tem, vsaj na tak način, sploh niso imeli možnost pošiljanja sporočil in so stranke obveščali le s klicem. Tu je prihranek na času seveda še bistveno višji, ne moremo pa v teh primerih narediti primerjave s sedanjimi podatki, saj se le - ti podatki niso zbirali.
5.4 Število napak
V prejšnjem poglavju smo se osredotočili samo na prihranek na času ob uporabi aplikacije.
Ob tem nismo upoštevali, da se je pri tem zmanjšalo število napak uporabnikov, ki so bodisi pozabili poslati sporočilo SMS, ali pa zapisati komentar v zgodovino stranke. Vsaka napaka pa seveda lahko pomeni dodatno delo. V kolikor se stranki ne pošlje sporočila SMS, to pomeni, da stranka ni bila obveščena o situaciji, ter se predvidoma še enkrat obrne na naše agente. To pa seveda pomeni dodaten klic in posledično lahko vodi do pritožbe. Povprečen čas za reševanje ene pritožbe pa je 4 minute. Če predpostavljamo, da se to zgodi pri 1% primerov, to v povprečju pomeni dodatnih 6 ur dela mesečno, ali 72 ur letno.
Druga težava, ki se je lahko pojavila pa je bil zapis v zgodovino stranke. V kolikor se pozabi narediti zapis v zgodovino, ter se stranka v bližnji prihodnosti obrne na naše agente, le - ta ni obveščen, kaj točno se je delalo s stranko. To seveda pomeni dodatno raziskovanje. Če spet vzamemo, da je takšnih primerov 1% (v praksi jih je skoraj zagotovo več), to v povprečju pomeni 2 minuti dodatnega dela, pridemo do številke 3 ure mesečno, kar 36 ur letno. Ob tem seveda moramo poudariti, da tudi z novo aplikacijo, kjer je oboje skupaj združeno, do napak še vedno lahko pride. Je pa zagotovo ta številka precej nižja, vsaj glede nato, da ima agent en opravek manj.
5.5 Zadovoljstvo uporabnikov
Manj napak ter enostavno obveščanje strank preko sporočil SMS, pa ima še eno pozitivno plat. To je zadovoljstvo strank zaradi dobre uporabniške izkušnje. Stranke namreč določena
obvestila oziroma navodila prejmejo kar preko SMS obvestil. Če recimo vzamemo za primer navodila za vklop raznih storitev ali nastavitev na aparatu, lahko takoj ugotovimo, da so napisana navodila za uporabnika precej preglednejša, stranka pa lahko v miru lahko opravi željeno storitev po končanem klicu. Vse skupaj pa je precej enostavnejše tudi pri sporočanju raznih informacij. Le - te so preko sporočila SMS vseskozi na voljo, stranke pa v primerih, kjer se jih sicer pokliče, s tem ne motimo. Vse to so sicer le malenkosti pri vplivu na zadovoljstvo strank, ki pa se začne graditi ravno na takšnih malenkostih. Zadovoljstvo strank pa pomeni, da ostajajo naši zvesti uporabniki – obstoječe stranke pa je seveda lažje zadržati kot pa pridobivati nove.
37
6 Zaključek
V diplomski nalogi je prikazano, kako smo v telekomunikacijskem podjetju rešili težave prejšnjega sistema pošiljanja sporočil SMS strankam. Hkrati pa z novim sistemom tudi skrajšali čas, ki ga za pošiljanje sporočil porabijo agenti, pri le tem pa tudi zmanjšali možnost napak.
Agentom, ki do sedaj sploh niso imeli možnosti pošiljanja sporočil smo le - to omogočili. S tem smo precej olajšali delo uporabnikov našega sistema CRM, poskrbeli pa smo tudi za dobro uporabniško izkušnjo naših strank, ki sedaj navodila in obvestila prejmejo preko sporočila SMS, kar je zanje boljša uporabniška izkušnja, posledično pa tudi večje zadovoljstvo. Aplikacija je torej rešila več težav hkrati. Dokazali pa smo tudi, da lahko v relativno kratkem času naredimo aplikacijo s katero na dolgi rok prihranimo na času in tudi denarju.
Aplikacija omogoča tudi dodatne izboljšave in nadgradnje. Že med njeno izdelavo smo prišli na idejo, da bi bilo možno v prihodnosti preko aplikacije izvesti tudi pošiljanje elektronske pošte. Elektronska pošta bi se lahko pošiljala posamezno, ali hkrati z sporočilom SMS, naredil pa bi se tudi zapis v zgodovino pri stranki. Tako bi še dodatno poenostavili delo zaposlenih ter preglednost komunikacije s strankami. Naslednji malo bolj zahteven korak pa bi bil lahko tudi uvedba družbenih omrežij, s čimer bi omogočili komunikacijo preko sistema CRM, oziroma vsaj omogočili zapiske v zgodovino stranke.
Literatura
[1] Upravljanje odnosov s strankami. Dosegljivo:
https://sl.wikipedia.org/wiki/Upravljanje_odnosov_s_strankami, 2020. (Dostopano 12.1.2021).
[2] CRM. Dosegljivo: https://en.wikipedia.org/wiki/Customer_relationship_management, 2020. (Dostopano 12.1.2021).
[3] J. Zor, Diplomska naloga: Virtualizacija strežniške infrastrukture. Ljubljana. Fakulteta za računalništvo in informatiko, 2018.
[4] Prednosti in slabosti uporabe podatkovnih baz. Dosegljivo: http://colos.fri.uni-lj.si/ERI/RACUNALNISTVO/PODATKOVNE_BAZE/prednosti_in_slabosti_uporabe_
podatkovnih_baz.html, (Dostopano 22.5.2021).
[5] Opredelitev pojma SUPB. Dosegljivo: http://colos.fri.uni-lj.si/ERI/RACUNALNISTVO/PODATKOVNE_BAZE/opredelitev_pojma_supb.html, (Dostopano 22.5.2021).
[6] G. Narain, Annamalai, Melliyal; The Database Book - Principles & Practice Using the Oracle Database. Summit, N-J. Silicon Press, 2011.
[7] Splošni akt o prenosljivosti številk. Dosegljivo: http://npch.si/index.php/2-uncategorised/3-splosni-akt, (Dostopano 22.5.2021).
[8] Simobil Message Getaway. Dosegljivo:
https://www.a1.si/documents/10179/2305221/Tehni%C4%8Dna+specifikacija+-+Si.most+-dolga+stevilka.pdf/e4fb51be-018e-4986-b1a3-101c1af64d4f, (Dostopano 1.6.2021).
[9] M. Marjanović, Diplomska naloga: Analiza področja in predstavitev rešitve za SMS portal. Ljubljana. Fakulteta za računalništvo in informatiko, 2010.
[10] HTML. Dosegljivo: https://en.wikipedia.org/wiki/HTML, 2019. (Dostopano 21.1.2021).
[11] Uvod v HTML. Dosegljivo: https://nsa-splet.si/html/uvod/html-uvod-01.php, 2019.
(Dostopano 22.1.2021).
[12] M. Kaltenekar, Hitri vodnik – oblikovanje spletnih strani. Založba Pasadena, 2006.
39 [13] CSS. Dosegljivo: https://sl.wikipedia.org/wiki/CSS, 2009. (Dostopano 22.1.2021).
[14] Bootstrap. Dosegljivo: https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework), 2020. (Dostopano 25.5.2021).
[15] What is Bootstrap? Dosegljivo: https://www.toptal.com/front-end/what-is-bootstrap-a-short-tutorial-on-the-what-why-and-how, 2020. (Dostopano 25.5.2021).
[16] P. Mrhar, ASP – Active Server Pages. Nova Gorica. Založba Flamingo, 2002
[17] ASP.net. Dosegljivo: https://en.wikipedia.org/wiki/ASP.NET, 2019. (Dostopano 4.6.2021)
[18] G. T. Allen, SQL for Dummies. Hoboken: Wiley Publishing, 2006
[19] SQL. Dosegljivo: https://www.w3schools.in/mysql/ddl-dml-dcl/, 2019. (Dostopano 13.5.2021).
[20] Statistični urad RS, Opravljene delovne ure. Dosegljivo:
https://www.stat.si/StatWeb/news/Index/8872, (Dostopano 22.4.2021).
PRILOGA
41
Navodila za uporabo aplikacije za pošiljanje SMS-ov
Aplikacija za pošiljanje SMS-ov se nahaja v CRM-ju, v katerega se po ustaljenem postopku prijavite z svojim uporabniškim imenom.
V iskalniku poiščemo ter odpremo stranko, kateri želimo poslati SMS (bodisi MSISDN, ali pa Uporabniško ime).
Slika 1: Iskanje stranke v CRM-ju [(vir slike: lastni)]
V zavihku Podatki o uporabniku se nahaja nov zavihek, Pošiljanje sporočila SMS.
Odpremo ga s klikom:
Slika 2: Postavitev SMS aplikacije v meniju [(vir slike: lastni)]
Če imamo odprto mobilno stranko se podatek o MSISDN-ju ter davčni prenese v aplikacijo avtomatsko. V kolikor imamo odprto uporabniško ime linije, se prenese avtomatsko ta podatek ter davčna številka, vpis MSISDN-ja pa je potreben ročno. V kolikor pa nimamo odprtega
Če imamo odprto mobilno stranko se podatek o MSISDN-ju ter davčni prenese v aplikacijo avtomatsko. V kolikor imamo odprto uporabniško ime linije, se prenese avtomatsko ta podatek ter davčna številka, vpis MSISDN-ja pa je potreben ročno. V kolikor pa nimamo odprtega