Why Marketers Still Depend on IT in SFMC

‍

You already know the audience you want. Recent openers who have not purchased in the last ninety days.

Describing it takes one sentence. Building it in Salesforce Marketing Cloud takes a ticket, a queue, and someone who writes SQL.

That gap is why so many marketing teams still wait on IT to ship a segment.

‍

This is not a failure of effort or ambition. It is a structural feature of how SFMC stores and exposes its data.

Once you can see where the technical layer sits, the dependency stops feeling mysterious. So do the ways out of it.

‍

It is worth being precise about the problem before reaching for a fix. The dependency is not one big wall; it is a series of small technical steps, each of which quietly requires SQL.

‍

This post walks through what marketers actually rely on IT for inside SFMC, why a plain request turns into engineering work, and what is starting to shift.

‍

What depending on IT looks like day to day

‍

The request queue behind every audience

A marketer decides on a segment. A developer or ops specialist turns that intent into a query.

The request lands in a backlog, gets ranked against everything else on the roadmap, and comes back days later.

By the time it returns, the campaign window has often already moved on.

The pattern repeats for almost every non-standard audience, which is why the queue never really empties.

‍

Why a simple ask becomes a ticket

In plain language the ask sounds trivial. The build behind it is not.

It requires knowing which tables hold the data, how those tables relate, and how to express the logic as SQL that SFMC will accept.

Most marketers were never expected to carry that knowledge, so the work routes to whoever can.

That handoff, repeated across a year of campaigns, is the dependency in its clearest form.

‍

The technical layer marketers rarely see

‍

Data extensions and data views

SFMC keeps contact and engagement data in data extensions and in system data views.

Data extensions are tables you create and control. Data views are read-only system tables that SFMC maintains for you.

Data views such as _Sent, _Open, and _Click hold the engagement history behind every send you make.

According to Salesforce Help, you use them by creating a data extension to store results, then building a query that reads from the view and writes into that extension.

That indirect path, from view to query to new extension, is invisible in the marketing brief but unavoidable in the build.

‍

The SQL Query activity in Automation Studio

The tool that ties this together is the SQL Query activity in Automation Studio.

It lets you write a query, run it immediately or on a schedule, and drop the output into a target data extension for later use.

Setting one up means naming the query, choosing a target extension, and deciding how the results are written.

You pick whether results are appended to existing data, updated and appended, or written as a full overwrite of the extension.

‍

Where SQL knowledge becomes the gatekeeper

‍

Joining engagement data across views

Useful segments rarely live in a single table.

An unengaged audience means joining send data to open and click data, typically on keys like JobID, ListID, BatchID, and SubID, then matching contacts on SubscriberKey.

Writing that join correctly is the line between a clean audience and one that quietly excludes the wrong people.

Get a key wrong and the query still runs; it just returns the wrong contacts, which is harder to catch than an outright error.

This is where the marketing intent and the technical detail drift apart, and where a second reviewer earns their keep.

‍

The rules that trip people up

SFMC SQL is based on SQL Server 2016, but it does not match it exactly, so habits from other databases do not always carry over.

A few constraints catch newcomers most often:

• Queries time out after thirty minutes.
• A broad SELECT across a large extension can slow the whole account.
• Salesforce suggests limiting date ranges, often to around six months.

None of these are hard once you know them, but each one is a place where a marketer without SQL training gets stuck and files a ticket.

‍

The real cost of the dependency

‍

Slower campaigns and missed windows

Every audience that needs a query adds a handoff between two people.

Handoffs add days, and days turn a timely campaign into a late one. The delay is rarely the query itself; it is the wait in front of it.

Seasonal sends, reactivation pushes, and quick reactions to behavior are the campaigns that suffer most from that wait.

‍

A bottleneck of one or two people

When only a couple of people can write SFMC SQL, they become a single point of failure for the whole team.

A vacation, a resignation, or one busy sprint can stall every segment on the calendar.

The knowledge sits in their heads rather than in a system the team can share, so it walks out the door when they do.

Documenting the common queries helps, but documentation ages quickly as data extensions and naming conventions change.

‍

What marketers can own themselves today

‍

Learn to read a query, not write one

You do not need to author SQL from scratch to loosen the dependency.

Being able to read a query, check which tables it touches, and confirm the logic already shortens the loop and cuts the back and forth.

Reading skill also makes you a better reviewer, so the queries that do come from IT ship correct the first time.

Even a working vocabulary of a dozen SQL terms changes how you scope a request and how quickly it comes back.

‍

Build a library of reusable patterns

Most audiences are variations on a handful of patterns: recent openers, lapsed buyers, suppression lists.

Saving working queries as templates lets the team reuse them with small edits instead of rebuilding from zero each time.

Roles and permissions in SFMC decide who can run these activities, so it helps to agree early on who owns what.

‍

Where conversational AI changes the equation

‍

From ticket to sentence

The dependency exists because plain language has to be translated into SQL by a person.

Conversational AI removes that translation step. You describe the audience you want, and the query is generated for you.

The request that used to become a ticket becomes a sentence you can run yourself.

The technical steps still happen; they simply happen for you instead of blocking you.

‍

Keeping a human in the loop

Generated SQL is still SQL, so it can be inspected before it ever runs.

The marketer sees the audience they asked for, and anyone technical can still review the query behind it.

The result is fewer tickets and less waiting, without handing away oversight. Show me openers who have not purchased in ninety days becomes something you act on directly.

‍

See QAiry in action

‍

QAiry turns plain-language requests into production-ready SFMC audiences, so marketers can move without sitting in a query queue.

Watch it work on real segments at qairy.com/product-demos, or try it hands-on at qairy.com/try-it-free.