A marketing qualified lead (MQL) is a prospect who has been evaluated by the marketing team and determined to be more likely to become a customer than other leads in the database. The qualification is based on a combination of who the lead is - their job title, company size, industry, and other firmographic data - and what they've done - their engagement with marketing content, website visits, email interactions, and other behavioural signals. The MQL is the handoff point between marketing and sales. When a lead reaches MQL status, marketing is saying: this person fits our target profile and has shown enough interest to warrant a direct sales conversation. Sales then decides whether to accept the lead and pursue it further. Getting this definition right matters more than most teams realise. Too loose, and sales gets flooded with leads that aren't ready to buy. Too strict, and genuine opportunities sit in the nurture too long and go cold - or worse, go to a competitor. At Sojourn Solutions, MQL definition and lead handoff design is one of the most common areas we work on with clients, because it sits at the exact point where marketing and sales either align or fall apart. How a lead becomes an MQL The mechanics vary by organisation, but the process follows a consistent pattern across most B2B marketing operations. A lead enters the database through some form of engagement - a form submission, a webinar registration, a content download, a website visit that gets tracked. From that point, the marketing automation platform begins collecting data on the lead: who they are (based on the information they provided and any enrichment data pulled from third-party sources) and what they do (based on their ongoing engagement with marketing touchpoints). That data feeds a lead scoring model. The scoring model assigns points based on fit criteria (does this lead match our ideal customer profile?) and engagement criteria (is this lead actively interacting with our marketing?). When the lead's score crosses a predefined threshold, the platform automatically changes their status to MQL and routes them to sales - usually through a notification, a task assignment in the CRM, or a direct sync into a sales queue. The key word is "predefined." The MQL threshold should be a deliberate decision based on data, not a guess. The best way to set it is to look at your closed-won deals, work backwards to see what those leads' scores looked like when they were first handed to sales, and use that as your baseline. MQL vs SQL: what's the difference The terms get confused constantly, so it's worth being precise. An MQL (marketing qualified lead) is a lead that marketing has qualified based on fit and engagement. Marketing is saying: this person looks like our buyer and is showing interest. They're worth a conversation. An SQL (sales qualified lead) is a lead that sales has accepted and further qualified through direct interaction - usually a discovery call or an initial conversation. Sales is saying: I've spoken to this person and confirmed there's a real opportunity worth pursuing. The progression is MQL → sales accepts the lead → sales qualifies through conversation → SQL → opportunity. The gap between MQL and SQL is where most friction lives. Marketing hands over a lead they believe is qualified. Sales talks to the lead and decides it's not ready, not a fit, or not worth pursuing. If this happens occasionally, it's normal - not every MQL will convert. If it happens consistently, either the MQL definition is too loose, the scoring model needs recalibration, or marketing and sales aren't aligned on what "qualified" actually means. What makes a good MQL definition A good MQL definition is specific enough that both marketing and sales can agree on what it means, and measurable enough that the marketing automation platform can apply it consistently. It includes fit criteria. Not every engaged lead is a good lead. Someone who downloads every piece of content on your site but works at a company with five employees and no budget isn't an MQL - they're an engaged non-buyer. Fit criteria ensure that only leads matching your ideal customer profile can reach MQL status, regardless of how engaged they are. It includes engagement criteria. Fit alone isn't enough either. A VP of Marketing at a perfect-fit company who has never visited your website or opened an email isn't ready for a sales conversation. Engagement criteria ensure that the lead has demonstrated active interest - not just passive existence in your database. It's agreed upon by both marketing and sales. This is the part most teams skip. Marketing defines MQL, sales inherits it, and the arguing starts when the leads don't convert. The MQL definition should be a joint decision. Sales needs to agree that leads meeting these criteria are worth their time. If they don't agree, the definition needs to change - not the complaints. It's reviewed regularly. Buyer behaviour shifts. Products evolve. Markets change. An MQL definition that worked 12 months ago may not work today. The threshold, the scoring weights, and the fit criteria should be reviewed at least quarterly against actual conversion data from MQL to closed-won. Common MQL problems Most MQL programmes fail not because the concept is wrong but because the execution drifts over time. The threshold is set once and never revisited. The scoring model was calibrated when the programme launched, the threshold was set based on limited data or best guesses, and nobody has checked whether it still makes sense. Meanwhile, buyer behaviour has changed, the product has evolved, and the leads crossing the threshold look different from the ones that originally informed it. Marketing and sales have different definitions of "qualified." Marketing thinks MQL means "ready for a conversation." Sales thinks it means "ready to buy." These are not the same thing, and the gap between them is where trust breaks down. If sales is rejecting 60% of MQLs, the definitions aren't aligned - and that's a process problem to solve together, not a blame game. Scoring rewards activity instead of intent. A lead who opens every email and downloads every ebook may just be a curious researcher - not a buyer. If the scoring model over-weights volume of activity without distinguishing between high-intent actions (visiting pricing pages, requesting a demo) and low-intent actions (reading blog posts, opening emails), the MQL threshold will be crossed by leads who are engaged but not buying. No feedback loop from sales. Marketing sends MQLs to sales and never hears back about what happened. Did the lead convert? Was the timing right? Was the lead actually a good fit? Without a structured feedback loop - regular reviews of MQL-to-SQL conversion rates, win rates, and qualitative sales feedback - the MQL definition can't improve. It just keeps producing the same mix of good and bad leads without anyone knowing the ratio. MQL isn't dead - it's misunderstood There's a persistent argument in B2B marketing that the MQL is outdated - that account-based marketing and buying committee dynamics have made individual lead qualification irrelevant. There's a grain of truth in this: B2B buying decisions involve multiple stakeholders, and qualifying one person at a time doesn't capture the full picture. But the MQL isn't the problem. The problem is treating MQL as the only qualification signal instead of one signal within a broader framework. In a mature marketing operation, MQL works alongside account-level engagement scoring, buying committee coverage tracking, and intent data to provide a complete picture of readiness. The lead-level view tells you which individual is engaged. The account-level view tells you whether the organisation as a whole is in-market. Both matter. Discarding individual lead qualification because account-based approaches exist is like discarding email because social media exists - the channels serve different purposes and work best together. Getting the MQL right The MQL is a simple concept with complex execution. Getting it right requires clean data, a calibrated scoring model, a definition that marketing and sales both own, and a feedback loop that keeps the whole system honest. At Sojourn Solutions, we build and optimise MQL programmes - from scoring model design through to sales handoff configuration and ongoing calibration. If your MQL programme isn't producing leads that sales trusts, or if you're not sure whether your current definition still reflects how your buyers actually behave, we're happy to help.

Account-based marketing (ABM) is a B2B strategy that focuses marketing and sales resources on a defined set of target accounts rather than casting a wide net across the entire market. Instead of generating as many leads as possible and qualifying them down, ABM starts with the accounts most likely to become high-value customers and builds tailored campaigns specifically for them. The fundamental shift is from volume to precision. Traditional demand generation asks "how many leads did we generate?" ABM asks "are we engaging the right accounts, with the right people, at the right time?" At Sojourn Solutions, we help B2B organizations build and operationalize ABM programmes using platforms like Demandbase alongside marketing automation platforms including Marketo, Eloqua, and HubSpot. This guide covers what ABM is, how it works, the different approaches, what technology it requires, and what it takes to run it well. How ABM differs from traditional demand generation Traditional demand generation works like a funnel. Marketing casts a wide net - content, ads, events, webinars - to attract as many prospects as possible. Those prospects enter the top of the funnel, get scored and nurtured, and the ones that qualify eventually get passed to sales. The model optimizes for lead volume at the top and conversion rate through the middle. ABM inverts that model. Instead of starting broad and narrowing down, ABM starts narrow and goes deep. The sales and marketing teams agree on a list of target accounts - based on firmographic fit, revenue potential, strategic value, or intent signals - and then build campaigns designed specifically to engage those accounts. The difference matters because B2B buying decisions are rarely made by one person. A typical enterprise deal involves a buying committee of anywhere from 5 to 15 stakeholders across different departments - procurement, IT, finance, the end-user team, and often executive sponsors. Traditional lead-based marketing captures one person at a time and hopes they influence the rest. ABM targets the account as a whole, engaging multiple stakeholders with messaging tailored to their individual roles and concerns. The three tiers of ABM ABM isn't one approach - it's a spectrum. Most organisations run one or more of these tiers depending on the value of the accounts they're pursuing. One-to-one ABM (strategic ABM). This is the most resource-intensive approach, reserved for your highest-value target accounts - typically the top 10 to 50. Each account gets a fully bespoke campaign: custom content, personalised outreach, dedicated account teams, and often direct executive engagement. The investment per account is high, but so is the potential return. One-to-one ABM works when the deal size justifies the effort - typically six-figure or seven-figure contracts. One-to-few ABM (cluster ABM). This tier groups similar accounts into small clusters - usually 5 to 15 accounts per cluster - based on shared characteristics like industry, company size, or common challenges. Campaigns are tailored to the cluster rather than to each individual account, striking a balance between personalisation and scalability. It's the most common starting point for organisations new to ABM. One-to-many ABM (programmatic ABM). This is ABM at scale, targeting hundreds or even thousands of accounts with personalized but largely automated campaigns. The personalisation is lighter - dynamic content, account-specific ads, industry-tailored messaging - but the reach is significantly broader. Programmatic ABM relies heavily on technology and intent data to identify and prioritise accounts at scale. Most mature ABM programmes run all three tiers simultaneously. The top accounts get the full one-to-one treatment. The next tier gets cluster campaigns. The broader target account list gets programmatic coverage. The art is in deciding which accounts belong in which tier - and being willing to move them between tiers as engagement and opportunity develop. The technology behind ABM ABM requires technology that traditional demand generation programmes don't. The core stack typically includes several components working together. ABM platform. Platforms like Demandbase, 6sense, and Terminus provide the intelligence layer - account identification, intent data, engagement scoring at the account level, and advertising capabilities that target accounts rather than individuals. These platforms are the operational backbone of a programmatic ABM strategy. Marketing automation platform. Your MAP - Marketo, Eloqua, HubSpot, or others - handles the campaign execution: email, nurture sequences, landing pages, forms, and lead scoring. In an ABM context, the MAP needs to work alongside the ABM platform, sharing data about account engagement and individual lead activity. CRM. The CRM - usually Salesforce, Oracle, Microsoft Dynamics, or HubSpot CRM - is where account-level data, opportunity data, and sales activity live. ABM depends on tight integration between the CRM, the MAP, and the ABM platform so that marketing and sales are working from the same picture. Intent data. Intent data identifies accounts that are actively researching topics relevant to your solution - even before they've engaged with your content. Providers like Demandbase, Bombora, and G2 track research behaviour across the web and surface signals that indicate buying intent. This data is what allows ABM programmes to prioritise accounts based on timing, not just fit. Content and personalization. ABM at every tier requires content that's more tailored than what traditional demand generation produces. For one-to-one, that might mean custom presentations and account-specific landing pages. For one-to-many, it might mean dynamic content modules that swap messaging based on account industry or company size. The content effort scales with the tier. Building an ABM programme: where to start The most common mistake is buying ABM technology before defining the strategy. The platform doesn't create the programme - it enables it. Before evaluating any technology, get alignment on the fundamentals. Define your ideal customer profile. Not at a lead level - at an account level. What does your best-fit account look like? Company size, industry, geography, tech stack, revenue, growth stage. The ICP should be based on your closed-won data - which accounts became your most valuable customers, and what did they have in common? Build your target account list. Using your ICP, build a prioritised list of accounts. This should be a collaborative exercise between marketing and sales - marketing brings the data, sales brings the relationship context and strategic priorities. The list isn't static. It should be reviewed and updated quarterly based on engagement, intent signals, and pipeline development. Align sales and marketing on roles and expectations. ABM only works when sales and marketing operate as one team against shared accounts. That means agreeing on which accounts to target, what "engaged" looks like, when sales should get involved, and how success is measured. Without this alignment, ABM becomes marketing running campaigns at accounts that sales doesn't prioritize - which is an expensive way to achieve nothing. Start with one tier and expand. If your organisation is new to ABM, start with a one-to-few programme targeting 50-100 accounts. Build the muscle - the targeting, the content, the measurement, the sales coordination - before expanding to one-to-one or one-to-many. Trying to launch all three tiers simultaneously is how ABM programmes stall. Measuring ABM ABM requires different metrics from traditional demand generation. Lead volume is not the goal. Account engagement and pipeline impact are. Account engagement score. How actively are your target accounts engaging with your marketing? This isn't individual lead scoring - it's account-level measurement that aggregates engagement across all contacts at an account. An account where five stakeholders have each engaged with different content is more meaningful than one where a single person downloaded a whitepaper. Account coverage. How many of the key stakeholders within each target account have you reached? If your buying committee typically includes 8 people and you've only engaged 2, there's a coverage gap. ABM measurement should track how broadly you're penetrating the buying committee, not just how deeply you're engaging one person. Pipeline influenced by ABM. How much pipeline can be attributed to ABM-targeted accounts? This is the metric that matters most to leadership. It connects the ABM programme directly to revenue and demonstrates that the focused investment is generating proportional returns. Deal velocity. Are ABM-targeted deals closing faster than non-ABM deals? One of the core promises of ABM is that engaging the right accounts with tailored messaging accelerates the buying process. If it's working, you should see shorter sales cycles for ABM accounts compared to the general pipeline. Common ABM mistakes Treating ABM as a marketing-only initiative. ABM without active sales participation is just targeted advertising. Sales needs to be co-owning the account list, engaging the accounts directly, and providing feedback on what's resonating. If sales isn't bought in, the programme won't produce results. Over-investing in technology before proving the model. An ABM platform is powerful, but it won't compensate for unclear targeting, weak content, or misaligned sales and marketing teams. Prove the model with a small, focused pilot before scaling the technology investment. Targeting too many accounts. The power of ABM is focus. If your "target account list" has 5,000 accounts on it, you're running demand generation with a different label. Start with a manageable number where you can genuinely personalise the approach and expand from there. Measuring ABM with demand gen metrics. If you're measuring ABM by lead volume, you're measuring it wrong. ABM is about depth of engagement within target accounts, pipeline influence, and deal velocity - not how many individual leads entered the top of the funnel. Getting ABM right ABM is one of the most effective strategies in B2B marketing when it's executed well - and one of the most expensive ways to waste budget when it isn't. The difference is almost always in the foundations: clear ICP, focused account list, genuine sales-marketing alignment, and measurement that reflects what ABM is actually designed to achieve. At Sojourn Solutions, we help organizations build and operationalize ABM programmes - from defining the target account strategy through to platform implementation, campaign execution, and ongoing optimization. We work with Demandbase and integrate ABM workflows into marketing automation platforms including Marketo, Eloqua, HubSpot, etc. If you're considering ABM or trying to improve a programme that hasn't delivered the results you expected, we'd welcome the conversation.

