Domeniul de aplicare al portalului pentru clienți
Ce aparţine domeniului de aplicare al unui portal pentru clienţi?
Defineste un portal al clientilor prin roluri, inregistrari, decizii si fluxuri complete de lucru. Intelege cerintele care ii schimba domeniul de dezvoltare.
Un portal poate arăta simplu din exterior: o pagină de sign-in, un tablou de bord și câteva forme. Domeniul său de aplicare depinde de ceea ce aceste ecrane lasă oamenii să facă și ce se întâmplă cu informațiile după aceea.
Pentru a defini un nou portal, lucrați prin călătoria clientului și responsabilitățile personalului din spatele acestuia. Ecranul contează singur dor de o mare parte din aplicația reală.
Începeți cu motivul clientului pentru a reveni
Un portal util are un scop repetat. Un client ar putea verifica o cerere, prelua un document sau completa o acțiune necesară. Decide care scop contează mai întâi.
Apoi identificați înregistrarea care poartă acest scop. Dacă portalul este despre cererile de servicii, defini cererea și statele sale. Un tablou de bord devine mai ușor de proiectat odată ce știți ce înregistrări ar trebui să explice.
Separă rolurile
Un client poate avea nevoie pentru a vedea propriile înregistrări. Un membru al personalului poate avea nevoie pentru a vedea munca atribuită. Un administrator poate controla utilizatorii și configurarea. Acestea sunt responsabilități diferite, nu pur și simplu etichete meniu diferite.
Domeniul de aplicare trebuie să stabilească norme de acces și modul în care conturile devin autorizate. Să analizeze dacă un cont reprezintă o persoană, o societate sau un grup cu mai mulți utilizatori. Această decizie poate schimba modul în care sunt organizate înregistrările și permisiunile.
Pentru prima versiune, include rolurile care sunt necesare. Nu adăugați un editor permisiuni elaborate decât dacă cineva are un motiv definit să-l folosească.
Urmați o înregistrare prin întregul proces
Acceptă o cerere de servicii ilustrative. Clientul îl creează, personalul îl examinează, sunt solicitate informații lipsă și se înregistrează o decizie sau un statut de finalizare.
La fiecare pas, întrebați cine poate acționa, ce informații sunt necesare și ce vede următoarea persoană. Poate fi editată o cerere după depunere? Poate fi retrasă? Are nevoie un revizor de un motiv de respingere?
Aceste intrebari apartin domeniului de aplicare deoarece schimba comportamentul aplicatiei. Acestea nu trebuie tratate ca mici detalii vizuale pentru a rezolva dupa dezvoltare.
Decide cum sunt comunicate actualizările
O schimbare de stare poate apărea pe tabloul de bord, declanșa un e-mail sau necesită o acțiune din partea clientului. Acestea sunt caracteristici distincte. O notificare are nevoie de un eveniment definit, destinatar și mesaj, precum și o decizie cu privire la ceea ce informațiile nu ar trebui să apară în acesta.
Puteți păstra proiectul de notificare inițială limitată. O stare clară în cerere și un e-mail necesar poate fi mai potrivit decât notificări promițătoare pentru fiecare schimbare. Alegerea corespunzătoare depinde de fluxul de lucru.
Tratează documentele ca un flux de lucru propriu
Un buton de upload ridică întrebări despre tipuri de fișiere, dimensiune, proprietate, vizibilitate, revizuire și eliminare. Dacă un document are nevoie de aprobare, fișierul și decizia au nevoie de o relație pe care utilizatorul o poate înțelege.
Începeți cu documentele de care are nevoie fluxul de lucru principal. Partajarea publică, semnarea electronică și versiunea complexă a documentelor sunt cerințe separate, nu consecințe automate de adăugare a upload-urilor.
Fiţi atenţi la alte sisteme
O conexiune la facturare, o CRM sau o alta aplicatie are nevoie de o regula definita de inregistrare si actualizare. Portalul afiseaza informatii, creand-o sau schimband-o? Cat de curenta trebuie sa fie?
O primă versiune poate utiliza un proces manual convenit, dacă este cazul. Lucrul important este de a face această alegere vizibilă mai degrabă decât să descrie portalul ca fiind complet integrat atunci când un pas încă depinde de o persoană.
Descrieți testul de acceptare
Pentru un flux de lucru de bază cerere, un test ar putea verifica dacă un client poate crea o cerere, nu poate accesa dosarul unui alt client, vede o actualizare a personalului și primește notificarea convenită. Personalul trebuie să fie capabil să se ocupe de informații incomplete fără a pierde înregistrarea.
Acest exemplu nu prescrie funcţionalitatea fiecărui portal. Acesta arată modul în care un flux de lucru complet poate fi verificat din ambele părţi.
Ce tinde să extindă proiectul?
Mai multe tipuri de utilizatori, mai multe organizații pe cont, plăți, mesaje în timp real, integrări bidirecționale și rapoarte complexe introduc decizii suplimentare. Fiecare dintre acestea poate fi justificată, dar fiecare are nevoie de propriul său rol pe scurt.
Cea mai utilă conversație bugetară începe cu primul flux de lucru complet și dependențele de care are nevoie cu adevărat. O listă atractivă de caracteristici nu este încă un domeniu de aplicare de livrare.
Explorează dezvoltarea aplicației web personalizate sau Discută despre portalul tău..