How State Workforce Agencies Can Roll Out New Case Management and Jobseeker Portal Systems to Local Career Centers and Frontline Staff

On the Monday a state’s new case management system goes live, a career center opens its doors to a line of jobseekers. A career advisor tries to log in and is prompted to reset a password she did not know she needed. A colleague finds that a participant’s training plan, entered in the old system months ago, does not appear in the new one. At the front desk, a jobseeker says she tried to register on the new online portal over the weekend and could not get past the identity verification step. The phone rings repeatedly with similar questions. The help desk line has a long wait. By midday, the manager has sent an email to the state asking what to do, and staff are writing notes on paper to enter later. None of the people in the office doubt that the new system will eventually be better. All of them wish they had been better prepared for the first day.

State workforce agencies periodically replace or upgrade the technology systems that support the public workforce system: case management systems that record participant eligibility, services, and outcomes; jobseeker portals through which residents register, search for jobs, and access services; employer portals for posting jobs and managing recruitment; and reporting systems that produce federal performance data. These systems are central to daily work. Frontline staff use them constantly. Participants and employers increasingly interact with the workforce system through them. When systems change, nearly everyone in the workforce system is affected.

System rollouts are often treated primarily as technology projects, managed by information technology staff and vendors, with communication limited to announcements of launch dates and training schedules. But the success of a rollout depends heavily on whether the people who will use the system understand why it is changing, are prepared to use it, know what to expect during the transition, and receive help when problems arise. Technology that works perfectly can still produce a failed rollout if users are confused, resistant, or unsupported. Technology with problems can still produce a successful rollout if users are prepared, informed, and supported through difficulties.

This article examines how state workforce agencies can roll out new case management and jobseeker portal systems to local career centers and frontline staff. Its central argument is that system rollouts are communication and change management efforts as much as technology projects, and that success depends on explaining the case for change, involving frontline staff early, communicating timelines and readiness honestly, training staff for real work, preparing participants and employers, supporting users intensively through go-live and after, protecting continuity of service, ensuring accessibility, and managing problems with candor.

Why System Rollouts Are Communication Challenges

State workforce agency staff introducing a new case management system to local career center teamsTechnology projects have technical risks: software defects, integration problems, data migration errors, performance issues. They also have human risks: users who do not understand the system, resist change, lack time to learn, or lose trust when early problems occur. In the workforce system, human risks are often as consequential as technical ones, and they are largely communication risks.

The first challenge is the centrality of systems to daily work. Frontline staff in career centers use case management systems for nearly every interaction: registering participants, documenting eligibility, recording services, entering case notes, approving training, and tracking outcomes. A new system changes how they do their jobs. Even when the new system is better, learning it takes time and attention, and productivity typically dips during the transition. Staff who are not prepared experience the rollout as a disruption imposed on them.

The second challenge is the number and diversity of users. A statewide system serves state staff, local board staff, career center staff employed by many different providers, partner program staff, and sometimes training providers. Users vary in role, technical skill, and comfort with change. Communication must reach all of them through multiple organizational channels, many of which the state does not directly control.

The third challenge is public-facing change. Jobseeker and employer portals affect the public directly. Residents accustomed to one registration process must learn another. Employers must learn new ways to post jobs. Public users have no training, may have limited digital skills or access, and will contact career centers or help lines when they encounter problems, adding to staff workload during the transition.

The fourth challenge is uncertainty and delay. System projects frequently encounter delays, scope changes, and unexpected problems. Launch dates may shift. Features may be deferred. Communication must manage expectations honestly through this uncertainty, without undermining confidence or promising dates that cannot be met.

The fifth challenge is the gap between project teams and users. System projects are often managed by information technology staff and vendors who understand the technology deeply but may not fully understand frontline workflows. Users may feel that the system was designed without their input. Communication that connects project teams with users, in both directions, improves the system and builds acceptance.

The sixth challenge is continuity of service. During the transition, career centers must continue serving participants and employers. Data must migrate from old to new systems without loss. Participants in the middle of services must not be disrupted. Communication must address how continuity will be protected and what to do when problems arise.

The seventh challenge is reporting and accountability. Case management systems produce the data used for federal performance reporting. Transitions can affect data quality and reporting, with implications for performance results. Local areas need to understand how the transition will affect their data and how the state will address any effects.

The eighth challenge is fatigue and skepticism. Staff who have experienced previous troubled system rollouts may approach a new one with skepticism. Communication must acknowledge past experience and demonstrate that this rollout will be handled differently.

These challenges mean that communication cannot be an afterthought in a system rollout. It must be planned from the beginning of the project, resourced adequately, and integrated with technical milestones. The sections that follow describe how.

Skilled & Connected: Communication Strategies for Workforce Development Agencies, Career Centers, and Local Employment Services

This article is part of our series on strategic communication for Workforce Development Agencies, Career Centers, and Local Employment Services. To learn more and to see the parent article, which links to other content just like this, click the button below.

Audiences and What Each Needs

A system rollout affects many audiences, each with different roles, concerns, and information needs. A communication plan that identifies these audiences and tailors communication to each is more effective than a single stream of announcements.

State and Local Leaders

State agency leaders, local workforce board directors, and provider managers need to understand the purpose and benefits of the new system, the timeline, the resources required, the effects on operations and performance, and their roles in preparing staff. They need early, candid information so they can plan staffing, schedule training, adjust workloads, and communicate with their teams. They also need to know how to escalate problems.

Frontline Staff

Career advisors, eligibility staff, business services representatives, front-desk staff, and others who use the system daily need practical information: what the system will look like, how their work will change, when they will be trained, what to do during the transition, how to get help, and what will happen to the data they rely on. They need hands-on training that reflects their actual work. They also need reassurance that their concerns will be heard and that the state understands the burden of transition.

Partner Program Staff

Staff of partner programs who use the system, such as Wagner-Peyser, Trade Adjustment Assistance where available, veterans’ employment programs, or other co-enrolled programs, need similar information tailored to their workflows and any program-specific features.

Data and Reporting Staff

State and local staff responsible for data quality and performance reporting need detailed information about data migration, data definitions, reporting changes, and how the transition will affect performance data.

Training Providers

Training providers on the eligible training provider list may use portals to submit program information or performance data. They need to know about changes in submission processes and timelines.

Jobseekers

Residents who use the jobseeker portal need to know what is changing, when, what they need to do, such as creating new accounts or verifying identity, whether their existing information will carry over, and where to get help. Communication must be plain, accessible, multilingual, and delivered through channels jobseekers use.

