Implementing Benefits Eligibility + Enrollment Systems: Insights on State Approaches and Processes

Introduction

Increasingly, states are building integrated eligibility and enrollment systems (IEEs) to facilitate streamlined processes for people enrolling in and managing benefits. In 2025, Code for America reported that 35 states now offer integrated applications of at least three programs. Federal policy for public benefits programs is not designed for integration from the outset. To administer integrated applications and enrollment processes, states must create pathways for integration and manage processes for system development and updates, while adhering to federal requirements. 

To offer insight into states’ current processes and challenges, the Digital Benefits Network (DBN) at the Beeck Center for Social Impact + Innovation at Georgetown University launched Implementing Benefits Eligibility + Enrollment Systems, a research initiative documenting states’ processes for building and maintaining IEE systems, including how they interpret and translate policies into the software code that informs these systems.

Throughout summer 2025, the DBN conducted interviews with 24 leaders from seven states that operate or are building IEEs for core programs. Building on our previous primer publication, this publication provides insights on state processes for developing and updating IEEs. It offers a summary of state product management approaches, including the frameworks used, the cadence of updates, and the common steps involved. Additionally, it details pain points states identified in their IEE technology and processes, as well as states’ aspirations for improvements and alternative approaches. We hope this publication will provide foundational context for states already pursuing IEE systems, as well as inform new members of existing state IEE teams, along with those in state legislatures, other state offices, advocates, and civic tech partners.

Note: Under our research protocol, we are not disclosing which states we spoke with, nor attributing specific information or quotes to them throughout this publication.

IEE Product Management: State Approaches 

The process of updating and maintaining IEE systems varies across state agencies, depending on the number of distinct agencies involved, the governance structures used, and their approach to project management and development. In our prior publication, Implementing Benefits Eligibility + Enrollment Systems: Key Context, we documented the technologies, roles, and stakeholders engaged in IEE maintenance and updates. Below, we elaborate on the key factors and steps involved in making updates or changes to IEE systems. 

Cadence

IEE systems are complex and ever-evolving. To operate successfully, they must reflect the current state of many policies across multiple programs, and respond quickly each time any of those policies change. Successful IEE systems will also be responsive to changing user experience needs, and regularly address technical inefficiencies. While all of the states we spoke with described continuously working to address changes, they reported varying cadences for managing, prioritizing, and addressing those changes. These included:

• Frequently and consistently: One state contracts with a vendor to make regular system releases approximately every six weeks. 
• Quarterly or as-needed: Another state tries to make updates on a quarterly basis throughout the year. They also release updates in response to emerging needs—but not so often that clients get overwhelmed.

“We’ve tried to be pretty consistent with once-a-quarter major releases [and] once-a-month minor releases, because the feedback we were getting from our customers was that changes had been happening too quickly for them to understand what the impact was.”

State Leader

• Dependent on strategic roadmaps: Multiple states tie their update schedule to strategic roadmaps. These have varying timelines, and some states we spoke with described roadmaps projecting several years into the future. These roadmaps tend to be informed by federal and state legislative priorities and federal agency coordination. 

Frameworks

A second key factor in how states approach updates are the product management paradigms used to structure workflows. Throughout our conversations, states discussed two primary product management paradigms: agile and waterfall. 

States rarely described using only one paradigm or rigid interpretations of either approach. For example, states using agile processes more often used customized, not-fully-agile processes, or applied agile processes to some portions of the project and waterfall to others.

These paradigms were implemented by in-house teams, vendors, contracted team members, or a combination thereof. One state we spoke with used an agile approach and managed updates in-house. Others described operating in more of a waterfall fashion, relying heavily on vendors throughout—in some cases, vendors were serving as initial subject matter experts to interpret policy, passing requirements to other vendors to build and reviewing work when completed. 

Common Steps

Our conversations with states revealed a variety of approaches to updating IEEs, but reflected a core set of common steps. Below, we outline these steps and share examples from the states we spoke with, illustrating points of commonality and divergence. 

States regularly make different kinds of updates to their systems, including technical fixes, changes to rules to reflect new policies, and other enhancements. The steps below apply broadly to all types of updates, though some are more relevant for certain types than others (for example, assessing policy is more relevant when making changes to rules).

Prepare for Updates

States act to update systems for a variety of reasons. Some updates may be initiated in response to external demands—such as federal policy changes or revised priorities from the state legislature—and others by internal teams, perhaps in response to client feedback. 

States describe a range of preparatory steps to carry out before work can begin. These include:

• Consider funding: States preparing for major updates will need to seek and allocate funding to undertake these changes. In many cases, this means submitting advanced planning documents (APDs) to “request funding approval for a project which will require the use of [automated data processing] services or equipment, including the use of shared or purchased services in lieu of State acquired stand-alone resources.”

