Procese de activare si Customer Management pentru clientii din segmentul business

Cuprins:

Introducere 3

A. Proces achizitie 3

1. Concepere oferta 3

2. Proces vanzare 4

2.1. Managementul leadurilor 4

2.2. Proces ofertare 7

2.2.1 Ofertare 7

2.2.2 ISS Contracts Team 8

3. Implementare 9

3.1.1. Implementare voce 9

3.1.2 Telefoane 10

3.2. Implementare contracte date 12

B. Customer Management- Voce 13

1. MA 13

1.1Proces de calificare voce: 13

1.2 Proces de Welcome: 14

1.3 Actiuni proactive 14

1.4 Actiuni reactive : 15

1.5 Chooseri 15

2. GBM 15

Proces de calificare voce: 15

Proces de Welcome: 15

2.3 Actiuni proactive 15

2.4 Actiuni reactive : 16

Introducere

Scopul acestui document consta in eficientizarea tuturor proceselor de activare a clientilor si de management al lor pe intreaga arie de Business

Prin acest proces se urmaresc:

a.     simplificarea proceselor de activare solicitata de dep Sales

b.     automatizarea proceselor legate de activarea segmentului de business prin care se reduc sansele de activari gresite (atat pe parcursul procesului de activare cat si chiar de la introducerea datelor initiale) si se micsoreaza timpul de activare

c.      existenta unei baze de date complete din care se pot vedea intreaga istorie a unui client, ofertele facute in decursul timpului, toate interactiunile cu acel client. Acest lucru poate duce si la necesitatea integrarii aplicatiilor din Sales cu cele din Cops

A. Proces achizitie

1. Concepere oferta

Scop:

Marketing concepe o structura cu limite maximeminime care pot fi oferite de Sales catre client.

Flow :

a.     Mkt concepe o varianta de oferta-standard cu limite maximeminime

Calendar: de 2 ori pe an + quick fixuri (pentru produse si servicii noi)

b.     Implementarea ofertei in sistemul de Billing -Amdocs, Oracle (pentru telefoane); owneri: Mkt->IT (IRFR)

c.      Implementarea si configurarea ofertei in sistemul de activare (NewPos); owneri: Mkt->Cops

d.     Cops trimite notificare catre Mkt ca ofertele se pot implementa

e.      Mkt trimite notificare pe mail inainte de postarea ofertelor pe aplicatie

f.       In conceperea ofertei finale din sistem (in prezent in Infobiz) exista un feedback informal din partea Sales pe parcursul celor 6 luni

g.      Ofertele sunt postate de catre Mkt in sistem (in prezent in Infobiz)

Propunere:

sistem / proces care sa permita sa trimita/stocheze ofertele de la competitie

posibilitatea introducerii ofertei in sistemul de activare

sistem care sa permita introducerea de date din care sa reiasa abonamentul cu reducerea maxima si in acelasi timp sa permita solicitari de oferte personalizate

Livrabile:

oferta disponibila pentru clientii Vodafone impartita pe segmente

2. Proces vanzare

2.1. Managementul leadurilor

Leadurile sunt impartite pe diverse canale si vor avea un SLA de maxim 24 ore referitor la contactarea clientului:

Telemarketing- Owner Mkt

Referral- Owner Sales

Referral Angajati- Owner Mkt

Referral Site (www.vodafone.ro)- Owner Mkt

Customer request- Owner Sales (request de la clienti catre *222, Stores)

HotLead Telesales- Owner Telesales

Regula de Business: Clientul trebuie contactat de catre o singura persoana din cadrul VDF (nu va fi trimis catre alte departamente din VDF) cu unele exceptii (cand datele de calificare sunt introduse sau primite eronat)

Nota: Se doreste un sistem de management al leadurilor in care sa fie inregistrate si transmise toate leadurile cu informatii de calificare mandatorii (tbd de catre Sales) care sa permita inregistrarea unui history si vizualizarea statusului leadului respectiv, alerte la schimbarea statusului (deschidere si persoana alocata, in progress, completed), raportare

Livrabile: Prin Managementul Leadurilor, se urmareste optimizarea si urmarirea cat mai precisa a bazei de clienti in vederea semnarii unui posibil contract.

Telemarketing

Propunere flow inregistrare

Agentul din Telemarketing contacteaza clientul -> clientul este interesat -> Telemaketing va genera leadul (va contine info mandatorii care fac diferentierea clientului pe segmente) imediat dupa apel -> rulare automata matrice calificare -> alocare pe canal (DS, TS, GBM) -> notificare Manager Sales Achizitie-> distribuire catre un om din echipa ->analiza si ofertare client-> daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs. Catalin Ioan to review

Bonus pentru Telemarketer: acordat pe criterii de calitate informatii aduse si numar leaduri

Referral

Un agent de vanzari (DS, TS, Dealer GBM) poate afla informatii despre clienti noi sau existenti. In aceasta situatie se va crea un Referral

a. DirectSales1 to DirectSales2

i. criterii: cand afla de diverse servicii la concurenta sau cont nou sau

