RealtyFlow og Nexus: Fra egne behov til en felles AI-plattform

Hvilket problem forsøker RealtyFlow å løse?

I en eiendomsvirksomhet kan én kundehenvendelse berøre boligdata, områdevurderinger, visninger, e-post, markedsføring og videre oppfølging. Når disse oppgavene håndteres i separate verktøy, mister man lett historikk og bruker tid på å overføre informasjon manuelt.

Det første viktige spørsmålet var derfor ikke hvilke AI-funksjoner som kunne bygges. Det var hvilke beslutninger rådgiveren faktisk må ta, og hvilken informasjon som må være tilgjengelig for at de skal bli gode.

Hvorfor én plattform med fire apper?

Jeg har arbeidet frem en arkitektur med Sales, Marketing, Content og Finance på et felles grunnlag, med Nexus som en gjennomgående intelligens- og koordineringsdel. Hver app har et tydelig arbeidsområde, men bør ikke lage sin egen versjon av kunder, virksomheter og hendelser.

En markedsføringsaktivitet kan dermed bygge på samme eiendoms- og kundekontekst som en salgsoppgave. Samtidig må tilgangene være tydelige: En ekstern medarbeider som produserer innhold, trenger ikke automatisk innsyn i all økonomi eller alle kundedata.

Hva skal Nexus gjøre – og hva skal den ikke gjøre?

Nexus skal hjelpe til med å oppdage relevante signaler, foreslå neste handling og støtte gjennomføringen av strategier. Et mål er at den kan lære av hvilke innholdstyper og oppfølgingsformer som fungerer, uten at hvert valg må programmeres manuelt.

Men det er avgjørende å skille ambisjon fra dokumentert funksjon. Noen moduler og kontroller er utviklet, mens andre arbeidsflyter fortsatt krever testing og videre forbedring. Systemet skal ikke hevde at en bolig er tilgjengelig, at et tall er verifisert eller at en kunde har samtykket uten grunnlag.

Hvordan ser én sammenhengende arbeidsflyt ut?

Tenk deg at en kunde melder interesse for en bolig. Forespørselen blir knyttet til en kundekontekst. Rådgiveren får relevante opplysninger om eiendommen, kan be om alternative forslag og ser hvilken handling som bør tas videre.

Det samme datagrunnlaget kan senere støtte en artikkel, et nyhetsbrev eller et SoMe-innlegg. Men publisering bør bruke kontrollerte opplysninger og riktig merkevareprofil. En god arbeidsflyt gjør også veien fra utkast til forhåndsvisning og publisering forståelig for den som bruker systemet.

Hvordan utvikler man uten å miste kontrollen?

Jeg prioriterer gradvis migrering, tydelige kvalitetskontroller og felles datamodeller. Det kan være mer krevende enn å lage én imponerende demonstrasjon, men det reduserer risikoen for datasiloer og motstridende informasjon.

En praktisk regel er å gjøre små forbedringer som kan testes av faktiske brukere. Når en bruker ikke finner et utkast etter at det er generert, er det et produktproblem – selv om den underliggende AI-funksjonen fungerer.

Hva er den kommersielle muligheten?

Når et internt system fungerer stabilt på tvers av virkelige arbeidsprosesser, kan enkelte deler utvikles til et kommersielt produkt. Det betyr likevel ikke at hele plattformen bør selges som den er. Kunden må kunne forstå verdien, ta løsningen i bruk og få forutsigbar støtte.

Jeg ser særlig muligheter i løsninger som hjelper en virksomhet å forstå sitt eget tilbud, kvalifisere relevante kunder og prioritere handlinger. Videre produktvalg må testes mot betalingsvilje, implementeringskostnad og reell differensiering.

Fra behov til produkt: en konkret arbeidsflyt

En eiendomsrådgiver mottar en henvendelse om bolig nær en skole. En nyttig arbeidsflyt starter med å lagre behovet strukturert, inkludert geografiske ønsker, kapasitet, prisramme og tidsperspektiv. Deretter kan relevante boligopplysninger sammenlignes mot kundens kriterier.

Før forslag presenteres, må systemet skille mellom registrert informasjon, nylig kontrollert informasjon og data som mangler verifikasjon. Neste steg er et utkast som rådgiveren kan vurdere, ikke en automatisk påstand om at en bestemt eiendom er ledig.

Dette illustrerer hvorfor CRM, salg og innholdsproduksjon må dele kontekst, men ikke nødvendigvis samme rettigheter til å endre eller publisere informasjon.

Hva viser dagens utviklingsarbeid?

Prosjektarbeidet har omfattet moduler for innhold og SoMe, kundeoppfølging, tilgangskontroll og kvalitetssikring i utviklings- og publiseringsløpet. Det har også avdekket hverdagsproblemer: for eksempel at brukere må finne igjen genererte forslag, forstå publiseringsprosessen og få synlig informasjon om hva som skjer etter lagring.

At en funksjon finnes i en kodebase betyr ikke automatisk at den er ferdig testet, kommersielt klar eller tilgjengelig for alle. Derfor skiller jeg mellom demonstrert funksjonalitet, intern bruk og planlagt utvikling.

Teknisk prinsipp: delt kjerne uten sammenblanding

Et felles datagrunnlag kan omfatte virksomheter, roller, kunder, eiendommer, dokumenter og hendelser. Hver app får et tydelig ansvar for egne arbeidsprosesser, mens Nexus kan analysere signaler på tvers når tilgangen tillater det.

Tilgang og handling må kontrolleres i serverlaget, ikke bare ved å skjule en knapp i grensesnittet. Revisjonsspor, samtykke, rolleavgrensning og mulighet for manuell overstyring er nødvendig når plattformen skal brukes av flere personer og virksomheter.

Hva vil jeg dokumentere før kommersiell lansering?

Jeg ønsker å kunne vise en reproduserbar kundereise, dokumenterte kontrollpunkter, målbar tidsbesparelse og en enkel måte for nye brukere å forstå systemet på.

Videre må drift, kostnader, personvern, support og tydelige grenser for AI-handlinger fungere. Det er disse spørsmålene som skiller et spennende utviklingsprosjekt fra et produkt en bedrift trygt kan betale for.