Siden jeg har hjulpet med å opprette hundrevis av OneDesk-kontoer nå, blir jeg ofte spurt av kunder og andre medlemmer av teamet vårt, hva er noen ‘beste fremgangsmåter’ som bør følges for å sikre kundesuksess. Siden jeg alltid er glad for å dele min visdom 🙂 Jeg tenkte at det kunne være nyttig å skrive opp et blogginnlegg som dekker noen leksjoner.
1) Å importere en liste med kunder er ofte unødvendig
OneDesk støtter muligheten til å importere kundelisten din samt eksisterende billetter. Hvis du vil gjøre dette, fortsett, men her er to hensyn.
– OneDesk oppretter automatisk kundeoppføringer for deg når den mottar en e-post fra en ny e-postadresse. Dette betyr at du bare kan la kundens poster samle seg når kundene dine sender inn billetter.
– Hvis du planlegger å importere eksisterende billetter, må du importere kundene dine FØRST. Dette er fordi når importprosessen oppretter en billett, kan den koble den til en eksisterende kundepost (så lenge e-postadressen til rekvirenten er i en kolonne i billettfilen).
2) Ikke gjør en oppgave når en arbeidsflytstatus er tilstrekkelig
Denne anbefalingen avhenger av situasjonen, men når du har en serie trinn som en oppgave må gjennomgå, og disse trinnene er gjensidig utelukkende, er en status veien å gå. Noen ganger er det fristelse til å lage en liste over oppgaver som i stedet kan representeres som en enkelt oppgave med forskjellige statuser. Noe å tenke på.
3) Gi brukerne det høyeste nivået av prosjektillatelser du kan.
OneDesk gir deg noen ganske kraftige tillatelseskontroller både på organisasjonsnivå og på prosjektnivå. Dette er fordi en bruker kan få lov til å gjøre visse ting i ett prosjekt, men ikke i et annet. Imidlertid anbefaler jeg at du for tillatelser på prosjektnivå gir alle det høyeste nivået du er komfortabel med (Dette betyr ‘prosjektleder’ eller ‘prosjektleder’). Hvis du ikke er forberedt på å stille spørsmål fra brukerne om hvorfor ikke kan gjøre noe, og bruke tid på å endre individuelle tillatelser i individuelle prosjekter.
5) Bruk typer med omhu
Når brukere oppdager det fantastiske typesystemet vårt, blir de ofte nøtter og lager typer artikler og prosjekter for alle sakene. Dette er sannsynligvis ikke den beste tilnærmingen.
– Du bør bare opprette en ny varetype når du trenger en annen arbeidsflyt. For eksempel, hvis et “problem” går grundig med andre trinn enn en “oppgave”, må du i det hele tatt opprette en ny varetype. Men hvis begge går gjennom de samme trinnene, legger du til kompleksitet bare for å ha et annet ikon.
– Å ha forskjellige typer prosjekter er som oftest unødvendig. Å ha forskjellige typer porteføljer nesten alltid unødvendig. Ovennevnte regel for artikler gjelder også for prosjekter og porteføljer, men med de ekstra punktene at prosjekter er enda mindre sannsynlig å ha forskjellige arbeidsflyter, og porteføljer ikke engang har arbeidsflytfunksjoner.