Asiakasportaalin soveltamisala
Mikä kuuluu asiakasportaalin soveltamisalaan?
Määrittele asiakasportaali rooleissa, rekistereissä, päätöksissä ja työnkulussa. Ymmärrä vaatimukset, jotka muuttavat sen kehitysalaa.
Portaali voi näyttää yksinkertaiselta ulkopuolelta: sisäänkirjautumissivu, kojelauta ja muutama muoto. Portaalin laajuus riippuu siitä, mitä näytöt antavat ihmisten tehdä ja mitä tiedolle tapahtuu jälkikäteen.
Määritellä uuden portaalin, työskennellä läpi asiakasmatkan ja henkilöstön vastuu sen takana. Näytöllä lasketaan yksin jättää paljon varsinaisen sovelluksen.
Aloita asiakkaan syystä palata
Hyödyllisellä portaalilla on toistuva tarkoitus. Asiakas voi tarkistaa pyynnön, hakea asiakirjan tai suorittaa tarvittavat toimet. Päätä, mikä tarkoitus on ensin.
Jos portaalissa on kyse palvelupyynnöistä, määrittele pyyntö ja sen tilat. Kojelautaa on helpompi suunnitella, kun tiedät, mitä tiedostoja sen pitäisi selittää.
Erota roolit
Asiakas saattaa joutua näkemään omat tietonsa. Henkilökunnan jäsen saattaa joutua näkemään määrätyn työn. Hallinnoija voi valvoa käyttäjiä ja konfiguraatiota. Vastuut ovat erilaisia, eivät vain erilaisia valikon merkkejä.
Soveltamisalassa on vahvistettava käyttösäännöt ja miten tilit hyväksytään. Mieti, edustaako tili henkilöä, yritystä tai ryhmää, jolla on useita käyttäjiä. Tämä päätös voi muuttaa kirjanpitojen ja lupien organisointia.
Ensimmäinen versio, sisältää roolit, jotka ovat tarpeen. Älä lisää yksityiskohtaisia käyttölupia editori, ellei joku on määritelty syy käyttää sitä.
Seuraa yhtä tietuetta koko prosessin ajan
Ota visuaalinen palvelupyyntö. Asiakas luo sen, henkilöstö tarkistaa sen, puuttuvat tiedot pyydetään ja päätös tai valmistumistila kirjataan.
Kysy jokaisessa vaiheessa, kuka voi toimia, mitä tietoja tarvitaan ja mitä seuraava henkilö näkee. Voiko pyyntöä muokata jättämisen jälkeen? Voiko se peruuttaa? Tarvitseeko arvostelija syyn hylkäämiseen?
Nämä kysymykset kuuluvat soveltamisalaan, koska ne muuttavat sovelluskäyttäytymistä. Niitä ei pitäisi käsitellä pieninä visuaalisina yksityiskohtina, jotka ratkaistaisiin kehityksen jälkeen.
Päätä, miten päivitykset toimitetaan
Kojelaudalla voi näkyä tilan muutos, käynnistää sähköpostin tai vaatia toimintaa asiakkaalta. Ne ovat erillisiä ominaisuuksia. Ilmoituksessa tarvitaan määritelty tapahtuma, vastaanottaja ja viesti sekä päätös siitä, mitä tietoja ei pitäisi näkyä siinä.
Voit pitää alkuperäisen ilmoituksen suunnittelun rajoitettuna. Selkeä sovelluksen tila ja yksi tarvittava sähköposti voivat olla sopivampia kuin lupaavat ilmoitukset jokaisesta muutoksesta. Sopiva valinta riippuu työnkulusta.
Käsitellään asiakirjoja omana työnkulkuna
Lataa-painike herättää kysymyksiä tiedostotyypeistä, koosta, omistajuudesta, näkyvyydestä, uudelleentarkastelusta ja poistamisesta. Jos asiakirja tarvitsee hyväksynnän, tiedosto ja päätös tarvitsevat suhteen, jonka käyttäjä voi ymmärtää.
Aloita dokumenteista, joita suurin työnkulku itse asiassa edellyttää. Julkisuus, sähköinen allekirjoitus ja monimutkainen dokumenttien versiointi ovat erillisiä vaatimuksia, ei automaattisia seurauksia lisäämällä latauksia.
Ole tarkka muista järjestelmistä
Liitäntä laskutukseen, CRM-sovellukseen tai muuhun sovellukseen tarvitsee määritellyn tietue- ja päivityssäännön. Näytetäänkö portaalissa tietoja, luodaanko se vai muutetaanko sitä?
Ensimmäinen versio voi käyttää sovittua manuaalista prosessia tarvittaessa. Tärkeintä on tehdä tämä valinta näkyväksi eikä kuvata portaalia täysin integroiduksi, kun askel on vielä riippuvainen henkilöstä.
Kuvaile hyväksymistestiä
Jotta peruspyyntö työnkulkua, testi voi tarkistaa, että asiakas voi luoda pyynnön, ei voi tutustua toisen asiakkaan tietueeseen, näkee henkilöstön päivittää ja vastaanottaa sovitun ilmoituksen. Henkilökunnan täytyy pystyä käsittelemään epätäydellisiä tietoja menettämättä tietuetta.
Tämä esimerkki ei määrää jokaisen portaalin toiminnallisuutta. Se osoittaa, miten täydellinen työnkulku voidaan tarkistaa molemmilta puolilta.
Mikä laajentaa projektia?
Lisää käyttäjätyyppejä, useita organisaatioita per tili, maksut, reaaliaikainen viestintä, kaksisuuntaiset integraatiot ja monimutkainen raportointi tuovat lisäpäätöksiä. Jokainen voi olla perusteltua, mutta jokainen tarvitsee oman tehtävänsä lyhyesti.
Hyödyllisin budjettikeskustelu alkaa ensimmäisestä täydellisestä työnkulusta ja riippuvuuksista, joita se aidosti tarvitsee. Houkuttelevien ominaisuuksien luettelo ei ole vielä toimituksen laajuus.
Tutustu web-sovellusten kehittämiseen tai keskustele portaalistasi.

