[TRACKING] Enable P2P distance requests

[JmillsExpensify]

DESIGN DOC ➡️

Proposal

Proposal: Add support for P2P distance requests

Problem: Expensify makes it easy to request money from a friend, split a dinner receipt with a group, or request reimbursement for a company expense. We are also building a seamless bottom up flow in wave 6 to upgrade P2P requests into a workspace requests. No matter the request type, everything is possible; except for distance requests, which can only be sent to workspaces. Not only does this create an inconsistent and confusing UX for requesting money, but the bottom up flow will also be limited to manual and scan requests. We will miss out on converting distance request users from free to paid plans, losing out on valuable revenue.

Solution: Add support for P2P distance requests whether you’re requesting from a friend, splitting expenses for a road trip, or introducing your boss to the power of Expensify for distance tracking.

Posted in #whatsnext here on 10/24/23

---

Long version

Hey everyone! I'm excited to move forward with this project after the #whatsnext post. Here is the expanded proposal.

Proposal: Enable P2P distance requests so that the bottom up flow works for all expense types.

Strategy:
If someone hears about Expensify (from chalk on a sidewalk or seeing the logo as a prestigious racing sponsor), our viral growth model can convert that curious onlooker into a paying customer. No matter the type of expense they want to create: a simple request, scanning a receipt, or tracking distance; the user can jump into the app and get started. Select the start and finish points, choose who you want to send it to, and be done. When the new user's boss gets the request they click the big green "Pay" button and can select "Business bank account". As described in the wave 6 basic bottom up flow, that kicks off an elegant process of creating a workspace, starting a free trial, setting up the bank account, and moving the request over to the workspace chat. Of course, the receiver may also be your carpool buddy that is a bit too comfortable with getting a ride to work everyday; or you might split the cost of your road trip with friends. The possibilities are endless with a super app, after all.

Problem:
Expensify makes it easy to request money from a friend, split a dinner receipt with a group, or request reimbursement for a company expense. We are also building a seamless bottom up flow in wave 6 to upgrade P2P requests into workspace requests. No matter the request type, everything is possible; except for distance requests, which can only be sent to workspaces. Not only does this create an inconsistent and confusing UX for requesting money, but the bottom up flow will also be limited to manual and scan requests. We will miss out on converting distance request users from free to paid plans, losing out on valuable revenue.

If a user hears about Expensify's distance tracking feature and wants to try it out they will jump into the app, click the green plus, request money, select distance, enter their waypoints and click next. So far they are dazzled by the ease of use and our fancy Mapbox animations. However, on the next page, they enter the email address of the person who owes reimbursement for their trip, and they see a little error message saying that distance requests can only be sent to a workspace. "Huh, that's weird. What am I supposed to do now?", they think. Confused, they close the app and never come back.

Solution:
Enable P2P distance requests whether you’re requesting from a friend, splitting expenses for a road trip, or introducing your boss to the power of Expensify for distance tracking.
First, allow individuals to be selected, as well as split with. The existing distance field can be separated into distance and rate fields on the confirmation screen; which is the last step before creating the request. The user can click “Rate” to input the rate amount and unit. It will be saved to the user's personal workspace, making it sticky for subsequent requests. An added benefit is that the user doesn't have to configure the rate separately in settings. For workspace requests the rate will also be displayed, but it will not be editable because it comes from the workspace settings and can only be changed by admins.

On the backend the basic operations and format stay the same. We will extend the existing P2P and split functionality to work with distance transactions. Distance requests already use the same underlying function as the rest of the expense types, so it's mostly a matter of setting up additional parameters. Along the way there will be close collaboration with the wave 6 bottom up flow team, to ensure that our designs mesh well out of the box. The test steps will focus on the upgrade flow for distance requests since that's the most important part of the solution.

Please keep an eye out in #wave5-free-submitters for a pre-design coming soon!

Best,
Neil

Emailed to strategy@expensify.com on 11/6/23 with the subject Proposal: Enable P2P distance requests so that the bottom up flow works for all expense types.

Tasks

• Post Proposal (full Problem/Solution statement) in #whatsnext
• Wait at least one full business day, and until the post has a majority (2/3) of positive reactions (👍)
  16 up / 22 total = 72% approval
