En guide til programansvarlige om konkurrentindsigt til salgsteams: ansvarsfordelingen mellem PMM, RevOps og salgsunderstøttelse, AI-assistenten som leveringskanal, der sikrer brugen, og de målepunkter, der viser, om programmet virker.
16. maj 2026 · 18 min. læsning
Hvis du har ansvaret for et program for konkurrentindsigt i salg, er dine læsere og dine købere ikke de samme. Du læser denne artikel. Dine sælgere mærker konsekvenserne af, hvordan du tilrettelægger programmet omkring dem. Det meste indhold om "konkurrentindsigt til salg" er skrevet, som om sælgerne var målgruppen. Det er de ikke. De er brugerne af det program, du bygger, og om de bruger det, afhænger af valg, der træffes længe før det første battlecard.
Dette er versionen til den programansvarlige. Den er til RevOps, salgsunderstøttelse og salgsledelse, som skal afgøre, hvem der har ansvar for hvad, hvilken leveringskanal der faktisk når sælgerne under salgsprocessen, og hvilke målepunkter der fortæller, om systemet virker. Du finder et overblik over disciplinen i hovedartiklen om konkurrentindsigt. For perspektivet fra PMM og det forudgående arbejde, se konkurrentindsigt til produktmarketingansvarlige.
Kort fortalt
Et program for konkurrentindsigt i salg har fire ansvarlige funktioner, ikke én. PMM producerer indholdet. RevOps har ansvaret for indsamling og videresendelse. Salgsunderstøttelse har ansvaret for, at programmet bliver brugt. Salgsledelsen har ansvaret for feedbacksløjfen. Programmer uden en navngiven ansvarsfordeling ender uden en ansvarlig.
Sælgere læser ikke battlecards. De stiller spørgsmål midt i samtalen. Løsningen er en arkitektur for levering af indholdet (AI-assistent, visning i CRM, Slack-notifikationer), ikke et flottere dokument.
Win/loss er et ansvar for RevOps, før det er et ansvar for PMM. CRM-feltet, den systematiske stikprøveudvælgelse og tilbageføringen til battlecards begynder alle hos den driftsansvarlige funktion.
Værktøjerne afhænger af virksomhedens udviklingstrin. Små og mellemstore virksomheder: selvbetjente værktøjer bygget til AI kombineret med samtaleanalyse som Gong. Store virksomheder: platformspakker med en sælgerdrevet købsproces (oftest Klue) oven på de samme grundelementer.
Fem målepunkter viser, om programmet virker: vinderate mod konkurrenter, battlecards' aktualitet, antal forespørgsler til AI-assistenten, registreringsgrad for win/loss og tid til opdatering efter et konkurrencetiltag. Ingen af dem er "antal leverede battlecards".
Hvem har ansvar for hvad i et program for konkurrentindsigt i salg?
Den hyppigste årsag til, at programmer for konkurrentindsigt i salg fejler, er uklart ansvar. CRO'en bakker op om programmet, fordi bestyrelsen har bedt om det. PMM får ansvaret for battlecards, fordi de er "tættest på budskaberne". Sælgerne er på papiret målgruppen, men bliver aldrig spurgt om formatet. Seks måneder senere er programmet gået i stå, og ingen ved, hvem der skal løse problemet.
Et velfungerende program udpeger udtrykkeligt fire ansvarsområder.
Klar til at overvåge dine konkurrenter uden manuelt arbejde?
Indhold i battlecards, positioneringsgrundlag for hver konkurrent, definition af relevante signaler, modsvar på budskaber ved lanceringer
CRM-datakvalitet, tiltag der får sælgerne til at bruge programmet, registrering af win/loss-data
RevOps / salgsdrift
CRM-felter (konkurrent ved afslutning, mærkning af salgsstadier), videresendelse af data, integrationer (Gong til CRM, MCP-feed), valg af værktøjer
Formuleringer i battlecards, positioneringsfortælling
Salgsunderstøttelse
Introduktion til programmet for konkurrentindsigt, coaching i brugen, træningsrytme, åbne sparringstimer om konkurrentindsigt i konkrete salgsmuligheder
Strategisk positionering, definition af overordnede målepunkter
Salgsledelse (VP / CRO)
Månedlig win/loss-gennemgang, opbakning fra ledelsen, eskalering når brugen går i stå, det målepunkt der udløser ændringer i programmet
Daglig indholdsproduktion
Fordelingen findes som regel allerede i store organisationer og må etableres aktivt i små. Et GTM-team på 15 personer skal stadig have udpeget alle fire roller, selv om én person har to af dem. Det afgørende er at placere ansvaret; uklarhed er det, der tager livet af programmet.
En konkret test af, om fordelingen virker: Når en konkurrent lancerer et nyt prisniveau en tirsdag eftermiddag, hvem opdaterer så battlecardet, hvem udløser Slack-notifikationen til sælgere med aktive salgsmuligheder mod den konkurrent, hvem bekræfter, at sælgerne har kvitteret for den, og hvem følger op på næste måneds ledelsesgennemgang? Hvis svarene er fire forskellige navngivne personer, er programmet sundt. Hvis tre af svarene er "PMM, tror jeg?", er det ikke.
Det øjeblik, hvor sælgeren faktisk har brug for hjælp
Sælgeren har brug for svar, ikke dokumenter. Den forskel sammenfatter hele udfordringen med at designe programmet i én sætning.
Tre tidspunkter i en salgsproces står for størstedelen af den faktiske brug af konkurrentindsigt.
Før samtalenHvem er sandsynligvis den nuværende leverandør? Hvordan har de senest ændret deres positionering?
Under samtalenHvordan håndterer jeg denne indvending lige nu? Hvilket spørgsmål kan afdække konkurrentens svaghed?
Efter samtalenHvad sagde den potentielle kunde om konkurrenten? Hvor registrerer jeg det?
Behovet før samtalen bliver godt dækket af de eksisterende kanaler. Sælgerne undersøger den potentielle kundes værktøjer, skimmer et battlecard og forbereder sig på sandsynlige konkurrencesituationer. De har tid, de har hænderne fri, og indholdet kan godt fylde fem afsnit. De fleste programmer for konkurrentindsigt dækker dette tidspunkt fint.
Det er under samtalen, at brugen falder fra hinanden. Sælgeren har brug for ét konkret svar mellem to spørgsmål fra den potentielle kunde. Der er ikke tid til at åbne en Notion-side med 6 blokke. Sælgeren kan ikke engang åbne en ny fane uden at miste øjenkontakten på Zoom. Hvis svaret ikke kan findes på tre sekunder, improviserer sælgeren. Alt, hvad du leverer til dette tidspunkt, og som kræver, at sælgeren konsulterer en separat brugerflade, kunne lige så godt ikke eksistere.
Efter samtalen skal sælgerne give noget tilbage til programmet. Uanset om salgsmuligheden bliver vundet eller tabt, bør salgsnotatet registrere, hvad konkurrenten gjorde eller sagde. De fleste programmer indsamler disse data dårligt, fordi feltet er valgfrit, opfordringen er gemt væk, og sælgerne ikke oplever nogen værdi ved at udfylde det.
Hvis du kun designer til tiden før samtalen, stiger antallet af battlecards, mens vinderaten står stille. Hvis du designer til brug under samtalen, bliver du nødt til at vælge en leveringsarkitektur, der ser meget anderledes ud end den, de fleste programmer tilbyder.
Battlecards som en leveringsudfordring frem for en indholdsudfordring
De fleste mislykkede programmer for konkurrentindsigt i salg har masser af indhold og mangelfuld levering. PMM har skrevet fremragende battlecards. Sælgerne åbner dem ikke. Begge observationer er sande på samme tid, og den programansvarlige stiller det forkerte spørgsmål med "hvordan forbedrer vi vores battlecards?"
Det rigtige spørgsmål er: Når en sælger har brug for et konkret svar om en konkurrent i en salgsproces, hvilken kanal gør så svaret tilgængeligt?
Sælgerens spørgsmål midt i salgsprocessen
CRM-kort for salgsmuligheden
AI-copilot via MCP
Konkurrentkanal i Slack
Besked til lederen
Samtaleuddrag fra Gong
Fire leveringsformer fungerer bedre end et statisk dokument. De supplerer hinanden frem for at erstatte hinanden.
Battlecard-felter integreret i CRM viser de to eller tre mest aktuelle pointer om konkurrenten direkte på salgsmuligheden, mærket med konkurrenten ved afslutning. Sælgeren er allerede i CRM; indholdet møder sælgeren dér. Det er her, Klue, Crayon og de fleste platformspakker med en sælgerdrevet købsproces lægger deres indsats, og det er et grundkrav til ethvert program med mere end ~10 sælgere.
Slack-kanaler for hver prioriteret konkurrent gør programmet til en løbende informationsstrøm. Nyt annoncemateriale fundet i Meta Ad Library, et nyt prisniveau på konkurrentens hjemmeside, en ny win/loss-gennemgang af en salgsmulighed mod konkurrenten. Alt væsentligt bliver slået op i en dedikeret kanal, hvor interesserede sælgere som udgangspunkt slår notifikationer fra og søger, når de har brug for det.
Gong (eller et andet værktøj til samtaleanalyse) bringer konkurrentindsigten tilbage i den brugerflade, hvor samtalen foregår. Når et konkurrentnavn registreres i en samtale, ser sælgeren det relevante battlecard-uddrag direkte i den efterfølgende samtalegennemgang. Nogle platforme viser det også i realtid under samtalen.
AI-assistenten via MCP eller API er den kanal, de fleste teams endnu ikke har bygget, og som rummer det største potentiale for yderligere værdi i de næste to år. En sælger spørger midt i en samtale sin interne copilot eller salgsassistent: "Hvad svarer vi om prisen, hvis de fremhæver Klue på Enterprise-niveau?" og får et klart svar hentet fra de samme battlecard-data. Det virker kun, hvis indholdet i battlecards findes som maskinlæsbare, strukturerede data og ikke som en PDF. MCP-endpointet eller en stabil API er den kontrakt, der lader alle assistenter i sælgerens værktøjsmiljø forespørge den samme fælles datakilde.
Beskeder til lederen er den menneskelige reserveplan. Når alt andet svigter, skriver sælgeren til sin leder. Et godt program ser mønstre i lederens svar som et signal om, at de forudgående kanaler har svigtet, og arbejder derfra tilbage for at lukke hullet.
AI-assistenten som kanal: MCP, copiloter og AI i CRM
AI-assistenten som kanal fortjener sin egen gennemgang, fordi den ændrer forudsætningerne for programmets design mere end de tre andre.
Sælgere læser ikke. Men de stiller gerne spørgsmål. Når en intern copilot er tilgængelig på deres bærbare computer eller i deres CRM, tager spørgsmålet "hvilket spørgsmål kan afdække en svaghed hos Klue inden for sikkerhed?" 4 sekunder mellem to mails til potentielle kunder. Det sænker indsatsen ved at bruge indsigten fra at åbne en fane til at skrive en sætning, og i de teams, der har etableret forbindelsen, stiger brugen af konkurrentindsigt med en faktor ti.
For den programansvarlige følger der tre arkitekturvalg af det.
Indholdet i battlecards skal findes som strukturerede data. Felter, tags, kilde-URL'er og tidsstempler for seneste opdatering. Ikke afsnit i en PDF. Ikke et Word-dokument på et fællesdrev. Formatet er den kontrakt, der gør det muligt for en AI-assistent at hente oplysninger og sammensætte pålidelige svar.
Der skal være en adgang til at hente indholdet. Enten et MCP-endpoint (den mest ligetil løsning for teams bygget omkring AI) eller en API, som interne copiloter kan kalde. Mange arbejdsplatforme til konkurrentindsigt bygget til AI (herunder Watchr) tilbyder denne adgang direkte. Platformspakker med en sælgerdrevet købsproces er ved at indhente dem, men med varierende dækningsgrad.
Assistentkæden skal have tilladelse til at bruge den. Det er her, de fleste programmer går i stå af ikke-tekniske årsager. Sikkerhed og IT skal godkende forbindelsen. Salgsunderstøttelse skal lære sælgerne, at "spørg din copilot" nu er et dokumenteret trin i salgsmanualen. Uden begge dele findes kanalen teknisk set, men bliver ikke brugt.
Teams, der forbinder det hele fra ende til anden, oplever den hurtigste stigning i brugen af nogen kanal for konkurrentindsigt i salg i 2026. Det skyldes ikke, at AI er magisk. Det skyldes, at det endelig kræver mindre at stille et spørgsmål end at slå svaret op.
Win/loss som feedbacksløjfe for RevOps
Win/loss er det mest undervurderede input til konkurrentindsigt i de fleste salgsorganisationer og det, der lettest kan forbedres. Problemet er strukturelt: Data findes i samtaler, ikke i felter, og samtaler kan ikke bare samles til et overblik.
RevOps har ansvaret for den strukturelle løsning. PMM har ansvaret for at sammenfatte indsigterne.
Løsningen har tre dele.
Et obligatorisk CRM-felt til konkurrent ved afslutning på hver tabt salgsmulighed med en overskuelig rullemenu og valgmuligheden "andet". Dårlige rullemenuer tvinger sælgerne til at skrive fritekst, fritekstdata skaber støj, og støj ødelægger den efterfølgende analyse.
Systematisk stikprøveudvælgelse frem for en aggregeret rapport. RevOps udvælger hver måned 15 til 20 notater fra salgsmuligheder tabt til konkurrenter og sender dem til PMM til gennemlæsning. Mønstre træder frem i små stikprøver, som forsvinder i dashboards. Dashboardet fortæller dig, at I tabte 14 salgsmuligheder til Crayon i sidste kvartal; gennemlæsningen af notaterne fortæller dig, at I tabte dem alle på en bestemt indvending om implementeringstid.
En fast rytme for opfølgende samtaler med som minimum den sælger, der afsluttede salgsmuligheden, og helst med den potentielle kunde. Selv en samtale på 15 minutter med sælgeren 48 timer efter, at salgsmuligheden er lukket som tabt, giver oplysninger, som CRM-notatet ikke fangede. Programmer, der bygger dette ind i arbejdsgangen for tabte salgsmuligheder (en kalenderinvitation udløst af et stadieskift), får dataene; programmer, der venter på, at sælgerne selv melder ind, gør ikke.
Feedbacksløjfen lukkes, når de sammenfattede indsigter kommer tilbage til sælgerne som opdaterede battlecards, nye spørgsmål, der afdækker konkurrenters svagheder, og en Slack-besked i den relevante konkurrentkanal, der opsummerer ændringerne. Hvis sløjfen ikke lukkes, holder sælgerne op med at rapportere, fordi de ikke oplever noget udbytte af deres dataregistrering. RevOps har ansvaret for datadisciplinen; PMM har ansvaret for at føre indsigterne tilbage.
Værktøjer og integrationer til salgsdrevet konkurrentindsigt
Værktøjslandskabet for konkurrentindsigt i salg kan opdeles i fire lag. De fleste modne programmer bruger flere på én gang, fordi de løser forskellige problemer.
Lag
Eksempler
Hvad det løser
Passer til
Platformspakke til konkurrentindsigt med sælgerdrevet købsproces
Klue, Crayon, Kompyte
Udarbejdelse af battlecards, levering integreret i CRM, nogle gange integreret win/loss
Mellemstore virksomheder og opefter med infrastruktur til salgsdrift
Samtaleanalyse
Gong, Clari, Avoma
Registrering af konkurrentomtaler i samtaler, visning af relevant konkurrentindsigt i kontekst
Alle teams med >20 sælgere, der optager samtaler
Arbejdsplatform til konkurrentindsigt bygget til AI
Watchr, nyere udbydere
Kvalificeringsprompt for hver konkurrent, MCP-læsbart feed, lave opsætningsomkostninger
Små til mellemstore virksomheder, teams der arbejder med AI
Ændringsregistrering / specialværktøjer
Visualping, Wachete, værktøjer oven på annoncebiblioteker
Indsamling af rå signaler fra konkurrenters kanaler
Alle udviklingstrin; normalt som en komponent
Platformspakker med en sælgerdrevet købsproces står centralt i programmer hos mellemstore og store virksomheder, fordi de som standard leverer battlecards direkte i CRM, som er den kanal, der giver størst udbytte under salgsprocessen. Klue er mest integreret med salgsarbejdsgange. Crayon har den længste historik inden for registrering af hjemmesideændringer. Kompyte ligger mellem de to med stærkere overvågning af sociale medier og annoncer. Alle tre har priser og årskontrakter rettet mod store virksomheder; de er krævende at indføre for teams uden medarbejdere i salgsdriften til at understøtte dem.
Platforme til samtaleanalyse bliver i stigende grad selvstændige kanaler for konkurrentindsigt. Muligheden i Gong for at markere konkurrentomtaler i samtaler og vise det relevante battlecard-uddrag under samtalegennemgangen er en af de få oplevelser med konkurrentindsigt i kontekst, som sælgere faktisk bruger af sig selv. Hvis I allerede bruger Gong eller en tilsvarende platform, så undersøg, hvilke funktioner til konkurrentindsigt der er inkluderet i jeres nuværende abonnement, før I køber mere.
Arbejdsplatforme til konkurrentindsigt bygget til AI er den nyere kategori. De er organiseret omkring en LLM-kvalificeringsprompt for hver konkurrent frem for regelbaserede filtre og har MCP-læsbar levering, så AI-assistenter kan forespørge kvalificeret konkurrentindsigt direkte. De passer til salgsorganisationer i små og mellemstore virksomheder, der ikke har budget til en stor virksomheds løsning til konkurrentindsigt og er ved at opbygge interne arbejdsgange med AI. Selvbetjente prismodeller gør en væsentlig forskel for muligheden for at få opbakning i en organisation med 10 til 30 sælgere.
Værktøjer til ændringsregistrering og andre specialværktøjer passer ind under alle ovenstående som laget til rå signaler. Et velfungerende program bruger sjældent kun specialværktøjer, fordi der mangler et kvalificeringslag; forholdet mellem signal og støj forbliver for lavt for sælgerne.
Sådan måler du, om programmet virker
De fleste programmer for konkurrentindsigt i salg rapporterer på de forkerte målepunkter. "Battlecards udgivet dette kvartal" er et tal uden reel værdi. "Sælgere trænet i positionering mod konkurrenter" er en trænings-KPI, ikke et mål for programmets tilstand. Fem målepunkter hænger faktisk sammen med programmets effektivitet.
Målepunkt
Definition
Hyppighed
Ansvarlig
Vinderate mod konkurrenter
Vinderate for salgsmuligheder, hvor en registreret konkurrent var med
Månedligt
Salgsledelsen gennemgår; RevOps registrerer
Battlecards' aktualitet
Medianen for antal dage siden seneste opdatering på tværs af aktive battlecards
Ugentligt
PMM har ansvaret; RevOps viser det i dashboardet
Antal forespørgsler om konkurrentindsigt til AI-assistenten
Antal forespørgsler om konkurrentindsigt, som sælgerne sender til den interne assistent pr. uge
Andel af salgsmuligheder lukket som tabt med et udfyldt felt for konkurrent ved afslutning og et salgsnotat
Månedligt
RevOps har ansvaret
Tid til opdatering efter et konkurrencetiltag
Timer mellem et væsentligt konkurrencetiltag (ændret prisniveau, lancering) og opdateringen af battlecardet
Pr. hændelse
PMM har ansvaret; salgsunderstøttelse kontrollerer
To principper går igen i alle fem. De handler alle om brug og aktualitet, ikke om produktion. Og de er alle tidlige indikatorer for vinderaten mod konkurrenter, ikke bagudskuende trofæer. Formålet med at måle er at finde ud af, hvilken kanal i programmet der svigter, ikke at fejre, at programmet findes.
Programmer, der når sunde niveauer for aktualitet, antal forespørgsler og registreringsgrad, ser typisk vinderaten mod konkurrenter stige med 4 til 8 procentpoint over to til tre kvartaler. Programmer, der ikke gør, stagnerer typisk eller går tilbage, uanset hvor meget der investeres i indhold.
Mønstre, der kvæler brugen
Fem tilbagevendende mønstre varsler, at programmet vil fejle, uanset teamets størrelse.
Battlecard-som-PDF-mønstret. En flot designet PDF, der udsendes i starten af et kvartal, åbnes to gange og derefter glemmes. PDF'er er statiske, kan ikke gennemsøges af AI-assistenter, kan ikke gennemsøges med grep af nogen og er adskilt fra den CRM-brugerflade, hvor sælgerne arbejder. Hvis jeres program leverer PDF'er, er næste ændring at udfase dem.
Fantasien om én fælles sandhedskilde. Troen på, at "hvis vi bare samler alt i ét værktøj, vil sælgerne bruge det". Sælgere arbejder i 5 til 8 brugerflader om dagen. Konkurrentindsigten skal møde dem dér frem for at trække dem ind i en sjette. Levering på tværs af brugerflader er ikke fragmentering; det er den eneste model, der virker.
PMM-har-ansvar-for-alt-mønstret. Når PMM bliver bedt om at have ansvar for indhold, indsamling, videresendelse og brug på samme tid, går programmet i stå. PMM er en indholdsfunktion. De tre andre opgaver er driftsopgaver. Fordel arbejdet, ellers bliver det ikke gjort.
Mønstret med fraværende ledelse. Programmer uden en CRO eller VP of Sales, der hver måned gennemgår win/loss mod konkurrenter, klarer sig markant dårligere end programmer, der har en. Branchedata peger på en forbedring af effektiviteten på cirka 76%, når denne gennemgang finder sted. Det koster en time om måneden fra én leder og ændrer næsten alt i det efterfølgende arbejde, fordi det fortæller sælgerne, at de data, de registrerer, faktisk bliver læst.
"Vi måler, når vi har lanceret"-mønstret. Programmer, der udskyder opsætningen af målinger til fase to, får den aldrig gjort. Win/loss-feltet, dashboardet over battlecards' aktualitet og målingen af AI-forespørgsler skal være klar sammen med programmet, ikke bagefter. Hvis I ikke måler på dag 30, måler I heller ikke på dag 300.
Næste skridt
Hvis du bygger et program for konkurrentindsigt i salg fra bunden, afgør seks tiltag i de første 60 dage, om det overlever året.
Udpeg de fire ansvarlige. PMM, RevOps, salgsunderstøttelse og salgsledelse. Selv om én person har to roller, skal rollefordelingen være skriftlig.
Tilføj feltet konkurrent ved afslutning i jeres CRM med en overskuelig rullemenu. Gør det obligatorisk, når en salgsmulighed lukkes som tabt.
Vælg den primære leveringskanal under salgsprocessen, og opsæt måling af brugen. Battlecards integreret i CRM til mellemstore virksomheder og opefter; AI-assistent via MCP/API til teams, der arbejder med AI; helst begge dele.
Opret Slack-kanaler for hver prioriteret konkurrent. Tre til fem, ikke femten.
Planlæg den månedlige win/loss-gennemgang med ledelsen. Læg den i CRO'ens kalender, før I lancerer noget andet.
Opsæt de fem målepunkter. De behøver ikke være perfekte fra dag ét; de skal være der.
Hvis du vil se, hvordan en arbejdsplatform til konkurrentindsigt bygget til AI ser ud som leveringslag i et program for konkurrentindsigt i salg, er Watchr gratis under den åbne beta. Det MCP-læsbare feed og kvalificeringsprompten for hver konkurrent er bygget omkring den arkitektur, denne artikel argumenterer for.
Ofte stillede spørgsmål
Hvem bør have ansvaret for et program for konkurrentindsigt i salg: PMM, RevOps, salgsunderstøttelse eller salg?
Alle fire med en tydelig ansvarsfordeling. PMM har ansvaret for indhold og positioneringsgrundlag. RevOps har ansvaret for dataregistrering og videresendelse. Salgsunderstøttelse har ansvaret for brugen. Salgsledelsen har ansvaret for feedbacksløjfen og opbakningen fra ledelsen. Den hyppigste fejl er at bede én funktion om at have ansvar for alle fire.
Hvad er det mindste brugbare program for konkurrentindsigt i salg til et team med under 30 sælgere?
Et obligatorisk CRM-felt for konkurrent ved afslutning, tre til fem Slack-kanaler for hver prioriteret konkurrent, ét vedligeholdt battlecard for hver prioriteret konkurrent i Notion eller jeres CRM (ikke PDF) og en AI-assistent eller copilot forbundet med indholdet i battlecards. Spring værktøjer til store virksomheder over i denne størrelse; værktøjer bygget til AI kombineret med samtaleanalyse dækker behovene.
Hvordan får vi sælgerne til faktisk at bruge battlecards?
Forkert spørgsmål. Det rigtige spørgsmål er, hvordan indholdet fra battlecards placeres dér, hvor sælgerne allerede arbejder (CRM, Slack, AI-assistent, samtalegennemgang), så de ikke skal "bruge battlecards" som en separat aktivitet. Brugen afhænger af, om kanalen passer til arbejdet, ikke af træningsintensiteten.
Hvor passer Gong ind i et program for konkurrentindsigt i salg?
Gong (eller et andet værktøj til samtaleanalyse) er en selvstændig kanal for konkurrentindsigt. Registrering af konkurrentomtaler, visning af battlecards i kontekst og uddrag med konkurrentindsigt under samtalegennemgang er alle mere nyttige, end de umiddelbart ser ud. Hvis I allerede bruger Gong, så gennemgå, hvilke funktioner til konkurrentindsigt der er inkluderet i jeres abonnement, før I køber flere værktøjer.
Hvor ofte bør salgsledelsen gennemgå win/loss-data om konkurrenter?
Månedligt. Hyppigheden betyder mindre end regelmæssigheden. Signalet til sælgerne er, at de data, de registrerer, bliver læst på ledelsesniveau.
Bør salgsunderstøttelse eller RevOps drive programmet?
Ingen af dem alene. Salgsunderstøttelse driver brugen og træningen. RevOps driver opsætningen af målinger og valget af værktøjer. Programmer, der vælger den ene og ignorerer den anden, klarer sig dårligere end programmer med en tydelig fordeling.
Hvad er den største fejl, nye programmer for konkurrentindsigt i salg begår?
At levere indhold, før leveringskanalerne er på plads. Velskrevne battlecards i brugerflader, som ingen sælgere besøger, er den hyppigste årsag til fiasko. Byg leveringsarkitekturen først; indholdet passer ind i den bagefter.