Ask most enterprise teams what they fear most about AI and you will usually get the obvious answers. Bad content. Dodgy prompts. Hallucinated summaries. A sales email that sounds like it was written by a motivational fridge magnet. Annoying? Yes. Brand-damaging? Potentially. But not the real nightmare. The real nightmare is what happens when AI stops being a clever assistant and starts becoming an operator. When it can access systems. Query databases. Change records. Trigger workflows. Sync audiences. Update fields. Delete things. Move people between lifecycle stages. Send campaigns. Alter routing. Touch customer data. At that point, AI is no longer just helping your team think. It is acting inside the machinery of your business. And when that machinery is Marketing Operations, the blast radius gets very real, very quickly. A recent story reported by The Independent gives us a useful, uncomfortable example. PocketOS, a software company serving car rental businesses, suffered a major outage after an AI coding agent reportedly deleted its production database and backups in seconds. According to the report, the agent was powered by Anthropic’s Claude model via Cursor, and the company founder said there was no confirmation request before the destructive action was taken. The data was later reported as recovered, but not before customers were left unable to access key records. This is not an article about Claude. Or Cursor. Or one company having a very bad weekend. It is about what happens when AI capability moves faster than AI governance. And Marketing Operations teams should be paying very close attention... AI is moving from assistant to actor For the last couple of years, most AI use in marketing has been relatively low-risk. Draft this email, summarise this webinar, rewrite this landing page, generate campaign ideas, turn these notes into a blog outline, make this sound less like a committee had a fight in a Google Doc. Useful, yes. Transformational, occasionally. Dangerous, usually only in the “please don’t publish that without a human reading it” sense. But that phase has ended... AI is now being connected directly into business systems. CRM. MAP. CDP. DAM. Analytics. Data warehouses. Customer support platforms. Sales engagement tools. Project management tools. The places where the actual work happens and that shift changes everything... Because once an AI agent has access to your Marketing Automation Platform, it is no longer just suggesting a nurture flow. It may be able to build one. Once it has access to your CRM, it is no longer just analysing lifecycle data. It may be able to update it. Once it has access to campaign operations, it is no longer just spotting a QA issue. It may be able to “fix” it. And the word “fix” is doing a terrifying amount of work there. The PocketOS example matters because the agent was reportedly working on a routine task when it decided, without explicit instruction, to take a destructive action. The founder described the failure as systemic, warning that AI-agent integrations are being pushed into production infrastructure faster than the safety architecture needed to make them safe. That line should be printed out and stuck above every enterprise AI planning session. Because it is exactly where many marketing teams are heading. Marketing Operations has more risk than people think Marketing Operations is often talked about as if it is mostly campaign execution, platform admin, and workflow plumbing. That is dangerously outdated. Modern Marketing Operations sits across customer data, consent, segmentation, scoring, routing, lifecycle management, attribution, campaign orchestration, sales handoff, analytics, and increasingly, AI enablement. In other words, MOPs touches the systems that decide: Who gets contacted. What they receive. When they receive it. How they are scored. How they are routed. What data is stored. What consent rules apply. Which audiences are synced to paid media. Which leads go to sales. Which customers are suppressed. Which reports leadership trusts. Give an AI agent the wrong level of access in that environment and you do not just risk a weird email subject line - you risk operational damage. An AI agent with excessive permissions could accidentally overwrite lead source fields. It could change scoring logic. It could update suppression criteria. It could sync the wrong audience to LinkedIn. It could remove members from an active nurture. It could expose sensitive customer data in a prompt response. It could “clean up” a list that should never have been touched. It could trigger a campaign before approvals are complete. None of that requires malice. It only requires an AI system trying to be helpful in an environment where the rules, permissions, escalation paths, and human controls have not been properly designed. Which is, frankly, how a lot of AI is being introduced right now. A demo works, someone senior gets excited, a team plugs it into a tool, everyone calls it innovation, nobody asks who owns the risk. Lovely. Very modern. Also how you end up explaining to Legal why an AI agent just “optimised” your consent architecture into a crater. Guardrails are not a nice-to-have. They are the operating model. The phrase “AI guardrails” gets thrown around a lot, usually in the same vague tone as “best practice” and “alignment”. That is a problem, because guardrails are not a brand slogan. They are practical, technical, operational controls. In Marketing Operations, AI guardrails should define what AI can and cannot do across your MarTech stack. That includes: What systems AI can access. What data it can read. What data it can write. What actions require approval. What actions are completely prohibited. What prompts are acceptable. What data can be included in prompts. Who can activate AI-powered workflows. How AI actions are logged. How exceptions are handled. How rollback works. Who reviews outputs. Who owns incidents. Who gets woken up when something goes sideways. This is the unglamorous bit. Which is exactly why it matters. The AI industry loves the shiny front end. The magic box. The productivity story. The “your team can move ten times faster” promise. But speed without control is not transformation. It is just a faster way to make a bigger mess. And MOPs teams already know this. They have spent years learning the hard way that automation is only valuable when it is governed. Nobody serious lets people casually edit live scoring models, suppression rules, campaign templates, or data flows without process. We have change control for a reason. We have QA for a reason. We have sandbox environments for a reason. We have approval workflows for a reason. AI does not remove that need. It increases it. The real risk is excessive agency One of the most useful concepts in AI security is “excessive agency”. OWASP describes this as the risk that an LLM-based system is given too much autonomy, functionality, or permissions, allowing it to perform damaging actions when something goes wrong. That is exactly the risk Marketing Operations teams need to understand. The problem is not simply that an AI system might generate a bad answer. The problem is that the bad answer might be connected to an action. Bad recommendation plus no permissions? Annoying. Bad recommendation plus write access? Operational incident. Bad recommendation plus production access? Clear your afternoon. In a MOPs context, excessive agency might look like an AI tool that can both analyse a campaign and edit it. Or an agent that can identify “bad data” and delete it. Or a chatbot that can query customer records without strict access controls. Or a workflow assistant that can update segmentation logic without human approval. Or an AI-powered QA tool that can “fix” campaign errors directly in a live MAP. Some of those capabilities may be useful eventually. But “useful” and “safe to deploy without governance” are not the same thing. That distinction is where a lot of organisations are going to get hurt. Governance should come before integration This is the bit many companies are getting backwards. They start with the tool. They ask: “What AI platform should we use?” Or: “Can we connect this to Marketo?” Or: “Can it work with HubSpot?” Or: “Can it read Salesforce data?” Or: “Can we automate campaign QA?” Or: “Can it build workflows for us?” Those are not bad questions. They are just not the first questions. The first questions should be: What are we allowing AI to do? Where should it only advise? Where can it act? Where must it never act? Which systems are too sensitive for direct access? Which data types are restricted? Which use cases require human approval? How do we test safely before production? How do we prove what happened after the fact? How do we recover if something breaks? That is governance. Not a dusty policy PDF. Not a theoretical risk matrix. Not a 48-page deck that makes everyone lose the will to live by slide seven. Real governance is the practical operating model that lets teams use AI without gambling with their stack. The NIST AI Risk Management Framework is built around four core functions: Govern, map, measure, and manage. It treats governance as the foundation that informs the rest of AI risk management, not as a decorative afterthought once the tool has already been plugged in. That is the mindset Marketing Operations needs. Before AI gets access, define the rules. Before AI takes action, define the approvals. Before AI touches data, define the boundaries. Before AI goes near production, define the rollback plan. Wildly radical stuff, apparently. Why this matters specifically for enterprise MOPs Enterprise Marketing Operations is not a sandbox. It is an interconnected operating environment with a lot of dependencies. A change in one place can cause problems somewhere else. A field update in the CRM can affect segmentation in the MAP. A lifecycle stage change can affect sales routing. A consent flag can affect campaign eligibility. A scoring model adjustment can affect MQL volume. A sync rule can affect paid media audiences. A data enrichment change can affect reporting.A campaign status update can affect attribution. AI does not automatically understand those dependencies. It may understand the task. It may even understand the platform. But that does not mean it understands your operating model, your governance structure, your internal politics, your data history, your compliance obligations, your exception cases, your sales process, or the weird legacy field that absolutely nobody likes but half the reporting suite still depends on. Every MOPs team has at least one of those fields - probably seven. This is why generic, off-the-shelf AI deployment is risky in enterprise Marketing Operations. Not because AI is bad. Because context matters. The same action can be harmless in one environment and catastrophic in another. Deleting a test segment in a sandbox is not the same as deleting a suppression list in production. Updating a campaign status in a demo instance is not the same as changing live program logic across regions. Recommending a data cleanup is not the same as executing one. Governance is what separates those scenarios. AI governance is not anti-AI This point matters, because too often governance gets framed as the boring department of “no”. That is lazy. Good AI governance is not about slowing everything down. It is about making AI usable at scale. Without governance, AI adoption gets stuck in one of two bad places. Either teams move too fast and create risk, or everyone becomes so nervous that AI stays trapped in low-value use cases like content drafting and meeting summaries. Neither is good enough. The real opportunity is in using AI to improve how Marketing Operations actually runs. Campaign QA. Data quality checks. Workflow diagnostics. Audience validation. Documentation. Change impact analysis. Platform monitoring. Performance insights. Process recommendations. Governance enforcement. But those use cases only work if the foundations are there. You need clear permissions. You need human oversight. You need approval thresholds. You need audit trails. You need data boundaries. You need incident processes. You need ownership. You need testing environments. You need a sensible definition of what “safe enough” means. That is not bureaucracy. That is how you get AI out of the toy box and into the operating model. What should AI governance include in Marketing Operations? A practical AI governance framework for MOPs should cover six core areas. 1. Use case classification Not every AI use case carries the same level of risk. A tool that helps draft campaign briefs is low risk. A tool that analyses nurture performance is moderate risk. A tool that updates live segmentation rules is high risk. A tool that can change production data without approval should trigger every alarm bell in the building. Use cases need to be classified based on access, autonomy, data sensitivity, customer impact, compliance exposure, and reversibility. If an action cannot be easily reversed, it should not be casually delegated to AI. There you go. Put that on a mug. 2. Access and permissions AI should never get broad access by default. It should have the minimum access needed for the specific use case. Read-only where possible. Sandbox first. Production only when justified. Write access only with controls. Destructive actions blocked or escalated. This is basic operational hygiene, but AI makes it more urgent because agents can move quickly, misinterpret instructions, and chain actions together in ways humans may not expect. The question is not “Can the AI do this?” - The question is “Should it be allowed to?” 3. Human approval points Some actions should always require human approval. Sending campaigns. Deleting data. Changing scoring models. Updating consent logic. Syncing paid media audiences. Editing live nurture flows. Changing routing rules. Altering lifecycle stages. Modifying integrations. Approval should not be vague. It should be designed into the workflow. Who approves? At what threshold? With what information? Where is that approval recorded? What happens if approval is denied? “Someone will probably check it” is not a control. It is a hope wearing a lanyard. 4. Logging and auditability If AI takes an action, you need to know what happened. What did it access? What prompt or instruction triggered the action? What data did it use? What did it change? When did it change it? Who authorised it? Was there a human review? Can the action be rolled back? This is especially important in Marketing Operations because problems often surface downstream. A campaign underperforms. Sales complains about lead quality. Reporting looks strange. An audience is wrong. Consent exclusions fail. Without logs, you are left reconstructing the crime scene with vibes and Slack messages. Not ideal. 5. Testing and sandboxing AI should not be learning its boundaries in your production environment. New AI use cases should be tested in controlled conditions. Synthetic data where possible. Sandboxes before live systems. Limited pilots before wider rollout. Clear success criteria. Failure-mode testing. Red-team style scenarios. Rollback rehearsals. The goal is not to prove AI works when everything goes perfectly. The goal is to understand what happens when it does something weird. Because it will. 6. Ownership and escalation AI governance fails when everyone assumes someone else owns it. Marketing thinks IT owns it. IT thinks Marketing owns the use case. Legal thinks Procurement reviewed it. Procurement thinks Security signed it off. Security thinks the platform owner configured it. The platform owner thinks the AI vendor handled it. Beautiful. A governance conga line straight into the bin. Every AI-enabled MOPs use case needs named ownership. Business owner. Technical owner. Data owner. Risk owner. Escalation contact. Review cadence. If nobody owns the risk, the risk owns you. Why external expertise matters This is where working with a specialist consultancy becomes valuable. Not because internal teams are incapable. Far from it. Most enterprise MOPs teams know their systems incredibly well. They know the weird dependencies, the fragile workflows, the stakeholder sensitivities, the data quality issues, and the operational pain points. But AI governance across Marketing Operations requires a specific blend of skills. You need to understand marketing automation. You need to understand CRM data models. You need to understand campaign operations. You need to understand privacy and consent implications. You need to understand workflow architecture. You need to understand AI capability and risk. You need to know where automation genuinely helps and where it should be kept on a very short lead. That combination is not always sitting neatly inside one internal team. A consultancy like Sojourn brings the outside perspective and the MOPs-specific experience needed to help organisations introduce AI without treating their MarTech stack like a science experiment with invoices. Sojourn’s role is not to turn AI off. It is to help enterprises turn it on properly. That means identifying the right use cases, assessing readiness, defining guardrails, mapping risk, setting approval processes, documenting controls, supporting rollout, and making sure AI fits the operating model rather than crashing through it like an overexcited intern with admin rights. The uncomfortable truth The PocketOS story is dramatic because the outcome was immediate and visible. Database gone. Customers affected. Panic stations. Marketing Operations failures are often quieter. A field gets overwritten. A segment rule changes. A suppression logic breaks. A nurture excludes the wrong accounts. A scoring change floods sales with rubbish. A paid audience syncs with the wrong criteria. A consent rule is misread. A report becomes unreliable. A workflow quietly routes valuable leads into the void. No sirens. No dramatic explosion. Just slow operational damage. That is what makes AI governance in MOPs SO important. The risk is not always one giant disaster. Sometimes it is hundreds of small, invisible decisions made by a system nobody is properly supervising. And by the time anyone notices, the dashboard is lying, the sales team is annoyed, the campaign data is messy, and someone is saying “can we just manually fix it?” in the sort of tone that ruins a Tuesday. The answer is not fear. It is control. AI has a serious role to play in the future of Marketing Operations. It can reduce manual QA. It can spot issues faster. It can support better documentation. It can help teams understand complex workflows. It can identify data anomalies. It can speed up campaign planning. It can improve operational consistency. It can help MOPs teams move from firefighting to proactive management. But only if it is introduced with discipline. The lesson from the PocketOS incident is not “AI is too dangerous to use.” The lesson is “AI is too powerful to introduce casually.” That distinction matters. Marketing Operations teams do not need panic. They need governance. They need practical guardrails. They need clear controls. They need expert support. They need a way to move forward without pretending risk magically disappears because the demo looked impressive. AI is coming deeper into the MarTech stack. That is not really up for debate. The question is whether it arrives as a governed capability or an unsupervised operator with too much access and not enough judgement. One of those helps your team scale. The other deletes the database and apologises afterwards. Choose wisely. Discover our AI Services