• Paste Proposal in the space above with a link to the Slack thread
• Email strategy@expensify.com and paste in the Proposal
• Fill out the High-level overview of the problem, Timeline, and Terminology sections of the Design Doc
• Email strategy@expensify.com (continue the same email chain as before) with the link to your Design Doc
• Host a pre-design meeting (example) in an appropriate slack channel to discuss any necessary details in public before filling out the High-level of proposed solution section. Posted here on 11/8/23
• Fill out the High-level of proposed solution section
• Email stategy@expensify.com again with links to the doc and pre-design conversation in Slack
• Add the DesignDocReview label to get the High-level of proposed solution section reviewed
• Respond to any questions or concerns and bring up blockers in Slack to get a consensus if necessary
• Confirm that the doc has the minimum necessary number of reviews before proceeding
• Host another pre-design meeting in the appropriate slack channel to ask for engineering feedback on the technical solution. Posted in Slack here on 12/27/23.
• Additional high level re-design conversation
• Fill out the Detailed implementation of the solution and related sections.
• Re-add the DesignDocReview label to this issue
• Respond to any questions or concerns and bring up blockers in Slack to get consensus if necessary
• Confirm that the doc has the minimum necessary number of reviews before proceeding
• Email strategy@expensify.com one last time to let them know the Design Doc is moving into the implementation phase
• Implement the changes - Implementation started on 2/20/24
• Add regression tests so that QA can test your feature with every deploy (instructions)
• Send out a follow up email to strategy@expensify.com once everything has been implemented and do a Project Wrap-Up retrospective that provides:
  • Summary of what we accomplished with this project
  • What went well?
  • What could we have done better?
  • What did we learn?

Issue Owner

Current Issue Owner: @neil-marcellini

[melvin-bot]

