Vendor Management Portal
B2B Supply-Chain SaaS · APM Take-Home · 2023
Context
The company is a B2B supply-chain SaaS building AR/AP and procure-to-pay automation for mid-to-large enterprises. As part of their APM hiring process, I was given a take-home assignment to scope a vendor management portal that would extend their existing platform — giving vendors a self-service interface to manage invoices, track payments, and communicate with clients.
I spent a day and a half on this. The assignment led to an interview with the CTO and a job offer, which I ultimately declined to pursue a family business opportunity.
My Approach
I started by researching the company's existing product before writing a single word. A few things became clear quickly. First, vendors are typically the underserved party in AR/AP platforms. Most tools are built for the buyer's finance team, not the supplier. Second, the most common pain points for vendors are invoice visibility, payment status, and communication with the client's AP team. Third, a vendor portal is a natural retention and upsell tool. If vendors actively use the portal, clients are less likely to churn.
The Prioritization Problem
The hardest part wasn't identifying features. It was deciding what not to build first. I structured the feature set into three phases.
Phase 1 (MVP): Invoice management, PO-to-invoice conversion, vendor onboarding, secure communication, document management. These address the core daily workflow.
Phase 2 (Monetization-ready): Reporting and analytics, accounting software integrations, mobile access, customizable alerts.
Phase 3 (Differentiation): Predictive analytics, vendor grading, supply chain finance, inventory management.
One decision worth flagging: I put PO-to-invoice conversion in Phase 1 despite it being more complex than some Phase 2 features. Reducing manual data entry is one of the highest-impact things you can do for adoption. If a vendor can click to turn a PO into a correctly formatted invoice, that alone is a reason to log in every day.
The Business Model Question
I noticed a problem the brief didn't explicitly ask me to address: if the vendor portal is provided free to the client's vendors, the company bears development and maintenance costs with no direct revenue from that user base. I flagged this and suggested paths forward: cost-sharing with clients, premium Phase 2 features, and longer-term cross-sell opportunities through the vendor ecosystem. A product that creates costs without a clear path to revenue is a business problem, not just a product problem.
The Wireframe
The homepage was designed around one question: what does a vendor need to see the moment they log in? The answer: pending POs, outstanding invoices, recent payments, and average DSO, all visible above the fold. I added configurable quick-action buttons, an invoice aging bar chart, and payment status breakdowns. The navigation panel is collapsible to give more screen real estate to data.
Outcome
The assignment resulted in an interview with the company's CTO and a job offer.
What I Would Do Differently
The research section reads as market context rather than user insight. It describes why AR/AP automation matters broadly, but not the specific frustrations of a vendor using a manual process today. I'd ground the feature decisions in user interviews or at minimum support ticket data from the company's existing clients.
The project timeline I included is too waterfall. I laid it out as sequential phases, which is not how a modern product team would build this. Agile sprints with parallel workstreams would have been more credible.