v2 Review — Stakeholder Answers (Apr 22)

Stakeholder Answers — 2026-04-22

From: Lejla Pehlivanovic | To: Kamran | Source: Apr 22 working-session meeting transcript (QF-Backend-Review-Apr-22.md)

This document is the durable record of the Apr 22 working session that resolved the three topics deferred from the Apr 15 review and the Apr 21 reply:

• A. Reporting — scope, formats, delivery
• B. Issue Queue — state machine, delegation, archive
• C. Repeat Semester — admin-side workflow, tagging, TA assignment policy

It extends (does NOT supersede) STAKEHOLDER-ANSWERS-2026-04-21.md. The Apr 21 doc resolved End Checklist + defaults; this Apr 22 doc resolves the remaining deferrals called out in lejla-email-draft-2026-04-21.md §A–C.

The spec edits that apply these answers are tracked in _apr22-worklog.md. ADR amendments: ADR-002 (repeat-TA rule inversion), ADR-006 (Issue Queue state machine, new).

Reading order: start here for the decision record. For verbatim conversational context, go to QF-Backend-Review-Apr-22.md. For the transcript-line-to-spec-edit traceability map, see _apr22-worklog.md §2.

Verbatim excerpts (transcript citations)

All excerpts are lifted from QF-Backend-Review-Apr-22.md. Line references point to that file.

A. Reporting (lines 41–64)

Lejla (L41): "The reporting section essentially needs to provide me with. All the reports that we would need in order to. Assess how the student body is doing how our enrollment is doing how what are we reaching like our target revenue like anything that we would need in order to assess like the health of the student body… I need to sit down and just figure out what type of reports will be useful to us."

Lejla (L47): "An overview of like the active semester enrollment. So it's essentially giving me a list of all the students who are enrolled as new students who are who enrolled as a repeat students who enrolled in year two and it's giving me all the students who are enrolled as level graduates with their status with their payment status."

Lejla (L55): "I would like for that for all of that information to be available in one place like which like new students are signing up how many students have graduated a level and are like have canceled their enrollment how many have signed up for repeat… the student body breakdown of like how many you know new students how many like level one level four level two year two students for each individual elective like gender, you know based analysis also just giving like the diagrams on when we had like the highest enrollment."

Lejla (L55, cont.): "We would like ideally we would also like to have like the revenue breakdown so how many students have like what percentage of students and at what amount has signed up for repeat for like family pricing so that we know like how much again just having like a clear picture of what the like revenue stream is looking like."

Lejla (L55, cont.): "For students who have like signed up maybe for installment payment for their first semester if they were offered. The one time payment for the next semester like to. You know, provide a discount like how many students would opt for that."

Lejla (L55, cont.): "Reports regarding notifications like letting us know if certain notifications or like emails contributed to more attendance for live classes or contributed to people catching up on their submissions."

Kamran (L56): "Normally what you do is you start off with your basic reports and then you build out from there. And some of the analysis that you're looking for, you do have to do independently. Like a report is something that's typically your base and it's there for reporting, right?"

Lejla (L59): "Understood. But I kind of also have to think like which information should be included in the report in order for me to do the analysis."

Kamran (L60–64): "I think that covers it. And then I think the export format CSV and PDF works?" — Lejla: "CSV is fine." — Kamran: "Yeah. And then live dashboard for some and then scheduled emails. Maybe I think it's just like downloadable versus or live."

B. Issue Queue state machine (lines 65–89)

Lejla (L65): "That's tricky because we have to figure out. How to not overlap with the CS team… If we are making reporting issues very easy to students and teachers in the app. And we are seeing all of these inquiries that are coming from, you know that stream the question is okay let's say a student submits an issue saying I can't see my. Live like I can see any sessions in my live schedule. That message will go to our dashboard. So the issue queue and then it will also go to our fresh desk inbox."

Kamran (L66): "Right now assume that there is no fresh desk integration. It's just going into the admin. Dashboard, the issue queue that you see here."

Lejla (L67): "Students will sometimes. Use the like the help button or the report issue button to report like a tech issue… But sometimes they will have like. Paragraph texts of like, oh, I'm falling behind and my mother is sick and my dog just died. So there is like a, you know, there is. Something that's not tech related that's being reported through that format."

Kamran (L68): "But there should also be one delegated too. And it could be delegated to."

Kamran (L70): "It could be delegated to CS or maybe even delegated to teaching staff or delegated to it."

Lejla (L73): "That would be excellent because if we could have it just like delegated to IT."

Kamran (L76): "Delegated kind of just means that you're informing them. But at the end of the day, whoever is managing the issue queue is still managing it. They're still going to have to follow up and make sure that they're getting answers."

Lejla (L77): "We can maybe just change the language from delete to like reject." — Kamran (L78): "Okay. So yeah, we'll change that to reject." — Lejla (L79): "Resolve and reject. Yeah."

Kamran (L80): "Can a resolved issue be reopened? Yes, it can." — Lejla (L83): "I would say go back to open and then adjust accordingly."

Lejla (L85–87): "I will keep everything… in. Just keep everything like an archive or something."

Lejla (L89): "I think it would be good for us to kind of run like run report and see what. How students are using it because that would also maybe help us figure out like what language needs to change in order to make it more clear for students what we are using this dialogue box for."

C. Repeat Semester workflow (lines 90–126)

Kamran (L90): "Does the admin need to see the list of students who opted in?" — Lejla (L91): "Yes."

Lejla (L93, L97): "It doesn't need to be, yeah, so it like I would keep it in the, I'm not seeing like in the new what's it called in the new mockup. I'm not seeing that section that we discussed like active enrollments. Remember like we had that." … "It could. Be, yeah, it could. Yeah, but you have to like filter by the new semester, I guess."

Lejla (L101): "What I would need to also have like a separate column would be like what their enrollment situation is. Because they could be year two students, meaning they could be continuing students. Meaning either they graduated from levels one to four or they are year two students. So those are continuing students, meaning they were with us. In the previous semester and they are enrolling in something new in the next semester. They could be repeat students. And they could be new students."

Lejla (L103): "That kind of answers the question like do I need a separate repeat section? I don't, but I need an indicator somewhere."

Lejla (L111): "Fully self-service. Yeah, I don't need to approve anything. They can sign up if they got the link."

Lejla (L115): "Students get a special… They are directed to a separate checkout, which is providing them with like a 50% discount. At least that's the current workflow. And the checkout, at least the new checkout should check if the student qualifies for repeat."

Lejla (L115, cont.): "Sometimes we will allow a student to skip a semester… those, if the checkout is. Cross referencing our repeat qualify list for the current semester, they will not, it will not find that name in that list because the students has been with us like two semesters ago. So those would be like the only exceptions where, you know, there could be like a need for like a manual override."

Kamran (L116): "That sounds like something that should be like a manual override." — Lejla (L119): "Or there could be like, like add a repeat student manually. Maybe that can be within like the operations. Just like a way to add a student manually to the current, not current semester, but to the repeat list. So when they actually get, what's it called? When they get a link to repeat, they can. Like finish the checkout process without any issues."

Lejla (L121–125): "No, no, they are, they are new." … "Yeah. Just so we know. Because usually what we will do is for repeat students, we will assign them to a different teacher, if at all possible. So that's like our policy and that kind of goes into like assignment criteria as well. That a student, if possible, is assigned to a different teacher for the upcoming semester."

Parsed mapping

A. Reporting

B. Issue Queue state machine

C. Repeat Semester workflow

Deferrals made or reconfirmed

Glossary additions from Apr 22