Produce research - Subscriptions

A small research created on how Invoice Manager is usable for reoccurring billing situations aka subscriptions. Here I explain how it currently is done, what an optimal solution would be and a proposed solution sketch.

With subscriptions, I am referring to the reoccurring invoices for our contacts. E.g: hosting, domains or IT solutions. This process is done via a manual process which includes re-creating invoices by hand. It is time-consuming and prone to errors.

Current Procedure

As of now, we are generating and sending invoices by hand with a minimum of automatization. Within the diagram, you'll see that this method has possibilities for errors. It requires the user to constantly pay attention to their actions.

Diagram 1 - Current BPMN

This method requires the administrator to know what invoices have an ongoing agreement. Because of this, knowing what contacts have which product agreements is a required feature to generate new invoices for that month.

Optimal criteria

An optimal solution would be to have a new screen that displays exactly what users have which agreements with the company. Criteria for the new system would look like the following:

  • It must show what product agreements there are;
  • It must show which contact has what agreement;
  • It must be able to generate invoices from these agreements;
  • It should show which invoices where created previously from these agreements;
  • It could have a dashboard with an overview of costs and analytics.
  • It mustn't be limited to one agreement per contact;
  • It mustn't require multiple agreements for every contact that has an agreement multiple times.

With these criteria in mind, the following solution should be created.

Procedure

From now on, we will call product agreements: subscriptions.

The following scenes and solutions are presented:

Every time you create a new product that has reoccurring invoices, you'll generate their respective subscription. E.g: You have a new hosting type

Every time you have a new user that wants to have an existing product that requires reoccurring invoices, you'll have to subscribe that contact to their respective (previously generated) subscription. E.g: A contact wants a new website hosted.

Every first day of the month that you want to send out new invoices, you'll have to generate them for every contact simultaneously. This should generate an invoice for every contact with every subscription their items that they have subscribed to. To see this manual process, see diagram 2.

Diagram 2 - Manual subscription generator flowchart

Data connection

With the optimal criteria in mind, you will need to connect different data with each other to get an optimal solution. Diagram 3 displays how data should be connected to each other.

Diagram 3 - Data connection ERD

Within here you'll see that every connection has almost every other data type as their connection. The connected type means a connection only within a graph database.

The connection between contact and subscription also has some meta information. It counts if a contact has subscribed multiple times a single subscription. Which in turns means that a subscription will append its items multiple times within generated invoice (see diagram 2).

Pages

For showing every data type correctly, there should be multiple pages showing from minimal to maximum times of information.

First, there should be an overview page with global information about the current month and its created invoices from subscriptions.

Second, there should be a page where every subscription (type) is displayed. Here you are able to see the different types of subscriptions that a contact can be subscribed to.

Third, there should be a page where you can see all the different contacts and what subscriptions, and how many times, they have subscribed to.

Lastly, there should be a page where you can generate the invoice for a specific month; 1st of the month.

All these pages should be in style and with as minimal components possible, except for the first dashboard page. I.e only a single list or not too many buttons / only a process