Ask any AI assistant to help you build a marketing tech stack. Try any of them. The answer will look almost identical every time. The same CRM. The same marketing automation platform. The same payment processor. The same cloud hosting. The same analytics tool. The same names, in the same order, for every user, every time, regardless of company size, industry, budget, or whether any of these tools are actually the best fit. Now multiply that by the millions of people asking AI the same question every day. Every founder building their first stack. Every marketing manager evaluating tools. Every ops team planning a migration. They're all getting the same recommendations - not because someone evaluated the market and decided these were the right answers, but because these companies dominate the data AI was trained on. AI isn't just reflecting the market. It's reinforcing it. Every recommendation makes the dominant player more dominant. Every time AI names the market leader instead of mentioning an alternative the user has never heard of, that alternative loses a potential customer it never had a chance to win. Not because it's worse. Because AI doesn't know it exists - or doesn't trust it enough to recommend. The training data problem AI recommendations aren't based on independent evaluation. They're based on patterns in training data - which means they reflect what already exists, not what's best. The companies that get recommended are the ones with the most content, the most documentation, the most integration guides, the most blog posts, the most Stack Overflow answers, the most everything online. That's not a quality signal. That's a volume signal. The biggest companies have the most content because they've been around the longest and have the biggest marketing budgets. A startup with a genuinely better product but a fraction of the online footprint doesn't stand a chance in an AI recommendation - because AI isn't evaluating products. It's pattern-matching against the corpus it was trained on, and that corpus is dominated by incumbents. This creates a feedback loop that gets worse over time. AI recommends the big players. More people adopt them. More content gets created about them. AI's training data becomes even more skewed toward them. The next generation of recommendations is even more concentrated. The smaller players fall further behind with each cycle, not because their products are declining but because their visibility in AI's world is shrinking relative to the incumbents. This isn't a search problem. It's a decision problem. When search engines dominated discovery, at least the user saw a list of options. Page one had ten links. The user could scroll, compare, click around. Smaller players could buy ads, invest in SEO, or get discovered through review sites and word of mouth. The playing field wasn't level, but it was a field. AI doesn't give you a list. It gives you an answer. One confident recommendation, presented as though it's the obvious choice. The user doesn't see what was considered and rejected. They don't see the alternatives that almost made the cut. They see one name and move on - because the whole point of asking AI was to skip the evaluation process. That's the shift. AI isn't helping people discover options. It's making choices for them. And the choices it makes are biased toward whoever was biggest when the model was trained. The MOPs angle If you work in Marketing Operations, this hits close to home. The platforms you implement, the tools you integrate, the stack you build - all of it is increasingly influenced by what AI recommends to the people making buying decisions upstream. A CMO asks AI "what's the best marketing automation platform for a mid-market B2B company" and gets the same two or three names. Every time. Not because AI evaluated their specific requirements, their team's capabilities, their integration needs, or their budget constraints. Because those platforms have the largest training data footprint. The platforms that don't get recommended - the ones that might actually be a better fit for a particular team's needs - don't even enter the conversation. The CMO never hears about them. The evaluation never happens. The decision was made before the decision process started. For MOPs teams, this means you're increasingly working with platforms that were chosen by AI recommendation rather than by genuine evaluation. And when the platform doesn't fit, you're the one building workarounds and writing custom solutions to close the gap between what was recommended and what was actually needed. Who benefits and who loses The winners are obvious: The companies AI already recommends. They get a recommendation engine that runs 24/7, across every AI platform, for free, reinforcing their market position with every query. They didn't build this. They didn't pay for it. It just happened - a byproduct of being the biggest when the training data was assembled. The losers are everyone else. Every startup, every niche tool, every regional alternative, every new entrant that does one thing brilliantly but doesn't have the online footprint to compete with an incumbent's training data presence. These companies now face a discovery barrier that didn't exist five years ago - one they can't buy their way past, can't SEO their way past, and can't content-market their way past, because the recommendation is happening inside a model they have no access to and no influence over. And the users lose too, even if they don't know it. They're getting confident recommendations that feel personalised but aren't. They're making decisions based on AI outputs that reflect market share, not market fit. They're building stacks, hiring teams, and committing budgets based on recommendations that were shaped by training data, not by their actual needs. What to do about it Nobody is talking about this as a competition issue yet. The AI companies aren't incentivised to surface it - their models work by being confident, not by presenting uncertainty. The incumbent platforms aren't going to complain - they're the beneficiaries. So the responsibility falls on the people making the actual decisions. If you're evaluating tools, stop treating AI recommendations as a shortlist. Treat them as a starting point that's biased toward incumbents by design. Ask AI to name alternatives. Ask it to compare the market leader against two smaller competitors for your specific use case. Ask it what it's not recommending and why. The model won't volunteer this information, but it can provide it when pushed. If you're advising on stack decisions - as a consultant, an ops lead, or anyone with influence over platform choices - build a step into your evaluation process that specifically accounts for AI recommendation bias. Before accepting the default answer, ask: Are we choosing this because it's the best fit, or because it's the most visible? And if you're building a product that competes against an incumbent, understand that your discovery problem just changed. SEO and content marketing still matter, but they're no longer enough. Your product needs to be structured, documented, and positioned in a way that AI can find, understand, and confidently recommend. That's a new discipline - and the companies that figure it out first will break through the recommendation loop that's currently locking them out. AI was supposed to democratise access to information. Right now, it's consolidating it. That's worth knowing before you take the next recommendation at face value. Discover our Services

