Marketing teams are often overwhelmed by ungoverned requests that never tie back to business goals. Here is how we replaced a scattered, approval-free intake process at a international airline company with a single unified queue in Adobe Workfront, using routing rules and Workfront Fusion to vet, forecast, and route work automatically.
Why our marketing intake needed to change
When I joined a project as a system administrator and product owner of a large international airline company, marketing had almost no governance. There were no consistent naming conventions, no real formality around how project templates were managed, and no standard process for how work entered the team.
The route to getting a campaign executed was cumbersome. Requests arrived with no upfront approvals and no prioritization. We ran multiple separate marketing queues, each built to intake a different kind of request, and those requests went straight to individual team members.
The deeper problem became clear when we looked at resourcing. As we analyzed how much capacity people had across their projects, we found that team members were spending time on work that did not roll up to the organization's goals. Anyone across the enterprise could submit a request, a traffic manager would pick it up and assign it, and there was no evaluation of whether the work laddered up to a marketing goal or made sense against budget. We had no reliable way to judge the real value of completing a given request.
That is what we set out to solve: bring the whole intake experience together into one unified queue across marketing.
How we built the unified intake queue
We built the solution in stages, starting with people and process before touching the technology.
Starting with stakeholder interviews and a committee
The first step was understanding the work. I ran interviews across marketing with the stakeholders who complete requests and projects in Workfront, so I could understand the volume and the different types of work coming through.
From there, we formed a stakeholder committee to act as the voice of the business throughout the project. This group represented marketing as a whole and spoke for the business side as we designed the solution.
Triaging requests and designing a consolidated form
With the committee in place, we took a close look at every type of request moving through the system and considered the best way to structure a single queue. We used queue topics and topic groups to organize the different request types.
A major piece was creating one consolidated custom form. In the old world, each queue collected very detailed information up front because it was aimed at a specific team. In the new solution, we took a step back and asked higher-level questions first, to vet a request before collecting the detailed information a team would eventually need.
Routing with rules and Workfront Fusion
To move work through the queue, we combined Workfront's routing rules with Workfront Fusion, the platform's automation and integration capability.
We built a two-queue solution:
-
A front-end unified intake queue, where all stakeholders with contributor access submit their requests to marketing.
-
A back-end execution queue, which was our original marketing queue repurposed so it was no longer public-facing.
Once marketing vetted a request and approved it, Fusion moved it from the intake queue to the execution queue and the routing rules assigned it to the right team. Project managers watch the execution queue to see which requests are approved, then start their own work streams from there.
Converting requests into projects
In this solution, approved requests are converted into projects. We mapped planned hours in our project templates, then used Fusion to combine the templates for the teams likely to work on a given request. That produced an overall planned-hours forecast for the project, which we used alongside resourcing. Based on the templates selected, the routing rules kicked off the right teams' projects.
The challenges we worked through
Aligning leadership and teams on the form
The biggest debate was around the initial custom form and how much detail to collect up front. Leadership wanted high-level information that tied a request to an overarching initiative or program. Some team members wanted to go down the usual path of collecting detailed information right away.
We worked through it with a series of working sessions that included both leadership representation and the project managers and team members who use the form. We landed on a consolidated form that met both ends: high-level questions that ladder a request up to a program, plus enough detail for a team to understand what they were being asked to do.
Hitting the custom form limit
One challenge caught us off guard, and it was technical. Workfront limits you to 10 custom forms on a single object, and we ran into that ceiling.
As a request moved through the process, we were attaching multiple forms: the initial intake form, additional forms for each team involved, a forecasting form, an office hours form, and more. A single request with three or four teams could easily need four or five extra forms on top of the others.
To resolve it, I worked with stakeholders to map which questions lived on each form and where different teams needed the same answers. By consolidating overlapping questions, we reduced the number of forms while still capturing everything each request needed.
The impact on the business
The change showed up in a few clear ways:
-
Fewer submitted requests. Once people understood what was needed for approval, they submitted fewer requests, which improved capacity planning and forecasting.
-
One request instead of many. Before, a stakeholder often had to submit several requests for a single ask. Now one request can triage into work for multiple teams, saving time and cutting out duplicate, siloed effort.
-
More automation. Fusion handled request-to-project conversion, capacity forecasting, and the project template logic, so teams could plan their work further ahead.
What changed for requesters, project managers, and leadership
Requesters were some of the biggest winners. Their front-end experience became far more streamlined, and because we overhauled accompanying reports and dashboards, they could finally see where their work stood and which projects related to their request.
Project managers had much of their manual back-end work, triaging and setting up projects, automated through Fusion, which gave them more visibility and made their jobs easier.
Leadership received new dashboards and reports that rolled up information from the unified intake experience. We also used Workfront Planning to build a marketing calendar, giving leaders a high-level timeline view of marketing campaign’s timeline and collateral.
Driving adoption across marketing
Adoption surprised me. We did a lot of enablement around the move from the old world to the new one, but it still took time for users to feel comfortable in the new system. Change management is always harder than the technology.
What helped was a mix of support: office hours, show-and-tell demo sessions, and role-based training tailored to each person's part in the process. We also set up a SharePoint site as a central hub for recordings, documentation, the office hours schedule, and the release roadmap.
Within a little over a month, people were getting into the groove. We kept running feedback sessions after go-live so stakeholders could tell us what to improve, which made the solution feel real and let us keep evolving it rather than treating launch as the finish line.
What I would do differently
If I went back, I would roll out the Fusion pieces in phases. We did a lot of automation up front, which was great for productivity, but from a user's perspective it was a lot of change at once. Layering the Fusion scenarios from least to most complex probably would have made onboarding easier. Beyond that, the project went well, and we are still building on the solution as marketing's work and Workfront's capabilities evolve and integrate with other systems.
My advice for teams considering unified intake
Unifying the experience around your specific business use case is a strong path forward for streamlining marketing operations, or operations for other work streams.
The biggest call-out I would make is to get the right people in the room to share how they want their work to flow. One of the biggest lightbulb moments for me was realizing that the problem usually is not the technology. It is the people and the process that need attention.
I always say it is not a technology problem, it is a people, process, and technology problem. Solve the people and process part first, then bring in the technology to tie it together. For us, that started with transparency. Co-creating a solution means being open about what you know and what you do not, and being willing to say you are not sure and will follow up.
We ran discovery sessions to understand stakeholders' pain points so we could build their feedback into the solution. Most of them did not know the technical side of Workfront, but they knew their business processes. My job was to own the technical pieces and meet users in the middle on the business side. Workfront was the right tool to bring it all together, and it had already been part of the ecosystem for a few years.
Frequently asked questions
Why build a single intake queue instead of keeping separate queues per team?
Separate queues sent requests straight to team members with no approval or prioritization, so people worked on things that did not tie back to business goals. A unified queue lets a review committee vet each request for business value before any team starts work.
How do routing rules and Workfront Fusion work together here?
Routing rules assign approved requests to the right team, while Fusion moves requests from the intake queue to the execution queue, converts requests to projects, and combines project templates to forecast planned hours.
How did you handle the 10 custom form limit on an object?
We mapped the questions on every form, found where teams needed the same answers, and consolidated overlapping questions so we stayed under the limit without losing any information.
What was the hardest part of the rollout?
Change management. Adoption took longer than expected, so we leaned on office hours, role-based training, demo sessions, a SharePoint hub, and ongoing feedback sessions to help users get comfortable.
What is the one thing that matters most?
Getting the right people in the room. Most of the time it is not a technology problem; it is a people and process problem, so solve that first and let the technology bring it together.