Why Daily Sickness Benefits Belong in Every Insurance App

Daily sickness benefits are among the claims where a lot is at stake for policyholders: income, financial stability, and the feeling of being “caught.” Nevertheless, the claims application process at many insurance companies still operates in a surprisingly analog manner: paper forms, faxes, and follow-up calls—resulting in correspondingly long processing times and a high risk of errors.

From the perspective of CEOs and decision-makers, this is doubly costly. On the one hand, the process is resource-intensive internally; on the other, policyholders today expect mobile, guided solutions—and this expectation grows with every banking and e-commerce app they use.

On top of that: leaner processes shorten processing times, reduce personnel costs, and increase customer satisfaction.

This blog post shows how a small idea can become a real feature. No large-scale program, no hundred-person project organization, but a clearly defined business initiative, driven by a few people and technically implemented by a small development team.

What I’m aiming for here:

• to show that with limited resources and a clear business vision, you can launch a robust feature in a short time,
• to explain why business expertise and logical structure make the difference, not just the technology,
• and to describe how you can use dynamic questionnaires and a rule editor to ensure your business unit remains capable of acting without constantly triggering new app releases.

Of course, when integrating into an existing app platform, all regulatory requirements (such as DORA), data protection regulations (GDPR), and internal guidelines must still be observed. The advantage: You can usually build on already established standards and don’t have to develop a completely new concept.

Why Sick Pay Belongs in the App

The story doesn’t begin with a big strategy workshop, but rather “on the side.” In conversations with colleagues, the same observation kept coming up:

“There’s already an app, but it’s missing truly relevant benefit processes.” Sick pay is an ideal example of this:

• The process is clearly definable.
• There is concrete documentation (e.g., a certificate of incapacity for work).
• Currently, much of the process is still handled via paper forms.

Instead of building a completely new app, it quickly became clear that we would integrate the daily sickness benefit feature into an existing insurance app.

This has several advantages:

• Login, identity, and security are already handled.
• Policyholders are already familiar with the app, so the barrier to entry is low.
• The IT infrastructure is already in place, and relevant interfaces are connected.

At the same time, resources were deliberately kept to a minimum:

One person took on nearly all technical roles: from product definition and the UX perspective to technical quality assurance. On the technical side, there were two developers who implemented the feature and built the prototype.

For CEOs and decision-makers, the specific scope is particularly important at this stage. Instead of trying to do everything at once (“all service processes digital”), we focused on the following questions for the first prototype:

• What must a daily sickness benefit feature absolutely be able to do in its first iteration to provide real added value?
• Where can we consciously say: “We don’t need that yet; we’ll need it in the final product”?

For our first prototype, these were essentially:

• 1. Submit a daily sickness benefit claim: directly from the existing app, via camera or file upload.
• 2. A dynamically guided questionnaire that asks only the truly relevant questions.
• 3. Simple feedback, including gamification, so that policyholders can see that their claim is being processed.
• 4. Push notifications for status updates.

The prototype did not include, for example:

• a fully automated benefits decision,
• sophisticated OCR/AI document analysis,
• a highly customized notification logic.

The rule of thumb here is: Anything that is technically sensitive, handled differently by insurers, or generates technical overhead (such as additional APIs or new databases), but is not strictly necessary for the first prototype, will only be implemented upon integration into the regular product.

The result: With one business expert and two developers, the prototype remains manageable and can be delivered quickly, depending on capacity and internal approval processes.

Refine the idea and define the scope

The real difference between a “nice app idea” and a viable use case lies in the technical details. Daily sickness benefits are not a self-service playground, but a service promise that must be fulfilled in full compliance with legal and contractual requirements.

That’s why the path to the prototype doesn’t start in the development environment, but with questions like:

• What events typically trigger a sick pay claim?
• Which documents are mandatory, and which are optional?
• What information does the insurer need to decide on benefits?
• What technical decisions (e.g., waiting periods, qualifying periods, upper limits) need to be prepared?

These questions form the core of the feature: the dynamic questionnaire.

Instead of digitizing a long paper form one-to-one, we conceptualize the process as a dialogue:

• The app asks only the questions relevant to the specific case.
• The answers determine which follow-up questions are even asked.
• Technical rules ensure that only the data that is truly needed is collected.

A (simplified) example:

• Is the insured person an employee or self-employed?
• Has their occupation changed?
• Are they receiving a pension?

These building blocks form a decision tree: Employees follow a different path than self-employed individuals. What’s important here is that the questionnaire remains understandable for the insured and manageable for the department.

This brings us to the second central building block: the rule editor or low-code approach.

Instead of embedding all decision logic deep within the code, the business rules should be modeled in such a way that they can be maintained via an editor. This means, for example:

• Business rules such as “For self-employed individuals, question Y must always be asked” are stored in a rule base.
• Adjustments, such as for new rates or changed conditions, can be made by the business department.

Internal quality assurance should still be ensured here, for example through the dual-control principle and a lean but regulated approval process.

For decision-makers, this is precisely a strategic lever:

• Time-to-market decreases not only for the first prototype but also for subsequent adjustments.
• The business department does not become a “supplicant” to IT but gains genuine creative freedom.

Of course, a rule editor does not replace professional responsibility. On the contrary: it makes it transparent where professional decisions are made and enforces clear, structured modeling of the rules.

Daily sickness benefits are just one example. The pattern can be applied to other claims processes: inpatient stays, dental services, accident reports. Wherever paper, email, and call centers dominate today, it’s worth asking: What if we reimagined this exact process as a lean app feature? Where are there still paper-based processes that shouldn’t just be digitized, but reimagined?

If you’re considering a similar project at your organization—whether it involves daily sickness benefits or another type of claim—a brief, focused discussion is worthwhile:

• Which use cases are suitable for a Minimum Viable Product (MVP)?
• What business roles do you need, and what can you cover internally?
• What might a meaningful combination of business expertise, a rule editor, and risk-based quality assurance look like for your specific context?

This is exactly why we at adesso develop practical approaches together with insurers. From the first workshop through the MVP to scalable operations. If you’d like to discuss how an idea within your organization can become an app feature with real added value, feel free to reach out.