Constructor University

가장 중요한 결정: 학생 데이터 기반으로 Salesforce를 유지한다.

Constructor는 이미 자체 Salesforce 환경과 확립된 학생 기록을 가지고 있었다.

초기 우려는 새로운 주택 플랫폼이 대학으로 다시 통합해야 할 별도의 맞춤형 데이터 구조를 생성할 것인지에 대한 것이었다.

Booking Ninjas는 대신 Constructor의 기존 Salesforce 연락처 및 개인 계정 구조와 협력했다.

주택 정보는 이미 대학의 다른 곳에서 사용되고 있는 학생 기록과 연결된 상태를 유지할 수 있었고, 승인된 팀은 모든 사용자가 Booking Ninjas 애플리케이션 내부에서 작업할 필요 없이 관련 정보를 접근할 수 있었다.

이는 프로젝트 중에 제기된 가장 명확한 우려 중 하나를 해결했다: 주택은 또 다른 데이터 섬이 될 필요가 없었다.

Booking Ninjas는 이 더 넓은 구조를 설명한다. Salesforce Org란 무엇인가?

학생 주택 여정은 하나의 연결된 흐름이 될 수 있다.

유용한 경험은 학생 기록에서 시작하여 주택 생애 주기를 통해 계속된다.

Constructor 설정이 어떻게 맞물렸는지

학생들은 주택 여정의 더 많은 부분을 스스로 처리할 수 있었다.

Constructor는 관리 주택 화면 이상의 것이 필요했다.

학생들은 또한 프로세스와 상호작용할 수 있는 명확한 장소가 필요했다.

Booking Ninjas는 학생 접근을 대학의 주택 워크플로우에 연결할 수 있는 브랜드화된 학생 포털을 구성했다.

포털은 학생들이 자신과 관련된 주택 정보를 보고, 적용 가능한 선호도를 유지하고, 예약 단계를 계속하며, 적용 가능한 주택 결제와 같은 행동을 완료하는 장소가 될 수 있다.

이는 일상적인 작업을 이미 답을 알고 있는 사람에게 더 가깝게 이동시킨다.

Booking Ninjas의 현재 학생 포털 학생 셀프 서비스를 Salesforce 기록에 직접 연결된 상태로 유지하며, 플랫폼 외부에서 학생의 또 다른 복사본을 유지하지 않는다.

대학 주택 규칙은 워크플로우의 일부가 될 수 있다.

Constructor는 모든 학생을 위한 동일한 주택 프로세스를 가지고 있지 않았다.

신입생과 복학생은 서로 다른 요구 사항을 가질 수 있다. 특정 방 유형은 서로 다른 자격을 가질 수 있다. 학생의 선호도와 기존 대학 정보도 다음에 일어나야 할 일에 영향을 미칠 수 있다.

직원에게 모든 변형을 수동으로 기억하고 설명하도록 요청하는 대신, Salesforce 데이터와 Booking Ninjas 워크플로우는 적절한 주택 경로를 결정하는 데 도움을 줄 수 있다.

이 프로젝트는 방 선호도, 층 선호도, 국적, 흡연 선호도, 룸메이트 고려 사항 및 통제된 재고 행동과 같은 더 깊은 할당 요구 사항도 탐색했다.

이러한 고급 매칭 및 할당 아이디어는 Constructor와 Booking Ninjas가 구현 중에 정의하고 다듬고 있는 영역으로 이해되어야 하며, 모두 확인된 생산 기능으로 제시되지 않아야 한다.

결제가 예약 상태의 일부가 될 수 있다.

Constructor는 학생에 따라 다양한 재정 경로를 가지고 있었다.

예를 들어, 복학생은 주택 보증금이 필요할 수 있지만 신입생은 다른 프로세스를 따를 수 있다.

Booking Ninjas는 Stripe 결제 활동을 학생 및 예약과 연결하여 적용 가능한 결제가 주택 워크플로우의 일부가 될 수 있도록 작업했다.

이는 훨씬 더 명확한 순서를 생성한다:

같은 구조는 예약을 시작하지만 즉시 결제를 완료하지 않는 학생에게도 도움이 된다. 예약은 상태를 유지하여 학생이 다시 시작하지 않고 미결 단계로 돌아갈 수 있다.

