Automate account upgrades and limit increases for STORJ token payments

[ferristocrat]

Description

The goal of this roadmap item is to improve the experience for customers who pay with STORJ tokens rather than a credit card. We aim to automate the process of upgrading to a "pro account" and adjusting the associated account limits based on token payments, eliminating the need for customers to create a support ticket. This will include setting limits based on the STORJ token balance and handling cases where the balance is too low or there are unpaid invoices separately.

Problem/Pain Point

Currently, customers who pay with STORJ tokens need to go through a manual process to upgrade their account to a "pro account" and adjust their account limits. This requires customers to create a support ticket, resulting in a suboptimal user experience and increased support workload.

Why Now?

As Storj continues to grow and attract new customers, it is essential to provide an optimal user experience for all payment methods. Automating the account upgrade process for STORJ token payments will streamline the user experience, reduce support workload, and encourage adoption of STORJ tokens as a preferred payment method.

Impact

Automating account upgrades and limit management for STORJ token payments will improve the overall customer experience, making it easier and more convenient for users to pay with STORJ tokens. This will also reduce the support workload related to manual account upgrades and limit adjustments.

In Scope

• Development of an automated system for upgrading accounts and adjusting limits based on STORJ token payments above a certain USD amount.
• Implementation of account limit adjustments based on STORJ token balance.
• Handling cases where the token balance is too low, including reducing limits or suspending the account.
• Handling cases with unpaid invoices, taking appropriate actions such as reducing limits or suspending the account.
• Documentation of the new automated process for customers and support staff.

Out of Scope

• Complete overhaul of the payment system or integration with additional payment methods.

Acceptance Criteria

1. Customers who pay with STORJ tokens can automatically upgrade their account to a "pro account" without creating a support ticket.
2. Account limits are automatically adjusted based on STORJ token payments and balance.
3. The system can handle cases where the token balance is too low, taking appropriate actions such as reducing limits or suspending the account.
4. The system can handle cases with unpaid invoices separately, taking appropriate actions such as reducing limits or suspending the account.
5. Comprehensive documentation is provided, explaining the new automated process for customers and internal support teams.

Success Metrics

1. Reduction in the number of support tickets related to manual account upgrades and limit adjustments for STORJ token payments.
2. Increase in the percentage of customers using STORJ tokens as their preferred payment method.
3. Positive customer feedback on the new automated process for STORJ token payments.
4. Reduction in the time taken to upgrade accounts and adjust limits for customers paying with STORJ tokens.

Links

• Milestone(s): TBD
• Relevant Figma Designs: https://www.figma.com/file/HlmasFJNHxs2lzGerq3WYH/Satellite-GUI?type=design&node-id=24185%3A332617&t=ceggIBTiYI6h6emC-1

[ferristocrat]

From @mobyvb:

Simple imperfect solution would be pretty easy. E.g. if we just want to bump a user who pays with STORJ to paid and adjust their limits to the paid limits, and let auto freeze/unfreeze take it from there, that would be easy. Probably fewer than two sprints of work, assuming we focus on upgrading and don't worry/care about users who pay a minimum amount of STORJ running out of their balance

Let's go with something like this

[mobyvb]

Notes:

Account limits are automatically adjusted based on STORJ token payments and balance.

This is the trickiest part of the acceptance criteria. Not because of technical difficulty, but because we will need to have clear requirements about how this works and how the user interacts with it. Since our limits are usage based and not cost based, how do we automatically decide what the storage vs egress vs segment limit should be?

My vote is that we just upgrade these to "normal paid tier" users, don't mess with the limits at all, and if they owe money on an invoice, let auto freeze take it from there. If we take this approach, there is very little additional work necessary to complete the feature.

If we do not add any additional limit-adjustment steps, and just rely on account freeze/warn, I think the rest of the work could be 1-2 sprints of effort.

With more advanced limit behavior, e.g. what I brainstorm in this document, I would add a minimum of 2-3 sprints on top to account for PRD, design documents, and understanding the problem we are solving.

[ferristocrat]

@mobyvb - let's go with your vote - we'll go with a static amount (that is configurable on the satellite) and upgrade to normal pro account limits.

Right now, @boshevski's designs have $10, but currently thinking $20 is a better number to have as the initial config.

[ferristocrat]

Hey Moby, since your 1-2 Sprints didn't take into consideration project and account level geo fencing is it safe to say the 1-2 sprints becomes a 3-4?

[mobyvb]

@ferristocrat I think that project and account level geo fencing do not require much additional complexity - we are doing something similar with egress/storage limits. I guess depending on how the designs look, it could add extra effort, e.g. if there is a different flow for account vs project vs bucket geo restrictions. I would feel comfortable saying 3-4 sprints