Skip to content

Externe identiteiten ​

Een externe identiteit is een record uit een extern systeem — een gebruikers-ID, een project-ID, een team-ID — dat gekoppeld moet worden aan een entiteit binnen SalesDash.

Externe identiteiten zijn de brug tussen providerdata en je SalesDash-configuratie. Ze maken het mogelijk dat SalesDash tegelijkertijd data ontvangt van meerdere externe systemen, zonder de gebruikers van het ene systeem te verwarren met die van het andere.

Waarom ze bestaan ​

Externe systemen hebben hun eigen ID's voor alles — gebruikers, teams, projecten. Bijvoorbeeld een LeadDesk-agent "12345" of een Teamleader-project "project-abc". SalesDash neemt niet aan dat deze ID's overeenkomen met een interne entiteit, of dat ze hetzelfde betekenen in twee verschillende systemen — tenzij je dat aangeeft met een koppelregel.

In plaats daarvan maakt een provider elke keer dat een nieuwe gebruiker, team of project in het externe systeem wordt aangetroffen een externe identiteit aan: "provider X heeft een entiteit met extern ID Y." Een implementeur koppelt die externe identiteit vervolgens aan de juiste interne entiteit in SalesDash.

Alleen data die behoort tot gekoppelde externe identiteiten telt mee in metrics.

Typen externe identiteiten ​

Providers maken externe identiteiten aan voor verschillende entiteitstypen. Elk type kan alleen worden gekoppeld aan het overeenkomende entiteitstype in SalesDash:

  • Agents — het meest voorkomende type; koppelt een externe gebruiker aan een SalesDash-agent
  • Teams — koppelt een extern team aan een SalesDash-team
  • Projecten — koppelt een extern project of account aan een SalesDash-project
  • Proposities — koppelt een extern product of dealtype aan een SalesDash-propositie

Agent-identiteiten moeten worden gekoppeld aan agents, teamidentiteiten aan teams en projectidentiteiten aan projecten. De entiteit moet al bestaan in SalesDash voordat je een identiteit eraan kunt koppelen.

Externe identiteiten koppelen ​

Ongekoppelde externe identiteiten zijn te vinden via Providers → Ongekoppelde externe identiteiten.

Maak eerst de doelentiteiten aan — agents via Data → Agents, teams via Data → Teams, projecten via Data → Projecten — en keer daarna terug naar de lijst met ongekoppelde externe identiteiten om ze toe te wijzen. Je kunt de lijst filteren op provider of entiteitstype en zoeken op externe naam of ID.

Genegeerde externe identiteiten ​

Een externe identiteit negeren heeft geen effect op je data — een ongekoppelde en een genegeerde identiteit tellen allebei niet mee in metrics. Het enige verschil: een koppelregel koppelt nooit een genegeerde identiteit.

Verder is een identiteit als genegeerd markeren een beheertool om de lijst overzichtelijk te houden. Gebruik het voor vermeldingen die je bewust niet wilt koppelen — een testaccount, een vertrokken medewerker, een interne bot — zodat ze niet langer in de lijst verschijnen. Genegeerde identiteiten zijn verborgen in de standaardweergave, maar kunnen zichtbaar worden gemaakt door het filter "genegeerd" uit te schakelen.

Meerdere identiteiten per entiteit ​

Een entiteit kan meerdere externe identiteiten hebben. Het meest voorkomende geval is één identiteit per provider — een salesmedewerker die zowel een CRM als een powerdialer gebruikt, heeft een externe identiteit uit elk systeem, beide gekoppeld aan dezelfde agent. Maar één provider kan ook meerdere identiteiten aanmaken voor dezelfde entiteit; bijvoorbeeld als een agent onder verschillende gebruikersaccounts of rollen voorkomt in hetzelfde externe systeem. Data van alle gekoppelde identiteiten wordt toegeschreven aan dezelfde entiteit en samen meegenomen in metrics.

Een externe identiteit overdragen ​

Sommige externe identiteiten horen bij een werkplek in plaats van bij een persoon: een dialer-login, een toestelnummer, een facturatieaccount. Als iemand vertrekt en een opvolger die login overneemt, verplaatst opnieuw koppelen alle data van de externe identiteit naar de nieuwe agent — ook alles wat de vorige agent deed.