Employers

Employers who post jobs or use other online services need to know about changes in how they access services, whether existing job postings and accounts will transfer, and whom to contact for help.

Unemployment Insurance Claimants

In many states, unemployment insurance claimants are required to register with the workforce system or the state job bank. Changes in the jobseeker portal may affect claimants’ ability to meet work search or registration requirements. Communication must be coordinated with unemployment insurance programs so that claimants are not penalized for transition problems.

Elected Officials and the Public

Major system projects may attract attention from legislators, the media, and the public, particularly if they are costly or encounter problems. Leaders may need to communicate about the project’s purpose, progress, and any difficulties.

Mapping these audiences, along with what each needs at each phase of the rollout, provides the foundation for a communication plan. The plan should assign responsibility for communicating with each audience, identify channels, and schedule communications aligned with project milestones.

Building the Case for Change

People are more willing to invest effort in learning a new system when they understand why it is needed and how it will benefit them. Frontline staff who see a new system as an arbitrary imposition, or as benefiting only the state’s reporting needs, will approach it reluctantly. Staff who understand how it will make their work easier or better, or why the old system could no longer serve, are more likely to engage constructively. Building the case for change is the first communication task of any rollout.

The first element is explaining why the current system must change. Staff often know the old system’s limitations well, but they may not know the full reasons for replacement, such as outdated technology that can no longer be supported, security vulnerabilities, inability to meet new federal reporting requirements, vendor contract expiration, or high maintenance costs. Explaining these reasons honestly helps staff understand that change is necessary, not merely preferred.

The second element is describing benefits concretely. Abstract benefits, such as modernization or improved efficiency, mean little to frontline staff. Concrete benefits, such as fewer duplicate data entry steps, the ability to see a participant’s full service history in one place, automatic eligibility checks, mobile access, or easier document uploads, connect the system to staff’s daily experience. Benefits for participants, such as online registration, document submission, and appointment scheduling, should also be described. Benefits should be described accurately, without overpromising.

The third element is acknowledging costs. Staff know that learning a new system takes time and that early weeks may be difficult. Acknowledging this honestly, rather than presenting the transition as seamless, builds credibility. Leaders can explain how they will support staff through the transition, such as by adjusting workloads, providing extra help, or adjusting expectations temporarily.

The fourth element is consistent leadership messaging. Staff look to state and local leaders for signals about whether a change matters and will succeed. When leaders at all levels express consistent support for the new system, explain its importance, and acknowledge the effort involved, staff are more likely to engage. Mixed messages, such as a local director expressing skepticism while the state promotes the system, undermine adoption.

The fifth element is addressing past experience. If previous system rollouts went poorly, staff may expect the same. Acknowledging past difficulties and explaining what is being done differently, such as more user involvement, more training, or a phased rollout, addresses skepticism directly.

The sixth element is connecting to mission. Ultimately, the workforce system exists to serve jobseekers and employers. Explaining how the new system supports that mission, such as by giving staff more time with participants or making services more accessible, connects the change to what staff care about.

The case for change should be communicated early in the project, before training and launch, and reinforced throughout. It should be repeated in different forms, through leadership messages, staff meetings, demonstrations, and frequently asked questions, since people absorb messages through repetition. And it should be grounded in reality: if the system does not deliver promised benefits, credibility suffers.

Involving Frontline Staff Early

Systems designed without input from the people who will use them often fit poorly with real workflows, and staff who had no voice in design are less likely to embrace the result. Involving frontline staff early, in requirements, design, testing, and rollout planning, improves the system and builds the network of informed advocates that a successful rollout needs.

The first form of involvement is requirements gathering. Before a system is designed or configured, frontline staff can describe how they do their work, what information they need, what frustrates them about the current system, and what would help. Interviews, focus groups, and workflow observation in career centers provide insights that project teams cannot obtain from documentation alone. Including staff from different roles, local areas of different sizes, and partner programs ensures that diverse workflows are understood.

The second form is design review. As the system is configured, staff can review screens, workflows, and forms, identifying problems before they are built in. Early prototypes or demonstrations allow staff to react to concrete designs. Their feedback should be considered seriously and, where it cannot be accommodated, explained.

The third form is user acceptance testing. Before launch, frontline staff can test the system using realistic scenarios, such as registering a participant, documenting eligibility, recording services, and approving training. Testing by actual users reveals problems that technical testing misses, such as confusing navigation, missing fields, or workflows that do not match practice. Testers should represent diverse roles and local areas.

The fourth form is super-users or champions. Many successful rollouts identify and train a network of super-users, staff in each local area or office who receive early, in-depth training and serve as local experts and first-line support for colleagues. Super-users can answer questions, demonstrate features, relay problems to the project team, and model positive engagement. Their credibility as peers often exceeds that of state trainers.

The fifth form is rollout planning input. Frontline staff and local managers can advise on rollout timing, such as avoiding periods of peak workload; training formats; and support needs. Their input helps the state design a rollout that fits local realities.

The sixth form is ongoing feedback channels. Throughout the project, staff should have easy ways to share questions, concerns, and suggestions, and should see that their input is considered. Regular updates describing what feedback was received and how it was addressed demonstrate that involvement is meaningful.

Involving frontline staff requires time from staff who are already busy, and from local managers who must release them. States should recognize this burden, schedule involvement efficiently, and, where possible, provide backfill or adjust expectations for participating staff. The investment pays off in a system that works better and a workforce prepared to use it.

Involvement also has communication value in its own right. Staff who participated in design and testing can tell colleagues truthfully that frontline staff helped shape the system, which builds credibility. Their stories about how their feedback changed the system are among the most persuasive messages a rollout can have.

The Role of Local Leaders and Providers

State agencies own statewide systems, but they rarely employ the staff who use them most. Career center staff are typically employed by local boards, contracted service providers, partner agencies, or state agencies operating under different lines of authority. This means that rollout communication must flow through local workforce directors, provider managers, and partner supervisors, who translate state messages for their teams, release staff for training, adjust workloads, and model attitudes toward the change. Equipping these local leaders is one of the most important parts of rollout communication.

The first need is early, candid briefings. Local leaders should hear about the system project early, with honest information about its purpose, timeline, resource demands, and risks. Leaders who are surprised by demands for staff time or launch dates cannot plan effectively and may resent the project. Regular leader briefings throughout the project, separate from staff communication, allow leaders to ask questions and raise concerns.

