Role: Wrike Consultant / Operations Specialist
Client: Global Marketing Team (Client name changed for privacy.)
Year: 2025
Team Size: 200+ marketing professionals across 4 regions
Tools: Wrike, Airtable, Zapier
The global marketing operations team at this company had been using Wrike since 2016. Nearly a decade is long enough for a workspace to become its ecosystem, with its history, accumulated decisions, and habits.
Some of those habits were good. Most of what had built up around them wasn’t.
By the time I came in in August 2025, the system had become so disorganized that teams across a lot of the regions were avoiding it.
To understand the scale of the problem, it helps to picture what using the workspace looked like day to day.
A marketing coordinator in Singapore needs to request a new landing page. She opens Wrike, goes to the request forms, and sees more than 20 options with almost identical names. Some were created in 2019, others in 2021, and it’s unclear which one is current. She picks one and hopes for the best.
A campaign manager in São Paulo searches for a project she knows was finished months ago. It’s still marked in progress along with hundreds of other tasks going back to 2018, some still active, most completed or abandoned years ago, and never properly closed out. Finding anything in that will take longer than it should.
A team lead in London pulls up a dashboard to check the status of regional campaigns. The data is inconsistent because projects are tagged differently across regions, and custom fields were never standardised. She wants to know how many webinars were run last quarter and there’s no clear answer. She’d have to manually dig through hundreds of projects, hoping the naming was consistent enough to spot them.
That was the daily situation for over 200 marketing professionals across APAC, EMEA, LATAM, and North America. The tool was there, but people just didn’t trust it anymore, and when people don’t trust a system, they stop using it, which makes the data worse, which gives them more reason not to use it. This was a cycle that had been running for years when the operations team decided something had to change.
The full scope of the engagement
Before anything got rebuilt or changed or revamped, the full picture of what existed needed to be understood. So I started with a complete audit of every space, folder, blueprint, custom field, workflow, and automation. Workflow usage reports going back 2 quarters to identify those no longer used, all access logs, and dashboards.
What came back wasn’t pleasing.
There were over 85 request forms. Many were duplicates or created two or three times over the years because nobody knew if the old version was still in use, so someone just made a new one. Hundreds of tasks and projects sat in permanent limbo, still marked in progress for work that had been finished or abandoned between 2018 and 2023. Nobody had gone back to clean them up, and over time, the backlog had grown so large that it felt impossible to address. Workflows set up years earlier were still running, even though the processes they supported had long since changed. Custom fields varied across regions because anyone could create them at any time, a restriction that was eventually set to space admins, but only after years of accumulated inconsistency.
The operations team knew things were bad, and the audit showed exactly how bad they were, and that specificity gave the rebuild a clear direction.
The cleanup came first, and it was the most painstaking part of the whole project.
All incomplete tasks and projects from 2016 to 2023 were reviewed while working with the operations team to determine which were still active and which had been left behind. The finished ones got properly closed out. The abandoned ones got archived. It was necessary because building anything reliable on top of years of unresolved data would have just created a cleaner-looking version of the same problem.
The request forms came next. All 85+ were reviewed, duplicates or drafts were identified, and the entire set was consolidated down to 50 forms with clear, specific purposes. Each one was restructured so that submitting a request automatically triggered the correct blueprint, assigned the right people, and populated the appropriate fields, thereby eliminating the manual setup required after every submission and the time-consuming process of doing it consistently. Regional teams were involved throughout to make sure the forms made sense for how they worked.
Workflows got the same treatment. Usage reports identified which ones were still being used for work and which had been running on inertia for months. The irrelevant ones were removed. The active ones were rebuilt properly.
One of the most significant structural changes was moving away from a generic project-and-task setup toward Custom Item Types, and it’s worth explaining why that was essential.
In the old system, everything was either a project or a task. A website launch was a project. A webinar was a project. A blog post was a task. An ad was also a task. Everything sat in the same categories regardless of what it was, which meant that if leadership wanted to know how many webinars the team had run in Q3, there was no straightforward answer. You’d have to manually search through hundreds of projects, hoping the naming conventions were consistent enough to identify them. Usually, they weren’t.
Custom Item Types gave each kind of work its own identity. Websites, landing pages, blog posts, ads, pop-ups, and campaigns are each tracked separately, each with its fields, workflows, and blueprints designed around what that deliverable requires. The result was that the team could work in a way that fit the specific type of work rather than forcing everything into one generic template. And reporting that had been essentially impossible became immediate. Could we tell how many web pages were delivered this quarter? How many webinars? How many blog posts?
For a leadership team trying to understand what 200+ marketing professionals were producing across four regions, that change was significant.
As the rebuild progressed, it became obvious that some workflows that were technically correct in Wrike were still too complicated in practice, and that complexity meant people would find workarounds or just stop using them.
The clearest example was requesting multiple assets at once. If a team needed to request a web page with different content requirements, each with different due dates and stakeholders, Wrike required either multiple separate form submissions or a single form with everything crammed into the description field. Neither option was good. For teams already uncertain about the system, that kind of friction was enough to push them back to email.
That’s where Airtable came in. Initially, we tried using Excel, but it didn’t fit our needs.
Note: Both Excel and Airtable Zaps are included here as working demonstrations built for this case study. In practice, Airtable was selected as the better fit for the workflow and is the platform on which the integration runs.
Using Wrike’s API and Zapier, I built a two-way sync between the two platforms. In Airtable, teams could submit a single record or form requesting multiple pages, set individual due dates for each page, assign different stakeholders to each page, and add any needed notes. Once submitted, the data is synced back to Wrike automatically, with each request becoming its own Custom Item Type, with the correct fields populated, the right blueprint applied, and the right people assigned. Everything is tracked in Wrike, where it was supposed to live. Airtable was just a cleaner front door for extremely complex requests.
Note: Both Excel and Airtable Zaps are included here as working demonstrations built for this case study. In practice, Airtable was selected as the better fit for the workflow and is the platform on which the integration runs.
For users, the process stayed simple, and for the operations team, nothing was left behind. The data was where it needed to be, organised as it needed to be, and ready to report on.
The technical work was only half the challenge. After a decade of usage, many on the team had frankly checked out. They didn’t believe this could work for them. Fixing the workspace wouldn’t automatically fix the issues over the years. It doesn’t come back because someone cleaned up the folder structure.
Rebuilding it took a different approach. I found Wrike champions in each region, who were people who already understood the tool or had some influence with their teams. I worked closely with them to spread the new system through their networks rather than pushing it top-down from the outside. Documentation was created for different learning styles because not everyone can absorb information in the same way. And every change that was made was tied directly to a problem the teams had named.
The operations team drove a lot of this. They knew their regions, their people, and what had not worked before. Following their lead on the cultural side of the change, rather than the technical side, allowed the new system to take shape.
This project is still ongoing. The foundation is established and functioning, but as with any large system, new phases emerge through progressive elaboration. Teams continue to find ways to improve, and what initially started as a cleanup has expanded into something more extensive.
The execution phase is ongoing. The Wrike-Airtable integration is being tested at scale across all regions. Advanced dashboards for leadership visibility are in development. Workflows are being refined based on user feedback as it comes in.
But meaningful growth has already occurred. Request forms are clear and purposeful. Custom Item Types allow teams to track and report their work in a way that reflects what they’re producing. The Airtable integration manages any complexity without affecting visibility. And the data, for the first time in years, is clean enough to trust.
The operations team approached the situation with a clear understanding of what went wrong and a willingness to fix it properly, rather than patching over the symptoms. That made the rebuild possible. A workspace of this size, with this much history, doesn’t improve solely because of good software choices but because the people responsible for it decide it will and then follow through.
