Slik skriver du en RFP for en kundedataplattform

Trenger du en RFP?

Bruk en RFP når du bruker et sekssifret beløp, håndterer regulerte data eller koordinerer mange team på tvers av merkevarer eller regioner. Hvis du må oppfylle kravene i GDPR, HIPAA eller SOC 2, trenger økonomi-, juridisk- og sikkerhetsteamene de samme svarene fra alle CDP-leverandører. Tydelige standarder for datahåndtering og forventninger til datakvalitet bør spesifiseres for å beskytte kundenes tillit og kundeengasjement.

Å erstatte en eldre martech-stakk, integrere flere systemer eller signere SLA-er over flere år krever også sammenlignbare tilbud og et tydelig revisjonsspor. Hvis dette høres ut som deg, bør du se etter disse signalene:

• Du behandler PHI/PII; GDPR-, HIPAA- og PCI-omfang gjelder (strenge krav til datavern og logging av samtykke)
• Du konsoliderer mer enn 10 systemer på tvers av regioner, merkevarer og team
• Du trenger identitetsoppløsning i sanntid på tvers av nett, apper, sosiale medier og POS
• Du krever en InfoSec-gjennomgang av leverandøren og en DPIA sammen med juridisk avdeling
• Du planlegger en flerårig kontrakt på over $250k med tjenester

Hvis du først og fremst prøver å forbedre kundeopplevelsen – for eksempel med mer relevante markedsføringskampanjer eller bedre orkestrering av kundereisen – kan en RFP tydeliggjøre ventetid, skalerbarhet og aktiveringsfunksjonalitet som påvirker resultatene.

Når en RFP kan være unødvendig omfattende

Hvis du er et lite team med én datakilde og noen få kanaler, eller du validerer det grunnleggende uten PII, bør du hoppe over RFP-en og gjennomføre en kort pilot. I så fall kan du begynne med en enkel sjekkliste for evaluering av CDP-er og et avgrenset omfang med fokus på grunnleggende datainnsamling og aktivering.

Hvis dette gjelder deg, kan du begynne med å se på mine beste anbefalinger her:

RFI vs RFP vs RFQ: Hva er forskjellen?

Bruk en RFI for å lære om markedet og leverandørenes kapasitet, en RFP for å få fullstendige tilbud basert på definerte behov, og en RFQ for å innhente faste priser på en fastsatt spesifikasjon. Ikke alle innkjøp trenger en RFP – velg det enkleste dokumentet som besvarer spørsmålene dine, slik at du kan effektivisere arbeidet og redusere friksjon. Slik skiller de seg fra hverandre ved første øyekast:

Vanlige RFP-feil du bør unngå

Hvis du haster gjennom eller hopper over viktige detaljer i en RFP, skaper det forvirring, sløser med tiden og tiltrekker leverandører som ikke passer, når du skal velge en kundedataplattform. Hvis du unngår noen vanlige feil, får teamet ditt mer presise tilbud og en smidigere utvelgelsesprosess.

Her er det du bør se etter, og hvordan du kan løse det:

Utilstrekkelig bakgrunn eller kontekst

Leverandørene kan ikke beregne datamengder eller kartlegge integrasjoner hvis du ikke deler stakkdiagrammer, sentrale datakilder, identitetsregler, volumer, regioner og samsvarsbehov. Du vil få svært ulike forslag, forsinkelser og endringsordrer. Del en arkitekturoversikt på én side, eksempelskjemaer, månedlige antall hendelser og profiler samt målscenarier for orkestrering, slik at leverandørene gir tilbud på det samme.

Uklart eller manglende budsjett

Hvis du skjuler budsjettet, tilbyr leverandørene enten pakker i toppklassen eller setter prisen urealistisk lavt, og du kaster bort tid. Oppgi et budsjettintervall, kontraktslengde og rammer, og vis til realistiske referanseverdier fra priser på kundedataplattformer. Be om grunnpris pluss alternativer basert på volumene og SLA-ene dine.

Vage krav eller juridisk sjargong

