Eftersom jag har hjälpt till att skapa hundratals OneDesk -konton nu, blir jag ofta frågad av kunder och andra i vårt team, vilka är några “bästa metoder” som bör följas för att säkerställa kundens framgång. Eftersom jag alltid är glad att dela med mig av min visdom 🙂 Jag tänkte att det kan vara användbart att skriva ett blogginlägg som täcker några lärdomar.

1) Importera en kundlista är ofta onödigt
OneDesk stöder möjligheten att importera din kundlista samt dina befintliga biljetter. Om du vill göra detta, fortsätt, men här är två överväganden.
– OneDesk skapar automatiskt kundposter åt dig när det tar emot ett e -postmeddelande från en ny e -postadress. Det betyder att du bara kan låta kundrekorden samlas när dina kunder skickar in biljetter.
– Om du planerar att importera befintliga biljetter, se till att du importerar dina kunder FÖRSTA. Detta beror på att när importprocessen skapar en biljett kan den länka den till en befintlig kundpost (så länge som begärarens e-postadress finns i en kolumn i biljettfilen).

2) Gör inte en uppgift när en arbetsflödesstatus räcker
Denna rekommendation beror på situationen, men när du har en serie steg som en uppgift måste gå igenom och de stegen utesluter varandra, är en status vägen att gå. Ibland finns det en frestelse att skapa en lista med uppgifter som istället kan representeras som en enda uppgift med olika status. Något att tänka på.

3) Ge dina användare den högsta nivån av projektbehörigheter som du kan.
OneDesk ger dig några ganska kraftfulla behörighetskontroller både på organisationsnivå och på projektnivå. Detta beror på att en användare kan tillåtas att göra vissa saker i ett projekt, men inte i ett annat. Men jag rekommenderar att du för projektnivåbehörigheter ger alla den högsta nivån du är bekväm med (Detta betyder “projektledare” eller “projektledare”). Om du inte är beredd att ställa frågor från dina användare om varför du inte kan göra något och spendera tid på att ändra individuella behörigheter i enskilda projekt.

5) Använd typer klokt
När användare upptäcker vårt fantastiska typsystem blir de ofta tokiga och skapar typer av objekt och projekt för alla deras fall. Detta är förmodligen inte det bästa tillvägagångssättet.
– Du bör bara skapa en ny artikeltyp när du behöver ett annat arbetsflöde. Till exempel, om ett “problem” går igenom grundläggande andra steg än en “uppgift”, skapar du för all del en ny artikeltyp. Men om båda går igenom samma steg, lägger du till komplexitet bara för att ha en annan ikon.
– Att ha olika typer av projekt är vanligtvis onödigt. Med olika typer av portföljer nästan alltid onödigt. Ovanstående regel för artiklar gäller också projekt och portföljer, men med de extra punkterna är det ännu mindre troligt att projekt har olika arbetsflöden, och portföljer har inte ens arbetsflödesfunktioner.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>