Client portal & reporting
A family pays tens of thousands of dollars a year and the engagement runs three to four years. The parent signs on trust. Then, for most of those years, they see very little.
Strategic foundation
That gap is where the money leaks. Families rarely leave because the work was bad. They leave because twelve months went by, nothing was visible, and they drew their own conclusion.
So we didn't start with screens. We started by asking where the revenue comes from and why clients walk. Everything below came out of those two answers.
Stakeholder alignment
The brief called for a portal where students log in and follow their own progress.
Research said otherwise. The people who log in week after week, and who use what they see to judge whether the money was well spent, are the parents. The student is who the service is for. The parent is who uses the software.
So the design assumption changed. We rebuilt the interface around how a parent reads rather than how a student operates, and we cut the student's ability to edit records. One accidental change and the report a parent receives is wrong, and that lands on the institution.
We didn't only take things away. Students got somewhere to upload their own materials and access to a shared resource library. Each role ended up able to do the things that role actually does.
Early structural sketch: mapping student operational scope vs. parent reading viewport.
Client experience architecture
Standard practice would be to email the family a registration link once they sign.
We argued against it. A parent who has just committed to years of fees at this level, and is then asked to create an account, verify an email and pick a password, has been handed a chore at the exact moment they are most sensitive to how they're being treated.
Accounts are created by the institution instead. The family gets a welcome pack and one link, and lands in a workspace that already has their student in it.
It costs an admin about a minute per account.
Institutional knowledge protection
In this industry the most common way to lose a family is not poor results. It's a consultant walking out the door.
Trust attaches to a person. When that person resigns the family often follows, and the institution is left holding an empty file. It usually can't even prove what happened.
A back-office system that ignores this is helping the consultant build his own client list.
We restricted export and cross-student access at the consultant level and consolidated the complete view and full history under the admin account. Consultants get everything they need to do the work. They can't walk out with the institution's assets.
Marketing site interface: anchoring authority on institutional leadership and proven outcomes.
Strategic advisory
The client wanted a page in the brochure listing every mentor on the roster. His reasoning was sound. The first thing a parent wants to know is the strength of the teaching team.
So we built it. Then we sent both versions over with three concerns attached:
Conversion architecture
We didn't build the marketing site to the brief either. We asked first where the traffic actually comes from.
Someone arriving from Xiaohongshu or WeChat already knows what the firm does. They have read the posts and watched the videos. They are on the site for one reason, to check that this is a real operation worth three years of their child's life.
Someone arriving from a search engine knows nothing yet and needs the basics.
Those two readers want opposite things. One is verifying, one is learning. We ordered the information for the verifier and pitched the depth for the newcomer, so the same page does both jobs.
Competitive positioning
A more fundamental question surfaced while we were working through the content.
Every firm in this market sells the same two things, faculty pedigree and years in business, and the older houses will always have more of both. That contest is decided before it starts.
This client had something none of them had. The entire service process existed as data, stage by stage, because the system we were building made it so.
Parents don't buy CVs. They buy a place at a good school, and credentials are one route there. Verifiable process management is another, and nobody was standing on it. We recommended building the position there, and replanned the system to match:
The core deliverable
This is what the whole argument was built toward. A report that reaches the family every month, that nobody had to assemble by hand.
Automated, immutable monthly progress report delivered directly to parents.
System architecture
Service blueprint from discovery. It maps what the family experiences, what the institution has to do, and what the platform has to support at each stage. The module list came out of this, not the other way round.
Security & compliance
Student records contain sensitive personal information and academic history.
Prior to deployment, we completed a thorough compliance review, migrating storage and databases to compliant US-resident cloud infrastructure with tiered role permissions and access logging.
Delivered as an integral engineering standard. In high-value advisory, data integrity and student privacy are foundational to institutional reputation.
Full scope delivered
Multi-disciplinary partner delivery across design, software engineering, and data infrastructure.