Uklare forespørsler som «innsikt i sanntid» fører til innhold uten substans, mens tett juridisk tekst skjuler det du trenger. Skriv 5–10 konkrete aktiveringsscenarier med inndata, mål for forsinkelse og suksesskriterier (f.eks. automatisk undertrykking av målgrupper med risiko for kundefrafall). Flytt standardiserte juridiske vilkår til et vedlegg.

Evalueringskriterier som ikke er delt

Hvis du ikke viser hvordan du skal gi poeng, gjetter leverandørene og legger inn ekstra marginer. Publiser et enkelt, vektet poengskjema (f.eks. egnethet for aktivering, integrasjoner, sikkerhet/samsvar, tjenester, totalkostnad), og be leverandørene knytte svarene til disse delene, slik at du raskt kan sammenligne dem.

Ingen standardformat for leverandørsvar

Friformede PDF-er gjør det vanskelig og tidkrevende å sammenligne tilbud på like vilkår og gi poeng. Bruk en RFP-mal for CDP med tabeller (integrasjoner, volumer, SLA-er, roller, prisgrunnlag) samt en kort del om «tilnærming», slik at du beholder strukturen uten å begrense nyttige detaljer. Overfør den til poengskjemaet ditt.

Sett sammen RFP-teamet for kundedataplattformen

En god RFP er ikke en solojobb; de beste gjenspeiler reelle behov fra hele organisasjonen. Når du involverer de riktige personene tidlig, reduserer du risikoen, unngår omarbeid og får raskere beslutninger.

Prosjekteier

Fastsetter resultater knyttet til kundesuksess og inntektsvirkning. Vedkommende godkjenner budsjettet og fjerner hindringer, slik at du kan gjennomføre prosessen på en smidig måte. Eksempler: CMO, VP Growth, Chief Data Officer, CIO, Head of Digital

Fageksperter

Praktiske spesialister som kjenner dataene, verktøyene og begrensningene. De dokumenterer mønstre for datainnsamling, volumer, identitetsregler, integrasjoner, SLA-er og samsvar, slik at leverandørene dimensjonerer arbeidet riktig. Eksempler: leder for markedsføringsdrift, leder for datateknikk, løsningsarkitekt, analyseleder, sikkerhetsleder

Innkjøpsansvarlige eller RFP-forfattere

De håndterer kommunikasjon, NDA-er og vilkår og sørger for at retningslinjer følges og at revisjonssporet er ryddig. De har ansvaret for RFP-prosessen, svarmalen, prisarket og poengkriteriene.

Sluttbrukere og interessenter

Disse personene bruker verktøyet daglig og definerer praktiske aktiveringsbehov som forbedrer kundeengasjementet. Eksempler: Ansvarlig for livssyklusmarkedsføring, CRM-ansvarlig, PM for produktvekst, leder for kundeopplevelsesdrift, driftsansvarlig for kundestøtte.

Definer krav og mål

Før dere sender en RFP, må dere samkjøre smertepunkter, mål og ufravikelige krav for å sikre at leverandørene svarer nøyaktig.

• Smertepunkter med dagens system. Hva gjør arbeidet tregere – 24-timers forsinkelser i batchkjøringer, sårbare integrasjoner, duplikate profiler? (f.eks. e-post- og appdata kobles ikke sammen; sammenslåing av identiteter mislykkes for telefonnumre; aktivering på tvers av kanaler gjøres manuelt).
• Nødvendige forbedringer og ønskede resultater. Hvordan skal «bra» se ut etter 90 dager og 12 måneder? (f.eks. hente inn hendelser på 5 minutter, optimalisere markedsføringskampanjer med bedre segmentering, eliminere manuell eksport).
• Funksjonelle, tekniske og regulatoriske behov. Oppgi integrasjoner, forsinkelse og sikkerhetsregler. (f.eks. synkronisering med CRM og annonser daglig, SSO/SAML, SOC 2, loggføring av samtykker, 24 måneders oppbevaring).
• Brukerroller, bruksnivåer og arbeidsflyter. Hvem bruker løsningen, og til hvilke oppgaver? (f.eks. 25 markedsførere som kjører automatiserte kundereiser; fem analytikere som bygger en samlet kundeprofil).
• Preferanser for utrulling. Hvor og hvordan bør løsningen kjøres for å passe risikoprofilen og veikartet deres? (f.eks. EU-region, VPC, privat lenke, datavarehus først med BigQuery, ingen SDK i iOS hvis det kan unngås).

