Ett Zendesk-ärende anländer med det Microsoft Dynamics 365 F&O-konto som det kopplades till, så en agent öppnar svaret redan med vetskap om vem som frågar och vad de för närvarande har på beställning.
Ett Zendesk-ärende kommer från en e-postadress. Den adressen kan tillhöra en kund med fyra öppna beställningar, eller någon på ett företag som ingen har hört talas om, eller en person som använder en personlig adress för ett företagskonto, och agenten spenderar de första minuterna av varje ärende med att lista ut vilket. Under tiden väntar kunden på ett svar på en fråga om en leverans. Genom att ansluta Microsoft Dynamics 365 F&O och Zendesk kopplas beställaren till ett konto där det kan lösas, och säger det tydligt där det inte kan, så agenten utgår från det som är känt.

Ett Zendesk-ärende innehåller det Microsoft Dynamics 365 F&O-konto som det kopplades till, så en agent öppnar ett svar med kundens öppna ordrar framför sig istället för ett namn.
Leveransdatum anges med ärendet, så den vanligaste frågan av alla besvaras från själva ärendet istället för att skickas till någon med tillgång till ERP-systemet.
En begärare som löser inställningen att inget konto finns markerad som just det, så en agent vet att de har att göra med en okänd avsändare snarare än att anta att informationen är försenad.
Eftersom kontext följer med ärendet, överförs färre samtal mellan agenter, vilket är där en svarstid faktiskt går förlorad snarare än att svaret skrivs in.
När ett Zendesk-ärende skapas kopplar Alumio beställaren till ett Microsoft Dynamics 365 F&O-konto där det går, och skriver de öppna ordrarna och leveransdatumen på ärendet, så att agenten börjar svara redan informerad.
En fråga om en leverans besvaras från de datum som redan finns på ärendet, så agenten öppnar inte ERP-systemet eller vidarebefordrar konversationen till en kollega som kan, vilket är där den största delen av fördröjningen i ett svar faktiskt uppstår.
Om en e-postadress inte matchar något Microsoft Dynamics 365 F&O-konto, anges det i ärendet istället för att det anländer tomt, så agenten behandlar det som en okänd avsändare istället för att vänta på kontext som aldrig kommer.
Alumio fungerar som en central integrationsplattform mellan försäljningskanaler och logistiksystem. Order dirigeras, transformeras och valideras, samtidigt som statusuppdateringar skickas tillbaka till varje kanal.
Autentisera dina system med Alumios färdiga kopplingar. Välj bland över 200 kopplingspaket i vår marketplace, utöver obegränsade anpassade integrationer.
Definiera hur datafält mappas mellan system i ett visuellt gränssnitt. Justera format, berika poster och tillämpa affärslogik – helt utan behov av anpassad kod.
Konfigurera flöden så att de körs i realtid baserat på händelser, enligt ett schema eller både och. Minska manuell datainmatning och låt Alumio hantera förflyttning och transformering mellan system.
När din första integration är live, ansluter du enkelt ditt ERP, PIM, WMS eller CRM till samma hubb. Befintliga flöden fortsätter att köras. Ingen ombyggnad från grunden krävs.
Det agenten fortfarande måste leta upp någon annanstans är den ärliga guiden, och efter beställningar är det oftast själva maskinen. En enhets- eller tillgångsregistreringspost är det vanliga tillägget, eftersom Microsoft Dynamics 365 F&O vet vad som såldes och registreringen vet vad kunden faktiskt har installerat, vilket inte alltid är detsamma. Alumio har båda anslutningarna, så en Zendesk-biljett innehåller båda.
Det är ärendets kontext som skrivs, och upplösningen till ett konto är det som gör det möjligt. Alumio läser Zendesk-förfrågan, kopplar den till ett Microsoft Dynamics 365 F&O-konto enligt den regel du anger och skriver de öppna ordrarna, datumen och fakturapositionen till ärendet. Där det resulterar i ingenting skrivs det också enligt det schema du väljer.
Nej, och agenten är den användare som detta är byggt för snarare än integratören. Vilka Microsoft Dynamics 365 F&O-fält som visas på ett Zendesk-ärende, hur en begärande part matchas och hur en misslyckad matchning ser ut är inställningar i Alumios gränssnitt. Om ett företag identifierar kunder med något annat än en adress tar Code Transformer den matchningsregeln.
Ofta ingen du kan vara säker på, och att säga det är mer användbart än att gissa. Ett Zendesk-ärende skapas av en e-postadress, och en adress kopplas bara till ett Microsoft Dynamics 365 F&O-konto om någon har registrerat den där, så en personlig adress, en ny kontakt eller en delad postlåda kan resultera i ingenting alls. Att matcha där det är möjligt och markera resten är det som hindrar en agent från att lita på ett tomt fält.
Aviseringen går till både agenten och integratören, eftersom personen som blockeras av detta svarar en kund. Alumio märker felet när det inträffar och registrerar varje ärende hos det Microsoft Dynamics 365 F&O-konto som det försökte, så ett Zendesk-ärende som skapas mot ingen visas som olöst snarare än som tomt, aviseringar utlöses omedelbart med orsaken, försök körs där de är konfigurerade och ingenting anländer tyst och ser ut som en känd kund utan historik.
Prata med en integrationsspecialist på Alumio. Vi tar fram rätt arkitektur för dina system, i rätt skala, så att din verksamhet förblir stabil genom alla förändringar.