Each red-numbered badge on the diagram corresponds to an unresolved question below. Context and ramifications included so you can decide without guesswork.
Marsha wants the system to detect existing AIM customers during signup so we don't create duplicate records. The question is whether "Claim AIM Account" triggers only during customer-initiated web signup, or also during CSR-initiated phone rentals when a possible match is detected.
If CSR-only, duplicate accounts will still happen when customers later sign up online. If dual-trigger, we need a second surface (web signup) with its own UX and a stronger matching algorithm. Dual-trigger is more effort but more effective at preventing duplicates long term.
CSRs need to override first payment date, rental rate, purchase price, description, and condition (e.g., honoring a half-price window that just closed, customer wants new-vs-used, inventory swaps). We have not discussed limits, approvals, or audit trail.
Unconstrained overrides create financial risk and audit headaches. Heavy approval workflows slow the CSR on the phone and defeat the efficiency gain. Possible middle paths: override dropdown with preset values only, override up to a $ or % limit with manager approval above, or free-text overrides with a mandatory reason code captured for reporting.
Current phone process: CSR invoices the downpay and collects payment in AIM, then creates the SignNow agreement (per Nicole's "Renting over the phone" doc). The new flow could enforce the same order, or it could allow the agreement to be emailed in parallel while the CSR processes payment in AIM.
Strict order: safer — we never email a signing link for an order the customer didn't pay for. Slower — blocks the CSR from wrapping the call until payment clears. Parallel: faster, lets the customer start reviewing while the CSR wraps up AIM. Risk: if payment fails after the agreement is sent, we have to cancel or void. In busy season, the parallel path could meaningfully shorten call time.
Nicole asked: if payment is collected online via the new flow, does the card automatically get stored for autopay, or should the CSR still explicitly confirm with the customer and add it manually in AIM?
Automatic-save is faster but raises consent questions (we need explicit customer agreement to store the card for future charges; this is usually a checkbox). Manual-ask matches current practice but adds a step. There's also a regulatory/PCI angle — AIM is the current system of record for stored cards because of TSYS/web interface issues, so whichever path we pick has to work with AIM as the vault.
Nicole says customers today complete web rentals and "don't automatically get a copy of that agreement sent to their emails. They don't even remember what they filled out or signed." The fix is either attaching the signed PDF to the confirmation email, linking to the customer portal (see Deliverable 5), or both.
Attachment-only: customer has the file immediately but email clients sometimes strip or block PDFs. Portal-link-only: always available but requires login and therefore call-volume to support forgotten-password resets. Both: belt-and-suspenders, small dev cost, reduces customer-service call volume meaningfully.
Today, a typo in a SignNow agreement (kid's name, email) requires voiding and sending a fresh document. Nicole wants relief. We could allow inline edits in the Mega Tool for agreements that haven't yet been signed, without creating a new version.
Inline edits: fewer revision records, lower friction for CSRs and customers. Risk: customer may have already opened the signing link with the old text — legally, the signing UI must always show the current version, so we need a mechanism to invalidate the link the customer is looking at and serve the new content on refresh. Full regeneration is the simpler, safer path — but it keeps the pain point Nicole flagged.