Demo: October 4

Agenda

• Review recurring charge failure notifications
• September 25 meeting recap
• Demo: client-property records

Recurring charge failure notifications

Portal notification of decline

• what is the current practice? Do you reach out to client, or retry immediately?

Stripe notifications

Error logging captured

Current Payment Plan Index

Improved Payment Plan Index

Sept 25 meeting recap

Challenges

When we associate Clients to Properties, we want an unambigious link between a client and a property record. Normally that means a unique key for both tables. But in PAMs,

1. We don’t have a Client ID key — the client name is used instead
2. We don’t have a Property table — properties are really property-for-appeal years

Observations

1. The PAMs “Property Address” is really a “property name.” It changes, it doesn’t reflect the USPS postal address, and isn’t normalized. When a property is sold to another client, the property name is changed slightly to distinguish it from its prior records. This works fine for the property-appeal-year table, but presents challenges when we want to think about “the property” itself.
2. We only want to solve problems we have to solve, today, for the Client Portal.

Possible Solutions

1. Solve the problem: we could create a new “Properties” table.
2. We could not solve this issue for the portal right now. We could grab the property-year record via client_name as foreign key, and use that in the Portal.

We tested this approach against several edge cases:

• 2012-2018 Parkside
• A developer buys multiple parcels, and over the years, builds out a 300 unit building; PINs change.
• Ms T has a shop, which is ¹⁄₂ of a parcel; she shares the PIN with Ms X.

DEMO Client / property import