The second need is a clear description of local responsibilities. Leaders need to know what the state expects them to do: identify super-users, ensure staff complete training, complete readiness checklists, clean up data, arrange coverage during launch, communicate with participants and partners, and report problems. A concise list of responsibilities and deadlines, with the support the state will provide, allows leaders to plan.

The third need is messaging support. Local leaders will be asked by their staff why the system is changing, how it will affect them, and what will happen if problems occur. Providing leaders with talking points, frequently asked questions, and short presentations they can use at staff meetings helps them deliver consistent, accurate messages. Leaders who feel equipped are more likely to speak positively about the change.

The fourth need is attention to contractual and employment relationships. Providers operate under contracts with local boards, and their staff time is budgeted. Significant training and launch demands may affect provider capacity and performance. Boards and the state should communicate with providers about these demands early and consider whether contract expectations, such as service volumes during launch, need adjustment. Where staff are covered by collective bargaining agreements, changes in work processes may require appropriate engagement with labor representatives.

The fifth need is a voice in decisions. Local leaders know their operations and can advise on rollout timing, training formats, and support needs. Including them in rollout planning, such as through an advisory group of local directors, improves decisions and builds commitment.

The sixth need is escalation paths. During and after launch, local leaders need a clear way to escalate serious problems, such as widespread access failures or payment disruptions, to state decision-makers. Knowing whom to call, and trusting that escalations will receive prompt attention, prevents frustration from building.

The seventh need is recognition. Local leaders and providers carry much of the burden of rollout. Acknowledging their effort, publicly and privately, sustains goodwill through a demanding period.

When local leaders understand the change, support it, and have the tools to lead their teams through it, the state’s rollout messages are reinforced in every career center. When local leaders are uninformed or skeptical, even the best state communication struggles to reach frontline staff.

Communicating the Timeline and Readiness

System projects follow timelines with milestones: design completion, testing, training, data migration, launch, and post-launch stabilization. Local areas need to plan around these milestones, scheduling staff for training, adjusting workloads, preparing participants, and coordinating with partners. Yet system timelines frequently change. Communicating timelines honestly, and communicating readiness clearly, helps local areas plan and preserves trust when dates shift.

The first principle is sharing the timeline early and in detail. Local leaders should receive a timeline showing key milestones and what they will need to do at each stage, well in advance. A rollout calendar showing training windows, data freeze periods, launch dates, and support periods allows local areas to plan.

The second principle is distinguishing firm dates from targets. Some dates are firm; others are targets that depend on testing and readiness. Labeling dates appropriately, such as target launch in a stated month, subject to readiness criteria, sets realistic expectations.

The third principle is defining readiness criteria. Rather than committing to a launch date regardless of readiness, states can define criteria that must be met before launch, such as completion of testing with defects below a threshold, successful data migration trials, training completion rates, and help desk readiness. Communicating these criteria helps local areas understand that launch depends on readiness, and reassures them that the state will not launch a system that is not ready.

The fourth principle is communicating changes promptly. When timelines change, local areas should hear immediately, with an explanation of why and what the new timeline is. Local areas that have scheduled training, adjusted staffing, or informed participants based on a date need time to adjust. Repeated last-minute changes erode trust and planning.

The fifth principle is honesty about delays. Delays are common in system projects. Explaining delays candidly, such as testing revealing problems that need to be fixed, builds more trust than vague explanations. Staff generally prefer a delayed launch of a working system to an on-time launch of a broken one.

The sixth principle is local readiness checklists. The state can provide checklists of steps local areas should complete before launch, such as ensuring all staff have accounts, completing training, cleaning up data in the old system, preparing participant communications, and arranging staffing coverage for launch week. Checklists help local areas prepare systematically, and the state can track readiness across areas.

The seventh principle is go and no-go communication. As launch approaches, the state should communicate its decision on whether to proceed, based on readiness criteria, with enough notice for local areas to execute final preparations. If the decision is to delay, local areas should know immediately.

The eighth principle is phased rollout communication. Some states roll out systems in phases, by region, function, or user group. Phased rollouts allow lessons from early phases to inform later ones. Communication should explain the phasing, what each phase includes, and how lessons are being applied.

Clear timeline and readiness communication allows local areas to prepare effectively and reduces the chaos that occurs when launches arrive unexpectedly or are changed at the last minute.

Connecting Technical Teams and Users

System projects are typically run by project managers, information technology staff, and vendors whose expertise lies in technology, while the system’s users work in career centers with expertise in serving jobseekers and employers. These groups speak different languages, work under different pressures, and often have little direct contact. Many rollout problems arise in the gap between them: technical teams make design or timing decisions without understanding their effect on frontline work, and users experience the system without understanding the constraints technical teams face. Communication that connects these groups improves both the system and its reception.

The first practice is a dedicated communication or change management role on the project team. Someone responsible for user communication, who understands both the technology and frontline work, can translate between the two, ensure that user perspectives inform decisions, and keep users informed. Without such a role, communication tends to be left to technical staff with other priorities.

The second practice is translating technical updates. Project status reports written for technical audiences, full of references to sprints, builds, defects, and environments, mean little to users. Translating updates into plain language, focused on what users will experience and when, makes them useful. A brief monthly update for local leaders and super-users, describing progress, upcoming milestones, and any changes, keeps users connected to the project.

The third practice is bringing users into technical decisions. When technical teams face trade-offs, such as whether to delay launch to fix a defect or to launch with a workaround, input from users about the practical effects helps teams decide well. A standing group of frontline representatives available for quick consultation supports this.

The fourth practice is bringing technical staff to the field. Technical staff and vendor representatives who visit career centers, observe staff using the old system, and later watch staff use the new one gain understanding that documentation cannot provide. These visits also show users that the project team cares about their experience.

The fifth practice is clear vendor communication roles. Vendors often play significant roles in configuration, training, and support. Users need to know when to contact the state and when the vendor, and messages from vendors should be consistent with state messages. The state should coordinate vendor communication with users rather than allowing parallel, uncoordinated channels.

The sixth practice is a shared defect and enhancement process. Users report problems and suggestions; technical teams prioritize and resolve them. A transparent process, in which users can see the status of reported issues and understand how priorities are set, connects the two groups and reduces frustration.

The seventh practice is shared celebration and learning. When milestones are reached or problems resolved, recognizing the contributions of both technical teams and users reinforces that the rollout is a joint effort.