Een overdracht verplaatst alleen de data vanaf een datum. Open de agent die de login tot nu toe gebruikte, zoek de externe identiteit onder Externe identiteiten en kies Overdragen:

  • Overdragen aan — de agent die de login nu gebruikt. Maak die agent eerst aan als hij nog niet bestaat.
  • Vanaf — de eerste dag dat de nieuwe agent de login gebruikte. Vandaag of eerder.

Data vanaf die dag gaat naar de nieuwe agent; alles daarvoor blijft bij de vorige. Dat geldt ook voor data die later binnenkomt: een sale van vóór de overdracht die je bronsysteem een week erna doorgeeft, telt nog steeds voor de vorige agent. Sales tellen op hun verkoopdatum, gesprekken op het moment dat ze gevoerd zijn, activiteiten op hun moment en periodes op hun begin — een periode die over de overdrachtsdatum heen loopt, blijft in zijn geheel bij de agent bij wie hij begon.

Het verplaatsen van de bestaande data gebeurt op de achtergrond en kan een paar minuten duren. Doelen, persoonlijke doelen, competities en achievements die al zijn afgerond, worden niet opnieuw berekend.

Je kunt een externe identiteit vaker overdragen. Een overdracht vervangt elke eerdere overdracht met dezelfde of een latere datum, zodat alle data vanaf die datum naar de agent gaat die je kiest. Om een overdracht te corrigeren, draag je opnieuw over vanaf de juiste datum — ook aan dezelfde agent. Om een overdracht naar een latere datum te verplaatsen, draag je de externe identiteit eerst terug aan de vorige agent vanaf de oude datum. De kolom Overdrachten laat zien wie de externe identiteit wanneer had.

  • Koppelregels. Externe identiteiten die een regel Zelfde externe ID aan deze heeft gekoppeld, delen de login en worden dus mee overgedragen. Externe identiteiten die een regel Zelfde externe naam heeft gekoppeld, volgen de nieuwe koppeling helemaal, zoals bij opnieuw koppelen: een naam hoort bij een persoon, niet bij een login.
  • Ontkoppelen of opnieuw koppelen van een overgedragen externe identiteit verwijdert de overdrachten: de koppeling geldt dan weer voor al haar data.
  • Ondersteunde providers. Overdrachten werken voor providers die op processors draaien, en voor Voys. Bij andere providers wordt de bestaande data bij de overdracht gesplitst, maar data die een latere synchronisatie opnieuw schrijft, gaat naar de huidige agent.

Koppelregels ​

Vaak hoef je een koppeling niet zelf uit te zoeken, omdat een andere externe identiteit van dezelfde persoon, hetzelfde team of dezelfde propositie al gekoppeld is. Met een koppelregel legt SalesDash die koppelingen voor je: voor elke externe identiteit van een provider zoekt de regel de externe identiteit die ermee overeenkomt, en koppelt die aan dezelfde agent, hetzelfde team of dezelfde propositie.

Hoe een regel die overeenkomst vindt, is zijn koppelmethode. Elke methode staat hieronder beschreven.

Zonder regel koppelt SalesDash nooit een externe identiteit aan waar een andere externe identiteit aan gekoppeld is.

Een regel instellen ​

Open Providers → Ongekoppelde externe identiteiten en kies Koppelregels. Maak een regel aan met:

  • Type — het soort externe identiteit dat je wilt koppelen: agents, teams of proposities, plus projecten en segmenten als je die gebruikt
  • Provider — de provider waarvan de regel de externe identiteiten koppelt
  • Koppelmethode — hoe de regel een overeenkomst vindt. Een methode kan om eigen instellingen vragen; die staan bij de methode beschreven.

Bij het opslaan koppelt de regel de externe identiteiten die al klaarstaan, en laat hij zien hoeveel koppelingen er veranderd zijn. Type en provider kun je niet meer wijzigen zodra de regel bestaat.

Wat een regel daarna doet ​

  • Een nieuwe externe identiteit wordt gekoppeld zodra die binnenkomt, zodat de data ervan meteen meetelt.
  • Wordt de externe identiteit waarmee een regel vergelijkt gekoppeld, aan iemand anders gekoppeld of ontkoppeld, dan volgt elke externe identiteit die ermee overeenkomt, samen met de data ervan.
  • Een regel koppelt alleen als de overeenkomst eenduidig is. Zijn de overeenkomende identiteiten aan verschillende agents, teams of proposities gekoppeld, dan wordt er niets gekoppeld — en een externe identiteit die de regel al had gekoppeld, wordt weer ontkoppeld en verschijnt in de lijst met ongekoppelde identiteiten, zodat jij die kunt afhandelen.