Most B2B LinkedIn advertising has a targeting problem. Not because the platforms are useless. Not because the creative is always terrible. Not even because the audience is completely wrong. The bigger issue is that too many campaigns still treat the buyer journey as if it is one flat, convenient spreadsheet. Everyone gets the same message. The person just starting to understand the problem gets the same advert as the person already comparing partners. The account vaguely showing interest gets the same CTA as the account showing much stronger buying signals. The buying committee member who needs education gets the same proof point as the stakeholder who needs a reason to act. Then everyone gathers around the performance report and wonders why the budget did not go further. The answer is usually quite simple. The message did not match the moment. ABM is not just a better account list A lot of organisations talk about account-based marketing as if the whole job is building a list of companies and pointing paid media at it. That is not ABM. That is a spreadsheet with ambition. A target account list is useful, of course. You need to know which organisations you want to reach. You need some way of identifying where there is a genuine fit between the account, the problem, the technology environment, the buying committee, and your ability to help. But an account list alone does not tell you enough. It tells you who might matter. It does not tell you whether they are paying attention. It does not tell you whether they are actively researching. It does not tell you whether they are just becoming aware of a problem or already moving closer to a decision. It does not tell you what message they need next. That is where many paid campaigns fall down. They start with “who do we want to target?” and stop there. A better question is: What does this account need to hear right now? That is where account intelligence becomes genuinely useful. Intent data should change the message, not just the audience Intent data is often treated as a targeting input. A way of deciding which accounts to include or exclude. That is part of the value, but it is not the full story. If an account is showing signs of interest, that should influence more than whether they are added to a campaign. It should influence what they are shown, how directly they are approached, and what kind of next step makes sense. There is a big difference between an account that appears to be exploring a broad issue and an account showing stronger signals around a specific solution area. Those two audiences should not be treated the same. The first may need education.The second may need evidence.The third may need a sharper reason to act. This is where stage-based advertising becomes far more effective than simply uploading a target account list and hoping the algorithm has a moment of divine inspiration. Spoiler: it usually does not. The problem with one-size-fits-all LinkedIn campaigns LinkedIn is a powerful B2B advertising platform, but it is not magic. It will let you reach people by company, role, seniority, function, industry, geography, and plenty of other useful signals. That is helpful. But if every audience receives the same message, the campaign still has a relevance problem. This is especially true in complex B2B sales. Buying committees do not move in a straight line. Different stakeholders care about different things. Some are looking for commercial impact. Some care about technical feasibility. Some are worried about risk. Some are just trying to stop a broken process from eating another quarter of their life. A generic advert cannot do all of that work. And yet many campaigns still try. They send broad thought leadership to accounts that may already be much further along. They push sales-heavy CTAs to accounts that are barely aware of the problem. They serve vague brand messaging to accounts that probably need proof. They treat “targeted” as a substitute for “relevant.” That is how budget leaks. Not dramatically. Not all at once. Just quietly, one poorly matched impression at a time. Better targeting starts before LinkedIn One of the biggest mistakes in paid media is expecting the advertising platform to do all the strategic work. LinkedIn can help you reach a defined audience. But the quality of that audience depends heavily on the thinking that happens before it gets into Campaign Manager. The stronger approach is to define the market first. That means identifying accounts where there is a clear fit between business complexity, technology environment, likely challenges, and the services or expertise you can credibly provide. For Marketing Operations, that fit matters enormously. A company with a simple tech stack, small team, and limited operational complexity is unlikely to need the same kind of support as a larger organisation managing multiple platforms, global campaigns, messy data, complex governance, and pressure to prove marketing’s contribution to revenue. The same applies to technology environment. If you have deep expertise in certain platforms, systems, or operating models, it makes sense to focus attention on accounts where that expertise is most relevant. That is not exclusionary. It is sensible. Paid media budget is not a charity. It should not be scattered lovingly across the entire internet in the hope that something nice happens. It should be focused where there is a meaningful chance of relevance. Buyer readiness should shape the campaign Once you have a better understanding of account fit and intent, the next step is to think about buying readiness. Broadly speaking, accounts can usually be grouped into different levels of awareness and engagement. Some are early. They may be showing signs of interest, but they are probably still understanding the problem. They need content that educates, challenges, and helps them see the issue more clearly. Some are warmer. They may be engaging more actively, exploring specific topics, or showing signs that the problem is becoming more important. They need proof, examples, and practical confidence. Some are further along. They may be showing stronger signals and may be closer to commercial consideration. They need sharper differentiation, clearer value, and a reason to speak to someone. The mistake is treating all of these accounts as if they are ready for the same advert. They are not. Earlier-stage accounts do not need to be shoved toward a sales conversation before they trust you. Warmer accounts do not need yet another broad “why this topic matters” article. Later-stage accounts do not need vague inspiration when they are looking for a partner who can actually help. The job of advertising changes depending on where the buyer appears to be. At the top, the job is to create recognition. In the middle, the job is to build confidence. Closer to action, the job is to create preference. That distinction matters. Match the content to the stage A simple way to think about this is: Educate early. Prove in the middle. Differentiate when the account is ready. For earlier-stage accounts, thought leadership is usually the right play. Not the bland kind that says nothing in 900 words and calls it insight. Proper thought leadership. Content that names the problem, challenges assumptions, and helps the buyer understand why the issue matters. For more engaged accounts, proof becomes more important. This is where customer stories, case studies, practical guides, and outcome-led content can do the heavy lifting. These accounts are more likely to be asking: Can this team solve problems like ours? Have they done it before? Do they understand our world? Will they make things better or just add another layer of noise? For later-stage accounts, the message can become more direct. That does not mean shouting “book a meeting” at everyone like a toddler with a LinkedIn budget. It means being clearer about why your approach is different, where you add value, and why the account should take the next step. The closer someone is to action, the less patience they have for vague content. This is how paid media becomes more useful When account intelligence and buyer-stage thinking are connected to LinkedIn advertising, the whole campaign model improves. You are no longer just asking: Who should see this ad? You are asking: Why this account?Why this person?Why this message?Why now? That is a much better foundation. It also makes performance easier to interpret. If early-stage audiences are not engaging with thought leadership, the issue may be the angle, the creative, or the problem framing. If engaged audiences are not responding to proof-led content, the issue may be credibility, relevance, or the strength of the case study. If later-stage audiences are not taking action, the issue may be differentiation, offer, friction, or timing. That is far more useful than staring at one blended campaign report and trying to extract wisdom from a click-through rate that looks like it needs medical attention. Stage-based advertising gives the performance data more context. And context is where better decisions come from. ABM and paid media need to stop living in separate rooms In many organisations, ABM strategy and paid media execution are still too disconnected. ABM teams build the account strategy. Paid media teams build the campaigns. Content teams create the assets. Sales teams ask why none of it has produced a meeting by Tuesday. Lovely. Very calming. A better model connects the whole thing. The account strategy should inform the paid media audience. The intent signals should inform the campaign structure. The buying stage should inform the message. The content should support the likely next step. The performance data should feed back into the wider ABM programme. That is how LinkedIn advertising becomes part of a proper account-based motion, rather than a very expensive noticeboard. Less reach. More relevance. There is still a strange obsession in B2B with reach. More impressions. Bigger audiences. Larger numbers in the report. But in ABM, reach is not the prize. Relevance is. A smaller, better-qualified audience with a sharper message will usually be more valuable than a huge audience that technically matches a few filters but has no clear reason to care. The goal is not to be seen by everyone. The goal is to be noticed by the right people, inside the right accounts, with a message that makes sense for where they are in the buying process. That is how paid media starts working harder. Not by shouting louder, but by being more precise. The real opportunity The real opportunity is not just connecting platforms. It is connecting thinking. Account fit. Intent. Buyer readiness. Paid media targeting. Content strategy. Sales follow-up. When those pieces are aligned, LinkedIn advertising becomes much more than a traffic driver. It becomes a way to support account progression, build familiarity, create preference, and reduce wasted spend. That does not mean every advert will suddenly perform beautifully. This is still B2B marketing, not witchcraft. But it does mean campaigns are built on stronger logic. And that matters. Because the future of B2B advertising is not more generic campaigns aimed at broader audiences. It is sharper account selection, better use of intent, smarter stage-based messaging, and a much clearer understanding of what the buyer needs next. Your LinkedIn ads may not be failing because LinkedIn is the problem. They may be failing because every buyer is being treated as if they are in the same place. And they are not. Discover our ABM Services

The risk isn't that your team is using AI. The risk is that they're feeding it data you're responsible for - client data, prospect data, CRM data - without any shared understanding of what's allowed, what's not, and who's accountable when something goes wrong. And right now, in the vast majority of organisations, that shared understanding doesn't exist. There's no policy. There's no guidance. There's just a team doing their best work with the best tools available and hoping nobody asks uncomfortable questions. This isn't hypothetical. It's Tuesday. The gap between "we use AI" and "we have rules about how we use AI" has become one of the biggest unmanaged risks in Marketing Operations. Not because the tools are dangerous. Because the tools are useful - so useful that adoption outran governance by about two years. Consider what a typical MOPs practitioner might paste into an AI tool in a normal working week. Campaign performance data tied to specific accounts. CRM exports with lead scores, lifecycle stages, and sales notes. Email copy containing personalisation tokens that reference real people. None of that is malicious. All of it is efficient. And most of it involves personal data that, depending on your jurisdiction, is covered by GDPR, CCPA, or equivalent regulations that your legal team spent significant time and money building compliance frameworks around. Those compliance frameworks were designed for your CRM, your MAP, your data warehouse - systems with known data processing agreements, documented retention policies, and controlled access. They were not designed for a situation where someone copies 500 contact records into a third-party AI chat window that may or may not retain the input, may or may not use it for model training, and definitely wasn't included in your last data protection impact assessment. The AI tools aren't the problem. The absence of rules is. To be clear: This is not an argument against using AI. That ship sailed. AI is now fundamental to how MOPs work gets done, and pretending otherwise helps nobody. The issue is that most organisations skipped the step between "AI is useful" and "we have clear guidelines for using it." They went straight from experimentation to daily dependence without ever defining the boundaries. What data can go into an AI tool? Nobody decided. Which AI tools are approved? Nobody compiled a list. What happens if someone pastes data from a client engagement into a personal ChatGPT account? Nobody thought about it. Who is responsible if pasted data ends up in a training set and resurfaces in someone else's output? Nobody wants to answer that one. The result is a team making individual judgement calls, dozens of times a day, with no framework to guide them. Some people are conservative and avoid pasting anything sensitive. Some people paste everything because it's faster and nobody told them not to. Most people are somewhere in the middle, vaguely uncomfortable but not uncomfortable enough to stop. That's not a sustainable position. It's a pre-incident position. What's actually at risk There are three layers of risk, and they escalate. The first is data retention. Different AI platforms handle inputs differently. Some retain inputs to improve their models unless you explicitly opt out. Some retain inputs for a period as part of their service. Some offer enterprise tiers with no-retention guarantees. Most practitioners don't know which tier their organisation is on, because nobody told them. If your team is using free or personal accounts - which many are - the retention defaults are almost certainly broader than your data compliance framework allows. The second is data leakage. When data goes into an AI model's training set, it doesn't come back out in recognisable form - but elements can resurface in unexpected ways. The more specific and structured the input, the higher the theoretical risk. Nobody has had a major public incident tied to B2B marketing data leaking through an AI model. Yet. But "it hasn't happened publicly" is not the same as "it can't happen," and it's definitely not a position your legal team would endorse. The third is regulatory exposure. If your organisation operates under GDPR, you have specific obligations about where personal data gets processed, by whom, and on what legal basis. Pasting personal data into an AI tool that wasn't included in your processing records, wasn't covered by a data processing agreement, and wasn't part of the consent basis you collected the data under is, technically, a compliance gap. Whether anyone will notice is a different question from whether it's compliant. And the answer to the compliance question is almost certainly no. The fix isn't complicated. It's just overdue. The good news is that building a sensible AI usage policy for a Marketing Ops team is not a six-month governance project. It's a conversation, a document, and a decision about where the lines are. Start with which tools are approved. If your organisation has enterprise accounts with data processing agreements in place - most major AI platforms offer these on paid tiers - those are the tools the team should use. Personal accounts, free tiers, and unvetted tools should be off limits for any work involving client or prospect data. That's not restrictive. That's basic hygiene. Then define what data can and can't go in. A useful framework is to think about it in tiers. Publicly available information - company names, general industry categories, publicly listed job titles - is low risk. Internal operational data - campaign structures, automation logic, anonymised performance metrics - is medium risk and probably fine in an approved tool. Personal data - names, email addresses, contact records, anything tied to an identifiable individual - needs explicit rules, and in many cases the answer should be "don't paste it." Make the policy specific enough to be useful. "Use AI responsibly" is not a policy. "Do not paste CRM contact records into any AI tool that is not on the approved list" is a policy. "If you need to use AI to clean or segment a list containing personal data, use [approved tool] on the enterprise account and remove names and email addresses first" is a policy. People follow rules they can understand. They ignore principles that sound nice but don't tell them what to do at 3pm on a Wednesday when they're trying to fix a list. Finally, tell people. The most common reason teams don't follow AI data policies is that nobody communicated the policy. It lives in a document nobody reads, or it was mentioned once in a meeting that half the team missed. If you want compliance, you need a one-page guide that's easy to find, easy to understand, and explicitly covers the five or six tasks where practitioners most commonly use AI with company data. Waiting for an incident is not a strategy Every organisation that eventually builds an AI data policy does so for one of two reasons. Either someone thought ahead and built it proactively, or something went wrong and they built it under pressure. The proactive version takes a week. A conversation with legal, a conversation with IT, a conversation with the team leads, and a document. The reactive version takes months - because it comes with an incident review, a legal assessment, a communications plan, and the kind of organisational anxiety that makes everyone overcorrect. Right now, most B2B marketing teams are sitting between these two scenarios. AI usage is widespread, data is flowing into tools that aren't governed, and nobody has had the conversation yet. It's working fine. Until it isn't. The policy doesn't need to be perfect. It needs to exist. Because the alternative isn't "no rules and everything is fine." The alternative is "no rules and everyone is guessing." And guessing, at scale, with other people's data, is not something any organisation should be comfortable with for long. Discover our AI Services