Special: cont existent care doreste sa isi mareasca volumul de servicii fata de cel deja existent

ii. Propunere flow inregistrare: DS1 inregistreaza datele mandatorii despre client (tbd de catre Sales) intr-o aplicatie de management de leaduri ->notificare Manager Sales Achizitie-> distribuire catre un om din echipa -> DS2 incepe analiza clientului si va fi introdus clientului de catre DS1-> ofertare-> daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs -> la inchiderea leadului, DS1 va fi notificat automat ;

Nota Se doreste un sistem de management al leadurilor in care sa fie inregistrate si transmise toate leadurile cu informatii de calificare mandatorii (tbd de catre Sales) care sa permita inregistrarea unui history si vizualizarea statusului leadului respectiv, alerte la schimbarea statusului (deschidere si persoana alocata, in progress, completed), raportare. Leadul va fi trimis de la DS1 catre Manager Achizitie

Comisionare (bonificare): in momentul in care leadul respectiv este inchis cu success, o notificare va pleca catre DS1. DS1 va fi asociat cu leadul respectiv. Atat DS1 cat si DS2 vor fi comisionati.

b. TeleSales to DirectSales

i. criterii: cand afla de diverse servicii la concurenta sau cont nou sau

Special: cont existent care doreste sa isi mareasca volumul de servicii fata de cel deja existent

ii. Propunere flow inregistrare TS inregistreaza datele mandatorii despre client (tbd de catre Sales) intr-o aplicatie de management de leaduri ->notificare Manager Sales Achizitie-> distribuire catre un om din echipa -> DS incepe analiza clientului (TS va fi notificat automat)-> ofertare-> daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs -> la inchiderea leadului, TS va fi notificat automat.

Comisionare (bonificare): in momentul in care leadul respectiv este inchis cu success, o notificare va pleca catre TS respectiv. TSul va fi asociat cu leadul respectiv.

c. Dealeri GBM to DS Achizitie MA

Flow inregistrare Dealerul completeaza intr-o interfata datele mandatorii despre client (tbd de catre Sales) ->interfata integreaza datele intr-o aplicatie da management al leadurilor-> notificare Manager Sales Achizitie-> distribuire catre un om din echipa -> Sales incepe analiza clientului -> ofertare-> daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs.

Comisionare (bonificare): in momentul in care leadul respectiv este inchis cu success, o notificare va pleca catre dealerul respectiv. Dealerul va fi asociat cu leadul respectiv.

Referral Angajati

Propunere flow inregistrare orice angajat poate introduce info despre un posibil client (sau care are max 2 SIMuri) -> din Intranet se trimite formul respectiv intr-o aplicatie de management Leaduri -> rulare automata matrice calificare -> notificare catre Manager Achizitie (TS, DS GMB, DS MA) sau Regional AM -> alocare catre un om din echipa -> Sales incepe analiza clientului -> ofertare daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs-> notificare automata catre angajatul care a initiat leadul

Bonus pentru angajat se acorda bonus ptr minim 3 SIMuri activate + o suma pentru fiecare SIM suplimentar

Nota: Aplicatia va trebui sa inregistreze datele despre persoana care genereaza leadul- > posibilitatea de raportare a aplicatiei. Aplicatia va trebui sa poata face filtrare dupa anumite criterii pentru persoana care inregistreaza leadul (de ex Sales sau Mkt nu pot sa introduca date in acest flow)

Referral Site

Propunere flow inregistrare Pe www.vodafone.robusiness exista un form care poate fi completat de client -> formul respectiv intr-o aplicatie de management Leaduri -> rulare set de criterii de calificare, special creat pentru acest flow -> notificare catre Manager Achizitie (TS, DS GMB, DS MA) -> alocare catre un om din echipa -> Sales contacteaza clientul in maxim 24 ore tinand cont de intervalul orar dorit de client -> ofertare ->daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs.

Customer request

a. Input din Cops (CS, Coll, TAM, MA Team, Fraud, Loy, Ma Data Support)

Propunere flow inregistrare: Cops introduce info mandatorii -> info sunt reconciliate intr-o aplicatie de management Leaduri-> rulare automata matrice calificare -> notificare catre Manager Achizitie (TS, DS GMB, DS MA) -> alocare catre un om din echipa -> analiza client -> ofertare ->daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs.

b. Input din Stores (pentru clientii care au profil superior celui pe care il pot oferta)

Propunere flow inregistrare: Strore Representative introduce info mandatorii -> info sunt reconciliate intr-o aplicatie de management Leaduri-> rulare automata matrice calificare -> notificare catre Manager Achizitie (DS GMB, DS MA) -> alocare catre un om din echipa -> analiza client -> ofertare ->daca respectivul client accepta oferta, Sales schimba statusul Leadului -> Implementare voce -> Leadul va fi inchis cu succes doar dupa ce va fi populat manual de catre Sales cu Customer ID din Amdocs.

Bonusare: pentru lead finalizat la nivel de cont

HotLead Telesales

