Loading...
Building an Inbox for agentic actions
Problem statement · GetGround needed cleaner in-year bookkeeping and a single home for assistant-led actions. We built an Inbox: one persistent surface where users understand, review, and complete high-intent actions across their portfolio.
Role · Lead Product Designer and Product Manager
Product principles
Show the right thing, not everything
Help users focus by surfacing what matters most in the moment. Prioritise clarity over completeness; not everything needs to be shown.
Build confidence with every interaction
Make it easy to understand, hard to get lost, and reassuring to use. Guide naturally, place support where it's needed, and use data-led insights to build trust.
Make it useful every time, not just the first time
Create features that are clear, intuitive, and valuable every time they're used. If it needs constant explanation, it's not intuitive enough.
Problem
A bookkeeping problem became a system problem
The work started as an in-year bookkeeping improvement. Cleaner records throughout the year would make our in-house accounting more efficient and reduce burden on the end-of-year flow.
Discovery showed the problem was wider than Bookkeeping. Actions lived across Tasks, Bookkeeping, and assistant-led jobs with no clear home. Refactoring Bookkeeping into an inbox would have created two competing task systems.
Bookkeeping had low reach (24% of logins) and users weren't finding value in the screens. The question wasn't how to refactor it, but whether we needed it at all. Tasks had more than double the usage (55%).
Shaping the solution
Pull, push, and persistent UI: an agent-first interaction model
I led a platform-wide interaction model so agentic AI and existing functionality could live side by side. It mapped primary, secondary, and tertiary user needs to agentic and deterministic UI, without favouring either approach.
Pull
When the user tells us what they need in that moment
- We assemble the UI required to complete that job
- Includes both adaptive (dynamic) and stable (static) content
Push
When the system detects something meaningful and surfaces it proactively.
- Surfaces insights in predictable locations
- UI structure never moves, only the content adapts
- Driven by scenario detection (portfolio changes, compliance needs, market shifts, and patterns)
Persistent
When the user is exploring or reviewing without asking a question or reacting to a scenario.
- Stable surfaces like tables, documents, navigation, asset overviews
- Accessible regardless of scenario, giving users reliable anchors
I mapped core jobs to be done to each interaction type: chat, dynamic tasks, or deterministic flows that stay in the same place.
Testing code-first prototypes
I prototyped on a design/playground branch in our monorepo with production-like components and real product patterns, not static screens. That made the information architecture problem visible earlier: Inbox needed to be a broader action surface, not a Bookkeeping refactor.
We tested comprehension of the new surfaces and removal of Bookkeeping face-to-face with 5 existing users to overall positive feedback. The standout finding was consensus on keeping the final action with the user when updating financial information.
“...getting a choice of how to be notified or how much control you can give the artificial intelligence... It's great.”
“I still want to be the decision maker.”
Release
Supporting existing tasks and setting a framework
The first release had two goals: migrate existing tasks into the Inbox, and define how agentic actions appeared as to-dos or activity items.
Skills, for us, and the agent
To migrate existing tasks, I built a skill based on our Inbox design principles. It takes an existing task or feature description and advises on Inbox content, including whether it should be a to-do or activity item.
The team iterated on the skill from real output, then wired it into our AI assistant so it could reliably decide how to surface actions.
I used it to scan our monorepo and produce migration documentation for engineers.
Setting the framework
A key part of the Inbox was the UI framework: how to-dos and activity items appear, what detail to show and when, how media and container queries behave, and what happens when the side chat is open. I resolved these in static designs, then built the components in our UI package for production use.
Enabling parallel work-streams: first agentic actions
I was also leading document extraction, which fed directly into the Inbox as the primary surface for reviewing suggested actions from extracted document data and user context. The first two use cases were updating property details and linking transactions to documents; both gather better data to improve user-facing and internal flows, including end-of-year accounting.
Impact
1,550% uplift in mortgage end dates added
Previously, users added around 2 fixed-term end dates per day. In the week after document extraction and Inbox launched, this rose to an average of 33 per day, with the biggest day reaching 158. This data is now automatically part of the remortgage engine, giving the mortgage team nearly double the leads they had previously.
Lettings and insurance details increased from 1% to 5%
Previously, only 1% of users added their lettings and insurance details. Since introducing Inbox with onboarding to-dos, this has risen to 5%. This data is gold for building out the lettings and insurance engines as we have done for mortgages.
Too early to tell
Tasks/To-dos completed
Users log in once every 2-3 weeks. Inbox is too new to start tracking any reduction in outstanding tasks.
NPS and real feedback
We have not yet had enough data to see if NPS is affected, positively or negatively, and what the qualitative data tells us.
Transaction activity
There has been a small uplift in transactions categorised, around 3% more per day, but Inbox is just the foundation to enable and encourage more bookkeeping engagement.
Next steps
Populate the activity feed
The activity feed is still sparse and doesn't push context-aware suggestions. Next: populate it with insights to grow weekly and monthly active users.
Act without user triggers
Today the assistant only acts on user input: chat, document uploads, or new transactions. Next: give the agent a heartbeat so it can act without explicit triggers.
What I would change
Better curation of to-dos
We weren't diligent enough in filtering tasks, so too much landed in the Inbox. Some users now have long to-do lists, which dilutes the surface's impact.
Refine agent instruction earlier
Users reported the agent suggesting changes from outdated documents (mortgage statements, receipts from prior tax years). We should have trained it earlier to distinguish current from historical data.