Background
Ontop is a an uprising startup helping businesses to go remote by automating international hiring and payments. They’ve products assisting their clients with contracts, paperwork, compliance or cross border payments
Following is an experiment to understand what kind of products that ontop can provide to its customers to give them additional benefits like flexibility, transparency and more control on their payments. Also give additional benefits and better FX rates that these customers already enjoy. Here I’m trying to devise a minimum viable product (mvp) for the
❓ Problem Space
There are many more sorts of regular & one time payments that the employees have to do on day-to-day basis. This is pretty hard to keep track of for the finance team and also harder for employees to recuperate the money that they might have paid vendors. Thus, there is for sure a need for a product that can better facilitate the easiness of making payments while also perfectly attribute each of the payment so that recuperation of money could be done properly. Let us deep down more into problem space to understand it better
👨👩👦 User Personas
Finance Team Member
Makes payment of employees but has real problem of attribution for personal payment done by employees
Vendor facing Teams
Interact with third parties and thus have to make lot of payments from their personal accounts
🚲 Current Solution
This is to focus whether our users already have a solution for the problems we’re stating. Well to consider our product ontop only provides services for payroll completions thus there is a big section of business still misses out which is the payments made to vendor as stated in our problem statement. Now this is an assumption made via the product info available on the main website. Currently when a team member makes a payment he relays the info to his fin team counterpart while sending the proof of payment. At the end of the month the fin team consolidates all the data and then make the requires payment. As you can see that there are lot of problems that can easily come up from both the personas. Let’s look into user stories from our personas to better understand the problem
🚗 Solution Space (Ontop cards)
So here is the solution to resolve the problem - Ontop corporate cards. Let’s look at different modules that I’m proposing and better understand the solution being produced
Setup 🏗️
To setup the architecture we can partner with one of the big card issuer like Mastercard, American Express & Visa and build our payment structure over it. Most of this architecture would be to add our existing service of getting the most from FX transactions
Goals 🥅
The features/module of solution space in the task focuses as functionalities that end up solving the problems that arose in the problem space for our user personas -
Payment Power Distribution
The obvious solution here arises from the ability to add cards and issue them to respective team members to be used. This would include single point of contact for mobile number that’ll control the card i.e. receive OTPs for transactions. So here are the features to solve the problem -
Payment Attribution
After every payment a notification is sent to payee to either mark the transaction as personal or for company. This option to tag can also be given in the passbook to have a better control over payments being made
Payment Limits
To set up limits for each of the task. Also have the option to showcase spending of the previous few months to better understand spending patterns of a team
Transaction View / API
This is a passbook type view for the finance team member to view all the transactions done how much of the limits have been completed and money saved overall in transactions
Product Design 📱
Following are a mockup of the product screens (designed on figma) that I’ve been thinking . With each of these I’m also explaining how I’m able to solve the problems that we’ve identified above
Wallets Screen
As you can see the following is a view for the admin (fin team member) to actually see all the cards given to a particular team
Screen can be broken down into following sections -
Teams - Distinction among teams to view the cards that’ve been assigned to them Card Type - We’ll have both virtual & physical card. Usage of each will depend on type of payment being done Cards - Each of the card has a unique card number & cvv with name of the issuer Add Button - To add new cards Transaction - At the end of the screen there will be transaction list . The list is not designed here but will be very similar to Add Card Screen
This screen acts more as a form then anything else and appears on pressing the “+” sign on previous screen. This screen is thus unique for each of the team. Following are the info that have to be put in -
Card holder name (One of the team member) Card balance (must be <= card limit) Card Type (Virtual Cards / Physical Cards) Remarks (for additional comments) After adding card a pop up comes up notifying that it will take a few days initiating the card from our side
Single Card Screen
This is a card view for a single card of a team. Let’s break down the screen now
Teams - Tapping on one of the tab will take you back to the of the respective team Card image - Both front & back of cards available. Imp numbers are blurred depending on who is viewing the screen Card Limits - These cards showcase balance, limit & amount on the card Control Modes - These are used by fin teams to have a control on the card & its limits Transaction history - These showcase payments done via the card with filters for sorting the list. Each transaction tile consists of following - Payment Tag (personal / company) - tagged while making the payment Three dots to change an attribute of payment Tagging Notification
This is a notification whenever a payment is made to notify our end users to tag the given payment as personal or for company based on other attributes
Dashboard Screen
This acts as a backscreen to our wallets screen. It includes-
some metrics like amount saved, in the currency chosen by our admin user, by using ontop products list of total transactions options to explore a detailed list of our product (one of them being our cards) This here is a screenshot of the dashboard screen present right now on your website. My aim is to pretty much be on the same track for all 4 layers of the design architecture
Feedback Loop 🔁
Now for every problem that we end up solving there is a need to define the metrics that can act as our feebdack to the release and these will end up measuring the release and give us areas to improve at
Final Notes 📄
All in all this was a fun exploration to do the reason especially being that we had 2 different personas to deal with one that was in need for service and the other that had the purchase power for that given service. I could we create an anology with a lot of Indian startups that are trying to solve the problem for teenagers who are really active on internet and are core buyers to a lot of stuff & the parents who end up paying for them. A big shoutout to volopay, I came across them and the problem they were solving during the research for this doc and it is wrong to say if they hadn’t given me some ideas. I know I could have been more in-depth with my approach but I pray that you guys would actually love this and I might end up getting a call 🙂