Constructor University behövde ersätta ett gammalt studentboendesystem, men att ersätta gammal programvara med en annan isolerad databas skulle bara skapa ett nytt problem.
Constructor University förlitade sig redan på Salesforce för studentinformation. Booking Ninjas arbetade med den befintliga miljön så att boendet kunde bli en annan kopplad del av studentens universitetsregister.
Projektet sammanförde bostadsreservationer, student självbetjäning, tilldelningsregler, betalningar, operativ data och rapportering kring den Salesforce-grund som Constructor redan litade på.
Utmaningen: boende berörde mycket mer än rumstillgång
Constructor var på väg bort från sitt tidigare boendesystem, Mercury.
Det innebar att befintliga fastigheter, studentkontakter, reservationer, bostadshistorik och operativa processer måste beaktas som en del av övergången.
Men boende i sig var också mer komplicerat än att tilldela ett tomt rum.
- Studentregister
- Bostadspreferenser
- Rumberättigande
- Reservationer
- Insättningar och betalningar
- Rumstilldelning
- Rapportering för boende
- Incheckning och utcheckning
Förstaårsstudenter och återkommande studenter kunde följa olika vägar. Vissa rumstyper hade olika berättiganderegler. Bostadsteam behövde förändrade rapporter. Studenter behövde ett användbart sätt att slutföra sin del av processen.
Det viktigaste beslutet: behålla Salesforce som studentdatafundamentet
Constructor hade redan sin egen Salesforce-miljö och etablerade studentregister.
En tidig oro var om den nya bostadsplattformen skulle skapa en separat anpassad datastruktur som sedan skulle behöva en annan integration tillbaka till universitetet.
Booking Ninjas arbetade istället med Constructors befintliga Salesforce-kontakt- och personkontostruktur.
Bostadsinformation kunde förbli kopplad till studentregister som redan användes på andra ställen i universitetet, och auktoriserade team kunde få tillgång till relevant information utan att varje användare behövde arbeta inuti Booking Ninjas-applikationen själv.
Detta adresserade en av de tydligaste oro som uttrycktes under projektet: boende behövde inte bli en annan datö.
Booking Ninjas förklarar denna bredare struktur i Vad är en Salesforce-org?
Studentboendets resa kunde bli ett sammanhängande flöde
Den användbara upplevelsen börjar med studentregistret och fortsätter genom bostadscykeln.
Börja från den studentinformation som Constructor redan underhåller i Salesforce.
Ge studenten en varumärkesanpassad ingångspunkt för boende med den information och de åtgärder som är relevanta för dem.
Studentstatus, preferenser, rumstyp och tillämpliga krav formar nästa steg.
Reservationen kan följa den betalning eller godkännande regel som gäller för den studenten.
Bostadsregistret förblir tillgängligt för tilldelningar, boende, rapportering och senare livscykelarbete.
Hur Constructor-uppsättningen passade ihop
| Constructor behov | Booking Ninjas tillvägagångssätt | Vad det gjorde möjligt |
|---|---|---|
| Ersätta gammal bostadsdata | Salesforce-infödda migrationsstruktur | Fastigheter, kontakter, reservationer och relevant historisk data kunde flyttas mot den nya miljön istället för att börja med ett tomt bostadssystem. |
| Behålla befintliga studentregister | Befintlig Salesforce-kontakt / personkontostruktur | Bostad kunde fungera runt universitetets etablerade studentinformation istället för att skapa en annan oberoende studentdatabas. |
| Ge studenter självbetjäning | Studentportal | Studenter kunde få tillgång till en Constructor-varumärkesanpassad miljö och slutföra relevanta delar av bostadsresan själva. |
| Tillämpa olika bostadsregler | Reservationsregler + Salesforce-arbetsflöden | Förstaårsstudenter, återkommande studenter, rumstyper, preferenser och andra studentattribut kunde påverka den process som visas för studenten. |
| Hantera bostadsinsättningar | Betalningsbehandling | Tillämplig betalningsaktivitet kunde förbli kopplad till studenten och reservationen istället för att redovisas separat. |
| Behålla ofullständiga reservationer användbara | Reservationsstatus + betalningsarbetsflöde | En student kunde återvända till ett utestående steg istället för att behöva återskapa bostadsbegäran från början. |
| Stödja förändrade rapporter | Salesforce-rapporter + instrumentpaneler | Residential Life kunde bygga olika vyer kring byggnader, rum, beläggning, studentattribut eller tilldelningar från samma data. |
Studenter kunde hantera mer av bostadsresan själva
Constructor behövde mer än en administrativ bostadsskärm.
Studenter behövde också en tydlig plats för att interagera med processen.
Booking Ninjas konfigurerade en varumärkesanpassad studentportal där studentåtkomst kunde kopplas till universitetets bostadsarbetsflöde.
Portalen kunde bli platsen där studenter ser den bostadsinformation som är relevant för dem, underhåller tillämpliga preferenser, fortsätter reservationssteg och slutför åtgärder som en tillämplig bostadsbetalning.
Det flyttar rutinarbete närmare den person som redan vet svaret.
Booking Ninjas nuvarande Studentportal håller studentens självbetjäning direkt kopplad till Salesforce-register istället för att underhålla en annan kopia av studenten utanför plattformen.
Universitetets bostadsregler kunde bli en del av arbetsflödet
Constructor hade inte en identisk bostadsprocess för varje student.
Förstaårsstudenter och återkommande studenter kunde ha olika krav. Vissa rumstyper kunde ha olika berättigande. Studentpreferenser och befintlig universitetsinformation kunde också påverka vad som behövde hända härnäst.
Istället för att be personalen att komma ihåg och förklara varje variation manuellt, kunde Salesforce-data och Booking Ninjas arbetsflöden hjälpa till att avgöra den lämpliga bostadsvägen.
Projektet utforskade också djupare tilldelningskrav som rumpreferenser, våningspreferenser, nationalitet, rökpreferenser, rumskompisöverväganden och kontrollerat lagerbeteende.
Dessa avancerade matchnings- och tilldelningsidéer bör förstås som områden som Constructor och Booking Ninjas definierade och förfinade under implementeringen, snarare än att alla presenteras som bekräftad produktionsfunktionalitet.
Betalning kunde bli en del av reservationsstatusen
Constructor hade också olika ekonomiska vägar beroende på studenten.
Till exempel kunde återkommande studenter behöva en bostadsinsättning medan förstaårsstudenter kunde följa en annan process.
Booking Ninjas arbetade med att koppla Stripe betalningsaktivitet med studenten och reservationen så att en tillämplig betalning kunde bli en del av bostadsarbetsflödet självt.
Det skapar en mycket tydligare sekvens:
Den samma strukturen hjälper också studenter som påbörjar reservationen men inte slutför betalningen omedelbart. Reservationen kan behålla sitt tillstånd så att studenten kan återvända till det utestående steget istället för att börja om.
Booking Ninjas nuvarande betalningsverktyg kopplar på liknande sätt transaktioner direkt med bokningar, fakturor och Salesforce kundregister. :contentReference[oaicite:3]{index=3}
Bostadslivet ville inte vänta på en mjukvaruleverantör varje gång det behövde en ny rapport
Universitetets bostadsfrågor förändras ständigt.
En person kan behöva studenter i en viss byggnad. En annan kan behöva beläggning. En annan kan behöva minderåriga, nationalitetsinformation, rumsfördelningar eller andra studentattribut.
Constructors team klargjorde att en fast lista med rapporter inte skulle vara tillräcklig.
Eftersom bostadsregistren förblev i Salesforce kunde auktoriserade team använda Salesforce-rapportering och tillåtna exporter för att besvara olika frågor från samma underliggande data.
- Byggnader och rum
- Studentfördelningar
- Beläggning
- Studentattribut
- Reservationsstatus
- Betalningsstatus
- Bostadsundantag
- Operativa exporter
Verkliga användare fortsatte att forma systemet
Användartestning avslöjade detaljerna som är viktiga när mjukvara når dagliga universitetsoperationer.
Constructor och Booking Ninjas arbetade igenom frågor kring studenttyper, rumskompetens, reservationsstatusar, betalningsbeteende, rapporter, preferenser, inventarier, terminologi och bostadscykelarbete.
Teamet utforskade också hur utcheckning och ruminspektion kunde bli mer strukturerade, inklusive att identifiera undantag och minska mängden manuellt arbete som krävs för normala avresor vid årets slut.
Några av dessa avancerade arbetsflöden definierades fortfarande, men den implementeringsprocessen visade hur Constructorns version av plattformen kunde fortsätta att formas kring verkliga bostadsoperationer.
Vad som blev mer kopplat för Constructor
Vi har inga verifierade numeriska resultat efter lanseringen för denna berättelse, så värdet visas bäst genom det arbete som Booking Ninjas kopplade och de manuella överlämningarna som systemet var utformat för att minska.
Universitetet behövde inte behandla bostaden som en helt separat studentinformationsmiljö.
Bostadsresan kunde gå genom en märkt portal istället för att bara bero på personalens instruktioner och manuella uppföljningar.
Studentstatus och annan Salesforce-information kunde hjälpa till att avgöra vilken bostadsprocess som gällde.
Tillämpliga bostadsinsättningar kunde bli en del av samma reservationshistorik istället för en annan frikopplad kontroll.
Salesforce-rapportering gav Bostadslivet mer flexibilitet än att bara förlita sig på ett fast leverantörsrapportsbibliotek.
Verkliga UAT-scenarier kunde mata tillbaka till konfigurationen istället för att tvinga Constructor att acceptera en fast bostadsprocess.
Deras universitet. Deras studenter. Deras bostadsregler. Deras org.
Constructor University är ett särskilt tydligt exempel på Booking Ninjas Salesforce-inbyggda modell.
Universitetet hade redan en org, studentregister, fält, behörigheter, rapporter och databasrelationer.
Booking Ninjas behövde inte be universitetet att kasta bort den grunden för att modernisera bostaden.
Istället kunde bostaden bli ett annat driftslager inom samma bredare miljö.
Det är också hur Booking Ninjas beskriver den nuvarande Student Housing-plattformen: student, rum, säng, fördelning, betalning, underhåll och operativ information kan förbli centraliserad i Salesforce.
En bostadsreservation kan bli starten på ett bredare bostadsarbetsflöde
Reservationshantering kan tillhandahålla den centrala bostadsregistren.
Runt det kan ett universitet koppla studentportaler, tillgänglighet, rum- och sängfördelningar, betalningar, rapportering, underhåll, incheckning, utcheckning, kommunikation och andra Bostadsliv-arbetsflöden efter behov.
Constructor behövde en rikare uppsättning eftersom dess bostadsverksamhet redan berörde många delar av universitetet.
En mindre bostad kan börja med färre delar.
Den användbara punkten är att båda kan använda samma Salesforce-grund utan att tvinga varje institution in i samma bostadsprocess.
För det bredare användningsfallet, se Student Housing-lösningen .
Läs mer om denna studentbostadsuppsättning
Se hur studentens självbetjäning kan förbli direkt kopplad till Salesforce-data, behörigheter, fakturering och universitetsarbetsflöden.
Utforska Studentportal →Se hur register, arbetsflöden, användare, rapportering, automatisering och andra operativa verktyg kan leva i en organisationsspecifik miljö.
Vad är en Salesforce-org? →Se hur reservationer, policyregler, tillgänglighet, förändringar och operativ rapportering kan förbli kopplade inuti Salesforce.
Utforska Reservationshantering →Om denna berättelse: Denna sida återspeglar Constructor Universitys implementering av Booking Ninjas och material för användartestning, inklusive arvsmigrering, Salesforce studentregister, bostadsreservationer, portal självbetjäning, betalningsarbetsflöden, rapportering och konfiguration av bostadsregler. Avancerad rumskamratmatchning, kontrollerad överbokning och inspektionsarbetsflöden beskrivs endast som områden som utforskades eller förfinades under implementeringen om inte senare produktionsbevis bekräftar deras slutliga implementering.
Modernisera studentbostäder utan att skapa en annan studentdatabas.
Se hur Booking Ninjas kan koppla reservationer, rum, studenter, betalningar, portaler, rapportering och Bostadsliv-arbetsflöden kring den Salesforce-miljö som din institution redan använder.
.jpeg)
.jpg)
.png)