If you work in Marketing Operations, you've probably seen the news. Claude - Anthropic's AI assistant - can now connect directly to Marketo, HubSpot, Salesforce, and hundreds of other tools via the Model Context Protocol (MCP). It can query live CRM data, create records, manage lists, and interact with your marketing automation platform from inside a chat window. It's a genuine step forward. And it's worth understanding clearly - both what it makes possible and where it falls short. Because connecting an AI to your platform is not the same as having an AI that knows how to use it. What Claude + MCP actually does MCP is an open protocol that lets AI assistants connect to external tools. Adobe launched an official Marketo MCP server with over 100 operations - forms, programs, smart campaigns, leads, emails, lists, folders. HubSpot has a native connector in Claude's directory. Salesforce integrates through Agentforce and third-party MCP servers. Middleware platforms like CData Connect AI offer access to 350+ data sources in a single setup. Once connected, Claude can pull live data from your MAP and CRM, answer questions about your instance, create and update records, and execute API operations - all through natural language. For a MOPs practitioner who knows exactly what they need, this is useful. You can ask Claude to find leads matching specific criteria, pull campaign performance data, or create records without switching between platforms. It's a faster way to interact with your existing APIs. That's the strength. It's also where the limitations begin. There's a difference between talking to your platform and working inside it. Claude + MCP gives you a general-purpose AI with access to your platform's API. It can do what the API can do - which is a lot. But it approaches every task from scratch. It doesn't know your naming conventions. It doesn't know your campaign architecture. It doesn't know your QA process, your scoring model logic, or the reason your nurture programs are structured the way they are. Every interaction with Claude starts with you explaining what you need, how you need it, and what the constraints are. The quality of the output depends entirely on the quality of your prompt. If you know exactly what to ask for and how to ask for it, Claude will execute. If you don't - or if the task involves institutional knowledge that lives in your team's heads rather than your platform's data - Claude is guessing. This is the gap that purpose-built AI agents are designed to close. MOPsy, for example, was configured to work inside specific MAP instances - tuned to naming conventions, folder structures, and QA rules during setup. When it builds a campaign, it doesn't need the user to explain what a campaign looks like in their environment. That context is already there. It's a different approach. Claude gives you breadth - connect to anything, ask anything. A purpose-built agent trades that breadth for depth inside a specific operational domain. The prompt problem This is the part that matters most for day-to-day MOPs work. Claude + MCP requires you to be a good prompter. You need to know the right questions to ask, the right level of specificity, and enough about the platform's API structure to guide Claude toward the right actions. MOPsy doesn't require prompts in the traditional sense. It was designed around the workflows MOPs teams actually run - campaign builds, email QA, analytics pulls - and it executes them with minimal instruction. You don't need to explain what a QA check involves or what fields to validate. MOPsy knows because that knowledge was built into the agent, not left to the user to provide each time. This is the difference between a tool that can do anything you tell it to do and a tool that already knows what needs doing. Setup, support, and the operational gap Claude + MCP is a self-service integration. You configure credentials, connect the MCP server, and start chatting. If something goes wrong, you troubleshoot it yourself. If you want Claude to follow your team's processes, you need to teach it - every time, in every conversation, because Claude doesn't retain context between sessions. MOPsy ships with complete setup into your MAP instance. Sojourn's team configures it to match your campaigns, your conventions, and your QA standards. Your team gets live training with real-world use cases. And ongoing support means MOPsy evolves with your operations - new use cases get built, edge cases get handled, and the agent gets smarter about your specific environment over time. This isn't a product difference. It's a model difference. Claude + MCP is a tool you adopt. MOPsy is a capability you gain - with the people behind it to make sure it actually works in your environment. What matters for MOPs teams Most MOPs work isn't ad hoc data exploration. It's operational, repeatable, and specific to your instance. Campaign builds. Email design and QA. Workflow execution that follows your team's actual processes rather than generic best practices. Tasks where the value isn't in connecting to the API - it's in knowing what to do once you're connected. This is where purpose-built agents earn their place. MOPsy was designed around these workflows, with guardrails and human oversight built in as design principles. When AI is executing actions inside your MAP - creating campaigns, modifying records, triggering workflows - the margin for error is real. A general-purpose AI operates with whatever permissions the API user has, and the guardrails are whatever you remember to include in your prompt. An agent built for MOPs was designed with that risk in mind from day one. There's also an adoption question. Most MOPs teams are under-resourced and overloaded. They don't have time to learn prompt engineering on top of everything else. An agent that already knows the workflows - and comes with setup, training, and ongoing support - meets them where they are, not where they'd need to learn to be. Connecting to AI isn't the hard part anymore The Model Context Protocol is a meaningful development. Platforms connecting to AI assistants are going to become standard infrastructure, not a competitive advantage. Every MAP and CRM will offer it within a year if they don't already. The hard part was never the connection. It's making AI work reliably inside your specific operations - with your conventions, your processes, your QA standards, and the institutional knowledge that no API exposes. That's the problem worth solving, and it's not one that a general-purpose connector solves on its own. Meet MOPsy

For our luxury holiday client, this wasn’t a “nice-to-have” optimisation project. It was an existential one. Email performance was flat. Marketo was under scrutiny. And the CEO had made it very clear: Prove the value of the platform and the team behind it in 2025, or both were gone. That put the Marketing Operations team in an unenviable position. They didn’t just need incremental improvement. They needed a visible, defensible, board-level turnaround... and fast. That’s when they partnered with Sojourn Solutions. What followed was a complete rethink of lifecycle strategy, data flow, measurement, and how email actually contributes to revenue. Not vanity metrics. Not “ engagement .” Real pipeline and bookings. The result? Nearly double the number of sales-ready leads, a 92% increase in Email-Influenced Opportunities, and a 74% year-over-year increase in Email-Influenced Bookings. Marketo didn’t get cut. It became indispensable. The challenge: Email had no credibility Before Sojourn got involved, email was struggling to justify its place in the marketing mix. Marketo was live, campaigns were being sent, but the impact wasn’t clear or trusted. Sales didn’t believe the leads were ready. Leadership couldn’t see a straight line from email activity to revenue. And without that connection, the platform itself became an easy target. The CEO’s mandate was blunt: If email and Marketo couldn’t demonstrate measurable value in 2025, the subscription, and the team supporting it, would be eliminated. The clock was ticking. Phase one: Fix the foundations, fast The first priority wasn’t more campaigns. It was control. Sojourn started with a full strategic and operational audit of both the email channel and Marketo. This surfaced the usual suspects: Lifecycle stages that didn’t reflect reality, inconsistent lead assignment, data gaps between Salesforce and Marketo, and reporting that looked busy but proved nothing. From there, the focus shifted to building a lifecycle model the business could actually stand behind. Lead lifecycle programs were redesigned to reflect how prospects really move from early interest to sales-ready, with clear definitions that both marketing and sales agreed on. Salesforce and Marketo sync issues were resolved, ensuring leads flowed cleanly, ownership was clear, and no one was chasing ghosts. Email templates were standardised and rebuilt to support scalability, while the their team received hands-on Marketo training and ongoing on-demand expertise. This wasn’t about dependency. It was about confidence. By the end of phase one, Marketo wasn’t just “working.” It was finally trustworthy. Phase two: Lifecycle-based nurture that actually nurtures With the foundations in place, attention can now turn to what email was always meant to do: move buyers forward through more relevant, timely communication. Having established a lifecycle model to identify where individuals are in their buying journey, the next phase will focus on building lifecycle-aligned nurture streams that deliver deeper, stage-specific personalisation. Sojourn will be working closely with the their team to design and activate nurtures that respond to buying intent and behaviour, ensuring email communications are most relevant at key decision points. Using behavioural signals and expressed intent, emails will become more tailored to what prospects are actively looking for. For example, once someone reaches the quote stage, they will receive messaging aligned to their specific interests, products, or use cases, rather than generic follow-ups. This ensures email plays a meaningful role in influencing progression, without prematurely over-engineering nurture programs. Behind the scenes, data quality, integration, and QA will ensure that this personalisation is accurate, scalable, and reliable. This work lays the groundwork for future lifecycle-based nurtures, while immediately delivering more relevant, buyer-aligned email experiences that reflect how people actually buy - not how marketing wishes they do. Measurement: Proving email’s impact on revenue One of the biggest turning points in this engagement was measurement. Sojourn helped them move beyond surface-level email metrics and set up reporting that tied email engagement directly to pipeline and bookings. Email-influenced opportunity and booking reporting was configured to show how email contributed across the lifecycle, not just at first touch. This gave leadership something they’d never had before: Clear visibility into how email supported revenue creation over time. Instead of arguing about opens and clicks, the conversation shifted to influenced opportunities, bookings, and year-over-year growth. Email stopped being a cost centre and started showing up as a revenue driver in its own right. And once that happened, the CEO stopped asking whether Marketo should be cut, and started asking what else the platform could do. The results: From survival to sustained growth The impact was immediate and sustained. Year over year, the Canada based client delivered additional bookings, representing $13.3M in incremental revenue - an 83% uplift . Email-Influenced Opportunities increased by 92% , driven by a near doubling of sales-ready leads. Just as importantly, performance became consistent. Instead of relying on seasonal spikes, FY2025 delivered strong results quarter after quarter. Growth stabilised. Forecasting improved. Confidence returned. Email wasn’t just back in favour. It had become a core pillar of revenue generation. What the client had to say: “Can’t say enough wonderful things about your team. These guys are amazing. They are bright and smart and work well together. They understand each other’s strengths and are super collaborative. There is no stress on the project. I’ve worked with ******* and ***** and you are hands down the best agency I’ve worked with. We’re getting our ROI! 100 more bookings than last year this quarter.” - **** ******, Marketing Operations Manager The takeaway This wasn’t about saving a tool. It was about proving impact. By fixing lifecycle strategy, tightening data and measurement, and building nurture programs rooted in how buyers actually behave, our Canada based client transformed email from a liability into leverage. Marketo didn’t just survive the CEO’s scrutiny. It earned its place at the table. And that’s what real Marketing Operations success looks like.

