Atharo Admin Portal
Modernizing music school without losing the personal touch.
Atharo Music is a company that helps music schools thrive. We started out as a music school operating in 5 states, and have grown into so much more. One of our most valuable assets is the music school management software that we're developing. From onboarding and scheduling to billing and content creation, this product has not only solved the problems of our administrators, but allowed our music schools to grow in ways that weren't possible before.
Because we were developing this software around our growing music schools, I needed to find a way to automate the "back end" as much as possible, lightening the load for the administration, while keeping the personal touch on client-side operations. This is a sneak-peek into the creation of the admin portal.
The administrators were juggling an unsustainable number of tasks, relying on inperfect workflows contingent on the outcome of interactions with the prospective customers. Our admins
complained about having lists and sticky notes all over their desks.
The ultimate goal was to automate admin tasks, so the approach I took here was starting with a workflow map of the current processes
which included 100% manual efforts on the part of the admins.
To imagine an automated version of this flow, I had to reinvent the user flow to incorporate not only the actions by the user, but also the possible auto-functions that we could implement.
This process required many user flows outlining all of the school's different existing processes, but allowed me to simplify them from the human perspective by
replacing much of the mundane with automation.
This is one of the early flows we tackled, the student onboarding process:
As complicated as this looks, since much of this is automation, and the rest are tasks on a card, all this back-end complexity allowed us to make the actual user flow for the admin incredibly simple:
I wanted to plan for future growth, so my initial sketches and sitemaps included all of the functions I could ever dream of so that there was room for everything once the time came. [EDIT: These future visions came to fruition, and much more, so my "maximum viable product" approach paid off within a few years].
Using mid-fidelity prototypes, I conducted a series of very loose user tests with the administrators and had several in-depth discussions with them about their frustrations and needs. We were able to identify which features were needed immediately vs. what might be added in the future.
These conversations helped me reorganize the structure based on the admin's workflows, and helped me see the processes from their point of view.
Because of the nature of our process (and timeline), we launched the beta version to our admin with only 4 features, and constantly iterated as we added features and updated based on testing and feedback. The following is an overview of each feature.
Our teacher database utilizes filters to help the admin schedule lessons quickly and easily based on availability, location, instrument, and status. Teacher availability can be updated at any time in the teacher portal and is reflected in this teacher database in the admin portal.
Each teacher profile contains every piece of information about the teacher from stats such as average lessons taught per month and turnover rate to their personal information and cancellation tracker. This helps management understand the performance of each teacher, and easily assess and take action where necessary.
The student database is structured in the same way, containing all information about the customer, and connected to many different parts of the application including billing, onboarding, scheduling, and our auto-email service.
The student onboarding feature is the most important and most used. When someone fills out the booking form on one of the school websites, a card is created in the Inquiry column. The idea is for a card to get pushed through to ultimately be onboarded completely. Each column regenerates the card with new tasks for the admin to follow. Many of these steps include auto emails sent to both the prospective student, and any teachers that might be a match.
An important problem that we needed to solve was simplifying and improving the hiring process. We added Career pages to the school websites which sent applicants' information directly to the admin portal on the Teacher Onboarding page.
When the candidate submits an application, it appears as a card on the teacher onboarding page. When the admin opens the application, they have the opportunity to reject the candidate or move them forward. Either way, an auto-email gets sent to the candidate.
The automation on the backend helped us speed up this process significantly, and prevented things from falling through the cracks.
Since we're a very small team, my contributions to this project spanned product management and design. One of the biggest challenges was creating, upholding, and updating the product roadmap due
to the size of the team. Since we were all wearing multiple hats, the capacity of the team was dependent upon what else was going on in the company. Prioritization had to be dynamic and projects had
to be directly effecting an important KPI in order to get prioritized.
Some important key performance indicators that we've focused on in recent quarters have been:
• Increasing lessons taught per month (decreasing cancellations)
• Improving LTV (the lifetime value of the client)
• Decreasing teacher churn
• Increasing number of booking forms
• Decreasing "time to onboard" (from first reachout to their first lesson)
During the student onboarding process, one of the biggest challenges turned out to be finding a teacher who is a good fit and close in proximity to the student's house.
Our solution: a scheduling column within the student onboarding card listing teachers with the correct availability and instrument, and ranked by distance from the student at that time.
Matched teachers recieve auto-emails with embedded buttons: "I'm interested" or "Not this time." This is reflected in the scheduling column so that the administrators can help move the process along while keeping the teachers' drive times down.
One initiative we took was setting up auto-emails on Sunday evenings to remind teachers about their upcoming schedule. This gives them the opportunity to look ahead and reschedule lessons if necessary.
As we iterated on the calendar, we decided to put more thought into the process of cancelling a lesson. We wanted to incourage makeup lessons / rescheduling, so we built that into the cancellation flow.
Originally, the contact page on the school websites created an inquiry card on the onboarding page of the admin portal. Our administrator's biggest goal was to get those prospective customers to fill out a
"New Student Form" which got them into our database, and gave us the information we needed to get them scheduled.
The admins were working hard to decrease the time it took from first inquiry to filling out the new student form. We decided to get that number to zero by cutting out that step.
Our concern was that it would scare people off from reaching out, so we solved that with a chat box.
Now when a prospective customer reaches out for the first time, it comes either in the form of the chat function or the "Book a lesson" form. When a customer uses the chat, a card is created in the admin portal task page
with steps for the administrators to follow. When a customer fills out the Booking form, a card gets created on the Student Onboarding page, and is connected to several automations with the goal of pushing the prospective customer forward as quickly as possible...
As we are constantly pushing forward new features, here are some that have made a big impact in the past couple years.
Management can now monitor the important data within their business such as student churn, cancellations, LTV, and much more.
The calendar is connected to every inch of both the admin portal and the teacher portal. It is the basis of scheduling (obviously) as well as billing and teacher payments. The administrators can see all teachers' schedules as well as availability. To prevent double-booking, they can set an "offer" until it's confirmed, and then switch it to "event."
From its humble beginnings processing teacher timesheets, we developed our billing portal into a end-to-end system from timesheet submission to customer billing and teacher payment.
The Atharo Admin Portal is trurly the tool that changed the game for us. It's the reason that we were able to go from 1 music school to 8 and counting, all being managed by 2 administrators. To get a better understanding of its counterpart, check out the case study on the Atharo Teacher Portal.