How to Prioritize AI Use Cases in B2B Marketing

Summary

Use a 3-part framework to evaluate use cases for AI in B2B marketing, and then prioritize based on where they fall in that spectrum. The 3 areas to review are leverage (how often are these tasks repeated), risk (what happens if things go wrong), and chainability (how does this fit into a workflow).

By Tom Swanson, Senior Engagement Manager at Heinz Marketing

Last month I wrote about using SWOTs to identify use cases for AI in B2B marketing workflows.  Today, I am writing about evaluating those use cases.

I have worked with numerous teams on improving their marketing orchestration.  For the last 1.5 years that has meant “how do we integrate AI?”.  Obviously the first step is how do you identify use cases that would be meaningful, and then have to prioritize them.

This framework is how I structure my thinking for teams of all sizes to focus on doing just a few things at a time, really well.

The framework is simple: leverage – risk – chainability.

So first, a little bit of definition, and in keeping with the simple theme:

Leverage = how often is the task repeated?

Risk = how bad will it be if this gets messed up?

Chainability = does this task produce an input for another task?

It is pretty straightforward how these 3 fit together.  If the task will save a lot of time/repetition, isn’t difficult to fix if things go awry, and produces an input for another similar task, then it is a great candidate for AI.

If, like me, you enjoy a simple visual, then lay these out on a cartesian plane.  Like this:

Chainability is more of a yes/no on whether or not the output will go AS-IS into another task.  If the output will need to be reviewed/changed then it is not chainable.  This will differ by team, so if you want humans to review/approve your campaign strategy before the machine generates a tactical plan, then it is not chainable.  Other teams might not care so much.

Working it this way gives you some flexibility in how you rank things along the x and y axes, with chainability as a Boolean gate or at least as a significant consideration.  Everything is a spectrum.

There are a lot of nuances in doing this.  Much of it is cultural.  The risk of a word being wrong might be huge for one firm or industry and small for another.  You’ll have to do this subjectively for many of the use-cases.

Anyway, let’s get into some examples.

Leverage: How often is this task repeated?

Rote, repeated tasks are the best fit for AI, particularly early on while you are still learning to build.  More complex tasks are easier to break down later, after you understand how the machine thinks.

When evaluating leverage, I like to look at the situation (read: use case), the frequency that the task is repeated, the cost of doing the task (in most cases: time), how the workflow differs from run to run, and finally how uniform the output is each time compared to previous runs.

Here is a real client example:

Local Data Miner

Situation: Regional reps needed to stay on top of new local businesses as potential prospects.

Frequency: Weekly.

Cost: ½ day.

Workflow: uniform, the same every time.

Output structure: uniform, the same every time.

Ultimately, this was a great candidate.  It has a regular frequency that can be automatically triggered, and it costs a decent amount of time that could be spent selling.  The automation requires little maintenance because the workflow and the outputs are the same every time.  Changes should be infrequent and additive.

As it happened, the risk profile and chainability were also solid for this tool.  A knockout!

Risk: What happens if it is messed up?

There are many, many ways things can go wrong.  Risks are task-specific, have high variance between tasks, and are weighted differently by organizations, teams, and individuals.  A team with a high risk tolerance due to AI-automation mandates is going to accept a financial risk faster than a team whose executive leadership is skeptical and measured about AI adoption.

I find it most useful to categorize risks by type and then essentially do a low/mid/high to define the risk inherent to the task.

Here is another real example:

Automated Campaign Strategy with Human Review

Use case context: the client wanted to automate their campaign strategy drafting with a team of agents that would pull CRM data, web research, and customer data to develop campaign strategies that would expedite time to market.  It is important to note that this would produce a deck for strategic review by leaders, not push anything into market itself.

Financial risk: Low. Token-cost only.

Rework risk: High. Strategic drift likely.

TCO risk: Mid. Documentation needs to be up-to-date.

Brand risk: Low. Offset by leadership review.

Adoption risk: Mid. Team will require coaxing to use it.

Accountability risk: Low. Offset by leadership review.

I have yet to codify a specific set of risks that need to be assessed on a task-by-task basis.  I think financial, brand, and TCO are probably the big 3, but there are others.  Content bots will have a different profile of risks than a win/loss analysis bot.

Chainability: How does this connect to other tasks?

For a fan of workflows, such as myself, this is the most interesting consideration.  How a bot fits into a workflow is pretty straightforward.  It is triggered either by a user or by another bot, provided and input, and then it runs its task.

The big question to ask is: when do you want a human review?  Maximally chained bots take an input from the previous bot in the chain, do their thing, then pass the output to the next bot.  This comes with some tradeoffs.

On the pros:

• You get an output down the line faster

On the cons:

• Problems require more sleuthing to find the broken link
• Adjustments to early links may require reworks to downstream links

Personally, I like to chain as much as I can, but am cognizant of how difficult it will be to make systemic adjustments should something change.

Here is an example from the bots I built for Heinz Marketing:

Use case context: We need to analyze websites and combine that with other strategic inputs during our discovery process.

Inputs: Client website URL and key pages

Input sources: Client info analyzer

Trigger: Input received

Output: Website analysis

Output destination: Content analyzer, messaging developer, campaign strategist

This agent takes in a URL provided from an analyst agent that reviews a data dump from clients.  It can also be kicked off manually, but that is a pain.  The main input is the URL, so it is easy to trigger.

It also outputs into 3 different agents.  That is solid chaining right there.  Not every agent can act right away (for example the campaign strategist only triggers once a few other inputs are provided), but it is still part of that chain.

Anyway, the better the chainability, the better the use case.

Conclusion

At the end of the day, what you prioritize is up to you.  This framework is a guide for how we try to maximize objectivity and figure out the right places to start.  However, if you are more advanced, you might not need this framework as much.  Risks that seem daunting today might be less scary when you better understand these tools.  Your specific setup may require more human intervention and thus reduce the weight of chainability.

The only way to do this effectively is to ensure you start by understanding your own team (so go read the SWOT post if you haven’t already).  Begin with this, and then work towards a roadmap.

Marketing, I think moreso than other fields, has real opportunity from AI that can generate ROI.  This, of course, requires it be done right.

One last thing: know that you can really only build 1 thing per team at a time.  There is other work to be done, and this takes some trial and error.  This is even more true when you need inputs/outputs to chain together.  Build one chain at a time, add parallelism modularly, and keep a visual workflow so you know what fits where.

Want to talk about it?  Email us.

Want to do some gap-finding?  Take our Orchestration Self-Audit.