Hver feilkonfigurerte import, ødelagte workflow og upålitelige rapport i HubSpot kan spores tilbake til samme rotårsak: en datamodell som ikke ble satt opp med intensjon.
Er du HubSpot-administrator eller RevOps-fagperson, er datamodellen din fundamentet alt annet hviler på — automatiseringene dine, rapportene dine, teamets evne til å stole på det de ser i CRM-et.
Får du den riktig, fungerer HubSpot slik det skal. Får du den feil, bruker du tiden din på å lappe problemer i stedet for å bygge systemer som skalerer.
Denne guiden tar deg gjennom hele HubSpot-datamodellen fra grunnen av.
Vi dekker hvordan HubSpot strukturerer data, hva som følger med rett ut av boksen, hvordan objekter relaterer til hverandre gjennom assosiasjoner, hvordan du bruker Data Model Builder, og når og hvordan du utvider modellen din med egendefinerte objekter.
Enten du setter opp en ny portal eller arver en rotete en, er dette referansen du trenger.
Hvordan HubSpot-datamodellen fungerer
Før du konfigurerer noe i HubSpot, hjelper det å forstå hva som faktisk skjer under panseret. HubSpots CRM er en relasjonsdatabase med et visuelt grensesnitt på toppen.
Terminologien er annerledes enn det en utvikler eller dataanalytiker ville brukt, men konseptene mapper direkte.
Et objekt i HubSpot tilsvarer en tabell i en database. Det er en datakategori — kontakter, selskaper, avtaler eller ethvert egendefinert objekt du oppretter. Tenk på det som en arkivskuff for én type informasjon.
En oppføring tilsvarer en rad. Det er én enkelt post inne i et objekt — én spesifikk kontakt, ett spesifikt selskap, én spesifikk avtale. John Smith er én oppføring i kontaktobjektet.
En egenskap tilsvarer en kolonne. Den definerer hvilke data du fanger om hver oppføring — som «Fornavn», «E-post» eller «Avtalebeløp». I databasetermer er det et attributt eller felt.
En egenskapsverdi tilsvarer en celle. Det er de faktiske dataene lagret for en spesifikk oppførings egenskap — krysningspunktet mellom en rad og en kolonne. For John Smiths e-postegenskap kan verdien være «john@email.com».
Slik ser det ut som en ekte tabell, med kontaktobjektet som eksempel:
| Oppføring | Fornavn (egenskap) | E-post (egenskap) | Telefon (egenskap) |
|---|---|---|---|
| REC 001 — John Smith | John | john@email.com | +1 555 0101 |
| REC 002 — Sarah Lee | Sarah | sarah@company.com | +1 555 0202 |
| REC 003 — Mike Brown | Mike | mike@startup.io | Ikke oppgitt |
Forstår du hvordan et regneark eller en databasetabell fungerer, forstår du allerede hvordan HubSpot lagrer data.
Forskjellen er at HubSpot pakker denne strukturen inn i et visuelt grensesnitt med tidslinjer, assosiasjoner, workflows og rapporter innebygd.
Denne mentale modellen betyr noe fordi hver beslutning du tar om datamodellen din — hvilke objekter du bruker, hvilke egenskaper du oppretter, hvordan du assosierer oppføringer — i bunn og grunn er en databasedesign-beslutning. Valgene du tar her, påvirker alt nedstrøms, fra hvordan teamet ditt legger inn data til hvilke rapporter du kan bygge og hvilke automatiseringer som er mulige.
Standardobjekter: Hva som følger med rett ut av boksen
Hver HubSpot-konto kommer med et sett standardobjekter som dekker kjernedataene de fleste B2B-virksomheter trenger. Før du oppretter noe egendefinert, er det verdt å forstå hva som allerede er tilgjengelig — og sørge for at du får mest mulig ut av det.
Kontakter er menneskene i databasen din. Hvert individ — enten de er et lead, en kunde eller en partner — bor her. Kontakter er det eneste objektet du kan sende markedsførings-e-post til, noe som gjør dem sentrale i de fleste go-to-market-operasjoner.
Selskaper representerer organisasjonene kontaktene dine tilhører. I B2B er selskaper typisk der du sporer firmografiske data som bransje, antall ansatte og årlig omsetning. Kontakter assosieres til selskaper, som gir deg et klart bilde av hvem som jobber hvor.
Avtaler representerer potensiell inntekt. Hver avtale beveger seg gjennom pipeline-faser — fra innledende kvalifisering til vunnet eller tapt. Avtaler assosieres til kontakter og selskaper, som knytter hver mulighet til menneskene og organisasjonene som er involvert. HubSpots prognose- og attribusjonsrapportering er bygget på avtaleobjektet, så det kommer med muligheter egendefinerte objekter ikke kan replikere.
Saker er for å spore kundeserviceforespørsler. Som avtaler beveger saker seg gjennom pipeline-faser og assosieres til kontakter og selskaper. Håndterer teamet ditt support, onboarding eller enhver prosess etter salget med definerte faser, er saker standardverktøyet.
Leads er et nyere tilskudd. De lar salgsteam spore og kvalifisere innkommende interesse før de konverterer den til en avtale. Leads er designet for å skille tidlig prospekteringsaktivitet fra avtale-pipelinen din, som holder pipelinen renere og prognosene dine mer nøyaktige.
Utover disse fem kjerneobjektene tilbyr HubSpot også objekter du kan aktivere avhengig av bransje: Appointments, Courses, Listings og Services.
Disse er av som standard, men kan slås på i Data Model Builder hvis de passer bruksområdet ditt. Når de er aktivert, oppfører de seg som ethvert annet standardobjekt — de vises på indekssider, støtter assosiasjoner og fungerer med workflows og rapporter.
Den generelle regelen er å maksimere hva du kan gjøre med standardobjekter før du strekker deg etter egendefinerte. Standardobjekter kommer med ferdigbygde rapporter (som avtaleattribusjon og salgsprognoser), native integrasjoner og funksjoner egendefinerte objekter ikke har tilgang til.
Kan du løse problemet ditt ved å legge til egendefinerte egenskaper på et standardobjekt, er det nesten alltid den enklere og mer vedlikeholdbare veien.
Hvordan objekter relaterer: Assosiasjoner
Objekter alene er bare datatabeller. Det som gjør dem til et CRM, er relasjonene mellom dem — og i HubSpot kalles de relasjonene assosiasjoner.
En assosiasjon er en kobling mellom to oppføringer, enten innenfor samme objekt eller på tvers av ulike objekter. Når du assosierer en kontakt med et selskap, sier du «denne personen jobber i denne organisasjonen». Når du assosierer en avtale med flere kontakter, sier du «alle disse menneskene er involvert i denne muligheten».
Assosiasjoner er det som gjør rapportering på tvers av objekter mulig, det som lar workflows referere til relaterte oppføringer, og det som gir teamet ditt hele bildet når de åpner en oppføring i HubSpot. Uten riktig konfigurerte assosiasjoner er CRM-et ditt bare en samling frakoblede regneark.
Assosiasjonstyper
HubSpot støtter flere typer assosiasjoner:
Én-til-mange-assosiasjoner betyr at én oppføring på den ene siden kan koble til mange oppføringer på den andre. Et selskap kan ha mange kontakter, men i mange oppsett tilhører en kontakt ett selskap. Dette er den vanligste typen.
Mange-til-mange-assosiasjoner tillater flere oppføringer på begge sider. En avtale kan involvere flere kontakter, og en kontakt kan være involvert i flere avtaler. HubSpot støtter dette native.
Assosiasjoner innenfor samme objekt kobler oppføringer i samme objekt. Du kan assosiere to selskaper som mor og datter, eller koble to kontakter som kolleger. Disse er nyttige for å kartlegge organisasjonshierarkier eller relasjoner mellom mennesker.
Assosiasjonsetiketter
Etiketter beskriver relasjonens art. I stedet for bare å vite at en kontakt er assosiert med en avtale, lar etiketter deg spesifisere at de er «Beslutningstaker» eller «Budsjetteier». For assosiasjoner mellom selskaper kan du bruke «Morselskap» og «Datterselskap».
Etiketter gjør datamodellen din mer uttrykksfull og rapportene dine mer presise. Når en selger åpner en avtaleoppføring, kan de umiddelbart se hvem beslutningstakeren er i stedet for å scrolle gjennom en liste med tilknyttede kontakter og prøve å finne det ut.
Assosiasjonsgrenser
Du kan konfigurere grenser for hvor mange oppføringer som kan assosieres med en spesifikk etikett. For eksempel kan du sette en regel om at hver avtale bare kan ha én kontakt merket «Primærkontakt». Dette forhindrer datakvalitetsproblemer der flere personer er merket som primær, og det holder rapportene dine rene.
Hver oppføring kan ha inntil 500 assosiasjoner totalt. Treffer du stadig den grensen, er det et signal om at datamodellen din kanskje trenger restrukturering.
Å få assosiasjonene riktige fra starten
Assosiasjoner er mye enklere å sette opp riktig under den innledende konfigurasjonen enn å fikse senere. Før du bygger noe, kartlegg hvordan objektene dine relaterer til hverandre:
- Hvilke objekter må kobles sammen?
- Er relasjonen én-til-mange eller mange-til-mange?
- Trenger du etiketter for å beskrive ulike relasjonstyper?
- Finnes det grenser for hvor mange oppføringer som skal kobles med en spesifikk etikett?
Skisser dette før du begynner å konfigurere. Fem minutter på en tavle forhindrer timevis med opprydding senere.
Trenger du hjelp med å designe HubSpot-datamodellen din? Ta kontakt med Superwork — vi spesialiserer oss på HubSpot RevOps for B2B-team og kan hjelpe deg med å få assosiasjoner, objekter og egenskaper riktig satt opp fra starten.
Data Model Builder
HubSpots Data Model Builder er der du ser, administrerer og utvider datamodellen din visuelt.
Den ligger under Data Management > Data Model, og det er den viktigste enkeltskjermen i innstillingene for alle med ansvar for CRM-arkitektur.
Data Model Builder gir deg to visninger: en oversikt og en editor.
Datamodell-oversikten
Oversikten er et visuelt kart over hele CRM-strukturen din. Den viser alle objektene dine — standard, egendefinerte, salg og aktiviteter — som kort, med linjer som forbinder assosierte objekter.
Som standard, første gang du åpner den, vises alle objekter og aktiviteter i en grafvisning.
Hvert objektkort viser tre opplysninger: totalt antall oppføringer, totalt antall egenskaper og antall andre objekter det er assosiert med. Dette gir deg en rask helsesjekk av datamodellen din uten å måtte grave i individuelle innstillingssider.
Du kan filtrere visningen på objekttype med «Filter by»-nedtrekkslisten — vise eller skjule CRM-objekter, egendefinerte objekter, salgsobjekter og aktiviteter enkeltvis eller gruppevis.
Dette er spesielt nyttig hvis du har en kompleks datamodell med mange objekter og trenger å fokusere på hvordan et utvalg av dem relaterer til hverandre.
For å utforske et spesifikt objekt, klikk «View details» på kortet. Du ser fire faner:
- Usage viser antall oppføringer, prosentandelen egenskaper med data på minst én oppføring, egenskaper uten data, ubrukte egenskaper, potensielle duplikater og siste importdato.
- Properties lister alle egenskaper for det objektet, med en lenke for å administrere dem i innstillingene.
- Associations viser definerte assosiasjoner og etiketter, med en nedtrekksliste for å se spesifikke objektrelasjoner.
- Used in avslører hvilke rapporter, workflows og segmenter som refererer til dette objektet — nyttig for å forstå nedstrømseffekten av endringer du vurderer.
Du kan veksle mellom grafvisning og tabellvisning etter preferanse. Tabellvisning er spesielt nyttig når du systematisk skal gjennomgå assosiasjoner på tvers av flere objekter.
Redigere datamodellen
Klikk «Edit data model» for å gå inn i editoren, som gir superadministratorer muligheten til å:
Opprette egendefinerte egenskaper direkte fra det visuelle grensesnittet. Utvid et objekts egenskapsliste, klikk «+ Create property», fyll inn detaljene i sidepanelet, og egenskapen vises umiddelbart på det objektet. Du kan også bruke Breeze Assistant til å opprette egenskaper ved å skrive kommandoer i naturlig språk som «Create the contact property Secondary email».
Opprette egendefinerte objekter fra venstre sidefelt. Klikk «+ Create a custom object», definer objektnavnet (entall og flertall), sett opp visningsegenskaper og klikk Create. Objektet vises i datamodellen umiddelbart. (Egendefinerte objekter krever et Enterprise-abonnement.)
Konfigurere assosiasjoner mellom objekter. Velg et objekt, klikk «+»-knappen, velg hvilket objekt det skal assosieres med, og opprett koblingen. Deretter kan du legge til assosiasjonsetiketter og sette assosiasjonsgrenser — som å begrense en relasjon til én-til-mange eller sette et maksimalt antall koblede oppføringer per etikett.
Aktivere eller deaktivere objekter. Noen objekter (Appointments, Courses, Listings, Services) er av som standard. Du kan aktivere dem her, og når de er aktivert, blir de tilgjengelige på tvers av indekssider, workflows og segmenter. Du kan også deaktivere objekter du ikke trenger, og holde datamodellen din ren.
Gi objekter nye navn. Passer ikke «Deals» terminologien din og du heller vil kalle dem «Muligheter» eller «Prosjekter», kan du gi standardobjekter nye navn direkte i byggeren — ingen grunn til å opprette et egendefinert objekt bare for en navneendring.
Eksportere lerretet som et bilde. Klikk treprikkmenyen ved siden av «Data Model» og velg «Export as an image». Dette er nyttig for dokumentasjon, interessentpresentasjoner eller opplæring av nye teammedlemmer.
Analysis-fanen
Analysis-fanen ligger ved siden av oversikten og gir grafer og tabeller som viser hvordan oppføringer ble opprettet, oppdatert, slettet eller flettet over tid. Du kan filtrere på objekt, datoperiode, handlingstype (opprett, slett, oppdater, flett) og kildetype.
Det er hit du går for å svare på spørsmål som: «Hvor kommer de fleste av våre nye kontakter fra denne måneden?» eller «Hvorfor falt avtaleantallet vårt forrige uke?» Hver kilde vises som en egen linje på grafen, og du kan holde musepekeren over datapunkter for å se nedbrytninger. Tabellen under gir deg de samme dataene i et sorterbart format.
Limits-fanen
Limits-fanen viser din nåværende bruk mot abonnementets grenser for oppføringer, assosiasjoner, pipelines, egendefinerte egenskaper, beregnede egenskaper, assosiasjonsetiketter og egendefinerte objekter. Sjekk denne jevnlig — spesielt før store importer eller når du planlegger å legge til nye egendefinerte objekter — så du ikke treffer en vegg midt i prosjektet.
Egendefinerte objekter: Når og hvordan du utvider datamodellen din
Standardobjekter dekker mye, men driver du en B2B-virksomhet med noe kompleksitet, vil du til slutt treffe scenarioer der de ikke er nok.
Kanskje håndterer du leverandørrelasjoner som ikke hører hjemme i selskaper. Eller sporer programvareabonnementer som ikke passer i avtaler. Eller driver et sertifiseringsprogram der hver sertifisering trenger sin egen tidslinje, assosiasjoner og rapporter.
Det er der egendefinerte objekter kommer inn. De lar deg opprette helt nye oppføringstyper — med egne egenskaper, pipelines, assosiasjoner og automatisering — som ligger side om side med standardobjekter som fullverdige borgere i CRM-et ditt.
Egendefinerte objekter er tilgjengelige på Enterprise-nivåabonnementer på tvers av alle huber: Marketing Hub Enterprise, Sales Hub Enterprise, Service Hub Enterprise, Content Hub Enterprise, Data Hub Enterprise, Smart CRM Enterprise og Commerce Hub Enterprise.
Beslutningsrammeverket
Det er her de fleste team gjør feil. Å opprette et egendefinert objekt er enkelt. Å vite om du bør, er vanskeligere. Still deg selv disse fire spørsmålene om dataene du prøver å spore:
Trenger disse dataene sin egen tidslinje? Trenger du å logge samtaler, e-poster, møter, notater og oppgaver mot denne entiteten uavhengig — ikke bare mot en kontakt eller et selskap — er det et sterkt signal for et egendefinert objekt. Sporer du et «prosjekt» og vil se all aktivitet relatert til det prosjektet på ett sted, gir et egendefinert objekt mening.
Trenger den sine egne assosiasjoner? Relaterer denne entiteten til flere kontakter, flere selskaper eller flere avtaler — og du trenger å spore de relasjonene eksplisitt — er et egendefinert objekt riktig valg. En «leverandør» som leverer til flere selskaper og kobler til flere avtaler, er et godt eksempel.
Trenger den sine egne rapporter? Trenger du å filtrere, gruppere og analysere disse dataene uavhengig i rapporter og dashbord, gir et egendefinert objekt deg den muligheten. Å prøve å rapportere på data stappet inn i egendefinerte egenskaper på feil objekt er en frustrerende opplevelse.
Trenger den sin egen pipeline? Beveger denne entiteten seg gjennom faser — som en onboarding-prosess, et sertifiseringsløp eller en leverandørevaluering — støtter egendefinerte objekter pipelines akkurat som avtaler gjør.
Svarte du «ja» på to eller flere av disse, er et egendefinert objekt trolig riktig valg.
Når et egendefinert objekt IKKE er svaret
Ikke hvert dataproblem krever et nytt objekt. Her er de vanligste situasjonene der team oppretter egendefinerte objekter unødvendig:
Du trenger bare å kategorisere kontakter. Vil du skille mellom «studenter», «foreldre» og «lærere», bruk en egendefinert egenskap på kontakter i stedet. Å opprette et egendefinert objekt for en persontype betyr at du mister muligheten til å sende markedsførings-e-post til dem, siden masseutsendelser kun kan gå til kontakter.
Du sporer aktivitet, ikke en entitet. Vil du logge interne forespørsler eller notater, er det det HubSpots aktivitetsverktøy er til. Et egendefinert «Notater»-objekt legger til kompleksitet uten gevinst — aktiviteter kan ikke automatisk assosieres til egendefinerte objektoppføringer, og du mister ferdigbygde aktivitetsrapporter.
Et standardobjekt med egendefinerte egenskaper dekker det. Før du oppretter noe nytt, sjekk om et eksisterende objekt med noen ekstra egenskaper ville gjort jobben. Standardobjekter kommer med ferdigbygde rapporter som avtaleattribusjon og salgsprognoser som egendefinerte objekter ikke kan replikere.
Du trenger bare å gi et objekt nytt navn. HubSpot lar deg nå gi standardobjekter nye navn direkte i Data Model Builder. Passer ikke «Deals» og du heller vil kalle dem «Tilbud», gi objektet nytt navn i stedet for å opprette et egendefinert fra bunnen.
Bruksområder fra virkeligheten
Slik ser egendefinerte objekter ut i praksis, med skjemadetaljer så du kan se hvordan de ville blitt designet:
Abonnementer (SaaS-selskaper). Objektnavn: Abonnementer. Primærvisning: Abonnements-ID. Nøkkelegenskaper: plannavn, startdato, fornyelsesdato, MRR, status (aktiv/churnet/pauset), bruksnivå. Assosieres til kontakter (kontoinnehaver), selskaper (konto) og avtaler (opprinnelig salg). Du kan bygge en pipeline for å spore abonnementets livssyklusfaser, trigge fornyelsespåminnelser via workflows og rapportere på MRR per plantype — ingenting av dette passer rent inn i avtaler.
Leverandørstyring (byråer og driftsteam). Objektnavn: Leverandører. Primærvisning: Leverandørnavn. Nøkkelegenskaper: region, tjenestekategori, kontraktsverdi, ytelsesvurdering, kontraktens utløpsdato. Assosieres til selskaper (koblede kundekontoer) og avtaler (aktive kontrakter). En leverandør er ikke et selskap i CRM-et ditt — det er en underleverandør. Å spore leverandører separat lar deg rapportere på leverandørytelse, automatisere påminnelser om kontraktsfornyelse og opprettholde et klart skille mellom kunder og leverandørkjede.
Sertifiseringer (kurs og utdanning). Objektnavn: Sertifiseringer. Primærvisning: Sertifiseringsnavn. Nøkkelegenskaper: utstedelsesdato, utløpsdato, status (aktiv/utløpt/tilbakekalt), sertifiseringsnivå. Assosieres til kontakter (sertifisert person) og selskaper (arbeidsgiver). Hver sertifisering har sin egen livssyklus og trenger uavhengig sporing. Du kan trigge påminnelser om resertifisering, rapportere på sertifiseringsrater per selskap og assosiere flere sertifiseringer med én kontakt.
Kjøretøy (bilforhandlere). Objektnavn: Biler. Primærvisning: Modell. Nøkkelegenskaper: VIN, årsmodell, kilometerstand, listepris, status (nytt på lager/i forhandling/solgt). Assosieres til kontakter (kjøper, selger) og avtaler (salgstransaksjon). Hvert kjøretøy trenger sin egen oppføring med sin egen tidslinje av henvendelser. En pipeline sporer hver bil fra «Ny på lager» til «Solgt», og prospektsamtaler logges direkte mot bilens oppføring.
Beste praksis for skjemadesign
Å få skjemaet riktig fra starten sparer deg for betydelig smerte senere. Interne navn på egendefinerte objekter kan ikke endres etter opprettelse, så invester tiden nå.
Navngiving: Bruk entallsnavn for objektet ditt (f.eks. «Abonnement», ikke «Abonnementer» — HubSpot ber om både entalls- og flertallsform). Hold navnene beskrivende, men konsise. Unngå forkortelser som bare gir mening for ett team.
Primær visningsegenskap: Dette er hovedidentifikatoren — det som vises øverst på hver oppføring og i første kolonne på indekssiden. Velg noe teamet ditt umiddelbart kan gjenkjenne. Du kan velge blant enkeltlinjetekst, tall, datovelger, enkel avkrysningsboks eller nedtrekksliste. Skal oppføringer være unike (som et ordrenummer eller VIN), aktiver kravet om unike verdier.
Sekundære visningsegenskaper: Disse vises under primærvisningen på profilkortet og fungerer som hurtigfiltre på indekssiden. Velg de to eller tre viktigste attributtene teamet ditt trenger med et raskt blikk uten å åpne hele oppføringen.
Interne navn: Hver egenskap og hvert objekt har både en etikett (det brukerne ser) og et internt navn (det API-er og integrasjoner bruker). Etiketter kan endres senere, men interne navn kan ikke. Bruk tydelig snake_case-navngiving — renewal_date heller enn field_7.
Kartlegg det først: Før du oppretter noe i HubSpot, skisser datamodellen din på papir eller en tavle. Vis de egendefinerte objektene dine, nøkkelegenskapene deres og hvordan de kobler til standardobjekter. Sammenlign det deretter med den eksisterende strukturen i Data Management > Data Model. Denne femminuttersøvelsen sparer timevis med omarbeid.
Grenser og kvoter
En Enterprise-konto kan definere inntil 10 egendefinerte objekter som standard, med grenseøkninger tilgjengelig som kjøpbare tillegg. Hver oppføring støtter inntil 500 assosiasjoner. Egendefinerte objekter er utelukkende Enterprise-nivå — det finnes ingen måte å få tilgang til dem på Starter- eller Professional-planer.
Viktige begrensninger å være klar over: du kan ikke sende masseutsendte markedsførings-e-poster til egendefinerte objektoppføringer (kun kontakter støtter dette), Timeline API og Webhooks API støtter ikke egendefinerte objekter, og ferdigbygde rapporter som avtaleattribusjon og salgsprognoser er knyttet til standardobjekter.
API-begrensninger betyr også noe hvis du synkroniserer egendefinerte objektdata med eksterne systemer: Enterprise-kontoer har en daglig grense på 1 million API-forespørsler og en burst-grense på 190 forespørsler per 10 sekunder. Planlegg for batching hvis du gjør store synkroniseringer.
Bygge pipelines på egendefinerte objekter
Representerer det egendefinerte objektet ditt en prosess med faser — som en leverandørevaluering, et sertifiseringsløp eller en onboarding-flyt — vil du ha en pipeline. Hvert egendefinerte objekt støtter inntil 100 pipelines.
For å sette opp en, gå til Settings > Objects > Custom Objects, velg objektet ditt, klikk Pipelines-fanen og opprett en ny pipeline. Legg til faser som gjenspeiler prosessen din, og sett for hver fase om en oppføring skal regnes som «Åpen» eller «Lukket».
For eksempel kan en leverandørevaluerings-pipeline ha faser som «Innledende gjennomgang» (åpen), «Due diligence» (åpen), «Kontraktsforhandling» (åpen), «Godkjent» (lukket) og «Avvist» (lukket).
Betingede faseegenskaper er en av de mest nyttige funksjonene her. Dette er felter som må fylles ut før en oppføring kan flyttes til en gitt fase. Krev en «Signert kontrakt»-opplasting før en leverandør kan flyttes til «Godkjent». Krev en «Score»-egenskap før en sertifisering flyttes til «Utstedt». Dette holder dataene dine rene og sikrer at teamet ditt følger prosessen i stedet for å hoppe over steg.
Du kan administrere oppføringer i både listevisning og tavlevisning (Kanban-stil), som gir teamet ditt en visuell måte å spore fremdrift. Tilpass tavlekortene til å vise de mest relevante egenskapene for hver pipeline, slik at teamet ser det som betyr noe uten å åpne hver oppføring.
Bruk Automate-fanen på pipelinen din til å sette opp fasebasert automatisering — som å automatisk opprette en oppgave når en oppføring går inn i en spesifikk fase, eller sende et internt varsel når en oppføring flyttes til «Godkjent». Du kan også bruke Pipeline Rules (tilgjengelig for superadministratorer) for å håndheve datakvalitet i hver fase.
Etter hvert som prosessene dine utvikler seg, revider pipeline-fasene. Du kan gi nye navn, endre rekkefølge, legge til eller slette faser uten å miste data. Sletter du en fase med eksisterende oppføringer, må du flytte dem til en annen fase først.
Rapportering på tvers av datamodellen din
Datamodellen din avgjør direkte hvilke rapporter du kan bygge. Jo mer intensjonelt du har strukturert objektene og assosiasjonene dine, jo mer nyttig blir rapporteringen din.
Enkeltobjektrapporter lar deg analysere ett objekt isolert — hvor mange aktive abonnementer du har per plantype, hvordan leverandørevaluerings-pipelinen din utvikler seg, eller hvilke kontakter som ble opprettet denne måneden per kilde. Du kan filtrere på enhver egenskap, gruppere på faser eller kategorier og visualisere som diagrammer eller tabeller.
Rapporter på tvers av objekter er der den virkelige verdien bor. Disse kombinerer data fra flere objekter for å svare på spørsmål som «Hvilke selskaper har flest aktive abonnementer?» eller «Hva er gjennomsnittlig avtalestørrelse for avtaler knyttet til våre best presterende leverandører?» Rapporter på tvers av objekter krever at objektene er skikkelig assosiert — er to objekter ikke koblet, kan du ikke rapportere på tvers av dem.
For å bygge rapporter på tvers av objekter, legg til objektene dine som datakilder i HubSpots tilpassede rapportbygger. Byggeren viser hvilke objekter som kan kombineres basert på dine eksisterende assosiasjoner.
Vanlige rapporteringsfeller å se opp for:
Ferdigbygde rapporter (avtaleattribusjon, salgsprognoser) er knyttet til standardobjekter og fungerer ikke med egendefinerte objekter. Du må bygge tilpassede rapporter fra bunnen for alle egendefinerte objektdata.
Egenskapstyper påvirker tilgjengelige visualiseringer. Numeriske egenskaper gir deg summer, gjennomsnitt og diagrammer. Tekstegenskaper gir deg tellinger og grupperinger. Velg egenskapstyper med rapportering i tankene under skjemadesignet — det er mye enklere å få dette riktig fra starten enn å migrere data mellom egenskapstyper senere.
Manglende assosiasjoner er den vanligste årsaken til «jeg får ikke bygget rapporten jeg trenger». Viser ikke rapporten din på tvers av objekter dataene du forventer, sjekk at de relevante oppføringene faktisk er assosiert. En avtale som ikke er koblet til et selskap, vises ikke i en avtaler-per-selskap-rapport, uansett hvordan du konfigurerer den.
Når du har bygget nøkkelrapporter, legg dem til et dedikert dashbord. Dette gir teamet ditt ett sted å overvåke data uten å bygge ad hoc-rapporter hver gang noen har et spørsmål.
Automatisering med datamodellen din
Egendefinerte objekter støtter workflow-automatisering akkurat som standardobjekter.
Du kan opprette workflows basert på egendefinerte objekter som trigges på oppføringsopprettelse, egenskapsendringer, faseoverganger i pipeline eller assosiasjonsoppdateringer.
Vanlige automatiseringsmønstre:
Når en abonnementsoppførings «fornyelsesdato» er 30 dager unna, opprett en oppgave for kundeansvarlig og send et internt Slack-varsel.
Når en leverandøroppføring flyttes til pipeline-fasen «Godkjent», sett automatisk egenskapen «Godkjenningsdato» og varsle innkjøpsteamet. Når en ny sertifiseringsoppføring opprettes og assosieres med en kontakt, oppdater en egenskap på kontaktoppføringen for å gjenspeile sertifiseringsstatusen deres.
Tilgjengelige triggere inkluderer: en egendefinert objektoppføring opprettes, en egenskapsverdi endres, en oppføring går inn i eller forlater en pipeline-fase, og en assosiasjon opprettes eller fjernes.
Tilgjengelige handlinger inkluderer: å sette egenskapsverdier, opprette oppgaver, sende interne varsler og e-poster, legge til eller fjerne assosiasjoner, melde oppføringer inn i andre workflows og forgreningslogikk basert på egendefinerte objektegenskaper.
Begrensninger å huske på: Du kan ikke bruke egendefinerte objekter som trigger for en kontaktbasert workflow — workflow-typen må matche objekttypen.
Timeline API og Webhooks API støtter ikke egendefinerte objekter, som begrenser noen integrasjonsscenarioer. Og noen tredjepartsverktøy støtter kanskje ikke egendefinerte objekter i HubSpot-integrasjonene sine ennå, så sjekk kompatibiliteten før du bygger komplekse automatiseringskjeder.
For pipeline-spesifikk automatisering, bruk Automate-fanen i pipeline-innstillingene i stedet for å bygge separate workflows. Dette holder den fasebaserte logikken samlokalisert med pipeline-konfigurasjonen, som gjør den enklere å administrere og feilsøke.
Vedlikeholde datamodellen din over tid
Å bygge datamodellen din er startpunktet. Å holde den ren og nyttig etter hvert som virksomheten din utvikler seg, krever løpende oppmerksomhet.
Kjør kvartalsvise revisjoner. Gjennomgå objektene, egenskapene og pipelinene dine minst hvert kvartal. Bruk Usage-fanen i datamodell-oversikten til å identifisere egenskaper uten data, ubrukte egenskaper og potensielle duplikater. Arkiver det du ikke trenger. En slank datamodell er en rask datamodell — for teamet ditt og for HubSpots ytelse.
Dokumenter alt. Skriv ned hva hvert objekt representerer, hva egenskapene betyr, hvordan det relaterer til andre objekter, og hvorfor det ble opprettet. Lagre denne dokumentasjonen et sted hele teamet ditt har tilgang. Når noen ny begynner i teamet eller en prosess endres, sparer denne dokumentasjonen timevis med forvirring. Data Model Builders eksportfunksjon er et godt startpunkt — eksporter lerretet ditt som et bilde og annotér det.
Lær opp teamet ditt. Egendefinerte objekter og nøye designede datamodeller leverer bare verdi hvis folk bruker dem riktig. Kjør en kort opplæringsøkt når du lanserer et nytt objekt eller gjør betydelige endringer. Fokuser på hvorfor objektet finnes og hvordan det hjelper dem — ikke bare mekanikken i å fylle ut felter.
Overvåk Analysis-fanen. Bruk Analysis-fanen i Data Model Builder til å spore hvordan oppføringer opprettes, oppdateres og slettes over tid. Uventede topper i slettinger eller et fall i nye oppføringer kan signalisere prosessbrudd eller integrasjonsproblemer før de blir større problemer.
Sjekk grensene dine jevnlig. Etter hvert som antall oppføringer vokser, hold øye med Limits-fanen i Data Model Builder. Vit hvor du står på oppføringer, assosiasjoner, egenskaper og egendefinerte objekter, slik at du aldri blir overrasket midt i et prosjekt. Nærmer du deg grensene, vurder om datamodellen din trenger restrukturering eller om en grenseøkning gir mer mening.
Iterer med intensjon. Virksomheten din vil endre seg, og datamodellen din bør endre seg med den. Legg til nye egenskaper når det er et klart behov. Finpuss pipeline-faser når prosesser utvikler seg. Men motstå trangen til å legge til kompleksitet for kompleksitetens skyld — hver ny egenskap og assosiasjon er noe teamet ditt må vedlikeholde.
Få HubSpot-datamodellen din til å jobbe for deg
HubSpot-datamodellen din er ikke bare en innstillingsskjerm — det er arkitekturen hver rapport, workflow og salgsprosess avhenger av.
Teamene som får mest ut av HubSpot, er de som behandler datamodellen sin som et levende system: designet med intensjon, gjennomgått regelmessig og videreutviklet etter hvert som virksomheten vokser.
Start med det grunnleggende. Forstå hvordan objekter, oppføringer, egenskaper og assosiasjoner jobber sammen. Få mest mulig ut av standardobjekter før du strekker deg etter egendefinerte.
Når du oppretter egendefinerte objekter, bruk beslutningsrammeverket for å sikre at de gjør seg fortjent til plassen. Design skjemaet ditt nøye, kartlegg assosiasjonene dine bevisst, og invester i rapportene og automatiseringen som gjør rådata om til operasjonell verdi.
Data Model Builder er cockpiten din for alt dette. Bruk den til å visualisere strukturen din, overvåke bruken din, oppdage hull og gjøre endringer med trygghet.
Setter du opp en ny HubSpot-portal, arver en rotete en, eller planlegger å utvide datamodellen din med egendefinerte objekter, ta kontakt med Superwork. Vi spesialiserer oss på HubSpot RevOps for B2B-team — fra datamodelldesign og migrering til rapportene og automatiseringen som får alt til å fungere.