Booking Ninjas의 현재 결제 도구는 거래를 예약, 송장 및 Salesforce 고객 기록과 직접 연결합니다. :contentReference[oaicite:3]{index=3}

주거 생활은 새로운 보고서가 필요할 때마다 소프트웨어 공급업체를 기다리고 싶지 않았습니다.

대학 주택에 대한 질문은 끊임없이 변합니다.

한 사람은 특정 건물에 학생이 필요할 수 있습니다. 다른 사람은 점유율이 필요할 수 있습니다. 또 다른 사람은 미성년자, 국적 정보, 방 배정 또는 기타 학생 속성이 필요할 수 있습니다.

Constructor 팀은 고정된 보고서 목록만으로는 충분하지 않다고 분명히 했습니다.

주택 기록이 Salesforce에 남아 있기 때문에, 승인된 팀은 Salesforce 보고서 및 허용된 내보내기를 사용하여 동일한 기본 데이터에서 다양한 질문에 답할 수 있었습니다.

실제 사용자가 시스템을 계속 형성했습니다.

사용자 수용 테스트는 소프트웨어가 일상적인 대학 운영에 도달할 때 중요한 세부 사항을 드러냈습니다.

Constructor와 Booking Ninjas는 학생 유형, 방 자격, 예약 상태, 결제 행동, 보고서, 선호도, 재고, 용어 및 주택 생애 주기 작업에 대한 질문을 해결했습니다.

팀은 체크아웃 및 방 점검이 더 구조화될 수 있는 방법도 탐색했습니다. 여기에는 예외 식별 및 정상적인 연말 퇴실에 필요한 수동 처리량을 줄이는 것이 포함됩니다.

그러한 고급 워크플로 중 일부는 여전히 정의되고 있었지만, 그 구현 과정 자체는 Constructor의 플랫폼 버전이 실제 주택 운영에 따라 계속 형성될 수 있음을 보여주었습니다.

Constructor에 더 연결된 것은 무엇이었는가

이 이야기에 대한 검증된 수치적 출시 후 결과는 없으므로, 가치는 Booking Ninjas가 연결한 작업과 시스템이 줄이도록 설계된 수동 인수인계를 통해 가장 잘 보여집니다.

그들의 대학. 그들의 학생들. 그들의 주택 규칙. 그들의 조직.

Constructor University는 Booking Ninjas Salesforce 네이티브 모델의 특히 명확한 예입니다.

대학은 이미 조직, 학생 기록, 필드, 권한, 보고서 및 데이터 관계를 가지고 있었습니다.

Booking Ninjas는 주택을 현대화하기 위해 대학에 그 기반을 버리라고 요청할 필요가 없었습니다.

대신, 주택은 동일한 더 넓은 환경 내에서 또 다른 운영 레이어가 될 수 있었습니다.

그것이 바로 Booking Ninjas가 현재 학생 주택 플랫폼을 설명하는 방법이기도 합니다: 학생, 방, 침대, 배정, 결제, 유지보수 및 운영 정보는 Salesforce에 중앙 집중화될 수 있습니다.

주택 예약은 더 넓은 주거 워크플로의 시작이 될 수 있습니다.

예약 관리가 핵심 주택 기록을 제공할 수 있습니다.

그 주위에서 대학은 학생 포털, 가용성, 방 및 침대 배정, 결제, 보고서, 유지보수, 체크인, 체크아웃, 커뮤니케이션 및 기타 주거 생활 워크플로를 필요에 따라 연결할 수 있습니다.

Constructor는 이미 대학의 여러 부분에 영향을 미치는 주택 운영을 위해 더 풍부한 설정이 필요했습니다.

더 작은 거주지는 더 적은 조각으로 시작할 수 있습니다.

유용한 점은 두 경우 모두 동일한 Salesforce 기반을 사용할 수 있다는 것입니다. 모든 기관을 동일한 주택 프로세스로 강요하지 않고도 말입니다.

더 넓은 사용 사례에 대해서는 다음을 참조하십시오. 학생 주택 솔루션 .

이 학생 주택 설정에 대해 자세히 알아보세요.