Deliverable 2 of 5

Mega Tool vs. AIM — System of Record Matrix

Field-level reference of which system owns what, where syncs happen, and where the handoff lives. Red-highlighted rows are unresolved questions.
How to read this: Each row is a piece of data in the rental process. "System of Record" is the authoritative source of truth. "Sync Direction" shows which way data moves between Mega Tool and AIM. "Sync Trigger" is what causes the data to move. Rows with a red ? highlight fields where the behavior is not yet confirmed and we need a decision.
Mega Tool owns this field
AIM owns this field
Both have a copy
✓ Immediate sync confirmed
5 min poll scheduled sync
Customer & Account Data
Field / Record System of Record Sync Direction Sync Trigger Notes
Customer account (name, address, contact info) Both MT ⇄ AIM ✓ Immediate on create from MT
5 min poll from AIM → MT
Confirmed by Swiz/Jack after 3/30 meeting.
Student / dependent info (student name, school) AIM AIM → MT (read-only display) 5 min poll Dependents tab in AIM is current source. CSR should set student + school on account creation (per Nicole's phone process).
Website login / password Mega Tool Mega Tool only Not synced to AIM. Convention today: password = phone number.
"Claim AIM Account" dedupe match rules Mega Tool (proposed) MT reads AIM Real-time lookup See Q1 — match on phone? email? name+zip? and does it fire on both web signup and CSR-initiated flow?
Rental Agreement Data
Field / Record System of Record Sync Direction Sync Trigger Notes
Rental agreement template (IL / IN / MI versions) Mega Tool MT only Managed in CMS. School selection drives which template is used.
Rental agreement record (the signed doc) Mega Tool MT → AIM (metadata only) On signature PDF lives in Mega Tool; AIM holds a pointer/reference.
Signature + timestamp (legal) Mega Tool MT only Audit trail is in Mega Tool for compliance.
First payment date Mega Tool MT → AIM On agreement create Default 4 months; CSR can override to actual date.
Rental rate, purchase price, description, condition Mega Tool (per agreement) MT → AIM (on order) On order creation in AIM Standard values come from Mega Tool catalog. CSR overrides flow through to AIM invoice.
CSR override of rate / price Mega Tool MT → AIM On save See Q2 — conflict resolution if AIM inventory state differs from what CSR overrode?
Agreement version (original, V1, V2, REV) Mega Tool MT only (latest version pointer to AIM) On revision All versions preserved in MT. AIM references latest active version. See Deliverable 4.
Order, Payment & Delivery Data
Field / Record System of Record Sync Direction Sync Trigger Notes
Cart / order AIM MT sends rental config → AIM CSR-initiated CSR builds the cart/order in AIM. MT does not carry a cart for this flow.
Invoice / downpayment AIM AIM only All invoicing/billing handled in AIM.
Credit card processing (one-time) AIM AIM only Web-based card processing has persistent TSYS issues; AIM hand-keyed processing is reliable. Confirmed scope decision.
Card on file for autopay AIM (proposed) AIM only See Q3 — does online collection auto-save, or does CSR have to ask and add manually?
Delivery ticket AIM AIM only Asset management team pulls from AIM.
Tax tables Mega Tool MT → AIM at transaction time On order Tax tables managed in MT. Rates applied at invoice creation.
Rental rates catalog Mega Tool MT → AIM at transaction time On order Standard rental rates come from MT config; overrides per agreement.
Inventory & Instrument Data
Field / Record System of Record Sync Direction Sync Trigger Notes
Instrument catalog (school, instrument, director preferences) Mega Tool MT only School-level supply lists and director preferences live in MT CMS.
Inventory quantity / serial tracking AIM AIM → MT 5 min poll Inventory-on-hand is authoritative in AIM.
Used vs. new decision & QFRR default Mega Tool (default rule) MT default; CSR override sent to AIM On order See Q4 — when MT defaults to used (QFRR) but parent wants new, which system reflects the accurate purchase price on the invoice?
Lowest-price rule Mega Tool MT → AIM On order Q&F always honors the lowest price. MT should enforce this on agreement generation.

Open questions on system responsibility

Each red-highlighted row above corresponds to a question below. Answers here have knock-on effects in the rental flow (Deliverable 1) and revision flow (Deliverable 4).

1 "Claim AIM Account" match rules and trigger points
Context

We need to decide what counts as a dedupe match (phone number alone? email? name+zip? combinations?) and whether the prompt fires only during CSR-created accounts, only during customer web signup, or both.

Why it matters

Too loose a match and we'll get false-positive "claim" prompts that confuse customers. Too strict and duplicates will slip through. Firing on both surfaces is more work but addresses the root duplicate problem; firing only CSR-side handles the phone-rental scenario but leaves the web-signup leak open.

Transcript 33:56–34:32
2 CSR override vs. AIM inventory state — who wins?
Context

Nicole described a scenario where MT has one instrument/price mapped but AIM inventory has already swapped to a different instrument during a busy-season crunch. CSRs currently edit manually. We need to decide: does the MT agreement override AIM, does AIM update MT, or does the CSR see a conflict prompt and resolve?

Why it matters

MT-wins: simpler, but the invoice can show wrong product. AIM-wins: invoice matches what ships, but the agreement document may name the wrong instrument. Conflict-prompt: safest for data integrity, adds CSR workload. Q&F's "honor the lowest price" rule needs to survive whichever path we pick.

Transcript 37:27–38:02
3 Card-on-file autopay — automatic or CSR-opt-in?
Context

Related to Deliverable 1 Q4. The system-of-record question is specifically: if/when we do save a card for autopay, is AIM always the vault (matching today's reliable AIM card processing), or do we ever consider storing it elsewhere?

Why it matters

AIM-as-vault: aligns with current reliable practice and avoids TSYS web-interface issues that Marsha and Nicole flagged. Alternative vaults add PCI scope and integration work. Strongly recommend AIM-as-vault, but it needs explicit confirmation.

Q&F Notes.pdf #5; Transcript 20:36–21:30
4 Used vs. new + QFRR default — purchase-price truth source
Context

Mega Tool defaults to pulling a used QFRR (refurbished rental return) instrument. Parents sometimes insist on new — same rental rate, different purchase price. Today Nicole overrides manually. We need to pick whether the override lives in MT (and flows to AIM) or whether AIM's inventory determines the price.

Why it matters

MT-override approach is simpler for the new flow since the CSR is already in MT creating the agreement. AIM-inventory-drives approach guarantees invoice accuracy but requires bidirectional updates when the parent changes their mind mid-call. Both paths need to respect Marsha's "always honor the lowest price" rule.

Transcript 36:56–38:00
Source references
Meeting: Q&F Mega Tool Priorities (3/30/26) — tldv recording
Documents: Q&F Notes.pdf and Renting over the phone.pdf from Nicole Leaich.
Post-meeting confirmation: Swiz and Jack verified immediate MT→AIM customer sync via API.