Bridging the gap between technical teams and users turns a technology project into a shared undertaking. Users who understand the project’s constraints are more patient with its difficulties, and technical teams who understand users’ work build systems that serve them better.

Training That Prepares Staff for Real Work

Training is the most direct way to prepare staff for a new system, and it is often where rollouts falter. Training that consists of generic demonstrations of system features, delivered weeks before launch with no opportunity for practice, leaves staff unprepared for the specific tasks they perform daily. Training designed around real work, delivered at the right time, with practice and ongoing reinforcement, prepares staff to use the system effectively from the first day.

The first principle is role-based training. Staff in different roles use the system differently. Eligibility staff, career advisors, business services representatives, managers, and data staff need training focused on the tasks they will perform. Role-based curricula avoid wasting time on irrelevant features and ensure depth on relevant ones.

The second principle is scenario-based learning. Training should walk staff through realistic scenarios, such as registering a dislocated worker, documenting youth eligibility, approving an individual training account, entering case notes, or recording a follow-up contact. Scenarios connect system features to actual work and help staff understand workflows, not just screens.

The third principle is hands-on practice. Staff learn systems by using them. A training environment where staff can practice without affecting real data allows them to build familiarity and confidence. Practice should continue after formal training, so staff can rehearse tasks before launch.

The fourth principle is timing. Training delivered too early is forgotten by launch; training delivered too late leaves no time for practice. Ideally, core training occurs a few weeks before launch, with practice time and refresher sessions just before go-live. Training should not be scheduled during periods of peak workload when staff cannot focus.

The fifth principle is multiple formats. Staff learn differently and have different schedules. Combining live instruction, in person or virtual, with recorded sessions, written guides, short videos, and quick reference cards accommodates different learning styles and allows staff to revisit material.

The sixth principle is job aids. Quick reference guides, step-by-step instructions for common tasks, and screen-by-screen walkthroughs help staff during the first weeks of use, when they cannot remember everything from training. Job aids should be concise and easy to find.

The seventh principle is accounting for workflow and policy changes. New systems often change workflows, and sometimes policies, not only screens. Training should explain workflow changes, such as new steps in eligibility determination or different approval processes, and connect them to policy guidance.

The eighth principle is training trainers and super-users. Super-users trained in depth can deliver or support local training, answer questions, and provide coaching after launch. Their local presence extends the state’s training capacity.

The ninth principle is verifying readiness. Brief assessments or practice exercises can confirm that staff can perform key tasks before launch. Staff who struggle can receive additional support.

The tenth principle is continuing training after launch. Questions and problems that arise after launch reveal training gaps. Follow-up sessions, refreshers, and updated job aids address these gaps. New staff hired after launch need onboarding training, which should be built into ongoing training offerings.

Training requires staff time, and local managers must release staff from service delivery to attend. States can help by scheduling training flexibly, offering multiple sessions, and recognizing that service capacity may be temporarily reduced. Adequate training is an investment that reduces errors, frustration, and help desk demand after launch.

Preparing Jobseekers and Employers for a New Portal

When a new system includes public-facing portals for jobseekers and employers, the rollout reaches far beyond career center staff. Residents and businesses who use the portal receive no formal training, may have varying digital skills, and will form impressions of the workforce system based on their experience. Preparing them for the change reduces frustration and help desk demand and protects the system’s reputation.

The first step is advance notice. Jobseekers and employers who currently use the old portal should be informed well before the change: what is changing, when, what they will need to do, and whether their existing information will transfer. Notices can be delivered through email to registered users, messages on the old portal, career center signage, social media, and partner organizations.

The second step is explaining what users need to do. If users must create new accounts, reset passwords, verify identity, or re-enter information, they need clear instructions. Step-by-step guides with screenshots, short videos, and plain-language frequently asked questions help users complete these steps. Instructions should be tested with real users before release.

The third step is addressing identity verification. Many modern portals require identity verification, which can be a significant barrier for some users, such as those without government identification, credit histories, or smartphones. Communication should explain verification requirements clearly, describe alternatives for those who cannot complete online verification, and direct users to in-person assistance.

The fourth step is coordinating with unemployment insurance. Where claimants must register in the jobseeker portal to meet requirements, communication must be coordinated with unemployment insurance programs. Claimants need to know how the change affects their requirements, and states should consider flexibility for claimants affected by transition problems, consistent with applicable rules.

The fifth step is preparing career center staff to help. Staff will receive questions from jobseekers and employers about the new portal. They need to be familiar with the public-facing portal, not only the staff-facing case management system, and should have materials to share. Career centers can offer assisted registration sessions or designated help times during the transition.

The sixth step is employer communication. Employers who post jobs need to know whether existing postings will transfer, how to access the new portal, and how to get help. Business services staff can reach key employers directly, and communication through employer networks and chambers can reach others. Employers who rely on the system for recruitment need assurance that disruption will be minimal.

The seventh step is accessibility and language access. Public-facing portals must be accessible to people with disabilities and available in languages common in the community, and communication about the portal must be similarly accessible. This is discussed further below.

The eighth step is a public help line and online support. Users who encounter problems need a clear place to get help, whether a phone line, chat, email, or in-person assistance. Help resources should be well staffed during the transition, when demand peaks.

The ninth step is feedback collection. Gathering feedback from public users, through brief surveys, help desk data, and staff observations, reveals usability problems that can be addressed through system changes or improved instructions.

Public users judge the workforce system by their experience. A smooth portal transition, with clear communication and accessible help, reinforces confidence; a confusing one, with no help available, damages it.

Communicating Through Go-Live

Career center staff learning how to use a new jobseeker portal during a hands-on training sessionThe days surrounding launch are the most intense period of any rollout. Users encounter the system in real work for the first time, problems surface, questions multiply, and anxiety runs high. Communication during go-live must be frequent, coordinated, and responsive, ensuring that users know what is happening, where to get help, and how problems are being addressed.

The first element is a pre-launch countdown. In the days before launch, communication should remind users of key information: the exact launch date and time, any cutover period when neither system is available, what to do during cutover, how to log in for the first time, where to find job aids, and how to get help. A short checklist for each user to complete before launch, such as confirming account access, helps prevent first-day problems.

The second element is cutover instructions. During the transition from old to new system, there may be a period when data are being migrated and neither system is fully available. Career centers need clear instructions on how to serve participants during this period, such as using paper forms to be entered later, and how to enter that information afterward.