Skriv RFP-en for kundedataplattformen

Dere har samkjørt mål og krav; nå skal dette settes inn i en tydelig og strukturert RFP for kundedataplattformen som teamet og leverandørene kan følge.

1. Sammendrag - Oppgi hvem dere er, hva dere ønsker å oppnå og hvorfor dere gjør dette nå. Fremhev 2–3 prioriterte aktiveringsscenarioer, datamengden, budsjettintervallet og ønsket tidsplan. Del beslutningsprosessen og hvem som gir endelig godkjenning. Eksempel: «Samle nett- og butikkdata på 6 måneder for å muliggjøre livssykluskundereiser; budsjett $250k–$400k; kortliste om 6 uker.»
2. Arbeidsomfang - List opp hva som er innenfor og utenfor omfanget i hver fase, slik at leverandørene kan beregne arbeidet riktig. Beskriv kanalene (e-post, app, sosiale medier), regionene og områdene dere skal prioritere først. Ta med forventede volumer og nødvendige leveranser, for eksempel orkestrering av kundereiser og samordning av profiler.
3. Tekniske krav - Beskriv dataintegrasjonsmønstre, nødvendige API-er/SDK-er og mål for forsinkelse (f.eks. under ett minutt for utløsere i sanntid). Definer identitetsregler, skjemakrav og tilkobling til datavarehus. Oppgi SSO, RBAC, revisjonslogger og forventet skalerbarhet for ulike volumtrinn. Del eksempler på nyttelaster og et enkelt diagram over teknologistakken.
4. Leverandørkvalifikasjoner - Be om bransjerelevant erfaring og to referanser. Be om dokumentasjon på tidligere migreringer, en kort del med kundehistorier og nøkkeltall samt informasjon om bemanningen for leveransen. Inviter leverandørene til å dele relevante webinarer eller workshop-er som viser produktfunksjonalitet.
5. Sikkerhets- og samsvarsbehov - Spesifiser SOC 2 Type II, ISO 27001, kryptering, tilgangskontroller og samtykke. Oppgi krav til dataresidens, oppbevaring, tidsfrister for varsling ved brudd og loggføring av samtykker. Fremhev krav til forvaltning av førstepartsdata og overvåking av datakvalitet.
6. Forventninger til implementering og opplæring - Presenter milepæler, ansvarlige og arbeidsfordelingen. Definer miljøer, sprintfrekvens, UAT og kriterier for produksjonssetting. Be om driftsveiledninger og rollebasert opplæring for markedsførere (kundereisebygging, segmentering) og analytikere (skjema, modellering).
7. Prising og lisensiering - Fortell leverandørene nøyaktig hvordan prisen skal beregnes: antall brukere, hendelsesvolumer, miljøer, integrasjoner og tjenester. Be om grunnpris, implementering, tillegg, trinn for overskridelse og prisbinding. Be om en TCO-tabell og oppgi eventuell pilotprising.
8. Kontraktsvilkår - List opp ufravikelige vilkår: SLA-er og kreditter, oppetid, responstider for kundestøtte og oppsigelsesrettigheter. Ta med dataeierskap, eksport ved avslutning, immaterielle rettigheter, revisjonsrettigheter og varsler om underleverandører.
9. Instruksjoner for innsending - Oppgi svarmalen og formatene – helst den standardiserte RFP-malen for kundedataplattformen – samt sidebegrensninger for å holde svarene konsise.

Definer evalueringskriteriene dine

Tydelige kriterier sikrer at beslutningen din er objektiv og knyttet til resultater som kundeopplevelse og påvirkning på kundereisen.

Hva er viktigst? 