• Communicate and request approval: States may also need to communicate with and request approval from federal agencies about changes. For example, FNS requires documentation about “major changes” to SNAP system operations. 
• Other internal agency processes: During interviews, states described different internal processes that preceded the start of formal work. One state said that program teams requesting updates filled out a mandatory change request template approved and prioritized by executive leadership. It outlined the motivation behind a change, who was involved, and provided the required timeline.

Assess Policy

Before acting on updates related to policy—typically based on new legislation or federal guidance—states bring stakeholders together to fully assess the policy’s meaning. 

As one state we spoke with described, the policy team’s input is essential at the start of a change process; this team clarifies the substance of the change before any other work happens. Who is involved in assessing policy varies based on the program, and may include outside partners; one state described working with a partner vendor to assess policy. 

Policy team members also engage directly with federal agencies like CMS, FNS, ACF to clarify questions ahead of updates. 

“We’ll also engage specifically with the federal government if we have questions. So, some examples: During the unwinding, several states had questions around how they were doing passive renewal for the Affordable Care Act. So, policy engaged directly with CMS to say, ‘We understand you said ‘x.’ Here’s a variation of ‘x.’…. What are your feelings about this?’”

State Leader

Analyze System Impact 

Because IEEs involve multiple programs, a key preparatory step is understanding how a system update initiated by one program will impact others. This requires state agencies that run different programs to collaborate and provide input. For example, when making a program-specific change to a screen in an IEE application that is used by multiple programs, teams will work to ensure the user experience remains stable for clients of all programs. They also check that a change to one part of the system will not unexpectedly impact a universal feature, such as a correspondence module. 

This ongoing work requires cross-program and often cross-agency collaboration, which states have various approaches to. Examples include:

• Core team of program representatives: One state’s IEE team included policy representatives for each program. When one representative requested a change to the system, they reached out to other program counterparts to understand the change’s potential impact.
• As-needed collaboration across agencies: In another state, team members from different agencies collaborated on change requirements and implementation when they identified changes beneficial to multiple programs’ needs.

States repeatedly emphasized how, when operating an integrated system for multiple benefits, cross-policy team collaboration is essential to ensure that a change driven by one program does not “harm the eligibility outcome” for another program. As one state explained, good governance is key to system impact analysis. 

“[We have] to ensure that we’re not introducing an unintended outcome as a result of a change that we may think is simple. That simple, simple change may have lasting impacts for families.”

State Leader

Read more about cross-agency collaboration in our publication: Implementing Benefits Eligibility + Enrollment Systems: Key Context.

Prioritize Changes 

In complex IEE systems, agencies often need to make multiple changes at once. States have different ways of prioritizing changes, and distinct governance structures that shape how this prioritization happens. Inevitably, prioritizing certain changes means there is less time and fewer resources for others. Several states described having a backlog of changes they wanted to make, but needing to deprioritize. For example, our October 2025 publication covers how states are reprioritizing planned updates and enhancements in light of H.R. 1. 

States describe approaches to governance and prioritization that vary in formality and structure, including: 

• Small group convenings: One state we spoke with convened a smaller group with a less determined governance structure, for minor changes (such as regular maintenance items, like updating a field).
• Formal governance work groups: One state has a formal governance work group that meets monthly to review changes to the system, reviewing the source of the change, implementation timeline, and the likely outcomes from the changes. The state using a smaller group for minor changes (described above) submits larger enhancements to a more robust governance group that meets regularly. This group gathers representatives from multiple teams to align on a quarterly roadmap for system updates. Program sponsors bring change requests to the group, which then votes on how to prioritize them. 
• Program-led work: Another state allows each program area to initiate their own changes. Other program areas can view ongoing projects and choose to engage if they believe their area will be impacted by a change. 
• Client engagement and input: States also described using client input to drive prioritization, such as through monthly committee meetings.

“We have an online improvement committee. So, they meet monthly, and [it has] consumers. And they provide us feedback about their experience working with us, systems, processes. … And we take those and then use those to help prioritize changes.”

State Leader

Plan and Design Updates 

Once agencies have decided on what changes to make, teams plan for and design their approach to implementing the change within the live IEE system. 

How implementation designs are developed and approved reflects a state’s approach to both project management and cross-team collaboration. 

Another state described the role of business requirement documents (BRDs) in preparing to implement system updates. BRDs outline the outcomes that an update must achieve—the what of a system change. These documents then shape the software development life cycle, or how a system change is implemented. 

“Let’s say we need updates to non-citizen eligibility. In that requirements document, we would write a requirement to state how the system needs to react to that policy update. So, we may have to be detailed enough to say, “add a new field” [or] “determine eligibility based off work quarters and five other values in the system.” [This] comes out on the eligibility backend.” 

