AI assistant for bureaucracy
Transforming a deadline-reminder app into a proactive service combining AI automation with human expertise.
Challenge
Büro already helped people remember administrative deadlines. The next challenge was to make it proactive: understanding each person’s situation, identifying relevant obligations and opportunities, and helping them complete the resulting practices.
Approach
I mapped the end-to-end service, designed the first proactive prototype and validated it through five two-week experiments with different audiences, propositions and levels of automation.
Outcome
The experiments showed that users were willing to share personal documents and pay for assisted practices. The resulting service model combined AI, automation and human specialists, and later informed Büro’s move towards B2B2C.
Context
The first version of Büro worked as a personal administrative calendar, helping users track important deadlines and act before they became urgent.
It addressed a real problem: forgetting a deadline could mean losing a benefit, delaying an application or paying an avoidable fine. But users still had to know which obligations and opportunities applied to them in the first place.
This led to a more ambitious question:
What if people did not have to search for every obligation and opportunity themselves?
Timeline
Discovery
Researching administrative pain points and identifying missed deadlines as a widely shared problem.
Reframing
Evolving Büro from a deadline-reminder app into a proactive assistant.
Service design
Mapping the experience across chat, profiles, documents, practices and specialist support.
Experimentation
Building a new prototype or feature for each test, targeting different audiences and validating document sharing, trust and payment.
Analysis and iteration
Reviewing campaign data and Smartlook sessions after each experiment, then evolving the product, automation and service flow for the next test.
The problem appeared at moments of change
Through interviews and an online survey, the same frustration surfaced across very different audiences. Moving home, settling in Italy, becoming a parent or losing a job suddenly introduced unfamiliar documents, deadlines and opportunities.
People were not only struggling to complete individual practices. They often did not know what applied to them until they had missed a deadline, lost a benefit or received a fine. This shifted our focus from simplifying bureaucracy to anticipating what each person needed next.
From reminders to a proactive assistant
I started by mapping the complete journey, from onboarding and profile building to document collection, recommendations, payment and fulfilment.
This exposed an important design challenge: the experience needed continuity across every stage. A question could lead to a document upload, reveal an opportunity and eventually become a practice handled by a CAF or another specialist. The service had to keep this information connected as the user moved from discovery to completion.
The service needed continuity across several spaces:
- the assistant collected information and explained what was happening;
- the profile stored facts about the user’s situation;
- the document area retained uploaded evidence;
- dedicated practice pages showed status, missing documents and next steps;
- automation transferred complete requests to the appropriate specialist.
Prototype
The prototype built an initial profile around key areas such as home, work, family, health and mobility. It developed gradually through useful interactions, including conversations and document uploads.
Büro then compared the user’s circumstances with changing administrative information to identify relevant opportunities, deadlines and deductions. Each recommendation explained why it mattered and offered a concrete next step, turning personal information into timely action rather than generic notifications.
Turning information into action
AI assistant training
Shaping the AI behind the conversation
Building its knowledge
We organised verified information about practices, deadlines, documents and eligibility into a structured knowledge base. The assistant was instructed to use this material instead of relying on general answers.
Designing its behaviour
I defined its tone, conversation rules and questioning logic. It asked for information progressively, explained why each document was needed and guided users towards a clear next step without overwhelming them.
Testing its limits
We tested realistic questions, incomplete requests and unexpected replies, then refined the instructions around recurring failures. When confidence was low or a case required professional judgement, the conversation was transferred to customer support or a specialist.
The assistant made the service approachable, but chat history was not a suitable place to manage a complex practice.
If someone started discussing their 730 tax return, that conversation needed to become a persistent topic. Documents uploaded in the chat needed to appear in a document area. Once the practice began, the user needed to understand its status without asking the assistant again.
I designed dedicated practice pages that brought together:
- the current stage;
- documents received and still missing;
- detected expenses or benefits;
- the next action required from the user;
- the work being completed by Büro or a specialist.
AI + Human
The assistant was powered by OpenAI and delivered through Landbot, with n8n coordinating the automation.
One of the Landbot flows
The key question was not whether people liked the idea of an AI assistant. It was whether they would trust it with real information and pay for real support.
We ran ten two-week experiments, changing the audience, communication, proposition and parts of the experience. Meta campaigns targeted specific situations such as having a young family, being a foreign resident or recently losing a job.
A functioning prototype connected:
- targeted Meta advertising;
- onboarding and chat in Landbot;
- an OpenAI-powered assistant;
- n8n automation;
- document collection;
- human customer support;
- CAF and specialist fulfilment.
Every section was tracked in Smartlook. We reviewed recordings and behavioural data to understand where people engaged, hesitated or abandoned the journey.
Results
Slow responses broke the conversation
Some AI responses took long enough that users left before receiving an answer. We introduced push notifications so people could continue with their day and return when the response was ready.
Document upload was the critical moment
The service depended on documents, but every additional step increased abandonment. Uploading was simplified and placed directly within the relevant conversation or practice.
Payment came too early
Asking users to pay before the system had checked their documents created uncertainty and drop-off. Payment was moved later, after Büro confirmed that the practice could proceed.
Key numbers
In one of the final experiments, a €50 targeted advertising campaign generated:
registered users
sessions
users who uploaded a document
requests for assistance
paid practices processed
The consumer experiments validated the underlying need and showed that completing bureaucratic practices requires access to organisations, specialists and established service journeys.
Büro later evolved towards a B2B2C model, bringing its document collection, form preparation and assisted workflows into the customer journeys of banks, insurers, utilities, automotive companies and public services.
The model changed, but the principle remained the same:
“Bureaucracy should become something the system handles with the user, not something the user must navigate alone.”
Links
The consumer app remains available on the App Store and Google Play, although some functionality may now be limited.
Learnings
A failed experiment is still a useful result
Not every test needs to produce positive metrics. Evidence that an idea is not working can save the team from investing in the wrong direction and create the confidence to pivot.
Complex ideas can be tested simply
Some solutions initially appeared to require months of development. By combining existing tools, automation and manual support, we could test the underlying assumption in two weeks before building the full product.
Test the riskiest assumption first
It is easy to spend time improving the interface while the fundamental question remains unanswered. I learned to identify the behaviour that would make or break the concept.
Looking for more detail on this project, or have a similar challenge in mind?