TL;DR

Plaid-like UX for Invoice Downloads and Payments

Table of Contents:

Overview

Plate IQ helps process and pay invoices for accounting teams in the hospitality industry. Invoices are delivered with ingredients that are purchased, and represent money owed to vendors at some point in the future — in short, these are very important pieces of paper.

Invoices are often lost, damaged, or difficult to read. Accounting teams spend days processing invoices each week, as some invoices can have 100s of line items. Plate IQ's core product makes this easy by processing invoices on their behalf so that accounting teams can categorize and pay their bills with an easy-to-use UI.

The first step is for accountants to upload their invoices. We've made this process as easy and accessible as possible (supporting 5 different methods to upload!). But what if there was a better way?

<aside> 💡 What if users didn't have to upload invoices at all? What if their bills magically appeared in the dashboard each day?

</aside>

Introducing: Vendor Connections.

Using a Plaid-like experience, users can enter their login credentials for their vendors, and Plate IQ fetches their invoices each night automatically. This saves users a lot of time. More importantly, these invoices are processed instantly with perfect data accuracy, which improves the entire Plate IQ experience altogether.

Results

Withholding results since this project is still fairly new and is a competitive advantage for Plate IQ.

The End

Or the beginning 🤔

What went well

• Cool product with company-defining potential
• Novel application of technology unseen in the accounting industry
• We made a correct, quick bet on Vendor Connections early on when deciding to build the MVP.

Key lessons

• I did not communicate project plans as effectively as I could have with executive stakeholders.
• I under-estimated demand for a key component, which over burdened our dev team's resources within 2 weeks of the Beta launch. This led to bad customer expectations that had to be reset.
• Reliability is a very hard problem for this type of product — we don't know what we don't know. I should have ensured a manual QA process was in place before, and fully resourced well after, the Beta launch.
• We made a slow, over-analyzed, and over-managed decision to pause development until stricter success criteria are met. The decision to momentarily shift resources was correct given high-impact alternatives, but reaching the decision became unnecessarily bureaucratic. I should have "managed up" better.