MuninMunin
Logga inKom igång gratis
Home/Journal/Ditt CRM borde fylla sig självt.
Field note · 5 min read

Ditt CRM borde fylla sig självt.

Ingen har någonsin gillat att skriva in en jobbtitel i en kontaktpost. Fyra agentrundor som håller CRM:et aktuellt utifrån samtalen du redan hade — och gränsen där de stannar och frågar en människa.

A battered cobalt blue plastic crate left on a Norwegian shingle tide line, already half filled with rounded grey stones and dry weed, cold sea beyond.
Kvarlämnad över natten. Tidvattnet fyllde den.

Varje CRM jag någonsin sett ett team använda förföll i ungefär samma takt, av samma skäl. Datainmatningen är någons jobb men ingens prioritet. En kund nämner under ett samtal att de bytt företag; den som hörde det äger inte posten; ingenting händer. Sex månader senare är segmentet fel, kampanjen går till en död adress, och någon förklarar att CRM:et behöver städas upp.

Vad innebär ett självfyllande CRM egentligen?

Det innebär att posten underhålls av agenter som läser samtalen du redan hade, snarare än av en person som skriver om det en kund nyss berättat. Ny kontakt kommer in, blir berikad. En supporttråd avslöjar ett jobbyte, posten uppdateras. Dubbletter dyker upp som förslag i stället för att samlas på hög.

Den viktiga hälften är gränsen: en del av det tillämpas automatiskt, och en del kan bara föreslås. Vilket som är vilket är ett designbeslut, inte en säkerhetströskel.

Var kommer data ifrån när ingen skriver in det?

Från tre ställen du redan har. Vad kunder själva berättar om sig i supporttrådar och chattar. Vad som ligger offentligt på deras företagssajt. Och den beteendemässiga posten — vilka sidor de läste, vilka trådar de öppnade, hur nyligen de gjorde något alls.

Skälet till att det här fungerar i Munin och inte i en typisk stack är att alla tre bor i samma databas. Konversationer, CRM, kunskap, innehåll, utgående kontakt och analys delar ett Postgres-schema och en contacts-tabell, så rundan som berikar en kontakt och kampanjen som senare riktar sig mot dem läser och skriver samma rad. Ingen integration, ingen synkfördröjning, ingen andra version av sanningen om vem den här personen är.

Vilka rundor gör jobbet?

Fyra, var och en ett markdown-recept du kan läsa och redigera — två följer med som färdigheter, de andra två är recept du kan skriva som färdigheter — körda på schema eller utlösta av en händelse:

  • 01Vid registrering — berika. Lead research läser den nya kontaktens företagssajt och fyller i roll, senioritet och bransch, och stämplar sedan en kort sammanfattning på posten med crm_set_ai_summary. Tillämpas direkt: det är offentlig information och trivialt att rätta.
  • 02Vid avslut — identitet. Kontaktextraktion läser en avslutad konversation efter vad kunden sagt om sig själv — namn, företag, telefon — och skriver det till CRM:et. Tillämpas också direkt, eftersom kunden sa det om sig själv, ospord.
  • 03Veckovis — passform och avsikt. Lead scoring går igenom ett segment, väger berikningsdata mot samtalston och aktivitetsnärhet, och stämplar varje kontakt med ett poäng och en enradig motivering. En ledtråd för människor, inte en grind.
  • 04Veckovis — dubbletter. Kontakthygien söker efter troliga dubblettpar och lägger in dem som strukturerade sammanslagningsförslag med en konfidensgrad. Du tillämpar eller avfärdar. Agenten slår aldrig ihop två kunder på egen hand.

Varför fyller det här inte bara CRM:et med rimligt skräp?

För att de destruktiva verben inte är tillgängliga för agenten. Att slå ihop två kontakter är ett separat, snävt avgränsat, separat reviderat verktyg som bara föreslår — så värsta fallet för en förvirrad eller prompt-injicerad agent är en dålig rad i en granskningskö, inte två kunder hopsvetsade.

Den uppdelningen går på reversibilitet snarare än konfidens. Att skriva en jobbtitel är billigt och reversibelt: blir det fel rättar du det på en sekund, och ingenting lämnade byggnaden. Att slå ihop två poster förstör information och kan inte göras ogjort rent. Därför är det billiga verbet rikligt och det dyra kräver en människa, oavsett hur säker modellen påstår sig vara. Granskningskön är inte en nödlösning tills automatiken blir bra nog — den är där omdömet bor.

Berikning är en samtyckesfråga, inte bara en datafråga

En agent som kan läsa en företagssajt kan fylla i en hel del om en person. Om du bör lagra det är ett annat beslut än om du kan, och i EU är det ett beslut med en tillsynsmyndighet fäst vid sig.

Munin håller samtyckesstatus på kontakten och kontrollerar den innan utgående kontakt. Sätt den medvetet — och märk massimporter med partiet, som initial-import-2026-07, så att du kan filtrera bort en dålig källa senare. Utan märkningen kan du inte det — så märk importen, och för in partiet som source på samtyckesposten, vilket samtyckesverktyget tar som ett förstklassigt fält. Samtyckeskontrollen körs i tjänsten innan någon utgående runda ser kontakten, oavsett om en människa eller en agent startade den.

Hur ser det ut efter en månad?

