PROJECT:
Company Requests
B2B SaaS · Supply Chain Intelligence · End-to-end Design & Delivery
Context
The company is a scale-up startup providing a mission-critical supply chain intelligence platform for high-profile clients. A major enterprise client, one the business couldn't afford to lose, was managing thousands of company profile requests by email and spreadsheets with the startup’s internal data team, whilst there was an existing company requests feature in the product. The process had become slow and confusing enough that the client was actively evaluating alternatives. The complaint landed with the data team I worked with closely as part of my squad's remit, which is how it reached me.
My role
Product Designer and Product Manager. Reframed the problem from a data team operational issue to a product capability gap and secured engineering commitment to build the solution. Planned and led discovery across six stakeholder groups (user interviews, workshops, technical discussions). Synthesised findings, defined feature requirements end-to-end. Designed and validated with users the UX/UI for both the customer-facing request tracking feature and the internal administration tool. Coordinated implementation across squad ownership boundaries through to release.
Impact
Delivered a native company requests feature with a supporting internal admin tool, fully eliminating manual request workflow.
Reduced request processing time by 2 weeks (per request cycle), improving visibility and control across all active requests.
Contributed to retaining a major client, receiving positive feedback following the release.
Discovery and findings
The reframe
This was raised as the data team's problem. I pushed back: the client was at risk of churning, and the real issue was a missing product capability, not a data-processing bottleneck. I brought it into product's scope and offered to run discovery and design end-to-end, on the condition that engineering resources were committed to building it.
What I needed to find out
Discovery
Through user interviews with 3 members of the customer's team, a workshop with the data team, and conversations with Customer Success, Sales, the Feature Owner PM and the Engineering Manager, I mapped the full process from both sides and uncovered constraints that ruled out the obvious solutions early, before any design work began.
Img. 1. Discovery scope
Findings
Discovery revealed that it was a multy-layer problem, tangled together inside the same spreadsheet-and-email loop. Breaking it down helped shape the solution.
Layer 1
Missing functionality of an existing feature created a manual workaround
Img. 2. Manual workaround for requesting company profiles
What I found
1. The feature was missing in the places where it was needed. 2. The request form didn't provide explicit submission guidance, which was causing errors and blocking profile creation. 3. Submitted requests only had two statuses (requested, completed) with no visiblity of ETA, impacting users' workload planning. 4. No way to communicate request issues, neither for the data team ("not enough input data"), nor for the client ("this is not the company I wanted"). 5. The legacy requests admin tool worked but didn't address the data team's needs.
Constraints
1. The feature owner had no discovery or design capacity, and they could only provide limited engineering resources, so the updates had to be as simple as possible. 2. The legacy requests internal admin couldn't be updated due to the tech stack used to build it, which was not supported by the engineering team.
Design direction
1. Place the feature where it's needed (company requests page, global search, company profiles, portfolios). 2. Set requirements and guide users on how to submit requests (file format, required input data). 3. Add missing functionality (relevant statuses, filters, feedback loops, notification system). 4. Build a new simple admin tool using a low-code solution to receive and manage requests.
Layer 2
Request complexity
Img. 3. Conditions for company requests
Img. 4. Customers/Prospects A, B, C request company profiles 1, 2, 3 with different data sets → Company profiles 2 and 3 should have all data sets added.
What I found
A company request can be submitted based on various conditions, whether a profile exists or not, whether data sets a customer subscribed to have been added to a profile or not, and whether the data is recent. Additionally, multiple clients/prospects could request the same company profiles but have different data set requirements. All of which required the data team deal not only with the volume of requests but also cross-referencing various requests options to clarify what work needed to be done.
Constraints
1. We cannot add all possible company profiles and all data sets upfront and keep them up to date) due to data partnership agreements and a time-consuming manual process, so it has to be based on actual customer needs at a given moment. 2. There is no way to standardise data sets, as different clients/prospects have different data needs for their use cases. 3. Automatic deduplication and resolution process is not feasible at the moment.
Design direction
1. Each request should provide a client with an option to specify data sets. 2. Each request should have: request ID (batch - if applicable, individual), client ID, data sets IDs, profile identifiers. 3. There should be options to create profile, add data sets and update data sets 4. The data team should easily understand what work needs to be done without unnecessary requests cross-referencing.
Layer 3
The company request resolution loop
Img. 5. Company request resolution loop
What I found
1. The resolution loop was the source of "all the comments" the customer was drowning in. Each unresolved request generated its own email thread and spreadsheet exchange. Both sides described this as the most painful part of the process. 2. Unresolved requests were mainly caused by company reorganisation or missing company identifiers. 3. Company reorganisation can mainly be standardised but will require a custom comment for clarification.
Constraints
1. Company reorganisation can have special cases that cannot be standardised. 2. In some cases, client should have an option to make a decision what to do if requested company profile cannot be delivered as expected. 3. Specifying request priority cannot guarantee creating a profile by expected date.
Design direction
1. Extended company request statuses (batch and individual) to inform the client about request progress. 2. Standardised status conditions (for company reorganisation cases) with a clarifying note. 3. Dedicated individual request status "Needs Review" allowing users from both ends to communicate special cases.
Solution
Placing the feature where it's expected
Providing the guidance on submitting company requests
Requests monitoring
Batch request monitoring
Individual request monitoring
Request review
Internal administration
Reflection
This project worked because every stakeholder had a reason to want it solved and I used that as leverage to drive the solution rather than trying to lift it alone. CS organised customer calls for discovery and usability testing, the data team processed all past requests to standardise the conditions behind each status, and developers actively shaped feasibility and suggested faster implementation paths. My job was to frame the problem clearly enough that the whole team could see themselves in it, and then translate everything we learned into a coherent design, mapping the workflows, structuring the statuses, and shaping the UI for both the customer-facing feature and the internal tool so the solution actually held together end-to-end.