State Leader

Test and Iterate Updates

States move from planning to deployment through varying levels of iteration. For example, if many client-facing screens are being updated, a team may work iteratively—making changes, inspecting the output, and making more changes based on what they see. Changes to a rules engine may be implemented and tested without the same kind of iterative development. 

States run testing to ensure that all planned updates perform as expected. They described varying approaches to testing, involving different tools and distribution of labor, including:

• A predominantly manual approach: One state we spoke with evaluates changes by manually running up to 400 scenarios in a testing environment mimicking their case management system. Their vendor analyzes how each change impacts anticipated eligibility outcomes at scale, and approves updates to go live once all tests were successfully completed.
• Automated testing: One state described how they are integrating automated testing processes by running changes in a non-production environment mirroring the production environment. From there, they assess if outcomes match expectations, and use those findings to make adjustments before going live. Another state described exploring generative AI and AI-supported code development to build out testing scenarios on a greater scale.
• Engaging real people in testing, including staff members and clients: One state described running testing with staff members working on specific programs—such as SNAP, WIC, or the Temporary Assistance for Needy Families program or TANF—during their acceptance testing process. They also ran testing with real clients at local offices or in coordination with community-based organizations.

“We have a core testing group. So, we have a testing lab in our office, and we bring people in and run through a number of scenarios, which are really staff-based in the sense that we’re bringing in members of the agency which manages the SNAP and TANF and home energy assistance programs…. We’re trying to get those people who work day-to-day in the office to be able to share what that experience is like from their lens.”

State Leader

• Varying levels of vendor testing involvement: One state noted that their vendor completes system integration testing to ensure all system components work together. Their teams then perform user acceptance testing (UAT) to confirm that the system update is performing as expected during given scenarios.

Make Final Changes and Approvals

After testing, states make final changes based on what they learn. From there, they run additional system checks and gather final approvals based on outputs. 

One state we spoke with described a Go/No-Go assessment as the final step before receiving the signoff for deployment from policy teams. 

States must ensure they are also following federal requirements for deployment. For example, the FNS SNAP Eligibility System Go Live Requirements guide the steps from user acceptance testing to piloting to statewide implementation. 

Assessment does not end after deployment. States continue to monitor the impact of changes after they go live, focusing on both technical stability and program performance. 

Train Staff

Even small updates to an IEE system can have implications for frontline staff. Research demonstrates that staff workflows are typically built around the particularities of the technical systems they work with, so changing an application sequence, question, or process means workers may have to adjust how they engage with clients, input data, or assess determinations. 

Depending on the scale of the system update, states offer different levels of training for staff members. States and counties vary in how and when they deliver this training, and which teams are involved. One state described engaging with their agency’s staff training team throughout a build or update project to prepare training materials for eligibility workers prior to launch. Another state noted that the policy team signs off on all training materials. 

Communicate Updates to Clients and Organizations

States described regular communications with clients, community-based organizations, and local agencies to explain and inform these groups of new system changes. For example, Pennsylvania released a SNAP communications toolkit in several formats to broadly share information on H.R. 1 work requirement changes through letters, flyers, and social media graphics and videos. 

Pain Points

States face challenges related to technology, personnel, and processes used for managing IEE systems.

Technology Pain Points

1. Many states are working with IEE systems that have grown incrementally over many years, accumulating significant “technical debt” and complex interdependencies. 

• Several states described the challenges of working with older IEE systems that had grown gradually over many years. Contributing factors include relying on the same vendors for long periods of time, and procuring flawed or already outdated systems from other states.
• States painted a picture of very large systems with complex webs of accumulated interdependencies. System changes are both more intensive and more complicated than in modernized systems, as code in one area of the system inevitably affects many others. One state leader referred to this challenge as “spaghetti code.”

“You put one thing into it, you break something else, and it requires about eight months from the time that we identify something that needs to be changed to the time that we can actually get that change implemented in our system.”

State Leader

• Several states’ IEE systems also have significant “technical debt”—the result of years’ worth of technical problems solved with quick fixes instead of more intensive, but sustainable, upgrades. Addressing the accumulated issues requires major investments. For example, in 2023, Colorado secured $100 million from their legislature to reduce technical debt. Two states we spoke with blamed their technical debt on a failure to remove outdated code when updating systems to reflect policy changes. These outdated systems cost states tens of millions of dollars annually just to run as-is.

• As states make changes over the course of years, historical code and documents often remain in the system for the sake of record-keeping, which inevitably leads to clutter and staff confusion. One state leader described how outdated client-facing notices remained in the system even after being updated, with no context for current staff on how they were used or why they were retained.
• This type of buildup also impacts the front-end experience for applicants, as teams are more likely to add to rather than subtract elements from applications. One state described how their agency had added additional questions over time in response to policy changes—without considering ways to streamline and minimize existing fields. 

