background

Constructor University

Constructor University havde brug for at erstatte et gammelt studenterboligsystem, men at erstatte gammel software med en anden isoleret database ville kun skabe et nyt problem.

Constructor University relyede allerede på Salesforce til studenterinformation. Booking Ninjas arbejdede med det eksisterende miljø, så boligen kunne blive en anden sammenkoblet del af den studerendes universitetsoptegnelse.

Projektet samlede boligreservationer, studenter-selvbetjening, tildelingsregler, betalinger, driftsdata og rapportering omkring den Salesforce-fundament, som Constructor allerede stolede på.

Kunde Constructor University
Drift Universitets studenterboliger
Hovedbehov Erstat gammelt bolig i Salesforce

Udfordringen: boligen berørte meget mere end tilgængelighed af værelser

Constructor bevægede sig væk fra sit tidligere boligsystem, Mercury.

Det betød, at eksisterende ejendomme, studenterkontakter, reservationer, bolighistorik og driftsprocesser skulle overvejes som en del af overgangen.

Men boligen i sig selv var også mere kompliceret end blot at tildele et tomt værelse.

  • Studenteroptegnelser
  • Boligpræferencer
  • Værelsesberettigelse
  • Reservationer
  • Indskud og betalinger
  • Værelsestildeling
  • Residential Life rapportering
  • Indtjekning og udtjekning

Førstegangs- og tilbagevendende studerende kunne følge forskellige veje. Nogle værelsetyper havde forskellige berettigelsesregler. Boligteamene havde brug for ændrede rapporter. Studerende havde brug for en brugbar måde at fuldføre deres del af processen.

Den vigtigste beslutning: holde Salesforce som grundlaget for studenterdata

Constructor havde allerede sit eget Salesforce-miljø og etablerede studenteroptegnelser.

En tidlig bekymring var, om den nye boligplatform ville skabe en separat tilpasset datastruktur, der derefter skulle have en anden integration tilbage til universitetet.

Booking Ninjas arbejdede i stedet med Constructors eksisterende Salesforce Kontakt- og Personkonto-struktur.

Boligoplysninger kunne forblive forbundet til studenteroptegnelser, der allerede blev brugt andre steder på universitetet, og autoriserede teams kunne få adgang til relevante oplysninger uden at hver bruger skulle arbejde inden for Booking Ninjas-applikationen selv.

Det adresserede en af de tydeligste bekymringer, der blev rejst under projektet: boligen behøvede ikke at blive en anden dataø.

Booking Ninjas forklarer denne bredere struktur i Hvad er en Salesforce Org?

Studenterboligrejsen kunne blive en sammenkoblet strøm

Den nyttige oplevelse starter med studenteroptegnelsen og fortsætter gennem boliglivscyklussen.

01 Studenteroptegnelse

Start fra de studenteroplysninger, Constructor allerede opretholder i Salesforce.

02 Portaladgang

Giv den studerende et brandet boligindgangspunkt med de oplysninger og handlinger, der er relevante for dem.

03 Boligregler

Studenterstatus, præferencer, værelsetype og gældende krav former det næste skridt.

04 Reservér + betal

Reservationen kan følge den betalings- eller godkendelsesregel, der gælder for den studerende.

05 Drift + rapportering

Boligoptegnelsen forbliver tilgængelig for tildelinger, Residential Life, rapportering og senere livscyklustilbud.

Hvordan Constructor-opsætningen passede sammen

Constructor behov Booking Ninjas tilgang Hvad det gjorde muligt
Erstat gammelt boligdata Salesforce-naturlig migrationsstruktur Ejendomme, kontakter, reservationer og relevante historiske data kunne bevæge sig mod det nye miljø i stedet for at starte med et tomt boligsystem.
Behold eksisterende studenteroptegnelser Eksisterende Salesforce Kontakt / Personkonto-struktur Boligen kunne arbejde omkring universitetets etablerede studenterinformation i stedet for at skabe en anden uafhængig studenterdatabase.
Giv studerende selvbetjening Studenterportal Studerende kunne få adgang til et Constructor-brandet miljø og fuldføre relevante dele af boligrejsen selv.
Anvend forskellige boligregler Reservationsregler + Salesforce arbejdsgange Førstegangs-, tilbagevendende studerende, værelsetyper, præferencer og andre studenterattributter kunne påvirke den proces, der vises for den studerende.
Håndter boligindskud Betalingsbehandling Gældende betalingsaktivitet kunne forblive forbundet til den studerende og reservationen i stedet for at blive afstemt separat.
Behold ufuldstændige reservationer brugbare Reservationsstatus + betalingsarbejdsgang En studerende kunne vende tilbage til et udestående skridt i stedet for at skulle genopbygge boligforespørgslen fra begyndelsen.
Støtte ændrede rapporter Salesforce-rapporter + dashboards Residential Life kunne opbygge forskellige visninger omkring bygninger, værelser, belægning, studenterattributter eller tildelinger fra de samme data.

