CRM-agenter i 2026: Piloten må teste fullmakter før fart

Markedet flytter seg fra assistent til agent

CRM-valget i 2026 handler ikke bare om kontaktkort, rapporter og salgsrør. Salesforce, Microsoft Dynamics 365 og HubSpot beskriver nå agentfunksjoner som kan finne signaler, berike informasjon og foreslå neste handling. Leverandørene bruker ulike navn, men retningen er tydelig. Mer av arbeidet flyttes inn i en salgsflate der systemet både leser data og forbereder handlinger. Det gjør fullmakt, logging og menneskelig kontroll til en del av produktvalget.

Dette er leverandørbeskrivelser, ikke uavhengig dokumentasjon av gevinst. Salesforce omtaler Prospecting Agent og bruk av CRM-signaler, nettdata og tredjepartskilder. Microsofts plan for 2026 wave 1 beskriver agenter som beriker data, analyserer signaler og prioriterer handlinger. Planlagte leveranser kan endres. HubSpot beskriver Breeze Prospecting Agent som beta. Markedet har altså beveget seg mye i funksjonsretning, men mindre i offentlig dokumentasjon av hva kundene faktisk oppnår.

Tre alternativer med ulike utgangspunkt

Salesforce er et relevant alternativ når virksomheten allerede har mye salgsdata og arbeidsflyt i Salesforce. Prospecting Agent beskrives som en funksjon som kan rangere prospekter og lage utkast fra flere signaler. Menneskelig gjennomgang før e-post sendes er en viktig grense. Piloten bør kontrollere hvilke kilder agenten får lese, hvordan et utkast merkes og om godkjenningen faktisk stopper utsending.

Dynamics 365 er særlig relevant for virksomheter som allerede bruker Microsofts data- og samarbeidsflate. Leverandøren beskriver koblinger til Microsoft Graph og agenter i salgsflyten. HubSpot er et alternativ for team som ønsker Smart CRM og en samlet salgsarbeidsflate, men Breeze-funksjonen er omtalt som beta. På den andre siden kan tett økosystemkobling redusere integrasjonsarbeid og samtidig gjøre et senere bytte vanskeligere. Ingen leverandør passer alle virksomheter.

Piloten må måle arbeid, ikke presentasjoner

Start med de samme oppgavene i alle tre systemene. La piloten finne en avgrenset liste med kontoer, foreslå en prioritering og lage et utkast som et menneske vurderer. Registrer hvor mye grunnlagsdata som måtte ryddes, hvor ofte forslaget ble avvist og hvor lang tid feilrettingen tok. Da blir sammenligningen konkret. En pen demonstrasjon sier lite hvis den bygger på data og regler som ikke finnes i egen virksomhet.

Mål datakvalitet, integrasjoner, arbeidsflyt, støttebehov og eksport. Noter også hvor mange manuelle unntak teamet må håndtere. I praksis bør piloten vise om leverandøren passer dagens salgsprosess, eller om prosessen må bygges om rundt produktet. Et raskt forslag er ikke nyttig dersom selgeren må lete etter kilden, rette identiteten eller gjenskape beslutningen i et annet system.

Risikoen ligger i fullmakten

Den viktigste risikoen er ikke bare at agenten skriver en dårlig setning. Den kan bruke feil data, prioritere feil konto eller gjøre mer enn brukeren forsto. Piloten må derfor dokumentere datatilgang, tillatte handlinger og krav til godkjenning. Den må også vise hvem agenten opptrer som. En felles systemkonto gjør revisjon vanskelig. En avgrenset identitet gjør det enklere å trekke tilgang tilbake.

Test en uønsket handling med vilje. Kontroller at den stoppes, logges og kan forklares. Prøv deretter feilretting og tilbakerulling. Hva skjer med opprettede oppgaver, berikede felt og kladder hvis forsøket avsluttes? Leverandøren beskriver funksjonene, men kunden må kontrollere resultat, datatilgang og feil selv. Den kontrollen er en del av anskaffelsen, ikke et arbeid som kan vente til etter kontrakten.

Slik bør kortlisten avgjøres

Kortlisten bør først følge eksisterende data, integrasjoner og kompetanse. Deretter bør den utfordres med ett reelt alternativ utenfor dagens økosystem. Bruk samme datasett, samme oppgaver og samme godkjenningsgrenser. Vurder ikke planlagte funksjoner som om de allerede er levert. Merk beta tydelig, og skill en offentlig produktplan fra en bindende leveranse i egen avtale.

Velg først når piloten har vist tre ting: Systemet støtter den faktiske arbeidsflyten, fullmaktene kan avgrenses, og data kan hentes ut ved tilbakerulling eller leverandørbytte. Hvis to løsninger gir omtrent samme arbeidsverdi, bør lavere styringsrisiko veie tungt. CRM-agentene er reelle markedsnyheter. Det gjør dem verdt å teste, men ikke til en grunn for å hoppe over testen.

Kilder og videre lesning

• salesforce.com: sales cloud product release
• learn.microsoft.com: dynamics365 sales
• hubspot.com: sales

Be leverandørene vise samme avvik

Gi hver leverandør et eksempel med manglende felt, motstridende kontaktdata og en handling som krever godkjenning. Be dem vise kilden til agentens forslag, loggen for beslutningen og hvordan en feil blir rettet. Test også hva som skjer når en bruker mister tilgang midt i arbeidsflyten. Dette gjør salgspresentasjonen mindre glatt, men beslutningen bedre. Den løsningen som forklarer et avvik på en forståelig måte, kan være mer verdifull enn løsningen som produserer flest forslag i en ren demo.

Kostnaden ligger også etter piloten

Regn inn opplæring, datarydding, kontrollarbeid og løpende forvaltning. Et produkt som krever mye manuell godkjenning kan fortsatt være riktig, men kostnaden må være synlig. Avklar hvem som eier regler og integrasjoner etter innføring. Be også om en konkret eksportprøve før avtalen inngås. Hvis teamet ikke kan hente ut sentrale data og forstå agentens historikk, er tilbakerulling bare et ord i prosjektplanen.

Kilder

• CRM-agentene er her, men piloten må teste fullmakter før fart