top of page

Student Onboarding simplified

Vah Vah Admin portal for Student management

Problem

All the student information was not in one place. With one course purchase comes course batch assignment, Payments and a kit which needs to be shipped to the student. It was becoming difficult to track all the information and streamline the process of batch assignment.

 

Currently Student payment was also not straight forward. Payments could be made in several instalments or single. Since there was so many steps to onboarding a student, it was becoming difficult to track which student has been assigned a batch and who hasn’t

Background

Prakshi is a student coordinator. She onboards a student and request for a kit shipment if the payment is satisfies and also assigns the student to a specific batch. She was very confused since the student wanted to pay the instalment in 3 smaller payments and wanted to pay a token amount to block the seat.

Since the student wanted to pay partial payments she had to track that payment and remember to assign and ship the kit only after payment was made and it was becoming difficult and was taking up a lot of time. This resulted in a lot of customer service calls.

To verify this we got insights on the number of customer service calls and the reasons and time required for it.

Numbers.jpg

Research

I took the time to talk to the student coordinator about the pain points. Their main pain-points were that all the student information is not curated in a single view and it was difficult for them to find each students information for each course they have purchased.

 

based on the information, I curated a complete flow of the process that currently takes place

Flow admin.jpg

Payment Module

The Payment part was quite complicated since it was not straight-forward and was an iterative result. This needed to do the most research also because it was a payment module.

There were 2 types of payments (as represented in the flow above)

  • Token amount for blocking seat

  • Full instalment amount

Based on the research above, I have created a page for blocking seat and a final student page which had only converted students information. The solution to go with 2 different pages was to keep the finance model clean and also help the student co-ordinators and the admissions counsellors to have a clear understanding and easy view to call back students to get the updates. This was also an internal tool, so I had to work with different stakeholders to understand any limitations as well.

Teams Impacted

  1. Finance Team

  2. Student Co-ordinators

  3. Admissions Councellors

  4. Logistics Team

Wireframe.jpg

Prototypes / Screens

Components

I started with creating base components after sketching out rough ideas for creating the interface.

I created a table with the student payment information and student details after doing the primary research after talking to Finance team and the operations team who would work on this dashboard the most

Blocking Seat Dashboard:

If the student wanted to think about it and come back with a decision, those students prefer to give a token amount so their seat is blocked. From here they either request a refund if they don't want to go ahead with the course or they pay the rest of the instalments or they could make multiple payments towards token amount. 

Students Dashboard

This is the master dashboard with all the students data with the courses purchased, They Kit Details and the payment details. Once the student makes a full payment towards the instalment, they will be converted to student for example: If the Student chose a package of 2 courses for Rs 30,000 and chose 2 Instalments. If the student pays 1 instalment then they will be converted to student. There are also different Payment methods and requirements accordingly.

Payments.jpg

Student Details Page

Once clicked on a student, they can see the details of the students. This is a summary Page which is the student details page. This page shows the Students personal details, address as the first part, Course and kit with the course if any in the second section, The thirst section shows all the purchases made by the student, could be courses, kits, extra products etc. 

Purchase Details Page

This was popularly used by our Finance Team, From here they can add New Payments, download Invoices, create credit note debit note for error management, Create Refunds. This page was the most iterated since there were new requirements and understanding these requirements was very important as this was a tool used to generate revenue reports and taxation as well. 

Course Details Page

The main users for this part were the students co-ordinators, to check any balance, assign a batch and send shipment request so shipment team can pick up that ticket. The also co-ordinate with the students during the certificate generation time to confirm all details before sending it for shipment. The shipment team has their own view. Once shipment is requested they get notified and they carry the next set of steps. 

Conclusion

The key takeaways from this project emphasise the significance of empathy. By understanding and empathising with the end users, I was able to address the main pain points and make the necessary improvements through several iterations. The use of prototypes and A/B testing allowed for valuable feedback to be gathered and incorporated, leading to the successful outcome. My personal involvement in testing the admin dashboard and gathering feedback from team members was helpful to ensuring the highest quality end product.

bottom of page