Velg kategorier som er knyttet til verdi: egnethet for aktivering, integrasjoner, ID-regler, sikkerhet og samsvar, brukervennlighet, tjenester og kundestøtte, totale kostnader og evnen til å effektivisere arbeidsflyter. Dette hjelper deg med å sikre at du maksimerer fordelene med en kundedataplattform.

Bruk en poengmatrise

Vekt kategoriene, og gi deretter poeng fra 1–5 eller 1–10. Definer hva en «5» sammenlignet med en «3» innebærer for hvert kriterium, inkludert dokumentasjon på aktivering på tvers av kanaler og opprettelse av en enhetlig kundeprofil.

Avklar poenggivingsprosessen

Utnevn ansvarlige: Datateknikk vurderer integrasjoner, markedsføring vurderer aktivering og innsikt i kundeatferd, og sikkerhet vurderer samsvar.

Send ut RFP-en for kundedataplattformen

Utsendelsen av RFP-en er bare halve jobben; detaljene i gjennomføringen er viktige.

1. Velg distribusjonsmetode: E-post, en RFP-plattform eller innkjøpsportalen din – velg én og hold deg til den. Bruk en sentral spørsmål-og-svar-logg slik at alle CDP-leverandører får de samme svarene.
2. Fastsett tydelige forventninger til tidsplanen: Publiser datoer (med tidssone) for utsendelse, spørsmål og svar, innsending og demonstrasjoner. Bestill tidspunkter for demonstrasjoner på forhånd, og be om et forløp som gjenspeiler aktiveringsorkestreringen din (inntak → ID → aktivering).
3. Definer kravene til innsending: Angi godkjente formater og hvordan filer skal navngis. Krev separate beskrivelser av sikkerhet og priser, og be leverandørene knytte funksjonene til milepælene i veikartet ditt.

Evaluer og lag en kortliste over leverandørsvar

Gjør forslagene om til en velbegrunnet kortliste.

• Organiser og formater forslagene for gjennomgang. Standardiser dem i malen din slik at delene samsvarer.
• Bruk en poengmatrise. Bruk vekting og godkjent/ikke godkjent-kriterier for samsvar og kritisk funksjonalitet.
• Planlegg demonstrasjoner og intervjuer. Sett av 60–90 minutter med fokus på utløsere i sanntid, automatiserte kundereiser, segmentering og analyse som gir innsikt i kundeatferd.
• Kontroller referanser. Bekreft hvor raskt kundestøtten svarer, og om det finnes uventede forhold knyttet til tidsplan eller kostnader.
• Avklar åpne punkter. Send en nummerert liste, og be om oppdaterte forutsetninger når svarene påvirker omfanget.

Velg og varsle leverandørene

Avslutt prosessen på en ryddig måte for å opprettholde fremdriften.

1. Varsle valgte og ikke valgte leverandører – Del beslutningene raskt og respektfullt, med overordnet tilbakemelding som kan hjelpe ved fremtidige tilbud.
2. Forbered de endelige forhandlingene – Fokuser på SLA-er, trinnvise priser ved overskridelser, forpliktelser knyttet til personvern, rettigheter til eksport og grenser for fornyelse.
3. Sikre intern enighet før signering – Sørg for godkjenninger fra ledelsen, juridisk avdeling og sikkerhetsavdelingen. Oppsummer de viktigste beslutningsfaktorene: aktiveringshastighet, egnethet for målgruppesegmenter og påvirkning på kundesuksess.

Hva skjer nå?

Hvis du undersøker en kundedataplattform, kan du ta kontakt med en SoftwareSelect-rådgiver for kostnadsfrie anbefalinger. Du får en kortliste tilpasset teknologistakken og målene dine, samt støtte gjennom hele kjøpsprosessen – fra den innledende CDP-evalueringen til kontraktsinngåelsen – slik at du kan optimalisere tiden frem til verdiskaping.

Du fyller ut et skjema og har en kort samtale der de går gjennom behovene dine i detalj. Deretter får du en kortliste over programvare du kan vurdere. De støtter deg til og med gjennom hele kjøpsprosessen, inkludert prisforhandlinger.