Studerende kunne håndtere mere af boligrejsen selv

Constructor havde brug for mere end en administrativ boligscreen.

Studerende havde også brug for et klart sted at interagere med processen.

Booking Ninjas konfigurerede en brandet Studenterportal, hvor studenteradgang kunne forbindes til universitetets boligarbejdsgang.

Portalen kunne blive det sted, hvor studerende ser de boligoplysninger, der er relevante for dem, opretholder gældende præferencer, fortsætter reservationsskridtene og fuldfører handlinger som en gældende boligbetaling.

Det flytter rutinearbejde tættere på den person, der allerede kender svaret.

Booking Ninjas' nuværende Studenterportal holder studenter-selvbetjening direkte forbundet til Salesforce-optegnelser i stedet for at opretholde en anden kopi af den studerende uden for platformen.

Universitets boligregler kunne blive en del af arbejdsgangen

Constructor havde ikke én identisk boligproces for hver studerende.

Førstegangs- og tilbagevendende studerende kunne have forskellige krav. Visse værelsetyper kunne have forskellige berettigelse. Studenterpræferencer og eksisterende universitetsinformation kunne også påvirke, hvad der skulle ske næste gang.

I stedet for at bede personalet om at huske og forklare hver variation manuelt, kunne Salesforce-data og Booking Ninjas arbejdsgange hjælpe med at bestemme den passende boligvej.

Projektet udforskede også dybere tildelingskrav som værelsepræferencer, etagepræferencer, nationalitet, rygepræferencer, roommate-overvejelser og kontrolleret lageradfærd.

Disse avancerede matchings- og tildelingsideer bør forstås som områder, Constructor og Booking Ninjas definerede og forfinede under implementeringen, snarere end at alt blev præsenteret som bekræftet produktionsfunktionalitet.

Betaling kunne blive en del af reservationsstatussen

Constructor havde også forskellige finansielle veje afhængigt af den studerende.

For eksempel kunne tilbagevendende studerende have brug for et boligindskud, mens førstegangsstudenter kunne følge en anden proces.

Booking Ninjas arbejdede på at forbinde Stripe betalingsaktivitet med den studerende og reservationen, så en gældende betaling kunne blive en del af boligarbejdsgangen selv.

Det skaber en meget klarere sekvens:

Den samme struktur hjælper også med studerende, der begynder reservationen, men ikke fuldfører betalingen med det samme. Reservationen kan bevare sin status, så den studerende kan vende tilbage til det udestående skridt i stedet for at starte forfra.

Booking Ninjas' nuværende betalingsværktøjer forbinder på samme måde transaktioner direkte med reservationer, fakturaer og Salesforce kundeposter. :contentReference[oaicite:3]{index=3}

Residential Life ønskede ikke at vente på en softwareleverandør hver gang, de havde brug for en ny rapport

Universitetets boligspørgsmål ændrer sig konstant.

En person har muligvis brug for studerende i en bestemt bygning. En anden har muligvis brug for belægning. En anden har muligvis brug for mindreårige, nationalitetsoplysninger, værelsestildelinger eller andre studenterattributter.

Constructor's team gjorde det klart, at en fast liste over rapporter ikke ville være nok.

Fordi boligoptegnelserne forblev i Salesforce, kunne autoriserede teams bruge Salesforce-rapportering og tilladte eksport til at besvare forskellige spørgsmål fra de samme underliggende data.

  • Bygninger og værelser
  • Studenter tildelinger
  • Belægning
  • Studenterattributter
  • Reservationsstatus
  • Betalingsstatus
  • Boligundtagelser
  • Operationelle eksporter

Rigtige brugere fortsatte med at forme systemet

Brugeraccepttest afslørede de detaljer, der betyder noget, når software når daglige universitetsoperationer.

