Want to know if this job is worth applying to?
Taguig, Philippines
Onsite
EviSmart
|
“Engineering ships the feature. This role makes sure it was the right feature — and that every person who needs to use it actually can.” |
📍 Manila, Philippines • On-site • Full-Time • Reporting to: Lead Systems Analyst
EviSmart is the leading dental Autopilot system operating across 28 countries in a $40B healthcare industry — and the Manila team builds and ships it. Not an MVP. Not a pilot. Live, in production, with thousands of dental labs and dentists depending on the platform every day to run their business.
We have multiple in-house AI teams building the next generation of dental design automation — and Manila is where it gets operationalized. Every feature we ship goes into the hands of real users running real operations. The Quality & Adoption Specialist is the person who makes sure features land correctly — verified against requirements before release, and adopted completely on the day they go live.
EviSmart ships continuously. The engineering team builds against Functional Requirements Documents. The operations team runs a global platform. And in between those two realities sits a critical gap: who verifies that what was built matches what was asked for, and who makes sure every end-user is ready to use it on Day 1?
Right now, that gap is managed informally. Features go live and edge cases surface in production. Support tickets accumulate around things that should have been caught in UAT or covered in training. Business stakeholders sign off without structured sessions. And when something is wrong, it takes longer to trace than it should.
The Quality & Adoption Specialist closes that gap permanently. This role owns the full bridge between Build and Live Operation — functional testing against FRDs, UAT management with business stakeholders, end-user training and documentation, and a 30-day post-launch audit to confirm adoption is real and support tickets are falling. When this role works, features land right the first time and users are ready for them.
|
“A feature that works but that nobody uses correctly is a failed feature. A feature that passes QA but ships with the wrong behavior is a failed feature. This role exists to make sure neither of those things happens — and to give us the confidence that what goes live is right, and that our users are genuinely ready for it.” — Des Peraren, CTO / GM, EviSmart Manila |
|
Area |
What You Do |
|
Functional Testing |
Create and execute detailed manual and functional test cases based on Functional Requirements Documents (FRDs). You verify that what was asked for is what was built — every time, before release. Edge cases are not optional. |
|
UAT Management |
Lead User Acceptance Testing sessions with business stakeholders. You structure the sessions, ensure all business edge cases are covered, and are responsible for gathering formal sign-off. UAT is not a formality — it is the last gate before go-live. |
|
Documentation & Enablement |
Own the creation of Help files, How-To videos, and tutorials. Every feature goes live with self-service documentation already in place. If a user has to ask a colleague how something works, the documentation is not done. |
|
User Training |
Conduct formal training sessions for end-users — Head of SaaS Ops, Data Annotation Leads, and others — before each feature goes live. 100% of targeted users are trained and able to perform the task on Day 1. Not most. All. |
|
Post-Launch Audit |
Monitor the first 30 days after every new feature launch. Verify the feature is being used as intended. Confirm that solvable support tickets related to the feature are declining. Document findings and flag any adoption gaps before they become support volume. |
|
Milestone |
What It Looks Like |
|
30 Days |
All existing FRDs reviewed and understood. First set of functional test cases built and executed. First UAT session structured and facilitated. Baseline support ticket volume for recent features documented. |
|
60 Days |
Test case library established for all active feature areas. At least one full feature cycle owned end-to-end: functional testing → UAT sign-off → documentation → user training → post-launch monitoring. Feedback loop with engineering on defect turnaround running. |
|
90 Days |
KPIs tracking at target: Requirement-Driven Rework Rate below 5%, Day 1 User Readiness at 100%, measurable reduction in solvable support tickets on launched features. Documentation library current and self-service ready for all active features. |
|
# |
KPI |
Target |
What It Measures |
|
1 |
Requirement-Driven Rework Rate |
<5% |
Features that require re-work after testing because the functional design was wrong — not bugs, but misaligned requirements |
|
2 |
Day 1 User Readiness |
100% |
Percentage of targeted users who are trained and able to perform the task on the day a feature goes live |
|
3 |
Reduction in Solvable Support Tickets |
Measurable decline |
Support tickets on launched features that could have been prevented by better training or documentation — tracked over the 30-day post-launch window |
We share work before it is ready. We debate decisions loudly and execute them quietly. We default to fixing problems instead of escalating them. EviSmart moves fast — the standard is high and the pace is real.
A feature that ships with an undetected requirement gap is not an engineering failure — it is a quality failure. A user who is not ready on Day 1 is not a training problem — it is an adoption failure. This role exists to make sure both of those failures happen less and less, and eventually almost never.
If you have worked in QA roles where testing meant running a checklist and training meant sending a PDF — you will notice the difference on your first week.
|
“Why EviSmart and not a larger company? Because at a larger company, quality and adoption are split across four different teams and nobody owns the outcome. Here, you own the full bridge between Build and Live. When a feature lands well — verified, adopted, and reflected in the support queue — that outcome has your name on it. That kind of ownership is rare. We think the best people want it.” — EviSmart Talent Team |
The most common hesitation we hear from strong candidates for this role: “Is this actually a QA role with training added on, or is it a training role with some testing in the mix?”
It is neither. This role owns the full lifecycle from requirements validation to adoption confirmation. Functional testing and UAT are not the job — they are the first half of the job. Documentation, training, and the 30-day post-launch audit are not extras — they are how you know the feature actually landed. A specialist who tests well but does not own adoption has done half the job. A specialist who trains well but does not catch requirement gaps has done the other half. This role does both.
This is also not a passive monitoring role. You run the UAT sessions. You conduct the training. You build the documentation. You track the support ticket data post-launch. The quality and adoption outcomes are yours to produce, not to observe.
|
What Makes This Role |
What That Means |
|
The bridge is the job |
Functional testing and user adoption are not two separate responsibilities stapled together. They are one continuous ownership — from verifying the build against requirements to confirming that real users are using it correctly 30 days after launch. Both halves have to work for the feature to be considered successfully shipped. |
|
Sign-off is not the finish line |
UAT sign-off is the midpoint, not the end. The 30-day post-launch audit is how this role closes the loop. If support tickets are not falling and users are not performing the task correctly, the feature is not done — regardless of what the release notes say. |
If you are the kind of specialist who reads a requirements document looking for the gaps, runs a training session and then checks whether it worked, and feels personally accountable for whether a feature actually lands — this role is built for you.
Apply at EviSmart Careers
EviSmart • Philippines • evismart.com