Triggered auto assignment to @lschurr (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @shawnborton (NewFeature)

[JmillsExpensify]

Still not a priority.

[neil-marcellini]

I don't think this is critical, I would say it's more polish right? If it's critical for smallbizexpo, why?

[JmillsExpensify]

Definitely not critical.

[JmillsExpensify]

Still not a priority.

[JmillsExpensify]

I need to prioritize this one this week.

[tgolen]

Do we have an idea of what exactly needs to happen to the product to enable this? Is it:

• Allowing you to select an individual when requesting a distance expense? (I think you can already do this)
• Adding the option to the composers "+" menu (ie. NOT the global "+" menu) when in a DM?
• Do we need to do anything for the payment side of things?

[JmillsExpensify]

The main change required is adding a Rate row, such that the distance rate can be updated at any time during creation.

[tgolen]

OK, can you please update the title and the OP to reflect that?

[neil-marcellini]

The bottom up flow has been implemented and deployed on the backend. I created a separate issue to get it working on the frontend, which shouldn't be too much work. Today I will work on making any updates needed to get the frontend distance splits PR through review.

I also completed [P2P Distance] Create the UpdateMileageRates chore today.

Here is all that remains.

• [P2P Distance] Enable split distance requests
• [$500][P2P Distance] Create UpdateMoneyRequestDistanceRate in App - very close to being done, PR almost merged
• [$250] [P2P Distance] Add RBR logic for the bottom up flow will be handled externally, can get started now
• Run through all the tests from the doc and fix any bugs
• [$500] [HOLD][P2P Distance] Remove beta checks from App
• [HOLD Phase3][P2P Distance] Remove the beta
• [P2P Distance]External Resource Update: P2P Distance Requests
• [P2P Distance] Internal Resource Update: P2P Distance Requests

[neil-marcellini]

Things are moving along well. The distance splits went out on the frontend recently, as well as updating the rate. The frontend RBR logic is underway, but the contributor found an issue with the violations coming from the backend. I'm pretty sure that issues lies in Web-E and I hope to fix it later this week to unblock him.

I'm going to do a search now for all the P2P distance related bugs, since a few popped up recently, and I will add them to the out-dated project just for tracking purposes. After we get everything finished and the bugs cleared up I will start running through the manual tests from the doc and create any additional bugs as needed. After that we can remove the beta, someday.

[neil-marcellini]

I didn't add the issues to the project since some are related to other projects, but I found a ton of existing issues and put [P2P Distance] in the title. All P2P distance issues can be found here

[neil-marcellini]

Head's up, I'll be working 50% for the rest of this week and next 🌲

[neil-marcellini]

I fixed tracking an expense on a workspace with a custom rate this week. I also helped a few conversations progress. Currently working on E[$250] [P2P Distance] Add RBR logic for the bottom up flow.

[neil-marcellini]

I got a chance to chat about this project with Tom in a fist bump meeting last week, and we decided it would be a good idea to evaluate the remaining bugs, test the core flows, and as long as that's solid enough launch it (remove the beta) even though there are some edge case bugs. That will free up the ability to choose a non-default workspace rate.

I'm going to set a reminder to work on this tomorrow.

[carlosmiceli]

@neil-marcellini Hey man, wanna chat and see if I can give you a hand with some bugs in the next few days? I'm starting to wrap up the homepage, and may dedicate about 50% of my bandwidth to helping with bugs for our new features / 50% to leading the implementation of another feature (most likely Workspace Downgrades).

[neil-marcellini]

That would be great yeah! It would be wonderful if you could pick up this internal issue [$250] [P2P Distance] Split - Incorrect amount & distance behavior when changing distance on confirm page offline

[carlosmiceli]

Sounds great! I'll let you know if I have any questions 👍

[neil-marcellini]

I went through all app issues that mention "distance" and added [P2P Distance] to the title. There was only one I had missed. There a good number of distance issues that are unrelated to P2P distance specifically so we can ignore those problems.

Here are the currently existing issues. For each one I will evaluate whether it should block the launch with 🛑 for blocking or 🟢 . I've organized the blockers to the top of this list in rough order of priority

• [$250] [P2P Distance] Track -Rate is always 0.67/mi when a different rate is selected when tracking distance expense - 🛑 seems pretty common and very annoying
• [$250] Distance - Inconsistency in showing unit in preview and transaction thread after updating unit - 🛑 Pretty problematic result of altering the appearance of existing expense when the policy distance unit changes.
• [$250][P2P Distance] Rate currency doesn't match expense currency #46844 - 🛑 Very similar to the one above, and on HOLD for it, but focused more on the currency. Also it's an even broader case of distance expenses between people from different countries.
• [HOLD #46753 #43588][$250][P2P Distance] Expense shared with accountant shows incorrect rate - 🛑 I would like to get this fixed before it goes live. It makes sense to hold this on some of the bottom up flow logic.
• [$250] [P2P Distance] Add RBR logic for the bottom up flow - 🟢 not a problem by itself because it's a super rare edge case, but it may be related to other issues, like the one above, which makes it more important
• [HOLD for payment 2024-10-10] [$250] [P2P Distance] - Split amount is not recalculated when entering 0 as input & editing distance #48302 - 🟢 It's an edge case
• [$250] [P2P Distance] Split - Incorrect amount & distance behavior when changing distance on confirm page offline - 🟢 ultimately it's an offline edge case, though it feels a little bad 🟡 because it's ugly
• [$250] [P2P Distance] Distance rate - Error when selecting distance rate that no longer has tax rate - 🟢 edge case related to tax rates

Issues under review

• [Hold for payment 2024-09-16] [$125] [P2P Distance] Split - Error shows up when splitting distance to workspace chat via QAB #47021 - 🔴 common flow with error and crash
• [$250][P2P Distance] - Disabled rate is not listed in the Rate list when it is still selected #46884 - 🔴 common enough that it should be fixed
• [$250][P2P Distance] - Amount field is not grayed out when changing distance rate offline #46880 - 🟢 offline, pretty minor
• [$250][P2P Distance] - Distance unit in the system message changes from "miles" to "mi" after changing rate #46873 - 🟢 not super important
• [$250] [P2P Distance] Split - Participants amount displayed 0.00 briefly on confirmation screen #47100 - 🟢 very minor and under review

Yeesh ok that took a while. Let's focus on getting all that fixed first, then I can do a run through of all the manual testing steps.

[neil-marcellini]

#47153

I merged the App PR for this so it should be fixed when that hits prod on Monday. The issue that was blocking it also happens on main, and I asked the contributor to report it, so there will probably be another issue to solve but I don't think it will need to be a blocker for this project.

[neil-marcellini]

Backend and frontend PRs are under review for #46753. Next up I will work on the inconsistency issues.

[neil-marcellini]

I'll work on this issue today. E[$250] Distance - Inconsistency in showing unit in preview and transaction thread after updating unit.

On Tuesday I chatted with Vit about it and he reminded be about the originalMerchant, which should have the right format to extract and store the unit on the transaction.

[neil-marcellini]

I haven't gotten any feedback on the plan for that issue yet, so I just tagged some folks in Slack. I'll check back in next week. I've been focused on some other weekly issues instead, but luckily the external stuff is still moving along. I'll try to squeeze in an update on this issue soon, since I don't think it needs to be blocked anymore #46844

[neil-marcellini]

I'm still working to finish off [$250] Distance - Inconsistency in showing unit in preview and transaction thread after updating unit. It's going to take a few more PRs.

The contributor is still fixing various bugs in the PR for this issue [$250][P2P Distance] Rate currency doesn't match expense currency

It's moving along very slowly and surely.