Constructor og Booking Ninjas arbejdede igennem spørgsmål omkring studenter typer, værelsesberettigelse, reservationsstatus, betalingsadfærd, rapporter, præferencer, lager, terminologi og boliglivscyklusarbejde.

Teamet udforskede også, hvordan checkout og værelseinspektion kunne blive mere struktureret, herunder identificering af undtagelser og reduktion af mængden af manuel behandling, der kræves for normale afslutninger ved årets slutning.

Nogle af de avancerede arbejdsgange var stadig under definition, men den implementeringsproces viste, hvordan Constructors version af platformen kunne fortsætte med at tage form omkring reelle boligoperationer.

Hvad blev mere forbundet for Constructor

Vi har ikke verificerede numeriske resultater efter lanceringen for denne historie, så værdien vises bedst gennem det arbejde, Booking Ninjas forbinder, og de manuelle overdragelser, systemet var designet til at reducere.

Bolig forblev med studenteroptegnelsen

Universitetet havde ikke brug for at behandle bolig som et helt separat studenterinformationsmiljø.

Studerende fik en selvbetjeningsvej

Boligrejsen kunne bevæge sig gennem en brandet portal i stedet for kun at være afhængig af personalets instruktioner og manuel opfølgning.

Regler kunne følge studenterkonteksten

Studenterstatus og andre Salesforce-oplysninger kunne hjælpe med at bestemme, hvilken boligproces der gjaldt.

Betalinger kunne forblive med reservationer

Anvendelige boligindskud kunne blive en del af den samme reservationshistorik i stedet for en anden frakoblet kontrol.

Personalet kunne stille nye spørgsmål til dataene

Salesforce-rapportering gav Residential Life mere fleksibilitet end kun at stole på et fast leverandorrapportbibliotek.

Systemet kunne fortsætte med at udvikle sig

Rigtige UAT-scenarier kunne give feedback til konfigurationen i stedet for at tvinge Constructor til at acceptere en fast boligproces.

Deres universitet. Deres studerende. Deres boligregler. Deres organisation.

Constructor University er et særligt klart eksempel på Booking Ninjas Salesforce-native model.

Universitetet havde allerede en organisation, studenteroptegnelser, felter, tilladelser, rapporter og datarelationer.

Booking Ninjas havde ikke brug for at bede universitetet om at smide det fundament væk for at modernisere boligen.

I stedet kunne boligen blive et andet driftslag inden for det samme bredere miljø.

Det er også sådan, Booking Ninjas beskriver den nuværende Student Housing-platform: studerende, værelse, seng, tildeling, betaling, vedligeholdelse og operationelle oplysninger kan forblive centraliseret i Salesforce.

En boligreservation kan blive starten på en bredere boligarbejdsgang

Reservationsstyring kan give den centrale boligoptegnelse.

Omkring det kan et universitet forbinde studenterportaler, tilgængelighed, værelses- og seng tildelinger, betalinger, rapportering, vedligeholdelse, check-in, checkout, kommunikation og andre Residential Life arbejdsgange efter behov.

Constructor havde brug for en rigere opsætning, fordi dens boligoperation allerede berørte mange dele af universitetet.

En mindre bolig kan starte med færre dele.

Det nyttige punkt er, at begge kan bruge det samme Salesforce-fundament uden at tvinge hver institution ind i den samme boligproces.

For den bredere brugssag, se Student Housing-løsningen .

Lær mere om denne studenterboligopsætning

Om denne historie: Denne side afspejler Constructor University's Booking Ninjas-implementering og brugeraccepttestmateriale, herunder legacy-migrering, Salesforce studenteroptegnelser, boligreservationer, portal selvbetjening, betalingsarbejdsgange, rapportering og boligregelkonfiguration. Avanceret værelsesmatchning, kontrolleret overbooking og inspektionsarbejdsgange beskrives kun som områder, der blev udforsket eller forfinet under implementeringen, medmindre senere produktionsbeviser bekræfter deres endelige implementering.

Moderniser studenterbolig uden at skabe en anden studenterdatabase.

Se hvordan Booking Ninjas kan forbinde reservationer, værelser, studerende, betalinger, portaler, rapportering og Residential Life arbejdsgange omkring det Salesforce-miljø, din institution allerede bruger.

WhatsApp-viesti

WhatsApp-viesti