The third element is a central command structure. Many successful launches establish a command center or rollout support team that monitors the system, tracks issues, coordinates fixes, and manages communication. A clear structure ensures that problems reported from the field reach the people who can fix them and that communication back to the field is coordinated.

The fourth element is frequent status updates. During the first days and weeks, users need regular updates on system status, known issues, workarounds, and fixes. Daily updates, delivered through email, a status page, or brief calls, keep users informed. Updates should be concise, focusing on what users need to know and do.

The fifth element is a known issues list. A continuously updated list of known problems, with workarounds and expected resolution, prevents many users from reporting the same issue and gives them immediate guidance. The list should be easy to find and clearly dated.

The sixth element is accessible help. Help should be easy to reach through multiple channels: super-users on site, a help desk line, an email or ticketing system, and possibly scheduled drop-in sessions. Help desk capacity should be increased for launch, anticipating high demand. Wait times should be monitored and communicated.

The seventh element is leadership presence. State and local leaders who visit career centers, join support calls, or send messages acknowledging the difficulty of the transition and thanking staff for their effort show that they understand what staff are experiencing.

The eighth element is managing performance expectations. During launch, productivity typically drops as staff learn the system. Leaders should communicate that this is expected and adjust expectations, such as appointment volumes or data entry deadlines, accordingly. Staff who feel pressured to maintain normal productivity while learning a new system become frustrated and may make errors.

The ninth element is daily feedback loops. Brief daily calls or check-ins with super-users or local managers during launch week surface emerging problems quickly and allow rapid response.

The tenth element is celebrating progress. As the initial days pass and problems are resolved, acknowledging progress and recognizing staff effort sustains morale.

Go-live communication sets the tone for users’ long-term relationship with the system. Users who feel informed and supported during launch, even when problems occur, are more likely to accept the system and work through its difficulties.

Support After Launch

The rollout does not end at go-live. The weeks and months after launch are when users settle into new workflows, discover features and limitations, encounter less common situations, and form lasting opinions about the system. Sustained support after launch determines whether initial adoption becomes effective long-term use.

The first element is continued help desk capacity. Demand for help typically remains elevated for weeks after launch. Reducing help desk capacity too quickly leaves users without support when they encounter less common tasks for the first time. Monitoring help desk volume and wait times guides staffing decisions.

The second element is super-user networks. Super-users remain valuable after launch as local experts. Regular calls or meetings among super-users and the project team allow super-users to share common issues and receive updates, which they relay to colleagues. Recognizing super-users’ contributions sustains their engagement.

The third element is regular updates on fixes and enhancements. As problems are resolved and enhancements are released, users need to know what changed. Release notes written in plain language, highlighting changes that affect users, keep users informed. Users should also know how to request enhancements and see that requests are considered.

The fourth element is refresher and advanced training. Some features may not be used until weeks or months after launch, such as year-end reporting or follow-up activities. Training timed to when features are needed is more effective than training everything at once. Advanced training can help users take advantage of features they did not learn initially.

The fifth element is updated job aids and knowledge base. Experience after launch reveals which tasks confuse users and which instructions need clarification. Updating job aids and building a searchable knowledge base of answers to common questions supports self-service.

The sixth element is data quality support. New systems often reveal data quality issues, either from migration or from users learning new data entry practices. Reports that help local areas identify data problems, along with guidance on correcting them, support accurate reporting.

The seventh element is user feedback. Surveys, focus groups, and analysis of help desk data a few months after launch reveal how users experience the system, what works, and what needs improvement. Sharing results and planned responses with users demonstrates that the state continues to listen.

The eighth element is transition to normal operations. At some point, the rollout transitions to ongoing system operation and support. This transition should be communicated clearly, so users know how support will work going forward, such as which help desk to contact and how enhancements will be prioritized.

The ninth element is onboarding new users. Staff turnover means that new users continually join. Onboarding training, job aids, and super-user support ensure that new staff can use the system effectively without relying solely on overstretched colleagues.

Sustained support signals that the state remains committed to users’ success with the system, not only to completing the project. Users who feel supported over time become proficient and are more likely to see the system’s benefits.

Data Migration and Continuity of Service

Moving from one system to another involves migrating data, including participant records, eligibility documentation, service histories, training plans, case notes, employer records, and outcome data. Data migration is technically complex, and errors or gaps can disrupt service to participants and affect performance reporting. Communication about data migration helps local areas prepare, verify results, and maintain continuity of service.

The first element is explaining what will migrate. Local staff need to know which data will move to the new system, which will not, and how historical data will be accessible. If some data, such as older case notes or closed records, will remain only in an archived version of the old system, staff need to know how to access them.

The second element is data cleanup before migration. Migration works better when data in the old system are accurate and complete. States can ask local areas to review and correct data before migration, providing reports that identify likely problems, such as duplicate records, missing required fields, or inconsistent entries. Clear instructions and deadlines for cleanup help local areas contribute.

The third element is data freeze periods. During migration, there may be a period when data cannot be entered in either system. Local areas need advance notice of freeze periods and instructions for recording activity during them.

The fourth element is verification after migration. After migration, local staff should verify that key data transferred correctly, such as by checking a sample of participant records. States can provide verification checklists and reports comparing old and new data. A process for reporting migration errors, and timely correction, is essential.

The fifth element is protecting participants in services. Participants in the middle of services, such as those in training or receiving supportive services, must not be disrupted by migration problems. Local areas should identify these participants and verify that their records, plans, and authorizations transferred correctly. Payment processes for training providers and supportive services should be tested to ensure that payments continue without interruption.

The sixth element is communicating performance implications. Data migration and the learning curve of a new system can affect performance data, such as through temporary data entry gaps or changes in how data are captured. Local areas need to understand how the state will handle these effects in performance reporting and monitoring. If federal reporting may be affected, the state should communicate how it is addressing the issue with federal partners.

The seventh element is employer and public data. Jobseeker and employer accounts, job postings, and resumes may need to migrate to new portals. Users need to know whether their information will transfer and what to do if it does not.

The eighth element is security and privacy. Migration involves moving sensitive personal information. Communication should assure users that data security is protected and explain any changes in access controls, such as new role-based permissions that affect what staff can see.

Clear communication about data migration reduces anxiety, enables local areas to prepare and verify, and protects participants from disruption. It also supports the accuracy of performance data, which matters for the state’s and local areas’ accountability.

Accessibility, Language Access, and Digital Access

