Perks

Eligible vs. "pre-eligible":

• Some perks you are "almost" eligible for, but not quite.
• You may need to complete direct deposit setup before you are eligible, but you are in the right group etc.
• You may need to get longer tenure, but you are otherwise in the right group.

Call these perks for which you are "pre-eligible". Render these as if you were eligible, but with a call-to-action / banner explaining when/how you can get it.

Available perks: A perk for which you are eligible or pre-eligible

Opt-in vs. auto-opt-in:

• Some perks are auto-opt-in, and are given via a worker.
• Other perks have an opt-in button.
• Some opt-in perks have an approval process.

Perk setup:

• Pay Me Now perk
• "I understand Pay Me Now" -> Configured perk
• Now you want to use the perk ->
  • Select your amount (optionally)
  • Creates perk instance, sends you money
• Flat tire loan
  • "I want this much money" -> Configured perk, pending approval
  • Employer approves -> create perk instance

Models

An organization has a number of enabled perk categories. These restrict the perk templates that the organization can see, and perks that the organization can create.

The superuser organization has a bunch of PerkTemplates.

Each organization has has perk templates that are pointers to superuser organization perk templates, and custom perk templates that superuser administrators have created for that organization.

PerkType: enum (Bonus / Loan / Badge / etc)

PerkTemplates: Organization Pointer: PerkTemplate. Type: PerkType. Per-type settings. Name Fine print: legal-ish description Active/Inactive (across all of Exhale) Superuser-level criteria.

Perks: Status for a particular member: _ineligible _ pre-eligible _eligible Name / Display name / Headline / Description Type Per-type settings (amount range). PerkTemplate: just for reference; updates to the template do not affect the perk. Active/inactive (this may need to be heavy). Criteria (so we get allowlist/blocklist/member-level properties) _ Move shared groups to be less prominent. Superuser-level criteria (initially copied from the perk template) Superuser-level criteria comes first. Opt-in type: auto-opt-in, user-opt-in, approval Perk types control state transitions for perks (e.g. when do we take the information about how much you want to be loaned vs. richer loan application information).

Actions: - Duplicate - View currently eligible members - Editing groups: we may want to let you "publish" these as well. - Publish/unpublish/archive? - Remove: remove configured as well, leaving underlying objects when relevant. Possibly disallowed. * If the perk has never been active/configured, maybe Remove is easier?

Configured perks:

• pending approval
• needs attention? -- maybe this is a "flag" that sends a notification.
• ready
  • They can have a "go" button
  • Or they can just sit there doing their thing
• approval rejected
• user rejected (don't offer me this kind of perk again)
• completed pending acknowledgment (or completed with needs attention?)
• completed
• hidden (for revoked perks)

Perk instances:

• stateless
• just a record of something that happened
• point at the actual transaction or whatever

Portal UI

Individual perk view

Perk creation

"Quick person finder"

• Jump menu style
• Search for members, perks, groups, organizations (for superusers)
• View a member and all of their configured and available perks
  • Allow user rejection by the organization administrator, too.

Flow

• "Add perk": only type is required, maybe with name
• End up on single perk view, with your perk type's options
• Allow editing criteria, highlight/indicate that you are editing clearly; cancel to revert
  • Show diff between current criteria and edited (but not saved) criteria
• Allow reverting to previous criteria (via activities feed for this object)

Consumer UI

My Perks:

• My perks are configured perks that are ready or completed-pending-acknowledgement.
• Separate section for completed

Available perks:

• perks for which you are eligible (or pre-eligible, at the bottom)
  • do not show perks for which you have a user-rejected configured perk
• configured perks that are pending approval (but don't show the perk itself)

Perk activity:

• all of the instances

Examples

High yield interest on savings account:

• Pre-eligibility: direct deposit + existing savings account
• Perk: "Opt in" button -> show opt in button, creates configured perk.
• Configured perk: immediately creates perk instance.
• Perk instance: active, no ability to remove(?)

Savings match:

• Pre-eligibility: direct deposit + existing savings account
• Perk: "Opt in" button -> show savings match form, creates configured perk.
• Configured perk: automatically creates perk instances every pay period.
• Perk instances: record savings match transfers.

Discretionary bonus:

• Pre-eligibility: none

• Perk: Auto-opt in?

• Payroll integration?

Badge booklet: type: Award

• Joined

• Mobile app

  1. Group targeted to everyone.
  2. Flag on user upon first app login; this is not criteria-targetable.
  3. Auto-opt-in.
  4. Should auto-opt-in show up in available perks? Let's say yes.
  5. Every day (or whatever) we run auto-opt-in.
  6. "Here's a perk, for which I am criteria-eligible. I check perk eligibility and conclude I'm not eligible. What do we do?" Ok, try again tomorrow.

• Direct deposit requested

• First received deposit

Criteria + Shared Groups

What happens when you hide a group that is part of another group?

When you edit a shared group you could affect eligibility across multiple perks.

• Show, shared groups should show which perks are affected by this shared group.
• Groups referencing groups make this confusing; how to clarify why a perk is affected by this group?
  • "Via" language?
• Maybe when you edit but don't yet save the criteria, you see:
  • All perks that use this shared group, show the difference between previous and new member lists.
  • Lets us give people "can't view member perks" while still letting them effectively administrate the system.
• There are some criteria types that are superuser-only; possibly we should only allow their use on the superuser criteria associated with perk types and perks.

Permissions

• View members but can't view their perks?
• View matches but not principal?
• Rule: we only show you the information that enables you to provide the perk.

Perk types

Loan:

• Get immediately, pay back in installments per paycheck.
• Get immediately, term/balloon payback

Perk libraries

Webhook

• Solid webhook comes in
• Deposit for account
  • Check deposit watchers
  • Find the direct deposit watcher
  • Check perks related to the watcher
  • How do we order these? E.g. if you have 3 perks active:
    • EWA
    • Flat tire fund
    • Savings account match
  • Gather configured perks into immediate, owed, net
  • Trigger each perks in order, carrying state between them?

Idea:

• First immediate payback for "money that isn't actually yours"
• Next comes loan payback for "money you owe"
• That yields "net deposit"
• Run through net deposit perks

Next Steps

Secure Direct Deposit Account:

• How/where to show this?
• How much functionality to start?
• Just a checking account under the hood for now.

Models:

• Perk Types
• Perks
• Configured Perks
• Perk Events

Views:

• My Perks
  • Current
  • Past
• Available Perks
  • Needs information
  • Pending approval
  • Eligible
  • Pre-eligible
• Perk History
  • Reverse chronological list

Webhook handler:

• Receive a webhook about a deposit
• Is it a direct deposit? Run logic.
• Otherwise, forward to checking account.