[Procurify] Automating Purchase Orders

Company overview

Procurify is a spend management platform that helps organizations maximize cash flow and track spending accurately. Targeting North American SMBs with 50-250 employees and revenues under $50M, Procurify offers a streamlined procurement workflow, ensuring budgets are managed efficiently while simplifying complex purchasing processes.

Project Overview

Procurify identified a challenge with adoption among SMBs that lacked dedicated procurement teams. Many of these customers found the requirement to create purchase orders (POs) cumbersome and redundant, particularly for purchases made directly on platforms like Amazon. This was inhibiting product adoption and retention within the target market.

I was brought onto the project team, which had been struggling to align on a solution after four months of work. I assumed full ownership of the design process, leading problem exploration and solution discussions. Working within a strict 6-week delivery cycle, I focused on ideation and iteration to deliver an effective MVP that addressed the adoption barriers.

Understanding the Problem

What is a purchase order (PO)?

A purchase order is a document sent from a purchaser to a vendor to confirm the purchase of goods or services. It typically includes information like item price, quantity, and delivery dates. POs also serve as a key reference point for finance teams, enabling them to match invoices with approved orders (a process called 2-way matching).

Traditional spend management workflow

In traditional workflows, the person requesting an item is often not the one making the purchase. For example:

• A new employee requests a keyboard through a Request for Order (RFO), which is approved by their manager.

• An office manager or IT team member then makes the purchase.

• The finance team creates a PO, validates invoices, and updates the organization’s budget.

In Procurify, permissions like Request, Approve, and Procure are assigned to different users, and budgets are updated only when a PO is created. This ensures accurate spend tracking but adds complexity for teams without dedicated procurement staff.

Why is this a problem?

SMBs are increasingly making direct purchases from e-commerce platforms like Amazon, where POs are unnecessary. In these cases:

1. Requesters often bypass POs entirely, which risks overspending and disrupts budget tracking.

2. Manual PO creation becomes a bottleneck, especially for teams without procurement specialists.

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 lacked a way to bypass manual PO creation while ensuring accurate spend tracking, a key blocker for adoption among SMBs.

Solutions & Iterations

Idea 1: Eliminate 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 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:

1. Request: A request for order is created

2. Approve: It’s approved

3. Procure: A purchase order is created and items are purchased

4. Accounts Payable: A bill is created for the item

5. 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.

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 and lowfi wireframes to effectively communicate different scenarios and what the user action would be for each scenario. 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.

Iteration 2

This feedback prompted us to refine our approach further and ask the question of who would have the info needed to automatically create a PO. 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. Since Requesters are usually the purchasers when customers want to automate the PO creation process, so naturally Requesters will have the most information about vendors.

I moved forward with 3 updates to the solution:

• Enable Requesters (who typically have vendor details) to add detailed vendor information when submitting requests.

• Automatically create vendors after final approval to avoid unused or erroneous entries.

  • 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

During the design phase, I identified an opportunity to improve the vendor creation form’s usability:

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

• 50% of all POs (~38,000/76,000) are now created automatically, reducing average PO creation time from 156.8 seconds to 0.

• Nine months post-launch, adoption reached ~40% of the target, with ~80 customers actively using the feature.

Next steps:

• Gather additional customer feedback to enhance the feature and increase adoption.

• Enable customers to activate Auto PO independently, eliminating reliance on internal teams.

Learnings & Takeaways

This project reinforced my ability to lead under tight deadlines and deliver impactful solutions. By quickly identifying customer pain points and iterating efficiently, I helped improve adoption and retention. Reflecting on the MVP, I see opportunities to have advocated for greater customer autonomy in enabling Auto PO, which would have further streamlined the process and reduced operational overhead for Procurify’s internal teams.