2. Systems rely on human data entry, risking errors and reducing efficiency. 

• Older systems inevitably provide a slower, more confusing, and more time-consuming user experience, leading to frustration and errors among caseworkers and clients. For example, one state described how caseworkers must manually enter applicants’ wages, a process which has a high risk of error. Another state shared how their technology is so old that younger workers struggle to navigate certain unfamiliar elements, such as data entry for green screens (a terminal interface that connects to a computer’s mainframe, characterized by green text on a black background). Workers are dispirited by the long wait times for a new system. 

“Everything (the caseworkers) do in the computer eligibility system is dependent upon them coding information. If a worker accidentally puts that an applicant is paid biweekly, but they are really paid weekly, we could have an error on the determination. So, it’s all contingent upon the worker putting the right codes in. … We have much more extensive training for the workers to teach them not only the programmatic side, but what they have to then key in to complete the eligibility.”

State Leader

“[For] the worker, your likelihood of error every time they have to re-key something—if it’s the same data—is just going to increase the error, and we have an error rate issue right now.”

State Leader

3. Integrated front-end web applications mask incomplete backend system integration. 

• Two states discussed the challenges of having a less-than-desired level of integration in their systems. One state used a shared web application for several programs, each with its own backend system. As a result, each time the state adds a program to its shared application, it also adds another backend system—which makes full integration even more challenging.
• Another state shared that, while it has an integrated web application for several Medicaid programs, the application does not automatically transmit clients’ information to the state’s Medicaid exchange. As a result, a caseworker has to manually enter client data into the application to create a case record in the Medicaid exchange’s backend system.

“We have bits and pieces that are strung together with human glue.”

State Leader

“Our staff that are actually out in the field doing the work, the number one complaint they have is how cumbersome and how un-useful the system is. Also, it’s the number one complaint that I get from our customers—that they can’t use our front-end portal. It’s built on a really old design that requires you to answer … 10 security questions before you even set up your access to get in to file a benefits application.”

State Leader

4. The absence of proper development environments and test data make it difficult to simulate complex policy changes and assess their potential impacts.

• Some states described using testing environments that offered some functionality, but are “not as faithfully replicating real life … to run the tests.” Other states described running between 20 to 400 scenarios manually to evaluate the impact of a particular change. 

“I think, for the most part, folks work really hard to implement … changes and implement them accurately, but because of the complexity of it, there are still cases where some of the situations either are missed, or it has impacts that turn out in ways that were not [what] the policy teams intended, because the computer worked in a way that was a bit obtuse and not transparent.”

State Leader

5. Systems have varying levels of technical documentation that require continual maintenance. 

• Because IEE systems are developed over years, with contributions from multiple internal and external stakeholders, technical documentation is critical for understanding system functions and change history. At some state agencies, where documentation processes are underdeveloped or under-maintained, it can be hard for staff to access this needed information. 

“Some of the things that we are thinking about for our future is trying to simplify [what workers have to parse through]. Starting with, ‘How do we document what we want the rules to be from a business perspective?’ Those documents … I’ve been told … used to exist, and then at some point stopped being updated and maintained fully. …So, we don’t have that documentation in the state that we would want. Having … documentation [running through] decision trees of how we want the rules to play out is one thing that … would help—both with being able to say ‘What are the changes that we want to make?’ and also … to predict the outcomes and the testing that we would need to do.”

State Leader

Personnel Pain Points

1. States are working with a consistent deficit of resources. 

• Several states described lacking the capacity to achieve their goals for their IEE systems. Two states expressed a desire to have more team members working on data and program analysis. In one state, program analysts are so in demand that they need two to three weeks to respond to questions. When those team members take time off, work often stops altogether. Another state leader noted that he had to recruit data analysts from a different division, because his state had not invested in increased data analyst capacity for the benefits division.

“We have to have the expectation that we are not outsourcing everything to a vendor. …. We have to staff ourselves differently in order to support this sort of model.”

State Leader

“Some projects do not get to the table, because there’s not enough resources.”

State Leader

• States described how business and policy team members have become responsible for holding technical knowledge and making technology decisions. One policy team member shared how making a policy change in their state’s IEE system requires them not only to specify how the system’s rules should change, but also identify the fields and data needed to implement the change. 

“I mean, I’m a social worker, I’m not a technologist.”

State Leader

2. Employee turnover presents significant risks. 