Odramatiskt, vilket är poängen. Kontakter har roller och företag ifyllda utan att någon skrivit in dem. Segmentet du skickar en kampanj till är aktuellt för att det underhölls löpande i stället för att städas upp i panik i förväg. Det ligger en liten kö av sammanslagningsförslag och väntar, och den tar några minuter att arbeta igenom.

Förändringen är inte att arbete försvann. Den är att arbetet som återstår är den del som behövde en människa: att avgöra om de här två posterna verkligen är samma kund, om den här kontakten överhuvudtaget bör vara i den här kampanjen. Det är samma slinga som gör lösta supportöverlämningar till kunskapsartiklar — en biprodukt av arbete som redan skett, arkiverad där den blir användbar nästa gång någon behöver den.

Vad kommer det här inte att göra?

Det kommer inte att hitta på data som inte finns någonstans. Har en kontakt aldrig uppgett sin jobbtitel och deras företag saknar sajt, förblir fältet tomt — och det är rätt beteende, inte en lucka.

Det läser vad ett företag publicerar, inte en licensierad firmografisk databas. Behöver du verifierad firmografi i stor skala — personalintervaller, finansieringshistorik, teknografi över femtiotusen konton — köp det från en dataleverantör byggd för precis det. Det är en verklig produktkategori och den gör ett verkligt jobb.

Och poängrundan arbetar utifrån signalen du redan håller: vad kunden sa, vad deras sajt säger, vad de gjorde. Behandla passform- och avsiktspoäng som en läsordning för en människa, inte som ett beslut. Vi säger samma sak i själva färdigheten, så att agenten inte heller översäljer dem.

Vad du får i utbyte är en post som är spårbar. Varje fält de här rundorna skriver kommer från något en kund sa i en tråd du kan öppna, eller något publicerat på en sida du kan besöka — inte en sannolikhet köpt av en tredje part och uppdaterad enligt någon annans schema. Och eftersom allt landar i samma contacts-tabell som din inkorg, kunskapsbas och kampanjer redan läser från, är en rättelse du gör en gång rätt överallt i samma ögonblick. Köp firmografin om du behöver bredden; rundorna fortsätter fylla i runt den från samtalen bara du har.

Vanliga frågor

Kan AI hålla mina CRM-data uppdaterade automatiskt? Ja, för allt som kan härledas ur källor du redan har — vad kunder säger i supportkonversationer, vad som är offentligt på deras företagssajt, och deras beteende i din produkt. I Munin körs de här som schemalagda eller händelseutlösta agentrundor: berikning vid registrering, identitetsextraktion vid avslutad konversation, poängsättning och dubblettdetektering veckovis.

Kommer en AI-agent att slå ihop mina kontakter felaktigt? Den kan inte slå ihop dem alls. Dubblettdetektering lägger bara in strukturerade sammanslagningsförslag med en konfidensgrad; en människa tillämpar eller avfärdar var och en. Uppdelningen handlar inte om hur säker modellen är — den handlar om att sammanslagning förstör information och inte kan göras ogjord rent, så den kräver en person – det är ett medvetet val.

Hur hanterar automatisk berikning GDPR och samtycke? Samtyckesstatus bor på kontaktposten och kontrolleras innan utgående körs, så berikning och tillåtelse att kontakta är separata beslut. Munin Cloud driftas i EU. Märk massimporter med partiet så att en dålig datakälla kan filtreras bort senare.

Vilken modell använder det här? Den du riktar mot det. Munin exponerar arbetet som MCP-verktyg och markdown-färdigheter, så Claude, ChatGPT, Gemini eller en lokal modell kan köra rundorna. AI-kostnaden är vad din leverantör tar, inte en avgift per åtgärd till oss.

Måste jag använda alla fyra rundorna? Nej. De är oberoende markdown-recept — kör en, kör alla fyra, eller redigera dem som inte matchar hur du arbetar. De flesta team börjar med berikning vid registrering, eftersom den är lättast att verifiera.

Vad händer när agenten har fel? Varje verktygsanrop revideras, och de billiga skrivningarna är billiga att återställa — därför är det de som får tillämpas direkt. Redigera posten och rättelsen loggas; redigera färdigheten och beteendet ändras nästa runda.

Kortversionen

  • CRM:er förfaller för att datainmatning är någons jobb och ingens prioritet. Agenter som läser samtal du redan hade rättar det löpande i stället för i en städpanik.
  • Fyra rundor: berika vid registrering, extrahera identitet vid avslutad konversation, poängsätt passform och avsikt veckovis, föreslå dubblettsammanslagningar veckovis.
  • Uppdelningen är reversibilitet, inte konfidens. Billiga reversibla skrivningar tillämpas direkt; sammanslagningar kan bara föreslås in i en granskningskö.
  • Det fungerar för att konversationer, CRM och analys delar ett schema och en contacts-tabell — ingen synk, ingen andra version av kunden.
  • Varje fält rundorna skriver kan spåras till en tråd du kan öppna eller en sida du kan besöka, och varje runda är ett markdown-recept du kan läsa och redigera innan du litar på den.

Varje runda är markdown du kan läsa innan du litar på den. Agentrecepten är stället att börja, och Munin Cloud är gratis att pröva en på.

Ett CRM som ingen underhåller är inget CRM. Det är ett kalkylblad med inloggning.

Kjell Rune Monsø, grundare.