Procurify - Auto PO
Company Overview
Procurify is a spend management company that helps organizations maximize cash flow and accurately track their spending.
Using Procurify, our customers can:
-
Request an order, get it approved, and received
-
Ensure the right orders are approved and under budget
-
Ensure orders are purchased and received in a timely manner
-
Create bills for purchased items and pay vendors
Procurify discovered an opportunity for its product-market fit with a specific user segment in North American small-medium business (SMB) with 50 - 250 employees and revenues under $50M.
While looking to expand this segment, we discovered that how the procurement process is set up made it difficult for customers to fully adopt Procurify. Customers this size typically do not have a dedicated procurement team. However, reporting spend from requesting an order to making a payment in Procurify requires a purchase order to be created. This can be an unfamiliar and unnecessary process that takes a lot of extra time and effort.
Project Overview
When I joined Procurify, there was already a designer, a product manager, and 10 engineers working on this project. The team had been working on the project for about 4 months and they were struggling to streamline and align on the solution. I was brought in to provide a fresh perspective and I saw an opportunity to learn more about the product and expedite the project.
I overtook the entire project as a designer and I led discussions to dive deeper into understanding the problem and to ensure we were building the right solution.
At the time, Procurify was operating with a 6-week cycle and we spent 2 weeks ideating and iterating and 6 weeks delivering the first slice of value for this project. The biggest constraint for this project was the 6-week timeline.
Understanding the Problem
Understanding the Industry Standard
What is a Purchase Order (PO)?
Purchase orders are documents that are sent from a purchaser to a vendor to confirm the purchase of goods and services. They include information like price, quantity, and expected arrival date of the item. Vendors will often include the PO number when creating an invoice so that the purchaser’s finance team can ensure information on both the PO and invoice is the same, through a process called 2-way matching before creating a bill for the order.
Traditional spend management workflow
Traditionally, the user that requests an order is not the same person making the purchase.
For example, if I am a new employee that needs a new keyboard, I will send a request for the keyboard by creating a request for order (RFO). This will be approved by my manager. Then another person like an office manager or IT will make the actual purchase when my request is approved. Then the accountant or someone in the finance team will use the documented approval to create a PO, validate invoices and create bills.
This is how Procurify is set up. There are different permissions like Request, Approve and Procure that can be assigned to users. And since the organization’s budget isn’t affected until the item is actually purchased, budgets are only updated when a PO is created.
Why this a problem?
It’s becoming more common for businesses to purchase from e-commerce platforms like Amazon. The start of this workflow is similar in that as a new employee, I will still send a request for a new keyboard to my manager. However, I may use Amazon to directly make the purchase and receive the keyboard myself. In this scenario, it’s very unlikely that I will know how to create a PO. Also, POs are unnecessary since vendors like Amazon do not require one.
This creates 2 issues:
-
These businesses still need to create POs in Procurify to make sure their spending is reported in budgets. Otherwise, approvals will be made over budget
-
Creating a PO allows an item to be marked as ‘Purchased’, which most customers use as the source of truth for department spend tracking
What are customers doing now?
Our customer-facing teams already gathered some good insight into what the customers are doing now and the pain points they were experiencing.The product manager and the previous designer had talked to 10 customers to validate these and to hear them first hand before I joined the project.
A big takeaway here was that both smaller and bigger businesses are impacted by this problem. Customers that did not have a purchasing team made it mandatory for Requesters to create a PO. For customers with finance or purchasing teams, they often had a dedicated person whose bulk of the workday would be spent creating POs or chasing down Requesters to create POs.
Some direct feedback we heard from customers were:
-
“The buyers and the purchasing team are the same people, so RFO is a redundant step for us.”
-
“The PO generation process just feels like another step.”
-
“...you have entered in as an already purchased service, it gets approved in the normal process and then just goes straight through to accounts payable. It would be good to bypass the purchase order.”
-
“And then all of a sudden I get this email that's like you don't need to do POs for legal. They don't need to do the extra work… There's things that a PO doesn't make any sense to have, but we have to have it in Procurify or there's no connection.”
-
“I put through about 500 RFOs and POs in the past 3 months.”
-
“Currently we have one person who produces the PO who’s in finance.”
Summary of the problem
Procurify does not have a way to skip the purchase order creation process without ensuring that spend is captured accurately and confidently.
This has become a blocker for product adoption which has led to issues in growing and retaining customers in the target segment.
With this in mind, we identified user goals and opportunities as:
-
Reduce or eliminate manual work of creating POs while maintaining accurate spend tracking
Solutions & Iterations
Idea 1: Kill the PO
Since we were hearing so much about how unnecessary POs were, my first thought was to get rid of purchase orders altogether.
However, this turned out to be a naive idea since:
-
POs are still recognized by the procurement and accounting industries as an essential ‘source of truth’ for spend approval and spend tracking.
-
It’s common for wholesale and construction vendors to require a PO or a PO number at the time of order
-
The only way for customers with Netsuite integration to sync tracked spend is from purchase order amounts. The only way that Procurify can be used with Netsuite is by creating a PO for every purchase.
Customers were looking to remove the manual process of creating a PO, not necessarily the PO itself.
Idea 2: Automate PO Creation
The next idea was to Automate the PO creation process. By doing this, Requesters or Finance Teams do not have to spend time creating POs but they can still be confident that the spend approval is documented, ready for invoice processing.
This created an interesting challenge. Procurify’s spend capture process can be summarized in 5 high-level steps:
-
Request: A request for order is created
-
Approve: It’s approved
-
Procure: A purchase order is created and items are purchased
-
Accounts Payable: A bill is created for the item
-
Receive: Items are marked as received
To automatically create a PO and ensure accurate spend tracking, all the information needs to be captured by the Approve step.
This information includes:
-
Detailed item information like quantity and price from Request
-
Vendor information from Request if the vendor already exists in Procurify or from Procure if a new vendor has to be created
The challenge here is that the vendor has to exist in Procurify for a PO to be created before the Procure. But the only place where it can be added is through the process of manually creating a PO. The goal of Auto PO is to reduce manual work as much as possible. This creates a serious limitation and a direct conflict.
I worked closely with the product manager and the lead engineer to brainstorm and ideate on how we can capture all necessary information before the Procure step.
Idea 2: Iteration 1
The first iteration of Auto PO was to allow Approvers to create vendors. This decision was made with the assumption that more responsibility should be given to Approvers. The role of the Requester should not go past submitting a request for the order. There would be a setting exposed to the customer where they can turn Auto PO on/off and allow Approvers to create new vendors.
I created multiple user flows to effectively communicate different scenarios and what the user action would be for each scenario.
I also created low-fi wireframes to go over this solution in detail. I led multiple brainstorming sessions and design reviews with the product manager, engineering team and the design team. Using inputs like technical feasibility and product usage data, I was able to eliminate multiple ideas to one clear vision for this project.
We ran this by internal stakeholders like the customer-facing team, VP of Product, and the product team as well as our customers and there were 2 main questions raised:
-
Should Auto PO Creation settings be exposed to customers at all? Especially for the first release?
-
If allowing vendor creation is highly recommended for Auto PO to work for all requests, the MVP should launch with this and see if there’s feedback regarding more control. Controlling this feature through a feature flag and not exposing the settings to customers would mean this can be launched faster
-
-
Will Approvers have the necessary information to create a new vendor?
-
There can be multiple levels of vendors in the approval chain and each level will have less and less information on the details of the order itself.
-
This was a big problem for most customers we talked to. They were confident that the users at the Approver level will not have the necessary vendor information.
-
Another interesting learning here was that the level of vendor information needed to create a new vendor varied greatly from customer to customer. Some just wanted the vendor name and some required very detailed and specific information like a tax form.
-
Idea 2: Iteration 2
With this in mind, I went back to brainstorming and ideating. At this point, we only had about a week left before we were supposed to start delivering on this project.
I was going over all the data we had so far and revisiting the problem when it occurred to me that Requesters are usually the purchasers when customers want to automate the PO creation process. So Requesters will have the most information about vendors.
The previous solution made the assumption that Approvers should create new vendors for auto PO. The question was not how much vendor information approvers have but whether or not they are the right group that has this information at all.
I moved forward with 3 updates to the solution:
-
Expose more vendor information that can be filled by the Requester
-
Usually, Requesters can only fill out the vendor name when creating a request with a new vendor.
-
For Auto PO, Requesters will be able to fill in more information, some optionally.
-
The input fields are the same as the vendor creation form in ‘Procure’.
-
This allows us to capture more information about the vendor and fill out more fields in an auto-created PO whenever possible (If the vendor is approved and created).
-
-
New vendors are automatically created in Procurify after final approval
-
If a vendor is created at the request stage and the request is later rejected, there is now a vendor that will show up in the vendor list that should not be used. This should be avoided, meaning creating the vendor at the request stage will not work.
-
If the vendor information is wrong, Approvers can reject the request or edit the vendor info before approving
-
-
For MVP, hide Auto PO settings from customers
-
This decision was made to reduce scope. The tradeoff was that customer-facing teams would need to request the feature flag to be turned on for certain customers through engineering.
-
Customers were happy with this iteration since there are minimal interruptions to the Requesters’ and Approvers’ current process. The only thing that the Requesters need to do is to create a request and add additional vendor information as needed. The only thing that the Approvers need to do is to approve the request. This ensures that there is no manual work needed to accurately capture spending.
Usability Improvements
While creating hi-fi wireframes, I identified an opportunity to make a usability improvement. We wanted to use the same vendor creation form in Procure when a Requester is adding a vendor in Request.
This form has 10 input fields in multiple columns, which has readability and accessibility issues:
-
The order of the input fields is up to the interpretation of the reader. If not read in the intended order, it will require the user to context switch
-
When the browser is at minimum width, some input fields collapsed into each other
-
All 10 input fields are presented at once and without any grouping. This can be overwhelming and is unnecessary since only 1 field is required
-
Older screen readers may not recognize columns and read the text on the form from left to right
I came up with a quick hi-fi prototype and proposed a redesign with the following changes:
-
Show the input fields in a single column
-
Hide the optional 8 input fields in a collapsed area
There was a consensus across product, engineering and design that this would improve the usability of the form. However, as a team we decided to make a tradeoff and deprioritize adding optional input fields for vendor creation altogether. Several factors that influenced this decision were:
-
The engineering team scoped the work for the first release of Auto PO and they estimated that they would barely make the delivery deadline of 4 weeks. So the team decided to prioritize work that will directly impact Auto PO creation
-
72% of all vendors created by customers only have the required field of vendor name filled in
-
This proposal made more sense as a product-wide update. This coincided well with an ongoing design initiative of an accessibility audit and an engineering initiative of updating our front end to React.
I created a document for this proposal; detailing the problem, the proposed solution and how it fit into other design and engineering initiatives.
Impact & Next Steps
Auto PO was released in June of 2021. Since then, we’ve seen:
-
Retention of a number of customers at high risk of churn due to manual PO creation
-
On average, about 50% of POs created are via Auto PO (~38,000/76,000)
-
On average, the time it takes to create a PO went from 156.8 seconds to 0 seconds
We forecasted that within the first 12 months, 40-50% of our customers (~200-250 customers) would have adopted this feature. As of writing this case study, we are 9 months in and we have about 80 customers, which is 32-40% of the target. We’re talking to our customers and working with the customer success team to identify top requests for the next version of the Auto PO to increase adoption.
Learnings & Takeaways
Auto PO was a high-stress but fun and rewarding project. I was happy to be able to provide value right away and I’m very proud of the team for delivering this project in such a short timeline.
However, because I felt so rushed, I didn’t take enough time to see what additional value could be added with the MVP release.
Looking back, I see an opportunity where I should have advocated for customers to enable Auto PO without Procurify team support. Auto PO is a highly requested feature for new customers and it creates unnecessary overhead for Procurify team members since they need to request and wait for the feature to be turned on/off.