Building Expense Rules: A journey to revolutionise expense management

Did you work on any problem for so long that you are relieved when the problem is solved and the customers are happy about it? Read this blog post to learn about one such story.

Hello, this is Pradyumna Dinni, a Product Manager at Fyle. It has been more than 18 months here.

In this blog, I'll talk about one problem we have been working on for many days and released this quarter, Merchant-based Expense Rules.

During my first quarter at Fyle (Q4 2021), in one of my early discussions with my manager about my roadmap items (we call them initiatives), there was an initiative called “Merchant Expense Rules.” I'll explain what's it and why it was added in a little bit.

Although this has been present in the roadmap, we postponed it because of other high-priority items and bandwidth constraints.

Cut to Q2 last year, when we finally prioritized it in the roadmap, and I started working on the initiative understanding the problem, and exploring the requirements.

I started working on the initiative towards the end of Q2 last year, but it was only about gathering requirements. Here's the timeline of events for this initiative.

Q2 2022 end (towards the end of July) - Gathering requirements

We got multiple requests from our customers by then. The administrators (Finance teams) mentioned that they have recurring expenses for specific vendors. For example, A Microsoft or Fyle subscription is accounted for in the same GL Account. The problems here are:

• Their employees are not filling in all details on the expenses.

• The details, at times, are incorrectly entered.

We also found that the merchant name sometimes, either from the receipts attached or from the corporate card transactions, is different from the correct name as present in Accounting Software.

For example: From card transactions, we used to get amaz1123 as the merchant name for Amazon. This is not the right name that goes into Accounting.

With these problems, the admins find it hard to edit the expenses or follow up with their employees to enter the correct details.

End result - The admins are working overtime and are getting delayed in closing the books in accounting.

At Fyle, our primary goal is “Not a second is spent on expenses.” The above problems must be solved to ensure the admins do their work on time, with minimal effort on Fyle.

Since we received multiple requests that spoke about either of the above problems, we were clear on the problem.

With the problem statement defined, we explored the solution approaches in detail in Q3 2022.

Q3 2022 - Solution approaches and extending the scope

Since the initial requests of the customer were related to only Merchant and Category (GL Account), I quickly ideated and came up with this solution:

An admin can create a merchant rule such that when the merchant name contains the characters entered by the admin, they can apply the rule, i.e.,

• Clean up the merchant name - enter the correct merchant on the expense

• Fill in the Category based on the merchant

Although we had clarity on the problem statement, we were getting requests around “conditioning one expense field on another” or “making two expense fields dependent” from customers in Construction Industry.

For example - One customer had Cost Codes, Cost Types dependent on the Projects. Depending on the Project selected on the expense form, only the allowed Cost Codes should be visible for the user to select.

Since I was exploring how to solve the problems, I thought to merge both.

I started exploring a solution that could solve both of these problems. Here's what I came up with:

I was obsessed with this solution and was like - “See, this is one-size-fits-all.” I used to open the repository of customer requests and run their problems through this solution. Incredible! All the requests, both around vendor rules and dependent fields, were working well with this.

Not only can this solution fill (or set) the fields on the expense form, but it also allows or restricts certain fields based on the conditions defined. Wow!

In my initial days as Product Manager, I stumbled upon this definition of Product Management. “Product Management lies in the intersection between Business, Technology, and User Experience.” In other terms, “Viability, Feasibility, and Desirability.”

Do you see what isn’t working here? What's the use if we build anything that no one will use or understand how to use?

While this approach solves all the problems, will the users understand its capability? Does everyone want this level of complexity for a simple problem?

Where's our KISS principle?

Q3 2022 - Focusing on what matters!

So, after a week or two of being obsessed with this solution, I came out of it and reflected upon why I am making things complex! The goal is not just solving the problem but solving it in such a way that it's obvious to the user. There should be no learning curve.

We limited the scope of this initiative by eliminating dependent fields and treating it as a separate roadmap item.

What's next?

Once the scope is re-defined, we are back to expense rules that can solve filling in the details on the expense form. Instead of just focusing on merchant-category, we thought to extend the solution to fill other fields, like Projects, etc.

Soon after this, our designers were onboarded. Shubhangi started working on it, and the whole design process was not only super efficient, but it was also swift.

She came up with different versions of designs. We discussed and finalized one version to get the design feedback from the customers.

Q3-Q4 2022 Customer Feedback

Soon after the designs and a prototype were ready, we started reaching out to customers with a requirement that could be solved via expense rules.

The feedback was unanimously positive. The customers were eager to test this out on the product. Here's what one user mentioned after testing the prototype.

“Fyle is getting easier to use every month, and I appreciate the time your team is putting in.”

Harsh was present towards the end of Q4, and we incorporated the feedback in the designs after the multiple feedback calls with the users. However, there were no major changes in the user experience.

Q4 2022 - Discussion with the Engineering

After we finalized the designs, we scheduled a design handoff call with the Engineering team, including Siva, Abhishek, and Vikas.