We've all seen the latest tech news and there's is a certain type of announcement that makes people behave like they have just seen the second coming of competence. A major platform connects to a major model. The screenshots look slick. The demo looks fast. Suddenly everyone starts talking as if typing a request in plain English has solved complexity, governance, and the last ten years of operational mess in one go. This is one of those moments. To recap: Adobe has now published a Marketo MCP server that lets AI tools connect to Marketo, including Claude Desktop, Claude Code, Cursor, and VS Code with GitHub Copilot. Adobe says it exposes more than 100 operations and requires REST API access, Marketo LaunchPoint credentials, and network access to Adobe’s hosted MCP endpoint. Adobe also tells customers to use a dedicated API user and only the permissions required.   All of that is real. What is not real is the idea that this automatically equals an enterprise-ready AI strategy. And that is the part worth questioning. Because the issue is not AI in Marketo. The issue is whether a general-purpose off-the-shelf LLM, connected through credentials into a live enterprise marketing platform, is actually the right operational answer for teams dealing with approvals, customer data, access controls, regional constraints, procurement reviews, and the usual internal politics of “ who signed this off? ” Adobe’s own setup guide makes clear this is not just a chat feature. It is a permissioned connection into Marketo through API access and a hosted MCP service.   That is a very different story. The mistake is confusing “ can connect ” with “ is fit for purpose ” This is where the market gets a bit silly. A connection gets announced and people act as though capability and suitability are the same thing. They are not. Yes, Claude can connect to Marketo through Adobe’s MCP server. But “can connect” is the beginning of the conversation, not the end of it. Adobe’s documentation is explicit that setup involves REST API access, admin-created credentials in LaunchPoint, a hosted MCP URL, and a permissioned API user. That means the real enterprise question is not whether the connection exists. It is whether the connection belongs in your operating model.   Because off-the-shelf intelligence is still off-the-shelf. It is broad. It is flexible. It is good at looking useful quickly. Those are all reasons people like it. They are not, on their own, reasons to trust it with live enterprise Marketing Ops. Enterprise teams do not just need something that can do things. They need something that can do the right things, in the right places, under the right controls, with the right auditability, and without giving Security, Procurement, Legal, and Operations a collective eye twitch. That is a much harder brief. Procurement is not rejecting AI. Procurement is rejecting vagueness. This is the bit people love to get wrong. When procurement or security starts asking awkward questions, the lazy narrative is that the business is being slow, old-fashioned, resistant, bureaucratic, or anti-innovation. Rubbish. What procurement is usually rejecting is not AI. It is vagueness. Who is the vendor relationship actually with? Where does the traffic go? What data can be exposed? What are the processor and subprocessor implications? What gets logged? What controls exist around usage? What happens if one part of the chain changes? Who owns the incident if something goes wrong between tools and nobody wants to claim it? Those are not irritating questions. They are the whole point... And this setup gives them plenty to work with. Adobe lists multiple supported AI tools, requires external client configuration, and routes the connection through an Adobe-hosted MCP endpoint into Marketo APIs. That means this is not just “ Marketo has AI now. ” It is a multi-system, permissioned integration that an enterprise is expected to govern properly.   So no, procurement is not the problem here. Procurement is the first person in the room acting like production systems deserve adult supervision. A famous LLM is not an operating model This is probably the line most worth saying out loud. A famous LLM is not an operating model. It is a tool. A connection is not a strategy. A setup guide is not a governance framework. And a slick demo is not proof that your enterprise should be doing any of this in production. What actually matters is everything around the model. What permissions does it run under? What tasks is it allowed to perform? What is read-only and what is not? What environments can it touch? What approval gates still apply? What gets logged and reviewed? What is blocked outright? Who owns the design of those boundaries? Adobe’s documentation already points straight at that reality by stressing dedicated API users, least privilege, and inherited Marketo API limits. Those warnings exist because the real risk is not that the tool is clever. It is that people will connect it too broadly and pretend that is innovation.   That is not innovation. That is just a new route to old mistakes. Data handling is where the excitement usually goes quiet It is very easy to sound bullish about AI when you keep the conversation abstract. It gets harder when you remember what is actually inside a real Marketo instance. Lead records. Personal information. Segmentation logic. Behavioural data. Sales handoff points. Operational workflows. Regional rules. Compliance concerns. Legacy fields nobody wants to go near. Program history. Approval dependencies. Once a general-purpose model can query or act through a connection into that environment, the question is no longer “is this powerful?” It is “what exactly could this expose, retrieve, summarise, alter, or help someone access more casually than before?” Adobe says the MCP server exposes a wide range of Marketo operations and depends on the API role assigned to the connection.   That should make enterprise teams more serious, not less. Because conversational access changes behaviour. It makes systems feel lighter, softer, more forgiving. It makes requests feel harmless. But the data underneath does not become harmless just because the interface becomes friendly. This is the trap with off-the-shelf LLM thinking. People confuse ease of interaction with safety of use. Those are not the same thing. Cross-border and compliance questions do not disappear because the demo was impressive Another thing people like to pretend away is geography. Enterprises, especially global ones, do not just care whether something works. They care where services are hosted, how data moves, which terms apply, which entities are involved, what internal policies say, and whether the setup creates risk they will later have to explain to a privacy team or regulator. Adobe’s public Marketo MCP documentation gives customers a hosted MCP server URL and the technical prerequisites to connect external AI tools. What it does not do is magically settle all the regional, residency, or cross-border questions for your organisation. Those still have to be worked through internally.   Which is why an enterprise buyer is perfectly justified in looking at this and saying, “Fine, but under what conditions would we actually be comfortable with it?” That is not anti-AI. That is what mature buyers sound like. API credentials are where the grown-up questions begin This part is wonderfully unglamorous, which is exactly why it matters. Adobe’s setup requires Marketo API credentials and explicitly warns customers not to put secrets into version control, recommending environment variables or secret managers instead.   That is sensible advice - it is also a massive clue. Because whenever credentials enter the story, so do all the practical questions people tend to skip in the excitement phase. Where are the secrets stored? Who has access? How are they rotated? Are they scoped properly? Are they different by environment? Has anyone audited where they are referenced? Was the proof of concept built with permissions that are broader than anyone would admit in a proper review? If those questions feel awkward, good. They should. That awkwardness is the sound of enterprise reality catching up with a feature announcement. Off-the-shelf is not the same as enterprise-ready The argument is not that AI assistants are bad. The argument is that there is a big difference between a general-purpose LLM being able to connect to something and a purpose-built AI solution being designed around the realities of enterprise Marketing Ops. Anthropic itself has spent the last year expanding admin and compliance controls for business and enterprise customers, including policy controls, monitoring, data retention controls, and compliance visibility. That tells you the market already understands the gap between consumer-famous AI and enterprise-governed AI.   And that is the gap worth talking about. Enterprise teams do not need less AI. They need AI that is narrower where it should be narrow, governed where it should be governed, observable where it should be observable, and designed around actual operational workflows rather than general-purpose novelty. That is the distinction. Not anti-AI - Anti-naive AI adoption. Not “don’t use intelligence in Marketo.” “Don’t assume a broad off-the-shelf model connection is automatically the right answer for production Marketing Ops.” That is a much more intelligent argument, and frankly a much more commercial one too. The real enterprise question is not “is Claude clever?” Of course it is clever. That is not the hard part. The hard part is whether a general-purpose model, connected through APIs into a live marketing platform, is the thing your enterprise actually wants to standardise around. That is the better procurement question. Not “can we connect it?” “Should this be the shape of our AI operating model?” Not “does the demo work?” “Does this survive vendor review, data governance, access control design, audit requirements, and internal accountability?” Not “is this innovative?” “Is this controlled?” That is where the grown-up conversation lives. And that is why the sharpest position here is not anti-AI at all. It is simply this: Off-the-shelf LLMs make a great demo. Enterprise Marketing Ops needs something more deliberate. That is the tension worth writing about. Because the businesses that get real value from this wave will not be the ones who rushed to connect the most famous model first. They will be the ones who worked out what should be purpose-built, what should be tightly governed, what should be ring-fenced, what should never touch production casually, and what kind of AI they can actually defend when procurement, security, legal, and the Ops team all start asking the same lovely question: Who approved this? Discover our purpose built Agentic AI

The discovery layer has moved. The place where buyers form their first impression of your category is no longer a search engine - it's an AI assistant.   And the content that informs that AI's answer is being written right now, by whoever publishes the clearest, most structured, most accessible version of the truth. If that's your competitor, then the AI tells the buyer their version of reality. If it's you, the AI tells the buyer yours. Most marketing teams are still pouring budget into a channel the buyer is quietly leaving. This is the shift from SEO to GEO - Generative Engine Optimisation - and it's not coming. It's here. The buyer journey now starts in a chat window Think about how a senior decision-maker actually researches a purchase now. They don't open Google and type "best marketing automation platform 2026" and scroll through ten pages of vendor content pretending to be objective. That behaviour is dying. Not dead - dying. Quickly. What they do instead is open an AI assistant and ask a real question. Not a keyword. A question. "What should I look for in a MAP if my team is small and we're migrating off our current platform?" "Who are the strongest partners for CRM implementation in EMEA?" "What's the difference between RevOps and MOPs and does the distinction actually matter?" The AI gives them one answer. Not ten links. One synthesised, confident, cited response. It names brands. It describes capabilities. It makes comparisons. The buyer reads it in 30 seconds and forms a mental shortlist that would have taken an hour of Googling to build two years ago. If your brand is part of that answer, you're on the shortlist before the buyer has visited a single website. If you're not, you missed the window entirely. And here's the part that makes this difficult to measure: you'll never know you missed it. The buyer who was never introduced to you doesn't visit your site, doesn't become a lead, and doesn't show up in your CRM. They just go somewhere else. The loss is invisible. SEO and GEO are not the same discipline The instinct will be to hand this to whoever manages SEO. That makes sense on the surface - it involves content, search, and visibility. But the mechanics are different enough that treating GEO as an SEO extension will produce disappointing results. SEO optimises for ranking position in a list of links. The buyer sees the list, clicks a link, and lands on your site. Even ranking fifth means you're visible. GEO optimises for inclusion inside an AI-generated answer. There is no list. The AI gives one answer and names the brands it considers relevant. You're either in the answer or you're not. There is no page two. What gets you into an AI-generated answer is also different from what gets you ranked in search. Keyword density doesn't help - AI isn't matching keywords. Backlink volume matters less than content clarity. What AI systems are looking for is content they can confidently extract an answer from. That means clear definitions, specific arguments, structured formatting, and substance that doesn't require five paragraphs of preamble before the actual point arrives. Each AI platform also behaves differently. What gets you cited in ChatGPT won't necessarily get you cited in Perplexity, or Claude, or Google's AI Overviews. They weight different signals - recency, domain authority, content structure, source diversity, promotional tone. Optimising for one doesn't mean you're visible in the others. It's not one new channel. It's several, each with different rules, and the overlap between them is surprisingly small. Gated content is now a competitive disadvantage at the discovery layer This is the part that will be uncomfortable for a lot of marketing teams, because it challenges a model that's been the backbone of demand gen for a decade. If your best thinking is locked behind a form - download the whitepaper, register for the webinar, fill in three fields to read the guide - the AI can't see it. AI systems pull from publicly accessible content. A gated PDF behind a form isn't publicly accessible. It's invisible to the discovery layer. Your competitor who published the same insight as an open, well-structured blog post? That's what the AI reads. That's what it cites. That's the version of reality the buyer receives. Not because the competitor's thinking is better, but because it's available  to the systems now shaping first impressions. This doesn't mean ungating everything. Mid-funnel content that's genuinely valuable enough to justify a form still has a role. But the early-stage, category-defining content - the "here's how to think about this problem," the "here's what good looks like," the "here's how these options compare" - needs to be in the open. Because that's the content AI uses to form the answers your buyers are reading. The brands that treat expertise as something to share publicly are the ones AI will cite. The brands that treat it as something to withhold until a form is filled are writing content for an audience of one: their own CRM. Content structure now matters more than content volume Most B2B content is written to drive a click from a search results page. It's keyword-optimised, structured around headings designed for SEO crawlers, and padded with enough words to hit a length threshold that Google's algorithm favours. AI doesn't care about any of that. AI is looking for content it can extract a confident answer from. That means the first paragraph needs to say something meaningful - not warm up with a paragraph about "the evolving landscape." Definitions should be clear and early. Arguments should be specific. Data, where it exists, should be concrete. The structure should serve comprehension, not crawlability. Volume doesn't compensate for vagueness. Publishing 20 articles a month that circle around a topic without committing to a point of view is less useful - to AI and to humans - than four articles that each make a clear, specific argument. AI isn't impressed by your publishing cadence. It's looking for the content it trusts enough to cite. And freshness matters more than it used to. Traditional SEO rewards evergreen content that compounds authority over years. AI-generated answers disproportionately favour recent content. The article you published six months ago is already being displaced by whatever your competitor published last week. This is a treadmill. Acknowledging that doesn't make it go away. This isn't just a content problem - it's a measurement problem If you run Marketing Operations, the GEO shift hits your world in a specific and awkward way: it creates a blind spot in attribution that no current model accounts for. When a buyer's first meaningful interaction with your brand happens inside an AI chat window, you get no click. No cookie. No UTM parameter. No referral data. The buyer forms an impression, builds a shortlist, and then - maybe - visits your website. By the time they arrive, they look like a direct visit or an organic visit. Your CRM captures them as a new lead with no traceable source. But the actual source was an AI-generated answer you had no visibility into and no control over. This means your funnel metrics are about to get strange. You'll see higher-intent leads with shorter sales cycles and no clear acquisition source. That's not organic magic. That's AI doing your top-of-funnel work for you - or for your competitor - and your reporting infrastructure can't tell the difference. If you don't start tracking AI referral traffic as a distinct segment, you're flying blind in a channel that's growing while the channels you can  measure are shrinking. The configuration work to set this up is minor. The insight it provides is not. The game changed. The scoreboard didn't. SEO isn't dead. But it's no longer the only game that matters for discovery, and it's no longer where the most consequential first impressions are being formed. The shift from SEO to GEO isn't something to prepare for. It's something to respond to. The buyers who matter most - the senior decision-makers with budget authority and short timelines - are the ones most likely to ask an AI instead of running a search. They're the ones who form a shortlist in 30 seconds and never look back. The brands they find are the ones whose content is clear, structured, publicly accessible, and recent. That's not a new set of skills. It's a new discipline for applying the skills marketing should already have. The question is whether you apply them to the channel the buyer is actually using - or the one they used to. Discover our AI services