New systems and portals must be usable by everyone who needs them, including staff and members of the public with disabilities, people with limited English proficiency, and people with limited digital access or skills. Accessibility should be built into the system and its rollout communication from the start, not addressed after complaints arise.

System accessibility is a legal and ethical requirement. Section 188 of WIOA and federal disability rights laws require equal access to workforce services for people with disabilities. The Department of Justice’s 2024 rule under Title II of the Americans with Disabilities Act established technical standards for state and local government web content and mobile applications, with compliance deadlines phased by government size. Jobseeker and employer portals, as well as staff-facing systems, should be designed and tested for accessibility, including compatibility with screen readers, keyboard navigation, sufficient color contrast, captions for videos, and clear structure. Accessibility testing with users who rely on assistive technology reveals problems automated tools may miss.

Rollout communication must also be accessible. Training materials, job aids, videos, user guides, and notices should be available in accessible formats. Staff with disabilities need accessible training and any accommodations required to use the system.

Language access is essential for public-facing portals. Residents with limited English proficiency need portals and instructions in their languages, or at least clear pathways to assistance in their languages. Notices about the portal change, user guides, and help resources should be translated into the languages most common in the state or local area. Help desk staff should have access to interpretation.

Digital access is a significant concern. Many jobseekers lack reliable internet access, computers, or smartphones, or have limited digital skills. A shift to online portals can create barriers for these users. Communication should make clear that in-person and phone assistance remain available, and career centers should be prepared to help users register and navigate the portal. Libraries, community organizations, and other partners can extend assistance.

Identity verification can create particular barriers. Online identity verification often relies on credit history, mobile phones, or government identification, which some users lack. States should provide alternative verification methods, such as in-person verification at career centers, and communicate them clearly.

Staff digital skills also vary. Some frontline staff are highly comfortable with technology; others are less so. Training should accommodate different skill levels, with additional support for staff who need it.

Accessibility and access should be monitored after launch. Help desk data, user feedback, and analysis of who is and is not using the portal can reveal barriers. For example, if registration rates decline among older jobseekers or in certain communities after a portal change, this may signal access problems requiring attention.

Attending to accessibility and access ensures that new systems expand rather than restrict access to workforce services. A portal that serves tech-savvy users well but excludes those with fewer resources fails the workforce system’s mission.

Managing Problems and Setbacks Honestly

Every system rollout encounters problems. Defects surface, performance slows, data migrate incorrectly, features do not work as expected, or launch is delayed. How the state communicates about problems determines whether users maintain trust in the project and the system. Honest, prompt, and constructive communication about problems builds credibility; minimizing or concealing problems destroys it.

The first principle is acknowledging problems promptly. When users encounter a problem, they want to know that the state is aware of it and working on it. Prompt acknowledgment, even before a fix is available, reassures users and reduces duplicate reports. Silence leads users to assume that the state does not know or does not care.

The second principle is candor about severity. Problems should be described accurately, neither exaggerated nor minimized. If a defect affects a critical function, such as eligibility determination or payment processing, users need to know so they can use workarounds. Describing a serious problem as a minor glitch undermines credibility when users experience its effects.

The third principle is providing workarounds. Users need to keep working while problems are fixed. Clear workarounds, such as alternative procedures, temporary paper processes, or instructions for avoiding a defect, allow work to continue. Workarounds should be communicated quickly and updated as needed.

The fourth principle is realistic timelines for fixes. Users want to know when problems will be resolved. Estimates should be realistic; repeatedly missed estimates erode trust. Where timelines are uncertain, saying so honestly is better than offering optimistic dates.

The fifth principle is closing the loop. When problems are fixed, users should be told. A brief notice that a problem has been resolved, and any action users need to take, such as re-entering data, completes the communication cycle.

The sixth principle is owning mistakes. When problems result from state or vendor decisions, such as inadequate testing or rushed timelines, leaders should acknowledge responsibility rather than blaming users or local areas. Owning mistakes builds respect; deflecting blame breeds resentment.

The seventh principle is protecting local areas from consequences of system problems. If system problems affect local performance data, compliance, or participant services, the state should address these consequences fairly, such as by adjusting monitoring expectations or working with federal partners on reporting issues. Communicating this commitment reassures local areas.

The eighth principle is learning publicly. After significant problems, a brief review of what happened, why, and what is being done to prevent recurrence, shared with users, demonstrates accountability and commitment to improvement.

The ninth principle is communicating with external audiences when necessary. Significant problems may attract attention from legislators, the media, or the public, particularly if they affect jobseekers or unemployment insurance claimants. Leaders should be prepared to communicate honestly about problems, their causes, their effects, and the plan to resolve them, coordinating messages across the agency.

Problems are inevitable; loss of trust is not. Users who see that problems are acknowledged, addressed, and learned from are generally willing to work through difficulties. Users who feel misled are not.

A System Rollout in Practice

The following hypothetical example illustrates how a state workforce agency might communicate the rollout of a new case management system and jobseeker portal. It does not describe an actual state or system.

A state workforce agency plans to replace its aging case management system, which can no longer be supported by its vendor and cannot meet new reporting requirements, with a modern system that includes a jobseeker portal. Staff remember a troubled rollout years earlier, when a previous system launched with inadequate training and many defects.

Early in the project, the agency develops a communication plan mapping audiences, messages, and milestones. The agency director sends a message to all local directors and providers explaining why the change is necessary, what benefits are expected, and what the agency learned from the previous rollout. She acknowledges that the transition will be demanding and commits to involving frontline staff and providing strong support.

The agency recruits frontline staff from local areas of different sizes to participate in requirements sessions and design reviews. Their feedback leads to changes in the eligibility workflow and case notes screens. Later, they participate in user acceptance testing, identifying problems that are fixed before launch. The agency shares updates on how staff input shaped the system.

The agency recruits super-users in every local area, trains them in depth, and holds regular calls with them throughout the project. Local directors receive a detailed rollout calendar and readiness checklist. The agency defines readiness criteria and communicates that launch will proceed only when they are met.

When testing reveals problems with data migration, the agency delays launch by six weeks, explaining the reason candidly. Local directors, who had been told readiness would determine the date, accept the delay.

Role-based, scenario-based training occurs in the weeks before launch, with a practice environment available. Job aids and short videos are posted in an online knowledge base. Local areas complete data cleanup using state-provided reports, and verify migration samples during a trial run.

