På denne side
Kontaktposten er allerede åben, da en salgsmedarbejder finder en dublet. I denne tænkte arbejdsgang kan en automatisering løse det, men medarbejderen skal åbne et særskilt dashboard, søge efter samme kontakt og gå tilbage til CRM-systemet for at kontrollere resultatet. Automatiseringen kan være hurtig; turen rundt om den er det ikke.
Det rejser et produktspørgsmål, som er let at overse, mens automatiseringen designes: Hvor skal resultatet vises?
En optaget samtale om automatisering på arbejdspladsen argumenterer for at handle i de systemer, hvor posterne allerede ligger, frem for at bede alle brugere lære en ny flade. Påstanden er en designhypotese, ikke bevis for at en bestemt løsning øger brugen. Den er nyttig, fordi den gør en færdig opgave til designets enhed i stedet for en skærm.
Følg posten, beslutningen og overdragelsen
Kortlæg én rigtig opgave. Hvor vises posten først? Hvem beslutter, om den er klar? Hvad skal personen undersøge? Hvor kontrolleres det, at ændringen slog igennem? Tæl trinene og de steder, hvor kontekst skal kopieres eller tastes ind igen.
I det tænkte tilfælde med en dobbelt kontakt har medarbejderen allerede kundeposten åben. Et forslag ved siden af posten kunne vise de felter, der ikke stemmer, og den foreslåede sammenlægning. Gennemgangen kan blive tæt på beslutningen. Resultatet kan vises på den opdaterede post. Den vej kan kræve færre trin end et nyt dashboard, selvom dashboardet ser pænere ud i en demo.
- Åbn posteneksisterende arbejdesamme kontekst
- Gennemgå forslagetfelter i konfliktpersonen beslutter
- Godkend ændringenkorrekt omfangslutkontrol
- Kontrollér resultatetopdateret post
Kildesamtalen beskriver også en opdeling mellem trin, der skal fjernes, deterministiske handlinger, vurderinger og menneskelige godkendelser. Placeringen betyder noget forskelligt for hver. En deterministisk opdatering kan køre uden synlig skærm og efterlade en tydelig status. En tvetydig sammenlægning behøver forklaring og et sted at gennemgå den. En handling med konsekvenser kræver godkendelse fra en ansvarlig person, uanset hvor brugerfladen ligger.
Vores guide til at integrere flere forretningsværktøjer beder teams fastlægge den autoritative kilde. Den beslutning hjælper med at placere interaktionen: Postens ejer er ofte det naturlige sted at undersøge og rette den. Det betyder ikke, at alle værktøjer kan vise enhver nødvendig forklaring.
Et resultat i den eksisterende flade kræver stadig et spor
»Ingen ny brugerflade« kan blive et slogan, der skjuler manglende kontroller. Hvis en automatisering ændrer en post i et CRM-system, skal brugerne vide, hvad der ændrede sig, hvorfor, og om det andet system nu er enig. En kort besked om »færdig« er for tynd, hvis opgaven går på tværs af to systemer.
Designet kan kræve en kort status i det værktøj, hvor arbejdet foregår, og en dybere historik et andet sted. De tjener forskellige øjeblikke. Medarbejderen skal handle på den aktuelle post. En administrator kan have brug for at gennemgå fejlede opgaver, tilladelser og mønstre på tværs af konti. Den bedste brugerflade kan derfor bestå af mere end én flade, hver til sin opgave.
Tajo stiller allerede en MCP-aktivitetsressource til rådighed med resultat, fase og rå hændelsesdata, som kan foldes ud. Illustrationen nedenfor placerer ideen i en samtale og tilføjer et foreslået verifikationspanel. Den ansvarlige kan læse resultatet med det samme og undersøge beviserne ved behov. Layoutet dokumenterer ikke kompatibilitet med alle værtsapps.
En afsluttet skrivning kræver stadig bevis
Blev kundesynkroniseringen færdig?
Skrivning anvendt. Verifikation afventer.
Destinationens tilstand er endnu ikke kontrolleret.
Synkroniseringsaktivitet
- Anmodning accepteret
- Opdatering anvendt
- Destinationskontrol afventer
Eksempelkørsel · 14:32 UTC
Det ved vi
- Udbyderens svar
- Accepteret
- Skriveresultat
- Anvendt
- Tilbagelæsning fra destination
- Afventer
Et vellykket kald beviser ikke sluttilstanden.
Foreslået layout inspireret af Tajos aktivitetslog. Illustrationen tilføjer en verifikationstilstand; den påstår ikke, at tilbagelæsning fra destinationen allerede er implementeret.
Et andet tænkt tilfælde: En butikschef vil vide, om en testordre gav den tilsigtede kundeopdatering. Et kort resultat ved ordren kan vise destinationsposten og dens status. En særskilt integrationsoversigt kan vise mappingregler og fejlhistorik. Guiden til Brevo Shopify-integration anbefaler at kontrollere en testkontakt og ordre i destinationen, før synkroniserede data bruges. Brugerfladen bør hjælpe nogen med den kontrol, ikke blot meddele, at en anmodning blev sendt.
Forskellen beskytter mod en kendt fælde. Et værktøj kan være let at åbne og svært at stole på. At vise den endelige tilstand dér, hvor brugeren arbejder, kan være mere værd end at spare et klik på et dashboard. Men hvis den eksisterende app ikke kan vise nok kontekst, kan det gøre opgaven sværere at presse hele beslutningen ind i en lille besked.
Test vejen, ikke præferencen
Vis begge design til en person, der udfører arbejdet: et indlejret forslag og en særskilt side. Giv personen samme tilfælde. Se, om vedkommende finder posten, forstår den foreslåede handling, opdager et forkert forslag og bekræfter resultatet. Tæl overdragelser og forkerte antagelser, ikke kun sekunder.
Hold beføjelse adskilt fra bekvemmelighed. En knap ved siden af posten skal stadig overholde brugerens tilladelser og arbejdsgangens godkendelsesregler. Artiklen om at lade fagpersoner forme automatiseringen forklarer, hvorfor de, der kender undtagelserne, bør definere dem, mens systemet håndhæver adgang og datakontrakter.
Der er gode grunde til en ny skærm: undersøgelse på tværs af systemer, opsætning, samlet gennemgang og revision kan overstige det, et CRM- eller butikssystem kan vise. Det rigtige spørgsmål er, om skærmen hjælper folk med at afslutte den opgave, de skal forlade deres øvrige arbejde for.
Når du tester designet, så tag den, der håndterer undtagelser, med, ikke kun den, der gennemfører normalforløbet. En kompakt handling på posten kan være ideel til rutiner, men efterlade den ansvarlige for undtagelser uden den historik, der kræves for at beslutte. Brugerfladen skal gøre overdragelsen synlig, samtidig med at normalforløbet er kort.
En brugerflade fortjener sin plads, når den bærer en nødvendig beslutning eller et bevis. Hvis arbejdet kan færdiggøres og kontrolleres dér, hvor det begyndte, er en ny skærm en omvej.
Ofte Stillede Spørgsmål
Skal hver automatisering have sit eget dashboard?
Nej. Spørg først, hvor brugeren opdager problemet og træffer beslutningen. En eksisterende post, besked eller gennemgangskø kan være et mere direkte sted at vise resultatet.
Hvornår er en særskilt brugerflade nyttig?
Brug den, når folk skal undersøge på tværs af systemer, konfigurere, føre tilsyn eller se historik, som det eksisterende værktøj ikke kan vise tydeligt. Mål de nye trin, den tilføjer.
Fjerner et resultat i et andet værktøj behovet for kontroller?
Nej. Adgang, gennemgang, revisionsspor og fejlhåndtering kræver stadig et tydeligt design. Placeringen af en knap giver ikke beføjelse til at ændre en post.