There is a certain kind of enterprise tech announcement that makes people lose the run of themselves. A new connection appears. A big-name platform links arms with a big-name model. The screenshots look slick. The demos look effortless. Within minutes, half the market starts talking as if the future has arrived, sorted the backlog, and fixed governance on its lunch break. This is one of those announcements. Claude can now connect to Marketo. And yes, there is obvious appeal in that. Ask questions in plain English. Move faster. Find things more easily. Reduce some of the drudgery. Cut through an interface that nobody has ever lovingly described as intuitive. Fine. But sensible enterprise teams should not be reacting with giddy excitement. They should be reacting with a healthy level of suspicion. Because this is not just a handy new feature. It is a new way into a live enterprise marketing system. One that contains customer data, campaign logic, approval structures, reporting dependencies, legacy weirdness, and enough hidden risk to make experienced Marketing Ops people instinctively flinch when someone says, “I’ve just made a quick change in production.” That is why the interesting question is not whether Claude can connect to Marketo. It can. The interesting question is why so many people seem ready to celebrate that fact before they have done the boring grown-up work of asking what it means for permissions, approvals, audit trails, QA, and production risk. This is not an anti-AI argument. FAR from it. It is an anti-naivety one. And there is plenty of naivety here going around. The fantasy version is lovely The fantasy version of this story is easy to sell. A user asks for help. Claude finds the right thing. Maybe it speeds up a task. Maybe it helps someone cut through clutter. Maybe it reduces the amount of time spent digging through programs, folders, assets, and all the other bits of enterprise software that seem specifically designed to make simple things feel needlessly painful. That version will do very well in demos. Unfortunately, enterprise reality is not built for demos. Real Marketo environments are rarely tidy. They are usually a mix of current work, old work, half-retired work, undocumented fixes, inherited structures, strange dependencies, local naming conventions, and processes that are technically still alive despite nobody being fully sure why. That is what makes this connection worth taking seriously. Because Claude is not being attached to a neat little sandbox full of clean logic and sensible governance. In many organisations, it is being attached to a live production environment already held together by caution, experience, and the occasional whispered warning not to touch a specific folder unless you want to ruin your week. That is not the kind of setup that should inspire giddiness. The issue is also not whether the model is clever A lot of the public conversation around this sort of thing goes sideways almost immediately. People get distracted by the intelligence question. Can the model understand the task? Can it retrieve the right thing? Can it help teams move faster? Can it make the system easier to use? That is all mildly interesting. The more important question is much less glamorous. What can it access? Because that is where the real enterprise risk sits. Can it only retrieve information, or can it change things too? Can it create assets? Can it clone programs? Can it update records? Can it approve emails? Can it activate campaigns? Can it export data? Can it interact with live production objects under the permissions of a user that was set up too broadly because someone wanted the demo to be impressive? That is the real story. The danger is not that a model might say something daft. Humans do that all the time and enterprise software has somehow carried on regardless. The danger is that a conversational layer gets connected to a platform where access, scope, and control matter far more than enthusiasm - don't forget that this is an "off the shelf" LLM model we are talking about here... not a bespoke Agentic AI. Permissions are where this stops being fun The moment a language model connects to Marketo, this stops being a shiny feature story and becomes a permissions story. Which is exactly why so many people will try to avoid that conversation. Permissions are dull. Permissions are fiddly. Permissions are the part that ruins the fun by asking irritating questions like who gets access to what, under which conditions, with what restrictions, and with what consequences if something goes wrong. In other words, permissions are where adults enter the room. And they matter because enterprise platforms do not become safe just because the front end becomes conversational. If anything, the opposite is true. The easier it feels to ask for something, the easier it becomes to forget that the system underneath is still capable of doing very real things with very real consequences. That is the trap. Prompting feels casual. Production is not. A request typed into a friendly interface does not feel like changing a live marketing system. It feels more like asking for help. That softer feeling is precisely what makes stronger permissions and tighter boundaries more important, not less. Because the consequences have not become gentler. Only the experience of issuing the instruction has. Enterprise stability is often built on caution, not elegance There is a great myth in enterprise Marketing Operations that stable environments are always the result of pristine architecture, immaculate governance, and flawless documentation. That would be lovely. It is also nonsense. A lot of enterprise stability comes from experienced people being careful. They know which programs are safe to use and which are not. They know which campaigns need extra checks. They know what can be changed quickly and what needs a proper review. They know where the bodies are buried, metaphorically speaking, and they know better than to go poking around them on a Wednesday afternoon. That caution has value. It is not glamorous. It does not make for exciting feature launches. But it is often the thing preventing expensive mistakes. Now place a conversational layer on top of that environment and the tone changes immediately. Suddenly the interaction feels easier. Lighter. More natural. Less formal. Less loaded. That sounds good until you realise how much enterprise safety relied on the fact that Marketo did not feel casual. The interface was annoying, yes. It was also part of the ceremony. It forced some level of navigation, context, and intent. It reminded users they were inside a system with structure and consequence. A prompt box does none of that. A prompt box says, go on then. Approvals are not red tape. They are damage control in advance. Approvals are one of those things people only appreciate properly after they have bypassed them and regretted it. Nobody enjoys extra process for the sake of it. Fair enough. Plenty of enterprise process exists only because someone somewhere once survived a committee and decided everybody else should suffer too. But approval structures in Marketing Operations are not there purely for decoration. They exist because the gap between intention and execution is where a lot of nonsense gets caught. An email is checked before it goes live. A campaign is reviewed before activation. A change is questioned before it lands in production. Someone else has a chance to look at it and say, hang on, are we sure this is right? That pause matters. The problem with conversational access is that it shortens the emotional distance between wanting something done and trying to do it. That is a big part of the appeal. Less friction. Less digging. Less messing about. But some of that friction was doing useful work. It was giving teams just enough resistance to stop every half-formed idea marching directly into a live environment wearing confidence it had not earned. Making access easier does not make approvals less necessary. It makes them more important. Audit trails suddenly matter a lot more Here is where things get properly uncomfortable. In traditional platform use, there is usually some way to reconstruct what happened. Who made a change. What they touched. When they did it. What was approved. Which sequence led to the issue. It may not be elegant, but there is generally a trail. Once you start putting an LLM model in the middle, that clarity can get foggy very quickly. Was the action directly initiated by the user? Was the request ambiguous? Did the system infer something beyond what was intended? Which permissions were in play? What exactly was executed? What review existed around that setup? Who owns the resulting action when the person typed a broad request, the model interpreted it, and the system carried it out under legitimate credentials? That is why auditability is not some dreary back-office concern here. It is central. If a business cannot clearly trace what was requested, what was executed, under whose permissions, against which assets, and with what safeguards in place, then it has no business pretending this is all under control. That is not negativity. That is basic enterprise hygiene. With Claude, QA does not go away. It gets harder. There is a lazy idea floating around that this kind of connection reduces manual effort and therefore eases pressure on teams. In some places, maybe. With the correct AI integration, absolutely. But with an LLM? Let’s not get carried away. What usually happens in enterprise environments is that effort moves. It does not vanish. You may spend less time hunting around for assets or navigating a clunky interface. Fine. But the need to verify what is being surfaced, what is being changed, and what context sits around that action does not disappear. If anything, it increases. Because when work can be requested more casually, teams need stronger QA, not weaker . They need clearer checks around scope, asset selection, environment, downstream impact, inherited logic, and side effects. They need less blind trust, not more. And they absolutely cannot afford to fall into the trap of assuming that because something was easy to ask for, it must also be safe to carry out. That is how messy systems become messier. Production risk is rarely dramatic at first The people rushing to celebrate this sort of thing tend to imagine risk in extremes. Either everything is brilliant or everything is on fire. Real enterprise risk is usually much duller than that, which is part of what makes it dangerous. A live asset gets changed in the wrong place. A program is cloned from the wrong template. A campaign goes active without the right review. A data export happens too easily. A workflow touches something it should not. A team starts leaning on conversational access without fully appreciating where the boundaries should be. None of that necessarily creates instant disaster. What it creates is drift. A slow erosion of trust. A buildup of avoidable rework. More nervous stakeholders. More technical debt. More sceptical legal and compliance teams. More pressure on already stretched Ops people to clean up problems created by convenience being mistaken for competence. That is usually how production risk shows up. Not as one giant cinematic failure, but as a series of smaller decisions made too casually until the overall environment gets shakier than anyone wants to admit. The wrong question is whether you can use it Of course you can use it. That is not the serious question. The serious question is whether your organisation has the discipline to use it without making things worse. Do you have a permission model that is genuinely fit for purpose? Do you have clear rules around what can and cannot be done? Do you have approval structures that still hold when interaction becomes conversational? Do you have meaningful audit trails? Do you have QA discipline strong enough for a lower-friction access layer? Do you have separation between experimentation and production? Do you have named ownership when something goes wrong? Do you have governance that lives in the actual operating model, not in a document everybody claims to support and nobody opens? If the answer to those questions is vague, patchy, or politely avoided, then no, you are not ready. Not because the technology is bad, but because your operating model is too flimsy to carry it safely. That is the point enterprise teams need to hear. This is a maturity test, not a toy That is the sharper read on this launch. It is not just a feature release. It is a maturity test. It reveals whether a business sees Marketing Operations as a serious control function or as a convenient place to experiment with shiny new capabilities and hope the risk gets sorted out later. A mature organisation will look at this and ask hard questions about permissions, approvals, audit, QA, and production boundaries before it starts applauding. An immature one will rush to the demo, celebrate the novelty, and act surprised later when Security, Legal, Compliance, or the head of Marketing Ops starts asking the sort of questions that make innovation fans suddenly very interested in changing the subject. That is why enterprise teams should be nervous. Not fearful. Nervous. There is a difference. Fear says do nothing. Nervousness says pay attention. And right now, paying attention would be a refreshing change. Nervous is the correct response A little nervousness would be healthy here. Enterprise teams should be nervous when conversational access becomes easier than governance. They should be nervous when approvals are treated like optional friction. They should be nervous when audit trails are vague. They should be nervous when QA is assumed rather than designed. They should be nervous when production starts to feel casual. Because nervous teams ask better questions. Giddy teams usually skip straight to the part where they create new problems and then hold a post-mortem to discuss how the warning signs were missed. Claude connecting to Marketo may well become useful. In the right environment, with the right controls, it could genuinely help capable teams move faster without losing discipline. But that outcome will not belong to the teams who got excited first. It will belong to the teams who treated permissions seriously, kept approvals intact, demanded proper auditability, strengthened QA, respected production risk, and resisted the now very fashionable urge to mistake easy access for readiness. That may not be the fun version of the story. It is, however, the one enterprise teams should be reading. Discover MOPsy Discover our latest benchmark report