Agentul din Telemarketing contacteaza clientul -> clientul este interesat -> Telemaketing transfera apelul catre TS Hunting-> Telemarketing va genera leadul catre TS in timpul apelului -> TS preia clientul -> evalueaza potentialul de vanzare -> daca clientul se incadreaza pentru TS, TS va face ofertarea clientului ; daca respectivul client se incadreaza pentru DS, TS incadreaza clientul in aplicatie pentru DS-> notificare Manager Sales Achizitie-> distribuire catre un om din echipa -> DS incepe analiza clientului (periodic se trimit notificari de status lead catre manager DS)-> ofertare.

2.2. Proces ofertare

2.2.1 Ofertare

Ofertarea se poate face in doua moduri:

Proactiv -> Reprezentantul de vanzari contacteaza clientul (vdf sau competitie), se face o analiza a evolutiei firmei si a nevoii de servicii de comunicatii (management flota, produse) - 3 intalniri

Reactiv -> Clientul este "atacat" de competitie sau client al competitiei. Daca respectivul client contacteaza Vodafone, se incearca gasirea unei oferte similare din punct de vedere cost/beneficii.

Livrabile: Procesul de ofertare urmareste semnarea contractului dintre Vodafone si client

Flow de ofertare:

Sales ia ca limita maxima oferta inregistrata in sistem

a.     Daca oferta include si date fixe, inaintea semnarii contractului se va efectua un Site Visit la client

Sales viziteaza clientul. Sunt necesare informatii relevante despre cont (numar de SIMuri, valoare, trafic, oferta actuala, tarife, discounturi etc)

Sales prezinta oferta-standard catre client

a.     Daca clientul accepta -> procesul de implementare

b.     Daca nu accepta-> pctul 4

Sales revine la Mkt (Pricing pentru refacerea ofertei; Aqusition&Retention pentru PRP-oferta resemnare, discounturi telefoane, oferte fidelitate)

a.     Daca oferta include si date fixe, Sales trebuie sa trimita catre Mkt Pricing si solutia tehnica de la Presales ISS

b.     exista un SLA intern Mkt (Pricing- 3wd; Licitatii- 5wd)

Mkt revine catre Sales cu raspunsul revizuit

Sales se intoarce catre client cu oferta revizuita de Mkt Pricing

a.     Semnare contract -> proces implementare

b.     Nesemnare contract-> pct 5 sau ramanere pe oferta existenta sau reziliere

Rezolutie finala consemnata in sistem ca si istorie a clientului- oferta cu care s-a semnat sau in caz contrar motivul nesemnarii. Daca exista, trebuie atasata si oferta de la concurenta.

Sistemul nou trebuie sa cuprinda:

ofertele si limitele pentru toate segmentele de clienti

ofertele primite de la concurenta

tool de simulare si comparare a ofertelor in functie de eligibilitatea clientului(intre ofertele VDF si intre oferat VDF vs concurenta)

istoria clientului dpdv interactiuni Mkt-Sales, istorie de plati, evenimente importante, oferte si acte avute de client de-a lungul timpului, cadouri trimise la client

sistem alertare in functie de anumiti parametri

un modul pentru Mkt Pricing care sa permita analiza la nivelul bazei de clienti a ofertelor curente +simulari

tooluri de raportare si analiza a clientilor

mobilitate (accesibil de pe deviceuri mobile)

si sa genereze documentele necesare semnarii unui contract (contract, acte aditionale) personalizat pentru fiecare client

2.2.2 ISS Contracts Team

ISS

In cazul negocierilor contractelor de ISS, pot fi cazuri in care clientul solicita modificarea anumitor clause contractuale. In aceasta faza, Agentul Sales trebuie sa se intoarca catre grupul ISS Contracts Team pentru luarea acceptului in ceea ce priveste modificarile solicitate de client. Aceste modificari au doua componente: continut si limbajul de redactare.

Propunere: grupul ISS Contracts Team trebuie sa fie format din Marketing, Sales, Legal, Finance, Collection, MA, Frauda

In prezent, toate modificarile reiesite din ISS Contract Team sunt prinse sub forma unui act aditional.

In viitor, aceste modificari trebuie sa fie prinse si in cadrul contractului, nu doar in acte aditionale deci se va putea personaliza continutul contractului propriu-zis

Owner proces: Mkt- Dana Berceanu. Continutul aprobat de Mkt in forma finala redactata de Legal va fi folosit de Sales pentru reofertarea clientului.

Flow: Sales negociaza contractul cu clientul -> Clientul solicita modificari ale clauzelor contractuale -> Agentul de Sales cere feedback grupului ISS Contracts Team-> notificare automata a grupului ISSContractsTeam-> fiecare departament din acest grup trebuie sa dea feedback (neaparat daca are implicare sau nu). Feedbackul va fi trimis din toate departamentele (timp de raspuns- maxim 2wd) -> feedbackul este centralizat de Mkt si trimis ca forma finala catre Legal pentru definirea lui in forma contractuala (se va incadra intr-un SLA maxim de inca 2wd) -> Sales este notificat in mod automat de statusul modificarilor ->Sales prezinta clientului forma revizuita

