Podatki o stranki

Sistem CRM je namenjen upravljanju s strankami. Podatke o strankah pa imamo shranjene v podatkovni bazi. Zaradi upravljanja s strankami te podatke nato prikazujemo uporabnikom sistema.

Slika 10: Strankini podatki v aplikaciji, ko je v sistemu CRM odprta mobilna stranka [(vir slike: lastni)]

Podatki o strankah se prikažejo na podlagi iskalnika, kjer lahko iščemo stranke po različnih parametrih. Na sliki 10 je primer prikaza, ko je v sistemu CRM odprta mobilna stranka. Dva izmed teh podatkov, ki ju nato tudi uporabimo v naši aplikaciji sta davčna številka in mobilna številka ali uporabniško ime. Posebnost prikaza podatkov pa je pri agentom klicnega centra, kjer sistem ob prejemu klica avtomatsko odpre podatke o stranki.

V naši aplikaciji od vseh podatkov, ki so nam na voljo uporabimo le davčno številko ter mobilno številko (v nadaljevanju številka MSISDN) ali v primeru stranke s fiksno tehnologijo uporabniško ime. Ko odpremo našo aplikacijo se ta dva podatka preneseta avtomatsko v aplikacijo. S tem vsaj v primerih, kjer se prenese številka MSISDN zmanjšamo možnost napak pri vnosu številke za pošiljanje sporočila SMS, pri strankah s fiksno tehnologijo pa je potreben vnos telefonske številke še vedno ročen. Da naredimo prenos podatkov o stranki v našo novo aplikacijo pa moramo raziskati pod katerimi parametri v sistemu CRM najdemo te podatke. V našem primeru so to parametri »msisdn«, »lineusername« ter »vat«. S spodnjo kodo preverimo če kateri podatki o stranki obstajajo, in v kolikor obstajajo jih uporabimo v naših spremenljivkah »sms_msisdn«, »line_username« ter »vat«. Preverba o tem ali podatek obstaja naredimo na enostaven način, s preverbo dolžine znakov parametra. V kolikor preverjamo ali obstaja številka MSISDN, lahko preverimo po dolžini 11 znakov, saj je številka MSISDN v obliki 386xxxxxxxx; V kolikor pa za uporabniško ime, pa naredimo preverbo, ali je dolžina podatka več kot 0. Če pa v sistemu CRM nimamo odprte nobene stranke, se ne prenese noben podatek, v tem primeru se vsi podatki vpisujejo ročno.

25 4.2.4 Vnaprej nastavljena besedila

Ker se nekatere vsebine sporočil, ki se jih pošilja strankam ponavljajo, je v aplikaciji funkcionalnost, da so določeni predlogi vsebin sporočil na izbiro v spustnem meniju. Slika 11 prikazuje primer vnaprej nastavljenih predlogov za pošiljanje sporočil.

Slika 11: Vnaprej nastavljena besedila [(vir slike: lastni)]

Vsebine sporočil imamo shranjene v podatkovni bazi, kjer smo v ta namen naredili novo tabelo (ukaz za kreacijo tabele na sliki 12). Tabelo smo poimenovali »SMS_TEMPLATE«, vsebuje pa polja »ID«, ki je številka zapisa, »SMS_TYPE« na podlagi katerega je določena vidnost zapisa, »TITLE«, kjer je ime oz. naslov zapisa, v polju »TEXT« se nahaja tekst za sporočilo SMS, »ORDER_NR« je namenjen razvrščanju podatkov v aplikaciji, ter polje

»ENABLED« v katerem označujemo ali je tekst še aktualen oziroma v uporabi. Polja

»ID«,«ORDER_NR« in »ENABLED« so tipa »NUMBER«, kar pomeni da so v teh poljih lahko le številski zapisi. »NOT NULL« pa pomeni, da polje ne sme biti prazno. Pri zapisih

»SMS_TYPE«, »TITLE« in »TEXT« pa so polja tipa »VARCHAR2«, kar pomeni, da lahko polje vsebuje vse znake, tako črke kot številke. Številka v oklepaju pa označuje velikost polja.

Slika 12: Ukaz za kreacijo tabele »SMS_TEMPLATE« [(vir slike: lastni]

Vpis podatkov v tabelo naredimo s komando »INSERT INTO«, vpis pa naredimo v orodju SQL Detective, s katerim upravljamo bazo. Slika 13 prikazuje primer novega vpisa v tabelo.

Slika 13: Ukaz za vpis podatkov v tabelo »SMS_TEMPLATE« [(vir slike: lastni]

Za prikaz podatkov iz tabele v aplikaciji pa uporabimo SELECT stavek (prikazan na sliki 14), ki prikaže vse zapise, s poljem »ENABLED« katero je nastavljeno na 1, kar v našem primeru pomeni omogočeno, podatke pa razvrstimo glede na podatek v polju »ORDER_NR«, od najnižje številke do najvišje:

Slika 14: Poizvedba za prikaz podatkov iz tabele »SMS_TEMPLATE« [(vir slike: lastni]

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.

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.

In document Umestitev aplikacije za pošiljanje sporočil SMS v obstoječi sistem CRM (Strani 33-0)