Constructor University måtte erstatte et gammelt studentboligsystem, men å erstatte gammel programvare med en annen isolert database ville bare skape et nytt problem.
Constructor University stolte allerede på Salesforce for studentinformasjon. Booking Ninjas jobbet med det eksisterende miljøet slik at boligen kunne bli en annen tilkoblet del av studentens universitetsopptegnelse.
Prosjektet samlet boligreservasjoner, student selvbetjening, tildelingsregler, betalinger, driftsdata og rapportering rundt Salesforce-grunnlaget som Constructor allerede stolte på.
Utfordringen: boligen berørte mye mer enn romtilgjengelighet
Constructor var i ferd med å gå bort fra sitt tidligere boligsystem, Mercury.
Det betydde at eksisterende eiendommer, studentkontakter, reservasjoner, bolighistorikk og driftsprosesser måtte vurderes som en del av overgangen.
Men boligen i seg selv var også mer komplisert enn å tildele et tomt rom.
- Studentopptegnelser
- Boligpreferanser
- Romberettighet
- Reservasjoner
- Innskudd og betalinger
- Romfordeling
- Rapportering for boligliv
- Innsjekking og utsjekking
Førstegangsstudenter og tilbakevendende studenter kunne følge forskjellige veier. Noen romtyper hadde forskjellige berettigelsesregler. Boligteamene trengte endrede rapporter. Studentene trengte en brukervennlig måte å fullføre sin del av prosessen.
Den viktigste beslutningen: beholde Salesforce som studentdatafundamentet
Constructor hadde allerede sitt eget Salesforce-miljø og etablerte studentopptegnelser.
En tidlig bekymring var om den nye boligplattformen ville skape en separat tilpasset datastruktur som deretter måtte integreres tilbake til universitetet.
Booking Ninjas jobbet i stedet med Constructors eksisterende Salesforce Kontakt- og Personkonto-struktur.
Boliginformasjonen kunne forbli koblet til studentopptegnelser som allerede ble brukt andre steder i universitetet, og autoriserte team kunne få tilgang til relevant informasjon uten at hver bruker måtte jobbe inne i Booking Ninjas-applikasjonen selv.
Det adresserte en av de tydeligste bekymringene som ble reist under prosjektet: boligen trengte ikke å bli en annen datøy.
Booking Ninjas forklarer denne bredere strukturen i Hva er en Salesforce Org?
Studentboligreisen kunne bli en sammenkoblet flyt
Den nyttige opplevelsen starter med studentopptegnelsen og fortsetter gjennom boliglivssyklusen.
Start fra studentinformasjonen Constructor allerede opprettholder i Salesforce.
Gi studenten et merkevaretilpasset boliginngangspunkt med informasjon og handlinger som er relevante for dem.
Studentstatus, preferanser, romtype og gjeldende krav former neste steg.
Reservasjonen kan følge betalings- eller godkjenningsregelen som gjelder for den studenten.
Boligopptegnelsen forblir tilgjengelig for tildelinger, Boligliv, rapportering og senere livssyklusarbeid.
Hvordan Constructor-oppsettet passet sammen
| Constructor behov | Booking Ninjas tilnærming | Hva det gjorde mulig |
|---|---|---|
| Erstatte gammelt boligdata | Salesforce-nativ migrasjonsstruktur | Eiendommer, kontakter, reservasjoner og relevant historisk data kunne flyttes mot det nye miljøet i stedet for å starte med et tomt boligsystem. |
| Beholde eksisterende studentopptegnelser | Eksisterende Salesforce Kontakt / Personkonto-struktur | Boligen kunne fungere rundt universitetets etablerte studentinformasjon i stedet for å lage en annen uavhengig studentdatabase. |
| Gi studentene selvbetjening | Studentportal | Studentene kunne få tilgang til et Constructor-merket miljø og fullføre relevante deler av boligreisen selv. |
| Bruke forskjellige boligregler | Reservasjonsregler + Salesforce arbeidsflyter | Førstegangsstudenter, tilbakevendende studenter, romtyper, preferanser og andre studentattributter kunne påvirke prosessen som ble vist for studenten. |
| Håndtere boliginnskudd | Betalingsbehandling | Gjeldene betalingsaktivitet kunne forbli koblet til studenten og reservasjonen i stedet for å bli avstemt separat. |
| Beholde ufullstendige reservasjoner brukbare | Reservasjonsstatus + betalingsarbeidsflyt | En student kunne gå tilbake til et utestående steg i stedet for å måtte bygge opp boligforespørselen fra begynnelsen. |
| Støtte endrede rapporter | Salesforce Rapporter + Dashboards | Boligliv kunne bygge forskjellige visninger rundt bygninger, rom, belegg, studentattributter eller tildelinger fra de samme dataene. |
Studentene kunne håndtere mer av boligreisen selv
Constructor trengte mer enn en administrativ boligs skjerm.
Studentene trengte også et klart sted å samhandle med prosessen.
Booking Ninjas konfigurerte en merkevaretilpasset Studentportal hvor studenttilgang kunne kobles til universitetets boligarbeidsflyt.
Portalen kunne bli stedet hvor studentene ser boliginformasjonen som er relevant for dem, opprettholder gjeldende preferanser, fortsetter reservasjonstrinn og fullfører handlinger som en gjeldende boligbetaling.
Det flytter rutinearbeid nærmere personen som allerede kjenner svaret.
Booking Ninjas' nåværende Studentportal holder student selvbetjening direkte koblet til Salesforce-opptegnelser i stedet for å opprettholde en annen kopi av studenten utenfor plattformen.
Universitetsboligregler kunne bli en del av arbeidsflyten
Constructor hadde ikke én identisk boligprosess for hver student.
Førstegangsstudenter og tilbakevendende studenter kunne ha forskjellige krav. Bestemte romtyper kunne ha forskjellige berettigelser. Studentpreferanser og eksisterende universitetsinformasjon kunne også påvirke hva som måtte skje neste.
I stedet for å be ansatte huske og forklare hver variasjon manuelt, kunne Salesforce-data og Booking Ninjas arbeidsflyter hjelpe med å bestemme den passende boligveien.
Prosjektet utforsket også dypere tildelingskrav som rompreferanser, etasjepreferanser, nasjonalitet, røykepreferanser, romkameratvurderinger og kontrollert lageradferd.
Disse avanserte matching- og tildelingsideene bør forstås som områder Constructor og Booking Ninjas definerte og finjusterte under implementeringen, snarere enn å bli presentert som bekreftet produksjonsfunksjonalitet.
Betaling kunne bli en del av reservasjonsstatusen
Constructor hadde også forskjellige økonomiske veier avhengig av studenten.
For eksempel kunne tilbakevendende studenter trenge et boliginnskudd mens førstegangsstudenter kunne følge en annen prosess.
Booking Ninjas jobbet med å koble Stripe betalingsaktivitet med studenten og reservasjonen slik at en gjeldende betaling kunne bli en del av boligarbeidsflyten selv.
Det skaper en mye klarere sekvens:
Den samme strukturen hjelper også med studenter som begynner reservasjonen, men ikke fullfører betalingen umiddelbart. Reservasjonen kan beholde sin status slik at studenten kan gå tilbake til det utestående steget i stedet for å starte på nytt.
Booking Ninjas' nåværende betalingsverktøy kobler på samme måte transaksjoner direkte med bestillinger, fakturaer og Salesforce-kundeposter. :contentReference[oaicite:3]{index=3}
Boliglivet ønsket ikke å vente på en programvareleverandør hver gang det trengte en ny rapport
Universitetsboligspørsmål endrer seg konstant.
En person kan ha behov for studenter i en bestemt bygning. En annen kan ha behov for belegg. En annen kan ha behov for mindreårige, nasjonalitetsinformasjon, romtildelinger eller andre studentattributter.
Constructor-teamet gjorde det klart at en fast liste over rapporter ikke ville være tilstrekkelig.
Fordi boligpostene forble i Salesforce, kunne autoriserte team bruke Salesforce-rapportering og tillatte eksport for å svare på forskjellige spørsmål fra de samme underliggende dataene.
- Bygninger og rom
- Studenttildelinger
- Belegg
- Studentattributter
- Reservasjonsstatus
- Betalingsstatus
- Boligunntak
- Operasjonelle eksporter
Virkelige brukere fortsatte å forme systemet
Brukertesting avdekket detaljene som betyr noe når programvare når daglige universitetsoperasjoner.
Constructor og Booking Ninjas jobbet gjennom spørsmål rundt studenttyper, romberettigelse, reservasjonsstatus, betalingsatferd, rapporter, preferanser, inventar, terminologi og boliglivssyklusarbeid.
Teamet utforsket også hvordan utsjekking og rominspeksjon kunne bli mer strukturert, inkludert identifisering av unntak og redusere mengden manuell behandling som kreves for normale avgang ved slutten av året.
Noen av de avanserte arbeidsflytene var fortsatt under definisjon, men den implementeringsprosessen viste hvordan Constructors versjon av plattformen kunne fortsette å ta form rundt virkelige boligoperasjoner.
Hva som ble mer sammenkoblet for Constructor
Vi har ikke bekreftede numeriske resultater etter lansering for denne historien, så verdien vises best gjennom arbeidet Booking Ninjas koblet sammen og de manuelle overføringene systemet var designet for å redusere.
Universitetet trengte ikke å behandle bolig som et helt separat studentinformasjonssystem.
Boligreisen kunne gå gjennom en merket portal i stedet for å være avhengig kun av personalinstruksjoner og manuell oppfølging.
Studentstatus og annen Salesforce-informasjon kunne hjelpe med å bestemme hvilken boligprosess som gjaldt.
Gjeldende boliginnskudd kunne bli en del av den samme reservasjonsloggen i stedet for en annen frakoblet sjekk.
Salesforce-rapportering ga Boliglivet mer fleksibilitet enn å stole kun på et fast leverandorrapportbibliotek.
Virkelige UAT-scenarier kunne gi tilbakemelding til konfigurasjonen i stedet for å tvinge Constructor til å akseptere én fast boligprosess.
Deres universitet. Deres studenter. Deres boligregler. Deres organisasjon.
Constructor University er et spesielt klart eksempel på Booking Ninjas Salesforce-native modell.
Universitetet hadde allerede en organisasjon, studentposter, felt, tillatelser, rapporter og databehandlinger.
Booking Ninjas trengte ikke å be universitetet om å kaste bort det grunnlaget for å modernisere boligen.
I stedet kunne boligen bli et annet driftslag inne i det samme bredere miljøet.
Det er også slik Booking Ninjas beskriver den nåværende Student Housing-plattformen: student, rom, seng, tildeling, betaling, vedlikehold og operasjonell informasjon kan forbli sentralisert i Salesforce.
En boligreservasjon kan bli starten på en bredere boligarbeidsflyt
Reservasjonsadministrasjon kan gi den grunnleggende boligposten.
Rundt det kan et universitet koble studentportaler, tilgjengelighet, rom- og sengtildelinger, betalinger, rapportering, vedlikehold, innsjekking, utsjekking, kommunikasjon og andre Boliglivsarbeidsflyter etter behov.
Constructor trengte en rikere oppsett fordi dens boligoperasjon allerede berørte mange deler av universitetet.
En mindre bolig kan starte med færre deler.
Det nyttige poenget er at begge kan bruke det samme Salesforce-grunnlaget uten å tvinge hver institusjon inn i den samme boligprosessen.
For den bredere bruken, se Student Housing-løsningen .
Lær mer om denne studentboligoppsettet
Se hvordan studentens selvbetjening kan forbli direkte koblet til Salesforce-data, tillatelser, fakturering og universitetsarbeidsflyter.
Utforsk Studentportal →Se hvordan poster, arbeidsflyter, brukere, rapportering, automatisering og andre operasjonelle verktøy kan leve i ett organisasjonsspesifikt miljø.
Hva er en Salesforce-org? →Se hvordan reservasjoner, policyregler, tilgjengelighet, endringer og operasjonell rapportering kan forbli koblet inne i Salesforce.
Utforsk Reservasjonsadministrasjon →Om denne historien: Denne siden gjenspeiler Constructor Universitys Booking Ninjas-implementering og materiale for brukertesting, inkludert legacy-migrering, Salesforce-studentposter, boligreservasjoner, portal selvbetjening, betalingsarbeidsflyter, rapportering og boligregelkonfigurasjon. Avanserte romkameratmatching, kontrollert overbooking og inspeksjonsarbeidsflyter er beskrevet kun som områder utforsket eller raffinert under implementeringen med mindre senere produksjonsbevis bekrefter deres endelige distribusjon.
Moderniser studentbolig uten å opprette en annen studentdatabase.
Se hvordan Booking Ninjas kan koble reservasjoner, rom, studenter, betalinger, portaler, rapportering og Boliglivsarbeidsflyter rundt Salesforce-miljøet din institusjon allerede bruker.
.jpeg)
.jpg)
.png)