• Many state IEE projects are run by long-term employees with many years of institutional knowledge, who are hard to replace. Incomplete internal documentation of decisions and changes means that when team members leave, knowledge is inevitably lost—including relevant histories of policy changes. Turnover also means states must confront the challenge of recruiting new developers familiar with the outdated technology undergirding their IEE system.
• Leadership change creates uncertainty and instability. The change of agency leaders, appointed by governors every four years at minimum, produces steep learning curves for onboarding, as well as shifts in priorities. States also report facing challenges recruiting and retaining qualified senior leaders, like chief technology officers. 

“When you have unstable leadership, you can’t do those sort of system redesigns that we’re talking about here. You have to make a decision, you have to have a champion, and then you have to be able to make those decisions to see that through.”

State Leader

Process Pain Points

1. Legislative cycles and technical processes are often misaligned, with the former having a significant impact on system operations and updates.

• State legislatures may make policy changes or appropriate funding on a cadence that does not match an IEE’s approach to product management. Two leaders discussed how their agencies prefer a “componentized” system, where they could work on distinct parts one at a time. This produces an iterative build style featuring regular smaller releases, and allows regular updates incorporating client feedback. As noted above, Congress and state legislatures have historically preferred waterfall-style projects, and thus a funding approach better suited to fewer, larger releases.

“I think our state legislators are getting [a] sense of [what it means to work in an agile process]. But it’s still…a cultural change. It’s going to take some time to fully mature.”

State Leader

• Another state described their desire to release updates on a regular cadence, but noted their legislature often requires changes on a different timeline. This means the agency has to make releases outside of their regular schedule. 
• Two states noted how legislatures and agencies often have different expectations of timing and scale. One leader described how legislators were surprised when the agency took 18 months to update their system with what legislators saw as a “simple” policy change. This leader expressed frustration with the legislature not giving the agency enough time to do things “right.” 
• Legislative priorities may require agencies to push aside ongoing modernization work. One leader shared how their agency has been unable to improve their system’s accessibility because they had to prioritize multiple policy changes from the state legislature. 
• Policy changes that are effective upon enactment are particularly challenging to implement properly, given the lead time needed for guidance development, analysis, and system modifications. The recent SNAP policy changes contained in H.R. 1 are a prime example of legislative misalignment with technical cycles. While some provisions of the bill phase in over several years, others—specifically, revised SNAP work requirements for able-bodied adults without dependents (ABAWDs) and eligibility rules for immigrants with legal status—took effect upon enactment on July 4, 2025, the date of the bill’s signing. FNS technical guidance was not issued until early October 2025, at which point states learned they would be held harmless for 120 days from enactment. This meant new policies had to be implemented by November 1, 2025—less than a month after the guidance was issued. 
• System improvements ultimately hinge on the availability of state funding earmarked for modernization, which requires buy-in from state legislators. Without this, modernization efforts are unlikely to get off the ground.

2. Congress and federal agencies tend to craft policies and guidance for programs in silos, which can make integration challenging.

• While states are designing IEE systems that integrate programs for streamlined delivery, federal programs and their associated policies are crafted in agency and legislative silos that do not account for integrated systems.

“I think one of the things that often frustrates me is we think about these things in such silos. We think about ‘The bill changed this in SNAP, it changed this in Medicaid, it changed this in … refugee and immigrant services.’ But our households are not in just one strata. They sit across maybe all of them.”

State Leader

• Several states pointed to H.R. 1 as an example of how different policies across programs create challenges for IEE system implementation. For example, the bill changed SNAP eligibility for immigrant groups with legal status upon enactment, but set the effective date for the Medicaid work requirement to January 1, 2027. The bill also introduced different work requirements for Medicaid than for SNAP and TANF. 
• The process for requesting federal funding is designed to serve those developing systems for single programs. As discussed above, CMS, FNS, and ACF have varying match rates, APD thresholds, and prior-approval requirements. This forces states working on IEE systems to prepare multiple complex documentation packages for each relevant agency, with little clarity on integrated cost allocation. 
• One state was prohibited from purchasing its ideal rules engine, due to the restrictions from CMS’s 90/10 funding. They ultimately purchased a different rules engine that could only be updated by development contractors, despite wanting changes to be made in-house. 

“There is not yet a really cohesive plan at the federal level for these social safety net programs to braid and blend funding when it comes to really anything—but certainly for system modernization. It is very hard when you’re doing cost allocation, when you’re figuring out who pays for what.”

State Leader

• Finally, programs have inconsistent data sharing policies, prohibiting some areas of integration. As we noted in our background publication on IEE systems, in the past several years, state agencies and civic technology organizations have explored how data sharing and coordination across agencies reduces administrative burden for both clients and staff, leading to improved program enrollment and administration (e.g., Center on Budget and Policy Priorities 2017, Benefits Data Trust 2023, Benefits Data Trust and the Center for Health Care Strategies 2023). But even for programs housed in the same agency, distinct processes and policies—for example, variations in verification and eligibility requirements and different processing timelines—may make data sharing complex, and states often lack clarity on what type of data sharing is allowed.