Nota:

a.     In momentul in care se solicita modificari in contract, Sales trebuie sa trimita si anexele (1 si 6) deja completate.

b.     Toate cererile venite de la client dpdv tehnic trebuie sa fie adresate in cerintele solutiei tehnice (prin Presales - Sol.Development) si nu prin grupul de e-mail/aplicatie/tool

Contractele care sunt modificate in urma acestui flow trebuie sa contina explicit clauzele care au fost modificate (istoria interactiunilor dintre dep impactate).

NonISS

Un flow asemanator cu cel de la ISS si respectivele modificari (conditii de plata). Vor fi necesare atasamentele actelor semnate.

3. Implementare

3.1.1. Implementare voce

Flow Implementare :

Clientul accepta ofertacontract->

a. Client existent->aplicatia completeaza automat contractul cu datele clientului-> agentul Sales introduce restul datelor mandatorii care sunt predefinite in aplicatie (oferta, numar SIMuri*, discounturi, tarife, grup, contract end-date, telefoane)

b. Client nou-> Sales introduce datele despre client(nume, cod fiscal) intr-o aplicatie ->aplicatia completeaza automat contractul cu datele clientului-> agentul Sales introduce restul datelor mandatorii care sunt predefinite in aplicatie (oferta, numar SIMuri*, discounturi, tarife, grup, contract end-date, telefoane)->

*Managementul SIMurilor : echipa de SIM Management face alocarea rangeului de numere in aplicatia URM catre Direct Sales fara asignare in Amdocs. Sales Admin gestioneaza alocareaeliberarea de numere catre codurile de agent de Sales intr-o aplicatie noua. Agentul de Sales atribuie numerele dorite catre contul cu care semneaza contractul. In momentul implementarii contractului de catre MAGBM Support, numerele inregistrate aici se asigneaza in Amdocs.

Propunere: in prezent in Amdocs daca este facuta o rezervare de range de numere, este posibil ca oricine sa se autentifice in aplicatie si sa sa anuleze rezervarea pentru un singur numar. Se doreste ca acest scenariu sa fie limitat din Amdocs.

->Aplicatia poate fi accesata de pe deviceul mobil al Sales-> Aplicatia completeaza  templateul de contract cu datele ofertei introduse anterior de Sales (aplicatia verifica eligibilitatea ofertei, daca nu este eligibila, se intra pe flowul de aprobare cu Marketing Pricing)-> Sales trimite din aplicatie Mail-to-FaxMail catre numarul clientului-> contractul completat este receptionat de client-> clientul semneaza si stampileaza contractul -> clientul inamaneaza contractul in original catre Sales-> Sales upload-eaza in cel mai scurt timp (inclusiv de la client) contractul precum si posibile acte aditionale (cod fiscal, certificat de inregistrare fiscale, buletin)in aplicatie -> Aplicatia trimite notificare de implementare in Frauda (pentru cazurile cu mai mult de 10 SIMuri)->

Nota:

a. In momentul negocierii contractului, pentru clientii noi cu contracte cu oferte standard, Frauda nu poate face Preassess. Acest lucru nu este posibil din punct de vedere legal atat timp cat nu exista contract semnat.

c. pentru clientii noi si existenti care doresc o suplimentare de SIMuri, Frauda va face verificarile doar dupa semnarea contractului. Frauda nu respinge activarea contractului ci, in cel mai rau caz, cere un depozit pentru activarea lui.

-> Frauda poate spune ca este ok sau trebuie platit depozit -> Frauda comunica prin aplicatie catre MAGBM Support limita de depozit -> MAGBM Support face analiza daca limita de depozit trebuie marita conform cerintelor lor -> Sales este notificat de aplicatie de limita necesara de depozit -> Sales comunica clientului necesitatea platirii depozitului -> daca depozitul nu este platit, contractul va sta in pending 1 luna dupa care se anuleaza ; daca depozitul este platit, clientul trimite fax cu confirmarea de plata la Sales-> Sales uploadeaza confirmarea de plata in aplicatie -> notificare MAGBM Support ca se poate merge mai departe la implementare si incepere flow Comanda Telefoane cu input (inputul nu se va face in Retail ci in aplicatia noua) (rezervarea Telefoanelor in Retail se poate face in orice moment chiar si la negocierea contractului)-> MAGBM Support implementeaza contractul in Billing-> Aplicatia trimite notificare automata catre Sales si Collection (doar pentru contractele care intra pe flowul de negociere cu Pricing sau cu ISS feedback)-> Sales anunta clientul de activare

3.1.2 Telefoane

Scop: Clarificarea si optimizarea procesului de livrare a telefoanelor catre clienti

Departamente implicate: Sales, Marketing, Cops- MA Team, GMB Team, Logistics

Se diferentiaza doua tipuri de achizitie a telefoanelor care vor fi detaliate mai jos:

a.    Achizitie telefon cu bani

