Vision and Strategy
Designing an AI-Native Financial Decision Workspace
What if software assembled itself around the problem a user is trying to solve? Rather than forcing users to navigate dashboards, reports, and workflows, what if they were given a workspace containing the exact context, data, and artifacts needed to make a decision?
Financial decisions do not live inside one product surface
A key insight I got from the user research on working capital was: Deciding on how much to borrow, from where, and how does not happen in isolation. Businesses settle on working capital sources when they are in the midst of planning, when they are thinking about payroll, upcoming bills, or delayed customer payments and they stitch together multiple sources of data to get all the insights they need to make an informed decision.
BILL sits at the payment layer, which gives it access to historical transaction data, payment behavior, invoice activity, bill obligations, and repayment patterns. In theory, that makes BILL a strong place for financial planning and working capital recommendations. But in reality, businesses do not come to BILL looking for capital weeks or months before a cash flow gap. They plan elsewhere, often in spreadsheets, and only return to BILL when it is time to pay their bills.
But even if they did, the product's architecture does not match how financial decisions actually happen.
Traditional product architecture was getting in the way
Traditional CRUD-based interfaces are bound by product architecture. Users have to navigate pages, menus, and reports, just to gather the materials they need to make a decision. That structure works for linear workflows, but it breaks down when the user is trying to make a decision that cuts across multiple artifacts.
How planning works for SMBs
To understand how finance teams approached planning, my research partner and I spoke with financial controllers, CFOs, and business owners.
Planning is fragmented
On average, SMBs use 8-10 different tools due to fragmented and siloed data. Spreadsheets are often used as the "Integration layer" and even then there is a lot of manual work involved. The CFOs and controllers found it hard to access Finmark because due to limited integration after the company was acquired, Finmark existed in its own hub in the product, quite isolated from the other areas of BILL.
There is a strong "I'll do it myself" mindset
But that does not mean users were trying to build their own software. They were trying to compress workflows. They were using spreadsheets, templates, AI tools, and manual processes to turn multi-step financial work into something they could control in one place.
AI adoption is high, but trust is uneven
Almost every single participant we interviewed uses AI tools on a daily basis for work. However, they didn't delegate all tasks to AI agents. High stakes tasks such as planning, scenario analysis, etc were still fully manual.
And these insights and product usage behavior helped me narrow down the key design principle:
AI should automate low-stakes decisions, but for high-stakes moments, it should reduce the distance between decision-makers and the evidence they need to act with confidence.
Getting directional alignment from leadership
Before I could start working on a unified capital and planning vision, I had to get leadership buy-in. To do that, I quickly created a rough functional prototype that integrated Finmark's planning capabilities with personalized working capital offers. The goal here was to provide a prototype leaders from the payments and AI orgs could play around with, to understand the feedback loop between planning and capital offers.
I built the prototype using the following stack:
- React.js
- Functional forecasting and scenario planning logic.
- CSV/spreadsheet upload so real business data could be used in testing
The learning: entry points were not enough
Testing with this prototype with real user data prompted high-value feedback from users:
Product architecture still limited usefulness of Finmark
Users did not just want a better planning page. During planning, they needed to move fluidly across invoices, bills, forecasts, customer payment history, spreadsheet assumptions, capital options, and repayment implications. They wanted to compare evidence, ask follow-up questions, and inspect the reasoning behind any recommendation.
Trust takes time and needs to be earned
On the agentic workflows and recommendation front, an interesting pattern emerged: Not all jobs-to-be-done are equal. Users were completely fine with agents driving certain tasks in the background, but for high value jobs, they wanted agents to help stitch the workflows together, but they wanted full control over judgement and decisions. Users were ok with offloading certain high value jobs, as long as the system was able to prove it could perform the job consistently well.
Designing the dynamic workspace canvas
The dynamic decision workspace is a temporary UI that is composed around a financial decision. It does not behave like a permanent dashboard. It does not require users to know where a feature lives. It appears when there is a meaningful problem to solve, pulls in the relevant data and artifacts, supports the user through analysis and action, and then goes away once the job is complete.
The workspace has two primary surfaces:
- The first is a natural-language workspace where users can ask complex financial questions, transform data, inspect assumptions, and bring in context that may exist outside of BILL.
- The second is a canvas where the system assembles the artifacts needed to make the decision: forecasts, invoices, bills, repayment terms, recommended actions, scenario tables, audit trails, and supporting evidence.
Evolution of the workspace canvas
Context based on the entry point
One of the most important interaction principles in the prototype was that the user should never land in an empty workspace. If the system detects a scenario that needs attention, the workspace can be pre-assembled around that problem and the entry point could be presented as a suggestion card anywhere within BILL.
The user can also invoke it from anywhere in the product. If they right-click on any element on a page, the system can use that object as the first layer of context and show a small set of relevant next steps. So when the user lands on the canvas, there is already enough context to dive straight into meaningful next steps.
Trust is part of the architecture
The workspace has to make reasoning visible by default.
If the system recommends financing invoices, delaying payments, using a credit line, or changing a payment schedule, the user needs to understand why. They need to see the source data, the assumptions, the tradeoffs, and the risk.
So the workspace pairs recommendations with:
- Source artifacts
- Editable assumptions
- Scenario comparisons
- Explanation blocks
- Approval steps
- Audit trails
- Clear separation between suggested actions and executed actions
This keeps the agent from becoming a black box. It positions AI as a system that can assemble the decision environment and prepare a plan, while the human remains accountable for high-stakes approval.
Making the canvas work outside BILL
If a user is already working in Slack, Google Sheets, Google Docs, email, ChatGPT, Claude, or another business tool, they should still be able to invoke BILL’s intelligence from there. The user should not have to stop what they are doing, open BILL, land on the dashboard, navigate to a workflow, and manually rebuild the context.
To explore this, I analyzed the current BILL API surface and the internal endpoints that could power this kind of external invocation. The idea was, if every endpoint becomes an artifact, then the workspace could be assembled anywhere. But financial workflows are bound by compliance, legal, risk, and partner requirements. Some endpoints may not be safe to expose directly and certain actions may require additional authorization, auditability, or partner specific constraints.
So instead of exposing sensitive end points directly, external tools could pass the user intent and context into BILL. After authentication, the user could be dropped into a pre-assembled canvas. This would completely eliminate the need for the user to manually reconstruct their intended workflow within BILL.
State of progress
This work is still ongoing.
The current prototype is being tested against cash flow scenario use cases, where BILL detects a potential gap, assembles a workspace with the relevant invoices, bills, forecasts, and financing options, and helps the user evaluate the best next step.