File naming convention shown: {Student}_{Instrument}_{SchoolYear}_V{n}.pdf — see Q2 below if this needs adjustment.
Since Marsha framed this as an "a la carte carve-out," answers to these questions will directly affect whether we can hit a reasonable budget.
Marsha flagged: "We are able to print them in the customer service backend. We're able to print on demand." The question is whether the customer portal should surface paper agreements at all, and if so, what action is available.
Hide-entirely: simplest, but customers with only paper agreements will still call. Placeholder-only: acknowledges the agreement exists but leaves the customer needing to call anyway. Request-a-copy button (as mocked above): most effort to build (needs a CSR queue, scanning workflow) but most fully solves the underlying complaint and over time converts paper → digital. Recommend the request-a-copy path if scope allows; hide or placeholder otherwise.
When a customer saves their PDF to their computer, the filename is the first thing they see. We need a convention that helps a parent find the right file when they have multiple kids and multiple years.
Our current proposal: {Student}_{Instrument}_{SchoolYear}_V{n}.pdf. Alternatives: include Q&F brand (for professionalism when forwarded to schools/insurance), include rental start date instead of school year (more precise for multi-year), or compress to shorter names. Should be Marsha's call — ideally informed by what customers actually ask for when they call Nicole.
Per Deliverable 4, revisions preserve V1 alongside V2. In the customer portal, we can surface every version (like the mock above) or only the current one.
Show-all: complete transparency, but potentially confusing for customers who don't need to see superseded versions. Show-current-only: cleaner UX, but customer may have questions about "but I signed a different one first." Recommendation: show current by default with an "expand" / "show previous versions" affordance for customers who want history.
Downloads/reprints can be logged (customer ID, timestamp, which agreement, which version). Alternatively, we treat reprints as silent — no log entry.
Log-reprints: useful for call-center triage ("I see you downloaded the agreement yesterday, is that the one you're calling about?") and for light fraud detection. No-log: simpler, fewer compliance questions. Low implementation cost either way — the question is primarily about operational utility.
If two parents share custody, they may each have their own account. Does each account show only agreements they personally signed, or all agreements for their child?
Per-signer: simplest model, but a non-signing co-parent can't retrieve the copy. Per-student: more useful to parents but requires a student-to-account relationship model (Q&F's AIM dependents tab does capture this today). Privacy-sensitive edge case: separated/divorced parents — we may need the ability for a signing parent to explicitly share or lock visibility. Worth getting Marsha's read on Q&F's actual customer base.
If we build the "Request a copy" button for paper agreements (Q1 resolution), we need to define: where does the request land (new task queue? existing queue?), how CSRs are notified, expected turnaround time, and what the customer sees in the meantime.
Under-promising on SLA (e.g., "2 business days") is safe but may prompt impatient follow-up calls. Over-promising ("within 24 hours") improves CX but strains CSRs in peak season. Building a dedicated queue is a few days of work; piggybacking on existing CSR tasks is faster but risks requests getting lost. This is a scope-vs-fidelity choice.