Given the integrated nature of IEE systems, if one program has prohibitive data sharing rules, it can interfere with how the whole system operates. 

“They are different programs, and so there’s challenges associated with aligning policies in a way that supports integration, but also align[s] data sharing. What can we share together? What can we leverage? Are the [data sharing] rules in this program going to hold us back from doing what we want to do for all of the programs?”

State Leader

3. Coordinating across agencies requires negotiating occasionally divergent priorities and requirements, and involves agency coordination at the leadership and frontline level.

• Many states coordinate their IEE systems between multiple agencies, with different leadership, technical teams, policy teams, finance teams, missions, objectives, and prioritization processes. As one state noted, adding another program means adding another set of decision-makers.

“Aligning [goals and objectives] is really important, and making sure we’re identifying the value-add for each agency is very important.”

State Leader

• Moving to an integrated eligibility model also requires the preparation of eligibility staff. One state discussed challenges integrating caseworkers from different agencies when it first launched its IEE system, as caseworkers who had previously focused on single programs now had to learn new policy and program areas. 

“One thing we found when we launched our integrated eligibility system is staff were listening to their previous agency. … So they would inadvertently cause issues [in] other programs by not understanding how the system worked, what SNAP was saying versus what medical policy was saying, [or] what [was] different around long-term care versus child care, and some of those nuances.”

State Leader

4. Extensive procurement requirements and small vendor pools present challenges in procuring technology vendors.

• There is a widespread lack of competition in federal procurement, with contracts often won by vendors without a single competitor. Research on this topic, from 2015, found this happened 44% of the time. In line with this trend, IEE systems are dominated by only a handful of entrenched vendors. The biggest, Deloitte, currently holds contracts for eligibility systems development in 25 states. Two states we spoke with noted the challenges of this small vendor pool, including difficulty determining which vendor best meets their needs, and the inevitable stifling of innovation.

“There’s the same key tech vendors in this space, right? And I went to [a conference] last fall. And after a while all the different applications sound the same. … And it’s like, okay, how do we suss out what really is the best solution?”

State Leader

“I keep seeing the same system packaged differently from a different vendor, and it is just over and over and over again. … I’ve met with every vendor, I think, in the country at this point. And it all looks the same after a while … None of it really looks innovative.”

State Leader

• One leader said that their state’s procurement requirements make it difficult to find new vendors to get new technology systems up and running. 
• In cases where states have worked with the same vendors for several years, the vendors have accumulated a large amount of knowledge about their systems, making it difficult for new vendors to compete. One state pointed to the lack of technical documentation as an added challenge for onboarding new vendors.

Alternative Approaches

States are looking towards a future in which alternative processes and improved technology make IEE systems easier to build and maintain. 

Goals for Alternative Processes

1. Less dependence on vendors and more in-house capacity. 

Two states expressed a desire to update and maintain their systems without relying heavily on vendors. They cited both the costs and time associated with engaging a vendor for system updates, as well as the lack of innovation that vendors have historically brought to IEE projects. One state already operates their system in-house, and other states are considering the possibility of bringing more IEE operations in-house.

2. New governance models to prioritize IEE projects. 

Two states discussed ongoing efforts to design new governance models to better gauge priorities for system updates. They are weighing factors such as value for clients and the agency, level of effort, cost, and available resources when deciding which projects to prioritize. One state was motivated to adopt a new prioritization model, so decisions would have more consensus, resulting in fewer changes later.

“You can’t have a lot of structure and no decision-making. You have to have decisions made, and then you have to stand by those decisions. You can’t make a decision one month and then turn around and revisit it, and change that decision the next month.”

State Leader

Goals for Alternative Technology

1. Improved client experience through more efficient and human-centered technology, including mobile-first applications, integrated data, and client correspondence.

1. Prioritizing seamless, mobile-first applications that center people’s needs. States know that clients’ need for well-designed and high-functioning government technology are only growing. Today, 16% of U.S. adults are smartphone-dependent, meaning they have a smartphone, but no other way to access the internet at home. For this population—largely made up of lower-income Americans—mobile-friendly applications are crucial for providing equal entry points to the benefits they’re likely eligible for. In 2024, Code for America reported an increase in mobile-friendly online applications—69% of surveyed applications, up from 43% in 2019. 
   • States know that client expectations are growing alongside their needs. Smartphone-dependent clients are also more likely to be younger—digital natives with high expectations for technology quality. They want fast, reliable service and high usability, similar to that of their favorite consumer apps.

