Current Challenge:
The existing workflow for editing payment plan charges requires users to input a percentage for each installment, after which the system calculates the corresponding dollar amount. While this may work in theory, it creates a frustrating experience when trying to assign exact dollar amounts to specific installments—especially in cases where families request precise payment distributions.
Why It’s Problematic:
It’s unintuitive: Most users think in terms of dollar amounts, not percentages.
It’s error-prone: Small miscalculations in percentages can lead to discrepancies in billing.
It’s inefficient: Users often have to manually calculate the percentage that matches the desired amount, which defeats the purpose of automation.
Proposed Solution:
Allow users to enter the dollar amount per installment directly, and have the system automatically calculate the percentage based on the total charge. This reverse-calculation approach would:
Make the interface more user-friendly
Reduce manual errors
Improve flexibility for custom payment arrangements
Align with how users typically think about billing
Example Use Case:
If a parent wants to pay $500 in September and $300 in October, the user should be able to enter those amounts directly. The system would then calculate the percentage each represents of the total tuition and apply it accordingly.
Maybe set up options to deal with mis-applied payment plans (for example a payment plan designed to deal with $30,000 applied to $40,000 in charges) such as:
Select Overflow Method:
Do not allow charges not equal to plan total to be applied to this plan.
Evenly apply overflow across all installments.
Apply overflow across all installments based on % of each installment of intended total.
Overflow is due as a lump sum on [select one: first; last] installment.
Overflow is due as a lump sum on [select specific date here].