For the jobseeker portal, the agency notifies registered users by email and through the old portal several weeks in advance, explaining what to do. It coordinates with the unemployment insurance division so that claimants affected by transition issues are not penalized. Career centers offer assisted registration sessions, and alternative in-person identity verification is available. Notices and guides are translated into the most common languages.

On launch day, a command center monitors the system, help desk staff are increased, super-users support colleagues on site, and daily status updates and a known issues list are distributed. The agency director visits career centers during launch week. Local managers are told to expect reduced productivity and to adjust appointment schedules.

Several defects surface, including a problem with training provider payments. The agency acknowledges the issue the same day, provides a workaround, and resolves it within a week, confirming the fix to all users. Three months after launch, the agency surveys users, shares results, and announces enhancements based on feedback.

The example illustrates the core principles: building the case for change, acknowledging past experience, involving frontline staff, using super-users, communicating timelines and readiness honestly, training for real work, preparing public users, coordinating with unemployment insurance, supporting intensively at launch, managing problems candidly, and sustaining support.

Measuring Rollout Communication

System projects are usually measured by technical milestones and defects resolved. Measuring the human side of the rollout, including communication, readiness, adoption, and user experience, provides essential information about whether the rollout is succeeding and where support is needed.

The first area is readiness. Before launch, tracking the share of users with active accounts, training completion rates, completion of local readiness checklists, and data cleanup progress shows whether local areas are prepared. Gaps signal where additional support is needed before go-live.

The second area is understanding. Brief surveys before launch can ask staff whether they understand why the system is changing, what will happen at launch, and where to get help. Low understanding signals a need for more communication.

The third area is help desk activity. Volume, types, and resolution times of help desk tickets after launch reveal common problems and support capacity. Declining volume over time indicates stabilization; persistent high volume on particular topics signals training or system issues.

The fourth area is adoption and use. System usage data, such as logins, completion of key transactions, and use of features, show whether staff are using the system as intended. Low use of certain features may indicate training gaps or design problems. For public portals, registration and usage rates, compared with the old system, show whether the public is adopting the portal.

The fifth area is data quality. Data quality reports after launch, such as missing fields or errors, reveal whether staff are entering data correctly and whether migration succeeded.

The sixth area is service continuity. Monitoring participant services, training provider payments, and other critical functions during transition shows whether participants are being served without disruption.

The seventh area is user satisfaction. Surveys of staff a few months after launch, asking about ease of use, training adequacy, support quality, and overall satisfaction, provide a picture of user experience. Public user satisfaction can be gathered through brief surveys on the portal.

Several questions help agencies assess rollout communication:

  • Did staff understand why the system was changing and what would happen at launch?

  • Were training completion and account setup complete before go-live?

  • How quickly did help desk volume decline after launch, and what issues persisted?

  • Are staff and public users adopting the system, and is data quality adequate?

  • Were participant services and payments maintained without disruption?

Access and equity should also be monitored. Tracking portal registration and use across demographic groups and regions, where data allow, can reveal whether the new portal creates barriers for particular populations.

Measurement findings should be shared with leaders and users and used to adjust support. A rollout that measures its human dimensions can identify and address problems before they undermine adoption.

How Workforce System Rollouts Compare With Other Agency Types

Many public agencies implement large technology systems that affect staff and the public, and their experiences offer lessons for workforce system rollouts.

State unemployment insurance agencies have implemented major system modernizations, some of which encountered significant problems at launch, including claimant access difficulties, processing backlogs, and public criticism. Some of these experiences, particularly during periods of high claim volume, illustrate the risks of launching systems before they are ready, the importance of testing with real users, and the need for strong communication with the public when problems occur. Because workforce and unemployment insurance systems are often linked, workforce agencies can learn directly from these experiences.

State human services agencies have implemented integrated eligibility systems for programs such as SNAP, TANF, and Medicaid, often affecting large numbers of county staff and clients. Their experiences emphasize the value of phased rollouts, super-user networks, extensive training, and attention to client access, as well as the consequences of inadequate preparation.

Health care organizations implementing electronic health records have developed sophisticated approaches to change management, including physician champions, at-the-elbow support during go-live, command centers, and phased rollouts. These approaches parallel super-users and command centers in workforce rollouts.

Federal agencies have implemented public-facing digital services, sometimes with notable early problems. Public reviews of some high-profile launches emphasized user-centered design, iterative development, realistic testing, and transparent communication about problems. Federal digital service guidance reflects many of these lessons.

School districts implementing student information systems face similar challenges of training many staff, migrating data, and communicating with families through parent portals.

What distinguishes workforce system rollouts is the combination of a statewide system used by staff employed by many different organizations, including local boards, contracted providers, and partner programs; public-facing portals serving jobseekers with varying digital access; links to unemployment insurance requirements; federal performance reporting that depends on data quality; and participants in the middle of time-sensitive services such as training. These features make coordination through local leaders and super-users, public communication with attention to access, unemployment insurance coordination, careful data migration, and protection of service continuity especially important. Workforce agencies can borrow change management practices from health care, user-centered design from federal digital services, and lessons from unemployment insurance modernization, adapting them to the workforce context.

Tying It All Together

Rolling out a new case management system or jobseeker portal is not only a technology project. It is a communication and change management effort that determines whether thousands of staff and members of the public can use the system effectively, whether participants continue to receive services without disruption, and whether trust in the workforce system survives the transition.

Rollouts are communication challenges because systems are central to daily work, users are numerous and diverse, public-facing changes affect people without training, timelines are uncertain, project teams are distant from users, continuity of service must be protected, reporting depends on data quality, and staff may be skeptical from past experience. Each audience, including leaders, frontline staff, partner programs, data staff, training providers, jobseekers, employers, unemployment insurance claimants, and officials, needs tailored communication at each phase.

Building the case for change explains why the system must change, describes benefits concretely, acknowledges costs, aligns leadership messages, addresses past experience, and connects to mission. Involving frontline staff in requirements, design, testing, super-user networks, rollout planning, and ongoing feedback improves the system and builds advocates. Communicating timelines with firm and target dates distinguished, readiness criteria defined, changes communicated promptly, delays explained honestly, local checklists provided, go and no-go decisions shared, and phasing explained allows local areas to prepare.

Training that is role-based, scenario-based, hands-on, well timed, multi-format, supported by job aids, attentive to workflow changes, extended through super-users, verified, and continued after launch prepares staff for real work. Public users need advance notice, clear instructions, attention to identity verification, coordination with unemployment insurance, prepared career center staff, employer outreach, accessibility, help resources, and feedback channels.