While the solution could solve multiple cases, the customer requests were only based on merchants. The proposed solution can accommodate creating the rules based on Project or other fields, but no one has asked for it. We discussed these points and went back to see if we could simplify it by limiting the scope to merchant-based expense rules.

All three customers we had feedback calls had requirements around merchant-based rules. The prospects who take demos also inquired about merchant-based rules. Hence, we reduced the scope and handed the designs to the Engineering team.

Now the solution is clear and straightforward. It's simple to understand and use. Swapna pitched in to help with the designs, and we had the final designs handed off to the Engineering team, led by Vaishnavi and Vikas, for development.

Q1 2023 - Development and Release

The solution is built to eliminate the manual work of adding expense details, so it impacted other modules on Fyle. It touches the policies, expense form, employee details, and Organization Settings like Projects, Cost Centers, Categories, etc.

Our Engineering team - Aniruddha, Ashutosh, Vaishnavi, and Vikas ensured that we didn't break any existing things on Fyle while developing this feature. We had to be double-sure here as it doesn't go well with the customers if we make them wait long and deliver something that screws up their workflow.

While the team was working on development, I focused on the release activities:

Release Plan

• We decided to go with two releases

  • Release-1 for Beta orgs

  • Release-2 for all orgs

Release Activities

• Identifying the beta orgs - preparing the list of orgs, i.e., customers with problems that could be solved using Merchant-rules.

• Email communication - once the feature is live, we have to announce the release to the admins (Finance Teams)

• Blog - collaborated with our Marketing team to mention this feature in our Quarterly Roundup blog here.

• Internal Demo - to all teams, including Sales, Marketing, and Customer Success.

• Creating the Analytics Report - With our Engineering team's help, we created events that can be tracked for analyzing the usage.

We followed iterative testing in this initiative. Instead of waiting for the whole feature to function properly, we tested each component at regular intervals before testing the full feature once it was ready. Aniruddha worked on Frontend, and Ashutosh worked on Backend for this initiative, and they'll share more details about the development process of this initiative soon.

Q1 2023 Beta Release

It was towards the end of March, precisely 30th March. We had one final round of testing and enabled the feature to the beta orgs. Soon after that, we informed the internal teams, announced to the customers of these beta orgs, and were biting our nails to see the customers respond and act on the expense rules.

After a couple of quarters on paper, this feature finally went live, although to a limited number of orgs.

We started seeing the usage on Mixpanel, which was encouraging. Aniruddha helped with Mixpanel events, and Ashutosh helped with daily updates on the merchants on which rules are created, expenses on which the rules are applied, etc.

Here's a sample data of the usage and metrics:

The trendline shows a steady increase in the creation of expense rules (percentage increase). But does the creation of expense rules solve the problem? How can we track whether it is helping the users?

Since we released the feature to beta orgs, our backend engineer Ashutosh has been sharing the following data daily. This table contains the data of orgs that have created expense rules and shows the number of expenses on which the rules are applied (Org names are hidden).

• ER Created = number of expense rules created

• % for ER applied = percentage of expenses on which the rules are applied.

For the top three orgs in this list, the percentage of expenses on which the rules are applied are 100%, 66.67%, and 66.67%, respectively. While this is not a significant number to celebrate yet, the admins are happy that the manual work and the errors are reduced.

The customers were elated to see this feature and responded with positive feedback.

Q2 2023 Final Release

While we released it to the beta orgs, we also enabled the feature to the newly onboarded customers so that they experience it from their Day-1 at Fyle.

In Q2, we planned to make this feature available to all orgs. Everything was smooth until we encountered scaling issues.

Wait… I'll let Ashutosh discuss it in detail as he promised to share his learnings :)

After load testing and feeling confident about the results, we released the feature to all orgs on 2nd May 2023.

We sent out the release announcement to the admins of impacted orgs and are currently tracking the usage.

So, is this it?

We are collecting feedback from the customers to solve their problems further. We won't stop until we are at a place where “Not a second is spent on expenses.”

Learnings

Reflecting, I evolved as a Product Manager while working on this initiative at Fyle. One of the unique initiatives that I worked on at Fyle is finally live to the customers, and we can't wait to improve it further!

While I mentioned the timelines and the details about our development process, here are the key learnings:

1. Solve the customers’ problems. Focus on the problem first, then think about how to solve it.

2. Be obsessed with the problem but not with the solution.

3. Build iteratively. Only aim to build everything after releasing the basic version.

4. Collect feedback at regular intervals. Don't wait until the product/feature is released. Invite your users to collaborate with you during the design phase too!

I'd like to sincerely thank my colleagues at Fyle, who helped at multiple stages of this initiative—starting with Yash, Siva, Gayathiri, Shubhangi, Harsh, Swapna, Abhishek, Vaishnavi, Vikas, Aniruddha, Ashutosh, Kirti Gautam, and the entire Sales and Customer Success Team.

Until next time with another story and learnings…