“About 92% of our consumers have a smartphone. Not just a cellphone, but a smartphone. And when you look at the majority of our users who follow in that 18 to 35 demographic, they’ve been raised on smartphones. … They expect us to be operating from a system that doesn’t look like a 24-page paper application that maybe you get something in the mail a couple weeks from now that tells me what I should do, and what I should respond to. We just have to enter into it with that mindset—that mobile is first—and then we support our work from the end of it.”

State Leader

2. Enabling systems to integrate client data across programs. States are weighing the desire to protect client data while also streamlining user experience. Some acknowledged the risks posed by sharing and integrating data across programs and agencies, but also described wanting a more fully integrated system that only requires clients to provide their information once. They noted that this approach would improve the client experience by allowing them to focus on their needs, such as hunger, instead of requiring familiarity with the relevant program, such as SNAP. It would also create efficiencies for caseworkers. These benefits are supported by other research (e.g., Code for America 2025, Code for America 2019, Herd and Moynihan 2018).

“You don’t have to know you’re applying for SNAP, you don’t have to know you’re applying for Medicaid, you don’t have to know you’re applying for TANF. You can come in and tell somebody that you’re hungry. And we just gather the information to help get your need met.”

State Leader

3. Improving client correspondence. Three states discussed ongoing work to improve client communication, and are implementing solutions—such as rewriting notices using plain language and clear instructions—to help clients better understand important information.

“We go to a model that focuses on the need of the individual, we gather the information that is necessary to get that need met, and we get you to the agency to meet that need. [Regardless], if that’s my agency, awesome. If that’s not my agency, I get you universally connected to the housing agency, or to Veterans Affairs, or to the WIC agency. I don’t need to say, ‘Oh, we don’t do WIC here, so go over there and apply for WIC.’ … I can literally get your need met and just get you there seamlessly—so from a customer standpoint, you don’t know any difference.”

State Leader

2. Rules engines that are easier for cross-disciplinary teams to update and understand. 

States described current rules engines as complex and cumbersome to update. One state noted that updating rules currently requires deploying their entire application, even if only changing a single rule set.

“I’ve also been told that there are places where [our team has] … found ways to make it simpler for people, but they haven’t [rolled this out], because the amount of effort it would take to implement in our system is too high.”

State Leader

Two states expressed the desire to simplify their rules engines so non-technical team members could update and interact with them. Describing their agency’s process for updating rules, one state leader noted, “We have these things right now called reference tables, where it’s basically like an Excel sheet. And they have a 30-day turnaround to update them. And in some cases, we’ve been able to convert those into live tables that, if you have the access, you can go in and just change what’s in there, and it’s instant. So, I feel like my ideal future state is … we could just go in and modify a table and say, ‘Do this as of this date, save, done!’”

As noted above, states may have varying levels of current documentation around their rules engines. Clear documentation is also key to enabling team members to understand and effectively maintain rules engines over time.

3. Rules engine eligibility calculations that are easier for caseworkers to understand and engage with.

Caseworkers’ limited insight into the rules governing IEE systems results in outputs that are confusing rather than clarifying. As one state leader told us: “Right now, the determinations come back, and it’s hard to know exactly what happened … Our caseworker[s] would tell us that they spend a lot of time trying to figure out what led to that, and maybe where … they make a data entry error that is causing the determination to come out differently than what they were expecting. So, having that traceability is also really huge.”

4. Modular systems with easy-to-replace components.

Multiple states mentioned a desire for modular systems, with different software supporting different key functions. This would keep systems from being too interdependent, allowing states to easily replace one module without impacting others. For example, many systems have separate rules engines that can be modified and called independently of the application or case database.

“How could we modularize our system … so we can still make updates to what a consumer wants on a portal, or what a staff person wants on their side of it—you know, really allowing greater flexibility?”

State Leader

5. AI-based alternatives that support people and processes.

Artificial intelligence (AI) and automation were common themes in our conversations. Many of the states we spoke with are in the process of considering how AI can support their IEE work. States are exploring using AI to: 

1. Provide answers to customers through call centers or chatbots using natural language processing.
2. Collect client data through Interactive Voice Response (IVR).
3. Translate information and communications for clients who are not English speakers. 
4. Determine potential eligibility through chatbots using a rules-based screener. 
5. Help suggest programs that clients may be eligible for. 
6. Process documents intelligently for case notes and to facilitate a digital mailroom.
7. Build out test scripts and scenarios system quality assurance.
8. Support narrative writing for caseworkers. 

One state described a “proof of concept” approach, testing out automation ideas to understand their impact before scaling:

“We’re focused on what we’re training the model against and how we’re validating that the information we’re getting is correct and accurate, and then releasing that. As opposed to trying to say, ‘Here are all the benefits and all the programs.’, we’re really trying to take baby steps and be constrained with our guardrails [on expanding] … what’s available from the chatbot.”

State Leader