Go-live communication includes countdowns, cutover instructions, command structures, frequent updates, known issues lists, accessible help, leadership presence, adjusted expectations, daily feedback, and recognition of progress. Support after launch continues through help desk capacity, super-users, release notes, timed training, updated knowledge bases, data quality support, user feedback, a clear transition to operations, and onboarding.

Data migration communication explains what migrates, supports cleanup, announces freeze periods, enables verification, protects participants in services, addresses performance implications, covers public accounts, and assures security. Accessibility, language access, and digital access ensure the system serves everyone. Honest management of problems, through prompt acknowledgment, candor, workarounds, realistic timelines, closed loops, ownership, protection of local areas, public learning, and external communication, preserves trust. And measurement of readiness, understanding, help desk activity, adoption, data quality, continuity, satisfaction, and equitable access shows whether the rollout is succeeding.

Strategic Communication Support

Frontline workforce staff assisting a jobseeker with a digital career services portalCommunicating a system rollout requires a plan that spans years from project start through stabilization, coordination with technical teams and vendors, messages tailored to many audiences, training and job aids designed around real work, public communication that reaches people with varying access, and rapid, candid communication when problems arise. State project teams are often focused on technical delivery and may not have dedicated communication and change management capacity. External support can help agencies prepare users and protect trust through the transition.

Stegmeier Consulting Group (SCG) helps public agencies communicate major operational changes to staff and the public. For state workforce agencies replacing case management systems or portals, that work can begin with a change readiness assessment: mapping audiences, understanding current workflows and pain points, gathering frontline perspectives, reviewing lessons from past rollouts, and identifying communication channels through local boards, providers, and partners.

From that foundation, SCG can help develop a rollout communication plan aligned with project milestones; core messages explaining the case for change; leadership talking points; super-user network design and communication; readiness checklists for local areas; plain-language job aids and user guides; public notices and instructions for jobseekers and employers in multiple languages; and coordination plans with unemployment insurance and partner programs.

Implementation support can include facilitating frontline involvement in design and testing, preparing go-live communication including status updates and known issues templates, supporting command center communication, and drafting candid messages when problems occur. Evaluation support helps agencies measure readiness, understanding, adoption, user satisfaction, and equitable access, and adjust support accordingly. The aim is a rollout in which staff are prepared, participants are protected, the public can use the new portal, and trust in the system grows rather than erodes.

Future Trends

Several established developments are shaping how state workforce agencies roll out new systems. Many states are modernizing workforce technology, moving from older, custom-built systems toward configurable platforms, cloud-based services, and integrated systems that connect workforce, unemployment insurance, and sometimes human services data. These modernizations promise improved functionality but involve significant change for users. Agencies undertaking them can benefit from the growing body of experience across states.

User-centered and iterative approaches to government technology have gained ground. Rather than launching large systems all at once after years of development, some agencies release functionality in smaller increments, test with users continuously, and improve based on feedback. These approaches change rollout communication, which becomes an ongoing conversation with users rather than a single launch campaign. They also allow problems to be found and fixed earlier.

Identity verification and fraud prevention requirements have intensified, particularly in systems linked to unemployment insurance. Stronger verification can protect against fraud but can also create barriers for legitimate users. Communicating verification requirements clearly, and providing accessible alternatives, will remain important.

Artificial intelligence features are beginning to appear in workforce systems, such as tools that suggest job matches, summarize case notes, recommend services, or answer jobseeker questions through chat interfaces. These features raise questions about accuracy, bias, transparency, and staff roles. Rollouts that include such features will need to explain how they work, what their limitations are, how staff should use them, and how human judgment remains central. Their role in public workforce systems is still developing.

Accessibility requirements for digital government services have become more concrete, including the Department of Justice’s 2024 rule establishing technical standards for state and local government web content and mobile applications, with compliance deadlines phased by government size. New systems and portals will need to meet these standards from launch.

Policy changes may require system changes. Federal legislation enacted in 2025 broadened work requirements associated with SNAP and introduced community engagement requirements for certain Medicaid enrollees, with implementation phased in by states. Where workforce systems track activities related to these requirements, system changes and accompanying communication may be needed. Potential changes to federal workforce program structure, contemplated in budget proposals in recent cycles, could also require system modifications if enacted.

Finally, staff turnover and workforce shortages in public agencies increase the importance of systems that are intuitive and well supported, with strong onboarding resources, so that new staff can become productive quickly.

Conclusion

The career advisor locked out on launch morning, the participant whose training plan did not appear, and the jobseeker stuck at identity verification were not victims of bad technology. They were victims of a rollout that treated communication as an announcement rather than a system of preparation and support. Each of their problems could have been anticipated: accounts confirmed in advance, migration verified for participants in services, alternatives to online verification explained, help desk capacity increased, and a known issues list ready before the first call came in.

For state workforce agency leaders, information technology managers, and local directors, the implication is that communication and change management should be planned, staffed, and funded as part of every system project from its first month. That means explaining honestly why change is needed, bringing frontline staff into design and testing, building super-user networks, setting readiness criteria rather than fixed dates, training around real work, preparing jobseekers and employers with accessible instructions, staffing go-live heavily, protecting participants in services, and owning problems candidly when they occur.

Agencies that take this approach will still encounter problems; every system launch does. But their staff will be ready, their participants will be protected, their public users will know where to turn, and their workforce system will come out of the transition with more trust than it had going in.

Stegmeier Consulting Group’s Strategic Approach to Communication Systems

SCG approaches system rollouts as communication systems that must carry thousands of users through change. That approach starts by mapping every audience a new case management system or jobseeker portal will touch, understanding frontline workflows and past rollout experience, and building a communication plan tied to project milestones. It then helps agencies explain the case for change honestly, involve frontline staff and super-users in design and testing, set readiness criteria that govern launch, train around real work, and prepare jobseekers and employers with accessible, multilingual instructions.

For state workforce agencies, this means local career centers that know what is coming and are ready when it arrives, go-live support with clear status updates and known issues lists, participants protected through data migration, unemployment insurance claimants coordinated rather than penalized, and problems acknowledged and resolved candidly. It means measuring readiness, adoption, and equitable access so that support reaches the people and places that need it most.

Use the form below to connect with our team and explore how strategic communication support can help your state workforce agency roll out new case management and jobseeker portal systems that local career centers and frontline staff are ready to use.