Sjekkliste for arbeidsflyt med delt Front-innboks for små team
En felles innboks bør gjøre ansvaret tydelig. Hvis teamet ditt vurderer en felles innboks på tvers av frontkanaler, bør du begynne med arbeidet som skjer etter at en melding kommer inn. Kanaler er viktige, men eierskap, overleveringer, svar kvalitet og rapportering avgjør om innboksen forblir håndterbar.
Denne sjekklisten hjelper deg med å dokumentere behovene før du konfigurerer et verktøy eller sammenligner alternativer. Den fokuserer på driftsbeslutninger, ikke antall funksjoner.
Kartlegg samtalene som kommer inn i innboksen
List opp alle stedene der kunder kontakter teamet ditt. Skill mellom support-e-post, salg, fakturering, returer og generelle spørsmål. Noter deretter hvilke samtaler som må inn i samme kø, og hvilke som bør holdes adskilt.
Ifølge Fronts dokumentasjon for felles innboks kan en felles Front-innboks motta e-post, Instagram- eller SMS-kanaler, eller fungere som en tom organisatorisk innboks. Det gjør kanalomfang til en tidlig beslutning. Et team som trenger flere kommunikasjonskanaler i ett samarbeidsområde, kan ha nytte av denne modellen. Et team der supportarbeidet starter i Gmail eller Microsoft 365, kan være mer opptatt av synkronisering av postkasser og billettkontroller.
Registrer følgende for hver kanal:
- Hvem som har ansvar for det første svaret
- Hvilke meldinger som krever en spesialist
- Hvilken informasjon som bør forbli privat for teamet
- Når en samtale regnes som løst
- Hvilke meldinger som aldri skal inn i supportkøen
Denne kartleggingen hindrer en vanlig feil: å bygge én stor innboks uten regler for hvem som håndterer hva.
Definer eierskap før du legger til automatisering
Alle åpne samtaler bør ha en tydelig neste ansvarlig. Skriv en enkel policy for nye oppgaver, omfordeling, fravær og eskalering. Bestem om eierskapet skal ligge hos en individuell User, en gruppe eller en roterende kø.
Fronts dokumentasjon for samtalearbeidsflyt beskriver samtaleeierskap, kommentarer kun for teamet, omtaler, regler og aktivitetsrapporter. Bruk disse funksjonene som utgangspunkt for driftsrelaterte spørsmål. Hvem tildeler nye samtaler? Kan noen ta direkte eierskap? Når bør en kommentar erstatte en videresendt e-post? Hvilke hendelser bør utløse et varsel?
En fungerende policy for eierskap kan være kort:
- Send hver ny samtale til gruppen som har ansvar for emnet.
- Tildel én User før arbeidet begynner.
- Bruk et internt notat for kontekst som kunden ikke skal se.
- Overfør ansvaret med en tydelig begrunnelse når en annen User må handle.
- Lukk samtalen først når den lovede handlingen er fullført.
Test policyen med eksempler fra virkeligheten. Ta med en hasteforespørsel, en uklar forespørsel, en duplikat og en melding som tilhører et annet team. Hvis det er uklart hvem som har ansvaret i noen av eksemplene, må du justere policyen før du automatiserer den.
Velg et minimum av rutingsregler
Automatisering bør fjerne forutsigbart sorteringsarbeid. Den bør ikke skjule uklare beslutninger. Begynn med betingelser teamet kan forklare, for eksempel mottakeradresse, avsenderens domene, emne, meldingstekst eller språk. Velg deretter en synlig handling, for eksempel å tildele en gruppe, bruke en tagg eller angi en prioritet.
Skriv hver regel i et enkelt språk. Legg til forventet resultat og et unntak. Et nøkkelord knyttet til fakturering kan for eksempel sende en melding til økonomiavdelingen, men en forespørsel om tilbakebetaling kan fortsatt kreve at support har eierskapet. Gå gjennom feiltreff etter lansering, og fjern regler som sparer lite tid.
Behold en manuell reservekø. Noen bør kontrollere samtaler som ikke samsvarer med noen regel, og teamet bør vite hvordan en feilruting korrigeres. Et lite regelsett som folk stoler på, er mer nyttig enn et stort regelsett ingen kan forklare.
Fastsett grenser for samarbeid
Delt tilgang skaper ikke automatisk godt samarbeid. Bestem hva som hører hjemme i et internt notat, hva som hører hjemme i et kundesvar, og når en omtale er nødvendig. Bruk notater til å bevare kontekst, beslutninger og lovet oppfølging. Unngå å bruke dem som et ekstra chatsystem.
Definer også hvordan teamet håndterer duplikatsamtaler. En kunde kan sende samme sak til to adresser eller svare fra en annen tråd. Policyen bør angi om duplikaten skal slås sammen, kobles eller lukkes, og hvor det endelige kundesvaret skal sendes fra.
Hvis du vil se nærmere på kontroller med postkassen som utgangspunkt, for eksempel tildeling, grupper, statuser, prioriteter, tagger, notater, omtaler, videresending og sammenslåing, kan du lese om Deskheroes funksjoner for felles innboks og saksbehandling.
Mål arbeidsflyten, ikke aktiviteten i innboksen
Velg et lite antall målinger som er knyttet til kundeutfall. Nyttige utgangspunkter er innkommende volum, tid til første svar, tid til løsning, gjenåpnede samtaler og arbeid fordelt på emne. Definer åpningstidene som ligger til grunn for alle tidsbaserte målinger, slik at teamet tolker dem konsekvent.
Gå gjennom et utvalg samtaler sammen med tallene. Et raskere førstesvar er ikke nyttig hvis det fører til mer oppfølging. Et lavere antall åpne saker kan skjule for tidlige avslutninger. Knytt hver måling til en kvalitetskontroll og en beslutning teamet skal ta når målingen endrer seg.
Planlegg en postkasseovergang med lav risiko
Ikke behandle et verktøybytte som én enkelt lanseringshendelse. Velg en startdato for nye samtaler, definer hva som skal skje med gamle tråder, og tildel en User til å se etter manglende eller dupliserte meldinger. Behold en skriftlig plan for tilbakeføring til teamet har bekreftet at sending, mottak, tildeling og varsler fungerer som forventet.
Hvis teamet ditt vurderer en helpdesk med postkassen som utgangspunkt, kan Deskhero koble til Gmail eller Microsoft 365, slik at innkommende e-post blir til saker og svar sendes fra den eksisterende adressen din. Users kan arbeide med tildeling, grupper, statuser, prioriteter, tagger, interne notater, omtaler, varsler, videresending og sammenslåing. Se de praktiske avveiningene på siden om Front-alternativet for små supportteam med felles innboks.
Kjør en pilot med et representativt utvalg samtaler. Test en ny forespørsel, et svar på en eksisterende tråd, et vedlegg, en intern overlevering, en duplikat og en melding utenom åpningstid. Registrer forventet resultat før hver test. Hvis resultatet avviker, må du avgjøre om arbeidsflyten eller konfigurasjonen bør endres.
Bruk sjekklisten til en endelig beslutning
Før du velger eller konfigurerer en felles innboks, må du bekrefte at teamet kan svare på disse spørsmålene:
- Hvilke kanaler og adresser hører hjemme i hver innboks?
- Hvem har ansvaret for en ny samtale, og hvordan endres eierskapet?
- Hvilken kontekst skal forbli intern?
- Hvilke rutingsregler er forutsigbare nok til å automatiseres?
- Hvordan håndteres duplikater og eskaleringer?
- Hvilke målinger viser kundeutfall?
- Hvordan skal teamet teste og overvåke en overgang?
Den riktige felles innboksen er den som støtter en tydelig driftsmodell. Dokumenter modellen først, og sammenlign deretter hvordan hvert produkt håndterer den. Slik blir en bred funksjonssammenligning til en beslutning teamet kan teste.