Koppelingen van jezelf of van een synchronisatie ​

Een regel verandert nooit een koppeling die met de hand of door de eigen synchronisatie van een provider is gemaakt. Koppel je een externe identiteit die een regel gekoppeld heeft opnieuw, dan wordt de koppeling van jou.

Een externe identiteit ontkoppelen houdt een regel er niet vanaf: de volgende keer dat de overeenkomst verandert, of iemand de regel opslaat, koppelt de regel die identiteit opnieuw. Wil je een regel definitief van een externe identiteit afhouden, negeer die identiteit dan.

Een regel vergelijkt ook alleen met koppelingen die met de hand of door een synchronisatie zijn gemaakt — nooit met koppelingen van een andere regel. Laat elke regel dus wijzen naar de externe identiteiten met de echte koppelingen, niet naar de identiteiten die een andere regel heeft gekoppeld.

Een regel verwijderen ​

Verwijder je een regel, dan blijven de koppelingen die hij gemaakt heeft bestaan, maar volgen ze geen wijzigingen meer. Heb je dezelfde regel twee keer aangemaakt, dan laat de kolom Gekoppelde externe identiteiten in de tabel met regels zien welke het werk doet — verwijder de regel die 0 toont.

Koppelmethodes ​

Zelfde externe ID ​

Gebruik deze methode als twee van je systemen dezelfde mensen kennen onder hetzelfde ID. Een typisch voorbeeld: de gebruikers in je CRM zijn gekoppeld aan je agents, en een tweede bron — een bonus-API, een salarisexport — rapporteert over dezelfde mensen met het gebruikers-ID uit het CRM. Een regel op die tweede bron koppelt elk van haar externe identiteiten aan de agent waaraan de CRM-identiteit met hetzelfde ID gekoppeld is.

Kies bij Vergelijken met provider de provider die de juiste koppelingen al heeft — in het voorbeeld het CRM.

  • Een externe identiteit die bij een project hoort, komt alleen overeen met externe identiteiten in datzelfde project.
  • Delen drie systemen hetzelfde ID, laat dan beide regels wijzen naar het systeem met de echte koppelingen, in plaats van de ene regel te laten vergelijken met de koppelingen van de andere.

Zelfde externe naam ​

Gebruik deze methode als twee van je systemen geen ID delen, maar dezelfde mensen wel onder dezelfde naam kennen. Een typisch voorbeeld: de gebruikers in je CRM zijn gekoppeld aan je agents, en je dialer rapporteert gesprekken onder de volledige naam van elke agent. Een regel op de dialer koppelt elk van zijn externe identiteiten aan de agent waaraan de CRM-identiteit met dezelfde naam gekoppeld is.

Kies bij Vergelijken met provider de provider die de juiste koppelingen al heeft — in het voorbeeld het CRM.

Vergelijken met provider kan ook de eigen provider van de regel zijn. Gebruik dat als één provider dezelfde persoon onder meer dan één ID kent — twee bronnen met een verschillende sleutel, of een account dat in het bronsysteem opnieuw is aangemaakt. Zodra een van die externe identiteiten gekoppeld is, volgen de andere met dezelfde naam. Binnen één provider wordt een externe identiteit die je ontkoppelt meteen opnieuw gekoppeld als een naamgenoot nog gekoppeld is; negeer die identiteit om haar ongekoppeld te houden.

Deze methode werkt zoals Zelfde externe ID, met deze verschillen:

  • Hoofdletters en accenten tellen niet mee: "José de Vries" komt overeen met "jose de vries". Verder moet de naam precies gelijk zijn — "J. de Vries" komt niet overeen met "Jan de Vries".
  • Zijn de externe identiteiten met dezelfde naam verschillend gekoppeld, dan koppelt die naam niets. Koppel die externe identiteiten met de hand.
  • Namen veranderen, en een regel houdt dat bij. Geeft een provider een externe identiteit een nieuwe naam, dan zoekt de regel opnieuw een overeenkomst. Krijgt de externe identiteit waarmee vergeleken wordt een nieuwe naam, dan volgen de externe identiteiten onder de oude en onder de nieuwe naam.
  • Een externe identiteit met een lege naam komt nooit overeen.
  • Stuurt een provider geen naam mee, dan gebruikt SalesDash het externe ID als naam; voor die externe identiteiten vergelijkt deze regel dus ID's.