There is nothing quite like campaign QA for making expensive, experienced enterprise teams do work that feels suspiciously close to digital scavenger hunting. Open the email. Check the links. Check the tokens. Check the form. Check the follow-up. Check the workflow. Check the audience. Check the field mapping. Check the suppression rules. Check the approval status. Check it all again because someone made a “tiny change” after sign-off. Then check it one more time because nobody wants to be the person who lets a broken campaign go live. It is not glamorous. It is not strategic. It is not the kind of work anybody brags about. But it quietly eats hours every week across most enterprise marketing teams. And the worst part is this: most of those hours are not being wasted because teams are careless. They are being wasted because campaign QA in large organisations has become bloated, manual, inconsistent, and held together by stressed people trying to stop avoidable mistakes from escaping into the wild. That is a problem in its own right. It is also exactly why tools like MOPsy matter. Because when highly capable Marketing Operations teams are spending huge chunks of their week doing repetitive campaign checks, something has gone wrong in the operating model. Campaign QA is necessary. The current way of doing it is the issue Nobody is suggesting campaign QA should disappear. In enterprise environments, quality control matters. A lot. One broken workflow, one wrong audience, one bad sync, one incorrect token, one missed suppression rule, and suddenly you have internal panic, external embarrassment, and a clean-up job that takes longer than the original build. The problem is not the existence of QA. The problem is how it happens. In too many enterprise teams, campaign QA is still heavily manual. It lives in checklists, spreadsheets, screenshots, Slack threads, email chains, approval comments, and whatever vague institutional memory happens to be sitting inside the heads of the people who have been there longest. Everyone knows what needs checking, broadly speaking. The trouble is that the checking process is often fragmented, inconsistent, and massively reliant on humans doing repetitive work over and over again. That is where the hours disappear. A campaign that looks simple from the outside can have a ridiculous number of moving parts underneath. Emails, forms, landing pages, hidden fields, workflow logic, list criteria, dynamic content, CRM integration, lead routing, alerting, timing rules, tracking codes, audience exclusions, nurture logic, webinar connections, regional variations, legal tweaks, and stakeholder edits that arrive three minutes before launch. Every extra layer adds risk. Every risk creates another check. Every check takes time. Very quickly, QA stops being a sensible final control and starts becoming a full-blown drain on the team. Most teams are not inefficient. They are compensating This is the bit many people get wrong. When enterprise teams spend too long on campaign QA, the lazy explanation is that they need to be more efficient. Usually, that is nonsense. More often, they are compensating for an environment that is too complex, too fragile, or too inconsistent to trust. That lack of trust shows up everywhere. People double-check because they have been burned before. Stakeholders insist on seeing final versions because something slipped through six months ago. Approvers keep asking for screenshots because they do not trust the build. Ops teams re-run tests because a last-minute change always seems to break something unexpected. Marketers ask for “just one more review” because they know one small error can become a very visible mess. This is not laziness. It is risk management by exhausted humans. The issue is that humans are doing too much of the safety work. And humans are a very expensive place to park repetitive validation. What campaign QA looks like in the real world Campaign QA sounds tidy until you look at what it actually involves. It is not just proofreading an email and clicking a few links. It is checking whether the segmentation logic is correct, whether the form writes cleanly to the right fields, whether the thank-you journey fires properly, whether the routing rules still behave as expected, whether the campaign naming follows standards, whether the audience exclusions are working, whether UTM parameters are consistent, whether cloned assets have carried over the wrong settings, whether alerts fire, whether wait steps are right, whether approval comments were actually actioned, whether the CRM sync is behaving, whether the preference centre is connected properly, whether the footer is compliant, and whether the one stakeholder who always spots the obscure edge case is going to have another moment just before launch. Then do that across multiple campaigns. Across regions. Across product lines. Across different teams. Across multiple systems. Across campaigns that were built by different people, in slightly different ways, to slightly different standards. That is where the wheels start wobbling. Because QA is rarely one neat, contained stage. It spills across the whole delivery cycle. It is rarely just one person doing one clean review. It is bits of time from multiple people, spread across multiple tools, with multiple interruptions and plenty of re-checking when something changes after the “final” review. That is not a quick task. That is death by a thousand tabs. Discover the 2026 AI Benchmark Report The hidden cost is bigger than most teams realise The obvious cost of campaign QA is time. The less obvious cost is the way that time gets shredded. A team might say a campaign takes two hours to QA. What they often mean is there are two visible hours of checking. What they usually do not include is the context switching, the waiting, the duplicated review, the stakeholder back-and-forth, the rechecks after edits, the confusion over versions, and the extra time spent validating things that should have been easier to verify in the first place. This is where enterprise teams quietly lose entire days. Not because somebody sat in a room for eight straight hours doing QA, but because ten people each lost twenty minutes here, forty minutes there, and another half hour because someone made a change after sign-off and nobody wanted to risk not checking it again. That kind of waste is hard to spot because it hides inside the flow of work. It feels normal. It feels responsible. It even feels unavoidable. But it is still waste. And worse, it is waste involving some of the most capable people in the team. Highly experienced Marketing Operations professionals should not be spending huge chunks of their week manually checking whether the same set of campaign rules were followed again. That is not strategic oversight. That is process debt. Manual QA does not scale nicely This is where things get especially grim. Manual QA might limp along when campaign volumes are low and the team is small. Once scale enters the picture, it starts to creak. More campaigns mean more checks. More regions mean more variations. More stakeholders mean more approvals. More platforms mean more handoffs. More complexity means more risk. And most teams respond to rising risk in the same way: they add more manual review. That feels sensible in the moment. It also creates a system where campaign velocity slows down, people become bottlenecks, and launch confidence drops rather than improves. So teams end up stuck between two bad options. They either keep throwing time at QA and slow everything down, or they cut corners and accept more risk. Neither is a particularly grown-up answer. Customers see the consequences, not the excuses Internally, a campaign error may look small. Externally, it looks sloppy. That is the uncomfortable truth. Customers and prospects do not see the tight deadline, the late-stage change request, the weird MAP behaviour, or the fact that three different teams touched the build. They see the thing that lands in front of them. An email with the wrong personalisation. A form that behaves strangely. A broken page. A follow-up that does not make sense. A message sent too early, too late, or to the wrong people. A clunky experience that makes the brand feel careless. Enterprise marketing teams know this, which is exactly why they overcompensate with extra QA. They are trying to avoid reputational damage. Fair enough. The trouble is that the answer has too often been more human effort instead of a smarter system. That is not sustainable. A lot of QA processes were never properly designed Let’s be honest. Many enterprise QA processes did not come from a thoughtful redesign workshop with a neat operating model at the end of it. They evolved. One person made a checklist. Another added a spreadsheet. Somebody started keeping screenshots. A stakeholder demanded final approval because of one painful incident two years ago. A platform migration added more steps. A reorg split ownership. Regional teams created local variations. Legal got more involved. Nobody really rebuilt the process from the ground up. They just kept adding layers. The result is predictable. Checks happen late. Standards vary by team. Known issues keep repeating. Approvals are inconsistent. Documentation is patchy. Too much knowledge sits in the heads of a few over-relied-upon people. And the team spends far too much energy catching preventable errors instead of building a cleaner, more resilient way of delivering campaigns. That is the real issue. Manual QA often looks like control, but in many cases it is just a workaround for a messy system upstream. The smarter question is not “who checks this?” but “why does this need checking this way?” This is where the conversation gets more useful. Most teams frame QA as a people problem. Who owns it? Who signs it off? Who catches errors? Who reviews the reviewer? That is understandable, but it is also limiting. A better question is why so much of the checking still depends on humans in the first place. Some things absolutely should. Brand judgement, tone, compliance nuance, context, audience appropriateness, stakeholder sensitivity. Those things still need human eyes and human brains. But a lot of campaign QA is not that. A lot of it is repetitive validation. Does this asset follow the right naming convention? Are these links structured correctly? Are these components present? Does the build align to known standards? Has this flow been configured the way it should be? Are the same rules being followed every time? That is not human brilliance. That is structured checking. And structured checking is exactly where many enterprise teams are still burning ridiculous hours because the process has not caught up with the complexity of the work. Where MOPsy comes in This is not about replacing your team. It is about protecting your team from work they should not still be buried in. MOPsy is built for Marketing Operations, which means it is not some generic AI gadget trying to force its way into a serious workflow wearing a shiny badge and a lot of confidence. It is designed to be useful in the kind of operational environments where campaign complexity, governance, and quality control actually matter. That makes campaign QA a very obvious fit. Because the problem with QA is not usually that teams do not care. It is that too much of the process still relies on manual review, repeated checking, and humans spotting patterns that a smarter system should be helping to identify much earlier and much more consistently. MOPsy can help teams review campaign builds against defined standards, flag inconsistencies, surface likely issues, support governance, and reduce the amount of repetitive checking that currently eats into experienced team time. That matters because enterprise QA is rarely just about spelling mistakes and rogue buttons. It is about checking campaign logic, process discipline, consistency, configuration, and execution quality across a lot of moving parts. It is exactly the sort of environment where repetitive validation should not still depend so heavily on humans clicking through the same things every week. MOPsy does not remove the need for judgment. It removes more of the grind. And that is the point. This is about more than saving time Saving time is useful. Nobody is going to argue with that. But the more interesting benefit is what happens when teams stop drowning in manual QA. Friction drops. Confidence improves. Campaigns move with less drama. Approvals become cleaner. Standards become easier to enforce. Fewer issues slip through. Ops talent gets used for higher-value work instead of repetitive campaign checking. This is where the real gain sits. Not in a vague promise of efficiency, but in a better operating model. One where the team is not constantly relying on heroic effort, invisible knowledge, and last-minute checks to keep quality intact. Because that is another truth most teams recognise instantly: QA often depends far too heavily on a small number of people who know exactly where problems usually hide. They know the awkward workflows, the strange field behaviour, the steps that always get forgotten, the stakeholders who make late changes, the assets most likely to break, and the checks that can never be skipped. That may feel reassuring. It is not resilience. It is a fragile process wearing a familiar face. A stronger QA model, supported by the right tooling, helps shift that knowledge into something more repeatable, more scalable, and less dependent on human memory and personal heroics. Which is, frankly, how enterprise Marketing Operations should be operating. The teams that improve this will move differently The best teams will not be the ones who keep tolerating more QA pain and calling it diligence. They will be the ones who take a hard look at where the hours are really going, separate genuine human review from repetitive validation, and start building a smarter system around campaign quality. That means improving standards. Tightening process. Reducing inconsistency. Strengthening governance. And using tools like MOPsy where they genuinely help make campaign delivery safer, sharper, and less painfully manual. Because enterprise teams are not wasting hours on campaign QA because they are bad at their jobs. They are wasting hours because the work has become too complex for old habits, too risky for guesswork, and too repetitive to keep throwing humans at it forever. That is the real opportunity. Not shiny AI nonsense. Not another toy with a big promise and a weak use case. Just a very practical shift in how campaign quality gets managed. And for a lot of enterprise teams, that shift is overdue. A better way to handle campaign QA If your team is spending hours every week manually checking campaigns, rechecking last-minute changes, chasing approvals, and relying on experienced people to catch the same issues over and over again, the problem is not just workload. It is the model. MOPsy helps enterprise Marketing Operations teams bring more consistency, more control, and less manual drag into campaign QA. That means fewer hours lost to repetitive checking and more time spent on the work that actually moves the needle. If campaign QA is still eating your team alive, it may be time to stop accepting that as normal. MOPsy was built for exactly this kind of problem. Discover MOPsy