Most of what I write about BenefitsBridge is about what the product already does. This article is a little different. As we look toward 2027, I want to share some of the things brokers are asking us to think about next and why the timing is interesting given what is happening across Microsoft’s business applications platform.
These are not feature announcements, and they are not all roadmap commitments. Some are early ideas. Some are being scoped more seriously. What makes them useful is that they are coming from agencies that already have the basics covered and are now pushing on the next layer of friction: the work that still gets re-keyed, reformatted, reconciled, chased down, or moved between systems by hand.
At the same time, Microsoft is changing the way it talks about, and increasingly builds, business applications. Starting in September 2026, Dynamics 365, Power Platform, and Dataverse roadmap content is moving into Microsoft’s AI at Work roadmap alongside Microsoft 365, Copilot, and agents. Microsoft’s reason is fairly practical: customers do not use these products in isolation anymore. The applications, data, automation, productivity tools, and AI increasingly work together as part of the same business process.
I think that direction matters for a product like BenefitsBridge. The opportunity is not to bolt an AI button onto every screen. It is to use a platform that is becoming more capable of understanding business data, following rules and permissions, automating steps, and bringing agents into the flow of work and then apply those capabilities to the very specific problems benefits brokers are asking us to solve.
The spreadsheet is not going away. The duplicate work should.
One agency we work with builds detailed renewal worksheets in Excel long before the information ever reaches the CRM. That is not unusual. Brokers develop tracking habits over years, and a new system does not magically erase the parts that still work well.
The frustration is the handoff. If the renewal data already exists in a spreadsheet, re-keying it plan by plan into the CRM is duplicate work. A broker told us directly that being able to upload from the worksheet they already maintain would save their team meaningful time.
The obvious answer is better import capability, but this is also where the Microsoft platform becomes more interesting over time. Excel, Power Automate, Power Apps, Dataverse, Copilot, and agents are increasingly part of the same technology story. That creates more ways to think about the handoff than simply “upload a file.” The long-term question is how much of the validation, mapping, exception handling, and follow-up can be assisted while the broker remains in control of the result.
That is the kind of AI use case I find compelling: not asking the user to change a working habit just so the software can claim to be modern, but reducing the manual translation between the tools they already use and the system that needs to hold the trusted record.
Commission processing is a good example of where AI may earn its place.
Carrier statements are inconsistent. Every carrier seems to have its own layout, terminology, and quirks, and benefits teams can spend a surprising amount of time normalizing those files into something consistent enough to reconcile and report on.
The volume makes the problem worse. Even with a good process, handling statements one at a time across dozens of carriers and hundreds of groups adds up quickly. One agency described the need pretty simply: they want to process statements in bulk instead of treating every statement like a separate project.
This is where AI can be more than a demo feature. Document understanding, pattern recognition, and agent-driven workflows can potentially do some of the first-pass work: identify a carrier format, map values into a common structure, flag what does not match expectations, and route exceptions to the right person.
The important part is the last sentence. I do not want an AI model quietly deciding that a commission statement is correct. I want it to remove repetitive work while leaving the judgment, thresholds, and exception handling where they belong. Microsoft is using similar language in its own business applications strategy: AI agents can help move work forward, but within the same data, permissions, rules, controls, and audit trails that govern the application.
For ForgeXRM, that is a useful architectural direction. BenefitsBridge already has the benefits-specific records and relationships. Dataverse provides the governed data layer. Power Platform gives us automation and application extensibility. Copilot Studio and the broader Microsoft agent stack create new options for how work can be assisted or carried out. The product question is where that combination delivers enough value to justify putting it into the workflow.
Task management raises the same question in a different way.
A number of agencies manage day-to-day tasks in a separate project or work-management tool while the client, policy, renewal, and service information lives in the CRM. There are perfectly good reasons for that setup, especially if the outside tool is already deeply adopted.
But over time the separation becomes noticeable. If a task exists because of a client, renewal, policy, or service issue, how much context should live with the task and how much should live back in the CRM? And if AI is going to help prioritize, summarize, or move that work forward, where should it get the context it needs?
I do not think the answer is automatically “put every task in BenefitsBridge.” The better question is whether consolidating the work creates enough value to change behavior. What Microsoft’s direction does give us is a more connected set of options: business data in Dataverse, workflows in Power Platform, productivity in Microsoft 365, and AI or agents that can work across those layers rather than treating each application as an island.
ICHRA is a bigger data-model question.
ICHRA comes up for a different reason. It is not simply another workflow to add to a group-benefits CRM. If a broker begins managing individual policies underneath an employer relationship, the underlying data model starts to change: employer, offering, employee or household, individual policy, carrier, reimbursement information, and renewal activity all have to relate to each other in a useful way.
We are hearing enough interest from brokers to keep researching what that could mean for BenefitsBridge. Today, much of the information may sit with outside administrators or in separate systems, which can make it difficult for a broker to see the entire client relationship in one place.
Where we stand is still straightforward: this is evaluation, not an announcement. We are trying to understand how brokers actually want to serve ICHRA business before we decide what technology belongs in the product.
The platform matters here for the same reason it matters everywhere else in this article. A well-structured data model creates the context that automation and AI need later. An agent cannot be especially useful if it does not understand how the employer, household, policy, carrier, reimbursement, and renewal relate to one another. That is why I think the conversation about AI-enabled business applications has to start with the business application itself.
It is also worth keeping the market context in perspective. The HRA Council reported that roughly 83% of employers offering ICHRA or QSEHRA in its 2025 dataset had not previously offered health coverage. That suggests the model is often expanding access rather than simply replacing an existing group plan. For us, that reinforces the idea that this may be an additional operating model brokers need to support, not necessarily a substitute for the group business BenefitsBridge was built around.
I wrote more about the data-model question here: What ICHRA Could Mean for Benefits Brokers—and the Technology Supporting Them.
The common thread is not “more features.” It is less manual work.
When I step back from these conversations, the pattern is pretty consistent. Brokers are not asking us for a collection of shiny AI tools. They are asking the system they already use to absorb more of the repetitive work around it.
Bring in the renewal data without re-keying it. Normalize carrier information without hours of manual translation. Process commissions at scale. Keep tasks connected to the client context. If ICHRA becomes part of the agency model, make that relationship visible without creating another disconnected application.
A few years ago, most of those requests would have sounded like separate product features. What is changing is that Microsoft is increasingly providing a common platform for the data, applications, automation, Copilot experiences, and agents behind them. Its new AI at Work roadmap is a visible sign of that shift. Dynamics 365, Power Platform, Dataverse, Microsoft 365, Copilot, and custom agents are being planned as parts of a connected work environment rather than independent product lanes.
Microsoft has also started describing business applications as moving from systems of record toward systems of action—applications where AI can help carry work forward under human-defined controls. I think that is an important distinction. The value of AI in a benefits CRM is not that it can answer a question in a chat window. The real opportunity is when it understands the client, the policy, the workflow, the business rule, and the exception well enough to help move the work forward safely.
That is where I see ForgeXRM’s role as a Microsoft partner. Microsoft is building the platform and infusing AI across it. Our job is to bring the industry context: the data model, workflows, edge cases, and customer understanding that turn general-purpose capability into something a benefits broker can actually use. Microsoft itself has been explicit that partners are important in this shift because domain expertise is what turns platform capability into real-world outcomes.
Not everything brokers ask for will become part of BenefitsBridge, and it would be a mistake to pretend otherwise. A roadmap should not be a transcript of customer requests, and AI should not become a reason to lower that standard. We still need to understand whether the problem is broad enough, whether the solution fits the product, and whether we can support the experience once it is in a customer’s hands.
The best roadmap ideas usually do not begin in a strategy meeting. They begin with somebody saying, “I still have to do this by hand every month. Why?” What is different now is that the platform underneath us gives us more ways to answer that question.
Those are the conversations we are paying attention to as we think about BenefitsBridge, AI, and 2027 and beyond.
Related reading:
The Philosophy Behind Every ForgeXRM Product Roadmap
What ICHRA Could Mean for Benefits Brokers—and the Technology Supporting Them
Microsoft Dynamics 365: An agent-ready business applications platform
