As Spendflo pivoted to an AI-native procurement platform, every module was being rethought. PR and approvals were already on the list: customers flagged the re-routing friction, CS flagged the config dependency, and our own UX audit confirmed both. The pivot gave us the moment. The feedback gave us the brief.
Timeline
3 months
Role
Lead Product Designer
Workflow self-serve
↑ 22%
Approval turnaround
↓ Faster
01 · What broke
A platform pivot. And two problems we already knew about.
When Spendflo committed to rebuilding as an AI-native procurement platform, every module was on the table. PR and approval workflows were already flagged, from customer feedback, CS escalations, and a UX audit using MS Clarity and PostHog. The platform shift gave us the mandate to fix what we'd been tracking for months.
Why this, why now
"We were already touching every module as part of the AI-native pivot. PR and workflow had known issues sitting in our backlog from customer feedback and CS. It was the right time to fix them properly instead of shipping around them again."
Three inputs shaped the brief: customer-reported friction around approval re-routing, CS team escalations about workflow configuration dependency, and behavioural gaps surfaced through MS Clarity session recordings and PostHog funnel analysis.
🔁
Re-routing approvers back into the product
When a purchase request needed approval, the notification landed in the approver's email or Slack. Clicking it re-routed them to the platform to take action. On mobile, the experience was unusable. On desktop, it broke the flow they were already in. Approvals stalled, moved to Slack, or got delayed until someone chased.
⚙️
Configuring workflows meant calling CS
The workflow builder required CS involvement for any meaningful change to approval rules. Customers couldn't update thresholds, add approvers, or change routing logic themselves. Most accounts were running the default setup from onboarding, regardless of how their actual approval process worked.
What the existing system actually delivered
Area
What we found
Approval re-routing
Approvers had to leave email or Slack, open the platform, and find the PR to act. On mobile the page was non-functional. Approvals stalled or resolved informally off-platform.
Workflow configuration
Any change to routing logic required CS involvement. Most accounts hadn't updated their workflow since onboarding. Self-serve was effectively impossible.
Visibility and collaboration
Requesters had no status after submission. Approvers couldn't see prior approvals or context. All discussion happened on Slack, unattached to the record.
Audit trail
Existing log recorded state changes only. No reasoning, no comments, no context per decision. Hard to trace why a PR was approved or rejected.
Existing PR form
Old PR detail view
Existing workflow builder
Old workflow builder
02 · Research
Problems were known. Research shaped the solution.
The two problems were already defined before research began, from customer feedback, CS escalations, and the UX audit. Interviews and session recordings were used to understand how each user type experienced the friction and what a better version needed to feel like for each of them.
1
Approvers weren't avoiding the product. They hit a dead end.
Session recordings showed approvers tapping through on mobile and bouncing immediately. It wasn't disengagement. The approval UI simply didn't work on mobile. They either switched to desktop later (and forgot) or resolved it informally on Slack. The intent was there. The experience blocked it.
2
Procurement leads had stopped expecting self-serve config
Interviews revealed that most procurement leads no longer tried to update workflow rules themselves. Filing a CS ticket had become the expected path. That normalisation was the clearest signal: the tool had consistently failed until users stopped expecting it to work.
3
PostHog and MS Clarity confirmed what interviews described
Funnel data from PostHog showed drop-off at the approval action step. Clarity recordings showed approvers on mobile hitting the page and leaving within seconds. Workflow builder sessions showed near-zero interaction after the initial onboarding setup. The quantitative data matched the qualitative signal exactly.
Who we designed for
👩💼
Procurement Lead
Primary user
Current behaviour
Submits PRs in the product but finishes approvals on Slack. Doesn't touch the workflow builder after initial setup.
Core frustration
Manually chasing approvers. No visibility once a PR leaves their queue.
What needs to change
Routing they can update themselves. Live status without having to ask anyone.
👨💼
Finance Manager
Approver
Current behaviour
Ignores in-product notifications. Gets context from procurement on Slack before taking any action.
Core frustration
Gets notified, tries to act on mobile, hits a dead end. Ends up doing it on Slack or forgetting until chased.
What needs to change
Act on approvals from the notification itself. Full context in the email. No platform re-routing required.
🧑💻
Business Requester
Occasional submitter
Current behaviour
Submits a PR then immediately pings procurement on Slack to confirm it was received.
Core frustration
No feedback after submission. No idea if the PR has been seen, approved, or is stuck.
What needs to change
Confirmation on submit. Live position in the approval chain without asking anyone.
Who does what
Step
Procurement Lead
Finance Manager
Business Requester
Raise PR
Notified on submission
Not involved
✦Fills in and submits
Route to approver
✦Automatic via workflow rules
Not involved
Gets submission confirmation
Approve or reject
✦First-level approver
✦Approves if above threshold
Notified on outcome
Collaborate on PR
✦Threads questions inline
Responds or requests info
Responds to clarifications
Track status
✦Monitors approval chain
Sees their step only
Live position in chain
Configure workflow
✦Owns rule setup via Flo AI
Reviews and validates rules
No access
✦ Primary owner of this step
03 · PR Redesign
Every gap addressed. Nothing bolted on.
The PR module had accumulated a set of UX gaps that individual fixes wouldn't solve. Approvals were stalling, visibility was poor, collaboration happened outside the product, and the audit trail was hard to trace. The revamp addressed all of them together, and added an AI layer that makes the whole thing faster to act on.
UX gaps we fixed
Gap 01
Approvals required re-routing back to the platform
When a PR needed approval, the notification landed in email. Approvers had to leave what they were doing, open the platform, find the PR, and act. On mobile, the page was unusable. The redesign puts approve and reject actions directly inside the notification email. Approvers act from their inbox. No re-routing, no context switch.
Gap 02
Multiple approvals from the same person created confusion
When the same person appeared at multiple steps in an approval chain, the product treated each as a separate action. Approvers received duplicate notifications with no clear link between them. The redesign consolidates sequential approvals from the same person into a single review step, clearly labelled so they know they're covering more than one stage.
Gap 03
Workflow visibility was missing for both sides
Requesters couldn't see where their PR was in the approval chain. Approvers couldn't see who had already reviewed before them or what stage came next. The redesigned PR page shows a live approval timeline visible to all parties: who has approved, who is pending, and what the next step is. Both sides always know where the PR stands.
Gap 04
Collaboration happened outside the product
Any discussion about a PR - clarifying questions, context, pushback - happened on Slack or email. None of it was attached to the record. The PR page now has inline comments threaded directly on the request. Approvers can ask questions, requesters can respond, and everything is preserved in the audit trail without leaving the product.
Gap 05
Audit trail was incomplete and hard to read
The existing audit log was a timestamped list of system events. It recorded state changes but not the reasoning behind them. The redesigned audit section captures who acted, what they decided, any comments attached to that decision, and when. Each approval or rejection shows the full context, not just the outcome.
Gap 06
No AI layer to support decision-making
The AI-native pivot made this the right moment to add intelligence to the PR page. Flo AI summarises the request for the approver before they act, flags potential issues like budget overrun, duplicate vendor requests, or missing information, and surfaces the summary at the top of the review view. Approvers get context prepared for them, not buried inside the PR.
Solving the re-routing problem
Approve or reject without leaving your inbox.
The notification email now carries the full context the approver needs: requester, vendor, amount, business reason, and the Flo AI summary. Two buttons sit at the bottom. Approve or reject from the email itself. If they want more detail, the link takes them to the full PR page. But most approvals don't need it.
Approve and reject actions embedded directly in the notification email.
Flo AI summary included in the email so approvers have context before clicking anything.
One-click approval for low-value requests. Full review page linked for complex ones.
Action taken in email is reflected immediately in the PR timeline and triggers the next step in the chain.
The AI layer on the PR page
Flo AI prepares the context. Approvers just decide.
Before an approver reads a single line of the PR, Flo AI has already done the prep. It summarises the request in two sentences, checks it against budget, flags duplicate or similar recent requests, and surfaces any missing information. The approver arrives at the decision, not the details.
Two-line summary of the request: what, who, why, and how much.
Budget check: remaining allocation shown against the requested amount.
Issue flags: duplicate vendor, policy mismatch, missing justification, or unusually high value for the category.
All flags are explainable. Approvers can expand any flag to see the data behind it.
Approval timeline
Live chain showing completed, pending, and upcoming steps. Visible to requester and all approvers on the PR. No one has to ask where it is.
Inline collaboration
Comments threaded directly on the PR. Questions, clarifications, and context attached to the record. Nothing falls through to Slack.
Full audit trail
Every action logged with who, what, and why. Comments on approvals and rejections preserved. Complete record from submission to close.
04 · Workflow Builder
Describe what you need. Flo AI configures it.
The old workflow builder required procurement leads to think like engineers: define conditions, set thresholds, wire up steps. Most couldn't. The redesign inverts that. Flo AI takes a plain-English description of the approval process and generates the workflow. Procurement leads review and adjust rather than build from scratch.
What made configuration hard before
Problem 01
Starting from scratch with no reference point
The builder opened to a blank canvas. No templates, no examples, no starting structure. Procurement leads had to know what a good workflow looked like before they could build one. Most didn't, and most gave up before saving anything meaningful.
Problem 02
Conditional forms were too complex to configure
Setting up conditional logic - showing different form fields based on request type or value - required navigating a nested settings panel. The options weren't labelled clearly. Small mistakes weren't caught until a real PR triggered the wrong path. Most accounts left conditional forms unconfigured entirely.
Problem 03
Discoverability across configuration options was poor
Settings for SLAs, escalation paths, fallback approvers, and parallel approval were spread across different panels. There was no single place to see what a workflow was doing. Procurement leads couldn't tell what they hadn't configured yet, so gaps stayed hidden until something went wrong.
Problem 04
No standards to maintain consistency across workflows
As accounts grew, they'd have multiple workflows with no naming convention, no shared logic, and no way to see where rules conflicted or overlapped. The redesign introduces workflow standards: a shared settings layer for company-wide rules like maximum approval thresholds and mandatory audit steps, that individual workflows inherit and can override within bounds.
The AI layer on the workflow builder
Tell Flo AI how approvals work. It builds the workflow.
A procurement lead types something like "All requests above $10k need finance sign-off. Engineering requests go to the VP first. Anything below $2k can be approved by the requester's manager alone." Flo AI parses that, maps it to a workflow structure, and generates the steps, conditions, and routing logic. The procurement lead reviews the output, adjusts anything that doesn't look right, and activates it.
Plain-English input converted to a structured workflow in one step.
Generated workflow is fully editable. Every node and condition can be changed manually.
Flo AI explains each step it created so the procurement lead can verify the logic matches the intent.
Ambiguous instructions are flagged before generation, not silently guessed at.
05 · Impact
Two metrics that directly reflect what we fixed.
↑
22%
Accounts configuring and updating approval workflows without a CS ticket, up from near zero before the revamp.
Significantly faster
Approval turnaround after inline email actions shipped. Approvers no longer re-routed to the platform for straightforward approvals.
06 · Moments that shaped the work
Three decisions that defined the outcome.
This was a revamp scoped within a larger platform pivot. Constraints were real, priorities shifted, and not every direction we explored made it through. These are the moments where the thinking mattered more than the output.
MS Clarity and PostHog changed the scope
The brief came in as two problems. The UX audit surfaced four more we hadn't been asked to fix.
Clarity recordings showed approvers bouncing on mobile within seconds of landing on the PR page. PostHog showed drop-off at the approval action step. But they also showed something we hadn't been briefed on: requesters pinging procurement immediately after submission because nothing confirmed the PR had moved. The audit gave us evidence to expand the scope to include the approval timeline, collaboration, and audit trail. I brought the recordings and funnel cuts to the roadmap review. All three were added.
Flo AI for workflow config almost didn't ship
The AI layer on the workflow builder was the most debated decision in the whole project.
Engineering's initial position was that plain-English workflow generation was too risky to ship in this cycle. Misconfigured workflows affecting live approvals was a real concern. I proposed a constrained version: Flo AI generates a draft workflow, the procurement lead reviews every step before anything activates, and no AI-generated step can bypass the completeness checker. That framing separated the generation from the activation. It addressed the risk without killing the feature. It shipped in the same release.
Inline email approvals solved the wrong problem first
The first solution for approval drop-off was a mobile-optimised review page. It was the wrong starting point.
We spent a week designing a responsive approval view before stepping back and asking why approvers needed to come to the platform at all for a straightforward approve or reject. The answer was that they didn't. Moving the action into the notification email removed the re-routing friction entirely for the majority of approvals. The mobile-optimised page still shipped for complex cases where full context was needed, but the email action handled most of the volume. Starting with the simpler intervention first would have saved the week.
07 · Reflections
What I'd do differently.
1
Start with the UX audit, not the brief
The MS Clarity and PostHog audit is what expanded the scope from two problems to six. That audit happened early, but it could have happened before the brief was even written. On any revamp, behavioural data should be the starting point, not a validation step after direction has already been set.
2
The email approval needed a fallback for complex cases earlier
Inline email approvals handled the straightforward cases well. But edge cases where approvers needed more context before acting weren't fully solved until late in the project. Designing the fallback path - the link to the full PR page on mobile - in parallel rather than as an afterthought would have closed that gap at launch.
3
Flo AI for workflow config needed more guardrails in the brief
The back-and-forth with engineering about AI-generated workflows added time we didn't have. The risk concern was legitimate. If I'd defined the constrained version - draft generation with mandatory human review - at the start of scoping rather than mid-sprint, the conversation would have been much shorter.