Nota: exista si situatii de achizitie a unui telefon cadou (cu buget subventionat de Marketing)

b.    Achizitie telefon cu puncte de loialitate

a.    Clientul doreste un anumit model de telefon -> clientul suna Account Manager (clientul poate suna in MA Team; MA Specialist ia legatura cu Account Manager sa contacteze clientul)-> Account Manager ia legatura cu Account Exectutive-> Account Executive completeaza un form standard intr-o aplicatie (Retail) -> aplicatia (Retail) verifica automat in Capone daca clientul are mai mult de 1 factura neplatita-> daca este, se returneaza mesaj de eroare, daca nu este, se merge mai departe -> aplicatia (Retail) provizioneaza datele in Oracle Order Management - > echipa Order Desk vizualizeaza comanda si genereaza un Release (SLA: maxim 2 ore)-> Releaseul este trimis automat la CEVA -> CEVA trimite coletul prin curier (SLA ptr livrari in Bucuresti la ora 10, 12 si 15 zilnic; pentru livrari in regiuni- toate comenzile pleaca in regiuni la 20.30 in aceeasi zi)-> curierul livreaza telefonul la client in baza avizului de expeditie (SLA- livrarea se face a doua zi lucratoare, pana la sfarsitul zilei (SLA total maxim 2 zile lucratoare)-> clientul primeste coletul-> clientul este multumit sau coletul nu este conform cu ceea ce a solicitat (in prezent clientul va suna ulterior la Sales-> pornire investigatie interna; in paralel Sales face o noua comanda cu diferenta de produse pentru client astfel incat sa ii fie livrate toate produsele comandate) sau clientul se razgandeste-> se face stornare

i. Propunere: Logistics va investiga daca se poate ca, in momentul livrarii, curierul sa stea cu clientul pana cand reprezentantul clientului verifica continutul coletului si semneaza pentru conformitate

Propunere : Sales va agrea cu Logisticul daca ora maxima de acceptare pentru comenzi este ora 18.00 in loc de ora 19.00

Nota: Pentru cazurile de Achizitie telefon cadou (cu buget subventionat de Marketing): Sales introduce date mandatorii despre client (in prezent in Infobiz) -> grupurile Marketing, DS Warehouse sunt notificate. Datele introduse trebuie stocate intr-un viitor sistem (posibil acelasi de la 1 si 2.2) ca si istorie a clientului cu posibilitate de raportare. In paralel, Sales Account Executive completeaza un form standard intr-o aplicatie (Retail) -> aplicatia (Retail) verifica automat in Capone daca clientul are mai mult de 1 factura neplatita-> daca este, se returneaza mesaj de eroare, daca nu este, se merge mai departe -> aplicatia (Retail) provizioneaza datele in Oracle Order Management - > echipa Order Desk vizualizeaza comanda si genereaza un Release (SLA: maxim 2 ore)-> Releaseul este trimis automat la CEVA -> CEVA trimite coletul prin curier (SLA ptr livrari in Bucuresti la ora 10, 12 si 15 zilnic; pentru livrari in regiuni- toate comenzile pleaca in regiuni la 20.30 in aceeasi zi)-> curierul livreaza telefonul la client in baza avizului de expeditie (SLA- livrarea se face a doua zi lucratoare, pana la sfarsitul zilei (SLA total maxim 2 zile lucratoare)-> clientul primeste coletul-> clientul este multumit sau coletul nu este conform cu ceea ce a solicitat (in prezent clientul va suna ulterior la Sales-> pornire investigatie interna; in paralel Sales face o noua comanda cu diferenta de produse pentru client astfel incat sa ii fie livrate toate produsele comandate) sau clientul se razgandeste-> se face stornare

Nota: echipa Order Desk vizualizeaza comanda si genereaza un Release (SLA: maxim 2 ore)-> Releaseul este trimis automat la CEVA -> CEVA trimite coletul prin curier (SLA ptr livrari in Bucuresti la ora 10, 12 si 15 zilnic; pentru livrari in regiuni- toate comenzile pleaca in regiuni la 20.30 in aceeasi zi)-> curierul livreaza telefonul la client in baza avizului de expeditie (SLA- livrarea se face a doua zi lucratoare, pana la sfarsitul zilei (SLA total maxim 2 zile lucratoare)-> clientul primeste coletul-> clientul este multumit sau coletul nu este conform cu ceea ce a solicitat (in prezent clientul va suna ulterior la Sales-> pornire investigatie interna; in paralel Sales face o noua comanda cu diferenta de produse pentru client astfel incat sa ii fie livrate toate produsele comandate) sau clientul se razgandeste-> se face stornare

Se doreste ca in viitorul sistem sa se faca o singura comanda si pentru cazurile de livrare la adrese diferite.

b. Clientul(MA) doreste un telefon -> clientul solicita acest lucru catre Account Executive sau catre Account Manager sau catre MA Specialist - > Account Executive sau MA Specialist completeaza in aplicatie (NewPos) datele despre client si verifica daca clientul are datorii neachitate sau daca nu are puncte disponibile (posibil ca aceasta verificare sa se faca in viitor in NewPos sau E-shop)-> trimitere automata pe mail catre client cu o "vitrina" care contine toate tipurile de telefoane cu valorile aferente in puncte de loialitate +informatii daca clientul poate achizitiona telefoane-> clientul opteaza pentru tipul de telefon-> clientul completeaza manual pe vitrina primita tipul telefonului, semneaza si stampileaza-> trimite inapoi cererea catre MA Specialist in orice format -> BackOffice MA Team proceseaza cererile in aplicatie (Retail) ->aplicatia (Retail) verifica automat in Capone daca clientul are mai mult de 1 factura neplatita-> daca este, se returneaza mesaj de eroare, daca nu se merge mai departe -> aplicatia (Retail) face redeem->aplicatia (Retail) provizioneaza datele in Oracle Order Management - > echipa Order Desk vizualizeaza comanda si genereaza un Release (SLA: maxim 2 ore)-> Releaseul este trimis automat la CEVA -> CEVA trimite coletul prin curier (SLA ptr livrari in Bucuresti la ora 10, 12 si 15 zilnic; pentru livrari in regiuni- toate comenzile pleaca in regiuni la 20.30 in aceeasi zi)-> curierul livreaza telefonul la client in baza avizului de expeditie (SLA- livrarea se face a doua zi lucratoare, pana la sfarsitul zilei (SLA total maxim 2 zile lucratoare)-> clientul primeste coletul-> clientul este multumit sau coletul nu este conform cu ceea ce a solicitat (in prezent clientul va suna ulterior la Sales-> pornire investigatie interna; in paralel Sales face o noua comanda cu diferenta de produse pentru client astfel incat sa ii fie livrate toate produsele comandate) sau clientul se razgandeste-> se face stornare

Account ExecutiveAccount Manager trebuie sa aiba redefinite drepturile de acces in aplicatii

Clientul(GBM) solicita acest lucru catre TAM -> TAM trimite un form Loyac catre client pe mail sau pe fax (propunere: TAMPresales completeaza in aplicatie (NewPos) datele despre client si verifica daca clientul are datorii neachitate sau daca nu are puncte disponibile (posibil ca aceasta verificare sa se faca in viitor in NewPos sau E-shop)-> clientul il semneaza si il trimite inapoi-> TAM face caz in Clarify catre Presales GBM-> Presales GBM Team proceseaza cererile in aplicatie (Retail) ->aplicatia (Retail) verifica automat in Capone daca clientul are mai mult de 1 factura neplatita-> daca este, se returneaza mesaj de eroare, daca nu se merge mai departe -> Retail face redeem->Retail provizioneaza datele in Oracle Order Management - > echipa Order Desk vizualizeaza comanda si genereaza un Release (SLA: maxim 2 ore)-> Releaseul este trimis automat la CEVA -> CEVA trimite coletul prin curier (SLA ptr livrari in Bucuresti la ora 10, 12 si 15 zilnic; pentru livrari in regiuni- toate comenzile pleaca in regiuni la 20.30 in aceeasi zi)-> curierul livreaza telefonul la client in baza avizului de expeditie (SLA- livrarea se face a doua zi lucratoare, pana la sfarsitul zilei (SLA total maxim 2 zile lucratoare)-> clientul primeste coletul-> clientul este multumit sau coletul nu este conform cu ceea ce a solicitat (in prezent clientul va suna ulterior la Sales-> pornire investigatie interna; in paralel Sales face o noua comanda cu diferenta de produse pentru client astfel incat sa ii fie livrate toate produsele comandate) sau clientul se razgandeste-> se face stornare

3.2. Implementare contracte date

Scop: Optimizarea procesului de activare tehnica si in Billing a porturilor de date

Departamente implicate: Sales; Cops- MA Data Support, MA Support, MA Team; FN; NIS; SAC; PM Net&Sys

Flow:

Ofertare: Mkt concepe portofoliul standard pentru clienti -> rezulta criterii stabilite pe segmente care vor fi stocate intr-o aplicatie-> Sales extrage datele din aplicatie pentru conceperea ofertei catre Client-> Sales se intalneste cu clientul pentru a identifica nevoile acestuia -> Sales DAS introduce datele despre client intr-o schema Presales daca sunt indeplinite anumite criterii (stabilite de EBU si Net&Sys- in progress)-> se primeste feedback de la Presales in maxim 5 zile -> solutia tehnica din presales se poate incadra in oferta standard din Mkt sau nu:

a.     Daca solutia se incadreaza-> Sales intalneste clientul pentru a ii face o oferta concreta (solutia tehnica +tarife)->

a.     Clientul accepta oferta facuta -> Sales introduce in aplicatie datele mandatorii despre client-> aplicatia completeaza automat contractul cu datele clientului-> -> Sales trimite din aplicatie Mail-to-FaxMail catre numarul clientului-> contractul completat este receptionat de client-> clientul semneaza si stampileaza contractul -> clientul inamaneaza contractul in original catre Sales

b.     Clientul nu accepta oferta facuta -> clientul nu accepta conditii contractuale (-> se intra pe flowul 2.2.2 ISS Contracts Team), pretul (Sales se intoarce la Mkt Pricing pentru revizuire oferta-> Mkt Pricing revine cu feedback catre Sales in maxim 3 zile-> Sales prezinta clientului oferta revizuita), solutia tehnica (->Sales DAS introduce datele intr-un nou Presales)

b.     Daca solutia nu se incadreaza-> Mkt Pricing analizeaza respectiva solutie-> Mkt Pricing genereaza o oferta personalizata de pret-> Sales prezinta oferta concreta clientului->

a.     Clientul accepta oferta facuta -> Sales introduce in aplicatie datele mandatorii despre client-> aplicatia completeaza automat contractul cu datele clientului-> -> Sales trimite din aplicatie Mail-to-FaxMail catre numarul clientului-> contractul completat este receptionat de client-> clientul semneaza si stampileaza contractul -> clientul inmaneaza contractul in original catre Sales

b.     Clientul nu accepta oferta facuta -> clientul nu accepta conditii contractuale (-> se intra pe flowul 2.2.2 ISS Contracts Team), pretul (Sales se intoarce la Mkt Pricing pentru revizuire oferta-> Mkt Pricing revine cu feedback catre Sales in maxim 3 zile-> Sales prezinta clientului oferta revizuita), solutia tehnica (->Sales DAS introduce datele intr-un nou Presales)

Nota: Aplicatia in care se introduc datele despre client pentru Presales, trebuie sa cuprinda toate datele despre client: voce fixa, date mobile, date fixe

Nota: pentru situatiile in care clientul doreste o banda superioara fata de cea agreata initial, la semnare, Sales va informa clientul ca este posibil sa fie un timp diferit de implementare.

Implementare Sales upload-eaza in cel mai scurt timp (inclusiv de la client) contractul precum si posibile acte aditionale (cod fiscal, certificat de inregistrare fiscale, buletin) in aplicatie -> Aplicatia trimite notificare de verificare Risk Assessment catre Frauda si MA Support -> maximul de depozit identificat ca necesar de Frauda si MA Support este comunicat catre Sales-> Sales comunica clientului eventualul depozitul -> clientul plateste depozit-> trimite confirmarea de plata pentru depozit pe fax catre Sales- > Sales ataseaza in aplicatie confirmarea de plata- > datele despre client (oferta de billing+ solutia tehnica detaliata) ajung in Aplicatia de Instalare tehnica ->

1.caz Radio Releu: SAC instaleaza suport echipamente in maxim 10 wd (pentru locatiile cu repetor, termenul de negociere+instalare este de 30 zile)-> FN implementeaza solutia tehnica in 21 wd-> flowul de instalare se finalizeaza cu notificare de status -> aplicatia trimite in Billing ofertele deja introduse despre client chiar si cu valori personalizate.

Propunere: activitatile de instalare SAC trebuie sa aiba acelasi moment de start cu activitatile de instalare FN

2. caz Breeze: FN instaleaza portul de date in maxim 15 wd-> flowul de instalare se finalizeaza cu notificare de status -> aplicatia trimite in Billing ofertele deja introduse despre client chiar si cu valori personalizate.

3. caz Direct Link: SAC instaleaza suport echipamente in maxim 10 wd (pentru locatiile cu repetor, termenul de negociere+instalare este de 30 zile)-> FN implementeaza solutia tehnica in 21 wd -> flowul de instalare se finalizeaza cu notificare de status-> aplicatia centralizeaza si trimite datele introduse de catre Sales referitoare la tarifele clientului pentru a fi provizionate in Billing sub forma unei singure oferte.

B. Customer Management- Voce

1. MA

1.1Proces de calificare voce:

a.     automat 1 dataluna: DWH califica sau nu contul ca si MA-> un Sales Analist aloca un AM in Amdocs ->DWH populeaza MAS in Clarify-> Clarify trimite zilnic datele in CM-> CM trimite zilnic AM si MAS in Capone-> la fiecare Bill Cycle Colombo aloca Collection Plan conturilor din segmentul de MA numai daca au facturile platite la zi-> Capone Support aloca MAC o data pe luna(la jumatatea lunii calendaristice), printr-un script -> finish; daca nu au facturile platite la zi, Collection notifica Sales ca omul nu are inca alocat un MAC si Coll face followup catre client pana plateste. (Coll are 1 echipa pentru GBM High+MA si 1 echipa pentru GBM Low si Medium)

propunere: Mkt +Coll+Sales trebuie sa agreeze criteriile de calificare

propunere: in momentul in care clientul se califica pentru MA, trebuie sa se faca alocarea concomitenta a AM, MAS, MAC, Coll Plan pe criterii prestabilite in aceeasi aplicatie.

propunere: criteriile de calificare: valoare finala a abonamentului cu discount inclus>500 EUR

propunere: sistemul sa poata calcula valoarea totala finala a abonamentului

b.     manual (in diverse situatii):

i. la o limita prestabilita (pentru activare mai mare de 50 SIMuri):  exista o regula prestabilita cu MA Support Team pentru conturile cu mai mult de 50 SIMuri: Sales trimite contract catre MA Support Team-> In Amdocs se trece Coll Plan- HV-> din Amdocs se provizioneaza automat 1 datazi contul in Clarify-> finish

propunere: existenta sistem automat care sa permita blocarea si deblocarea automata in orice moment a unor conturi pe baza unor criterii prestabilite (valoare estimata, calculata, nr de SIMuri, judet, Sales, cod de dealer etc) pe o perioada configurabila de timp. In momentul in care clientul se califica pentru MA, trebuie sa se faca alocarea concomitenta a AM, MAS, MAC, Coll Plan pe criterii prestabilite in aceeasi aplicatie

ii. la cerere Sales, Cops- MA Team: pentru clienti activi: modificarea in Clarify de catre MA Team sau GBM Team sau Sales Op.

propunere: sistemul sa faca toate modificarile in aplicatiile aferente ariilor: Coll, MA Team

1.2 Proces de Welcome:

owner Sales la intalnirea cu clientul, Sales ii prezinta intreaga echipa VDF: AM, MAS, MA Data Specialist, MAC, DAS, AE (existent)

propunere flow: sistemul trimite notificare cu calificarea conturilor in baza de MA inclusiv catre Sales-> in timp de 2 sapt, clientul va fi contactat telefonic de catre Sales->ajungem la pct 2(pas: trimitere DM catre clienti); ulterior, AMul strange toate datele despre client (intr-o aplicatie care sa centralizeze aceste date- Sales sa poata introduce in SFA datele despre client, MAS sa introduca datele despre client in Amdocs; noua aplicatie sa reconcilieze cele 2 sisteme actuale cu data cea mai recenta, pastrand si istoria)-> Sales viziteaza clientul

owner Mkt: se trimite un Direct Mail -se va implementa in viitor

propunere flow: o aplicatie care sa scoata roparte pe criterii configurabile (ex : conturile calificate in ultima luna sau care au avut schimbari la nivel de AM sau MAS); rapoartele se trimit la feedback catre MA Team si Sales (info+modificari eventuale)-> rapoartele vor ajunge la Data Minning -> personalizare DMurile pentru trimiterea la clienti-> trimitere DM catre clienti

1.3 Actiuni proactive

Actiunile proactive constau in resemnari, vizite, upsell, analiza, oferta.

Owneri Proces Sales, Mkt, Cops MA Team (voce+date), Collection

Sales

a.     vizite pentru intarirea relatiei cu clientul (sunt in prezent inregistrate in SFA ca planificare la nivel de luna- updatata 1 data3 luni si realizare de catre Sales). Propunere: planificare vizitelor sa se faca in fctie de segmentul clientului- input de la Mkt

b.     upsell (proiecte de vanzare): Sales face analiza clientului (il ajuta istoria contului), de dorit cu o implicare cat mai mica a MASului (aplicatia ar trebui sa contina toate datele respective)

c. vizite pentru promovarea produselor si serviciilor noi

d.     vizite pentru sustinerea campaniile impuse de VDF

e. resemnari de contracte si acte aditionale: Sales prezinta oferta noua catre client-> negociere-> daca este cazul, Sales revine catre Pricing cu solicitare pentru o noua oferta-> Mkt Pricing revine catre Sales cu oferta revizuita-> Sales va prezenta si negocia cu clientul aceasta oferta(vezi flow 1)-> resemnare-> implementare . Daca nu se resemneaza, clientul poate ramane activ in continuare pe oferta existenta sau se deconecteaza

f.       campanii de Sarbatori: cadouri trimise catre clienti - trebuie inregistrate aceste cadouri date

Mkt campanii de Direct Mail, MyAccount (newsboard), promotii, produse si servicii (echipamente, extraoptiuni), cadouri, programe (de resemnare, de migrare)

MA Team: apeluri catre clienti (ex: ptr probleme de sistem de care se stie)

Collection actiuni de collection conform timelineuri agreate (apeluri, scrisori, sms)

Frauda

1.4 Actiuni reactive : owner Sales(Direct+Magazine, Dealeri); Cops- MA Team, Collection, CS Business; Service

De discutat flowul de TOR

1.5 Chooseri

2. GBM

Proces de calificare voce:

c.     automat

d.    manual

Proces de Welcome:

owner Sales: la intalnirea cu clientul, Sales ii prezinta intreaga echipa VDF: AM, MAS, MA Data Specialist, MAC, DAS, AE (existent)

owner Mkt: se trimite un Direct Mail -se va implementa in viitor

2.3 Actiuni proactive (resemnari, vizite, upsell, analiza, oferta) : owner Sales, Mkt, Cops MA Team (voce+date), Collection

2.4 Actiuni reactive : owner Sales(Direct+Magazine, Dealeri); Cops- MA Team, Collection, CS Business; Service