Klientu portāla izstrāde: ko iekļaut pirmajā versijā

1. Kad klientiem patiešām vajadzīgs portāls

Portāls ir noderīgs, ja klienti regulāri atgriežas pie pasūtījumiem, dokumentiem vai pieteikumiem. Saskaitiet atkārtotus jautājumus atbalstam: “Kāds ir statuss?”, “Kur ir rēķins?”, “Kā pievienot dokumentu?”. Ja informācija sistēmā jau ir, bet pieejama tikai ar darbinieka starpniecību, rodas konkrēts pašapkalpošanās uzdevums.

Vienreizējam pirkumam vai retam pieprasījumam var pietikt ar skaidru formu un paziņojumiem. Obligāta reģistrācija rada papildu darbu klientam, tāpēc tai jāsniedz vērtība. Pirms individuālas izstrādes pārbaudiet esošās CRM vai nozares platformas klientu moduli — iespējams, tas sedz galveno scenāriju.

2. Veidojiet MVP ap vienu pabeigtu scenāriju

MVP ir minimāla versija produkta lietderības pārbaudei. Pakalpojumu uzņēmumam tas var būt ceļš: pieslēgties → atrast pieteikumu → saprast statusu → pievienot trūkstošo dokumentu. Tas ir vērtīgāk par nesaistītām sadaļām ar tukšu analītiku un nepabeigtiem paziņojumiem.

Ilustratīvs piemērs, nevis klienta projekts: uzņēmums apkalpo vairāku organizāciju iekārtas. Pirmajā versijā klients redz savas organizācijas pieteikumus, nākamās darbības datumu un saskaņotos dokumentus. Darbinieks maina statusu darba sistēmā, portāls to attēlo. Čats, lojalitātes programma un atsevišķa mobilā lietotne paliek ārpus pilotprojekta.

3. Nosakiet lomas un piekļuves robežas

B2B portālā cilvēka konts un organizācija ir atšķirīgas vienības. Vienā organizācijā var būt vairāki darbinieki: viens skatās pieteikumus, otrs augšupielādē dokumentus, trešais pārvalda piekļuves. Pirms izstrādes izveidojiet matricu “loma → darbība → objekts” un aprakstiet uzaicināšanu, darba attiecību izbeigšanu un pāreju uz citu organizāciju.

OWASP norāda uz objektu līmeņa piekļuves pārbaužu trūkumu kā API risku. Tiesības serverī jāpārbauda katram pieteikumam vai dokumentam; paslēpta poga vai grūti uzminams identifikators to neaizstāj.

Praktisks tests: organizācijas A lietotājs pieprasa organizācijas B pieteikumu, mainot identifikatoru. Serveris nedrīkst atdot svešus datus. Pārbaudiet arī failu lejupielādi, eksportu un vecas saites pēc piekļuves atsaukšanas. Tās ir parastas pieņemšanas pārbaudes.

OWASP: piekļuves pārbaude API objektu līmenī ↗

4. Katram laukam nosakiet galveno datu avotu

Pasūtījuma statuss var būt CRM, dokumenti — failu glabātuvē, lietotāja profils — portāla datubāzē. Katram laukam nosakiet, kur to maina un kā izmaiņas nonāk portālā. Ja vienus datus var mainīt gan klients, gan darbinieks, vajadzīgs konfliktu risināšanas noteikums.

Vienojieties par pieļaujamo atjaunošanas aizkavi. Dažiem statusiem pietiek ar periodisku sinhronizāciju, citiem vajag notikumu paziņojumus. Ārējas sistēmas kļūmes laikā saskarnei jāatšķir datu neesamība no ielādes kļūdas un vajadzības gadījumā jārāda pēdējās atjaunošanas laiks.

5. Kas nosaka izstrādes izmaksas un termiņus

Izmaksas vairāk nosaka noteikumi aiz ekrāniem, nevis to skaits. Viena dokumentu lapa var prasīt tiesību pārvaldību, versiju vēsturi, failu pārbaudi un ārēju glabātuves integrāciju. Vairākas informatīvas lapas bez šīm prasībām var būt vienkāršākas.

Lai salīdzinātu izstrādātāju piedāvājumus, dodiet visiem vienādu apjomu: scenārijus, lomas, sistēmas, datu struktūru un pieņemšanas kritērijus. Lūdziet atsevišķi izskaidrot izstrādi, datu pārcelšanu, infrastruktūru, uzturēšanu un pieņēmumus. Neskaidras API iespējas vispirms pārbaudiet nelielā tehniskā izpētē.

• ✓Lietotāju, organizāciju un lomu saraksts.
• ✓Galvenais scenārijs un skaidri atliktās funkcijas.
• ✓Datu avoti, API dokumentācija un testa piekļuves.
• ✓Failu, darbību vēstures un paziņojumu prasības.
• ✓Palaišanas, atbalsta, rezerves kopiju un atjaunošanas plāns.

6. Pārbaudiet lietderību ar nelielu klientu grupu

Uzaiciniet pilotprojektā klientus ar reāliem atkārtotiem uzdevumiem. Lūdziet bez palīdzības pieņemt uzaicinājumu, pieslēgties, atrast pieteikumu un dokumentu. Novērojiet grūtības, tostarp kļūdu ziņojumus, tukšus sarakstus un lietošanu telefonā.

Mēriet klientu īpatsvaru, kuri pabeidz lietderīgu darbību, jautājumu skaitu par statusiem un papildu slodzi darbiniekiem. Reģistrāciju skaits pats par sevi neparāda ieguvumu. Salīdziniet līdzīgas klientu grupas un periodus; sezonālu jautājumu samazinājumu nevar pilnībā piedēvēt portālam.

Pirms auditorijas paplašināšanas pārbaudiet piekļuves atjaunošanu, organizāciju tiesības, integrāciju kļūmes un atjaunošanu no rezerves kopijas. Nododiet komandai atbalsta instrukciju un nosakiet produkta atbildīgo, kas lems par turpmākajām funkcijām.