Outlook for Alternative Approaches

While states are optimistic about the promise of new processes and technology to improve IEE systems, they face hurdles in implementing these improvements. These echo the common pain points cited throughout this report: a consistent lack of funding and capacity, and divergent priorities from state and federal administrations. 

For AI-based alternative approaches, agencies are working at a moment where there is significant enthusiasm for the technology, but states have few examples of large-scale government AI implementations to point to and learn from. One state experimenting with AI noted that it is doing so cautiously to ensure the accuracy of AI-generated results and to protect clients’ personally identifiable information. Another state noted that state leadership was taking a conservative approach, using a statewide AI task force to set guidance on how AI could be adopted by state agencies. 

Automation also comes with considerations for the rights and protections of the state workforce. In addition to assessing the risks automation poses to clients and systems, state agencies must also weigh how changes will impact existing staff. In some cases, this work is required by federal regulation. For example, FNS requires state agencies to submit a request to use AI or other automation tools to complete certain tasks—both to address potential biases and security risks, and to explain how the change will affect merit staff. As automation becomes increasingly prevalent, states should expect to work with labor unions to adapt roles and ensure that rights and protections are in place. 

At the same time, states are thinking about other pathways to changing their systems, including new ways of working and collaboration. Two states raised rules as code approaches as potential pathways to ease the work of updating, maintaining, and engaging with rules engines. One state had recently contacted another state to view their eligibility rules, hoping to learn from their approach and apply it to their own system.

Recommendations

Based on our conversations with states, we offer the following recommendations to meet states at different points in their integration journey—ranging from items more easily within agency control of their IEE systems to the upstream policies, funding, and processes that inform them.

Legislation 

• Design legislation that considers benefits programs collectively rather than in isolation to reduce differing—and at times conflicting—eligibility criteria definitions and requirements. 
• Support funding models that decrease administrative burden for states that must “braid and blend” federal funding to modernize their systems.
• Engage with the state IEE team to synchronize the effective dates of legislation with feasible development cycles and implementation roadmaps. 

Stakeholder Engagement 

• Adopt a governance model that enables collaboration and transparency between partner agencies. 
• Create shared resources (e.g., reports, informational sessions) for executive leaders and legislators to understand the state’s IEE system, and the processes involved in maintaining and updating these systems.

In-House Capacity 

• Build in-house technical and product management capacity to ensure internal leadership of IEE system processes and development.
• Establish a product management paradigm responsive to policy changes, user needs, and technical inefficiencies. 

Technology 

• Keep code and technical documentation up-to-date and in a shared repository, enabling technologists, policy, and business teams to understand the system and maintain institutional knowledge.
• Break the system architecture into modular components that allow for independent control and the development of specific features. 
• Build rules engines independent of core application and case management functionalities, ideally with a common rules structure across systems (e.g., a Rules as Code approach), and provide support for traceability in eligibility calculations. 
• Invest in development environments, and test data and automation prior to deployment to make it easier to test changes. 

Procurement 

• Use modular system architecture to break procurements into smaller scopes and potentially attract a more diverse vendor pool. 
• Use Request for Information (RFI) processes to share strategies, analyze the vendor landscape, and answer key questions before designing Requests for Proposal (RFPs) and detailed requirements (see Louisiana and Minnesota examples).

Conclusion

State IEE teams are continually iterating on their processes and technologies to enable improvements for clients and state workers. While some states are delivering successfully and with modern practices, significant pain points prevent many states from efficiently transforming their integrated digital benefits delivery. We hope that by creating public documentation of these considerations, this report can support and guide more efforts to improve and modernize these systems. 

This publication concludes our series on Implementing State Eligibility + Enrollment Systems. You can review our other publications in this series to: 

• Gain key background information on IEEs, including what an IEE is, the relevant technology landscape, and the roles and stakeholders involved
• Understand how state agencies are responding to federal policy changes and their impacts on IEE systems

Get in Touch 

As of January 2025, the Digital Benefits Network merged into the Digital Government Network. We’re still here to help. We are able to connect you to peer state leaders, nonprofits seeking collaboration, and the latest resources and research. Get in touch at digitalgovernmentnetwork@georgetown.edu. 

Acknowledgments 

Thank you to the state leaders who spoke with us about their IEE systems. 

Thank you to Sabrina Toppa for copy-editing.

Citation

Ariel Kennan, Elizabeth Bynum Sorrell, Rachel Meade Smith, and Jason Goodman. “Implementing Benefits Eligibility + Enrollment Systems: Insights on State Approaches and Processes,” Beeck Center for Social Impact + Innovation, February 4, 2025, https://digitalgovernmenthub.org/publications/implementing-benefits-eligibility-enrollment-systems-insights-on-state-approaches-and-processes/.