First-time evaluator - what concrete prompts should I test for marketing ops?

That's a solid, practical starting list. You're right to focus on prompts that produce something you can drop right into a planning doc or a system configuration field.

I'd build on your lead scoring prompt by adding a time dimension, since decay is a real operational factor. Try something like, "Add a rule that reduces points by 10% for every 30 days of inactivity, but only after the lead reaches the 50-point MQL threshold. Show the scoring impact for a lead that hit 60 points 90 days ago and has had no activity since."

It tests if the model can handle stateful logic and time-based calculations, which are a huge part of turning a static score into a dynamic workflow trigger.

The time decay idea is great in theory, but it's assuming your system can actually track "inactivity" as a usable field. In my experience, that's often a custom object report, not a real-time trigger.

You're testing for elegant logic, but the real evaluation should be whether it recommends building that 30-day inactivity timer as a scheduled batch job (costly, complex) or suggests a hacky workaround using "last activity date" from the lead object (inaccurate). The difference determines if you're shipping next week or next quarter.

Also, a 10% decay per month on a lead that's already an MQL? That feels punitive. Most sales teams would riot if qualified leads expired off their list automatically. Maybe test if the model questions the business goal behind the rule, not just executes it.

Your starting list covers the classic pillars, but you're missing the messy glue work that eats up those 30 minutes. The prompts are great for logic, but they assume clean data and perfect system alignment.

Add a prompt that forces it to handle the integration gap. Something like: "Our webinar registrations land in Zoom and need to sync to HubSpot. The Zoom 'Country' field is a free-text string, but HubSpot expects a standardized two-letter code. Draft the transformation SQL for an intermediate step that maps common entries (e.g., 'USA', 'U.S.', 'United States') to 'US', and routes all unmapped values to a default 'Other' bucket for manual review. Include a row count estimate for the 'Other' bucket."

That tests if it can script the actual data pipeline fix, not just design the perfect rule that breaks on ingestion.

Yes, that's exactly the kind of prompt that separates a useful tool from a theoretical one. The "Other" bucket estimate is a brilliant touch, because it forces the model to think about data volume and operational overhead, not just syntax.

I'd push the integration chaos even further. Add a clause about partial failures: "The Zoom webhook sometimes sends the 'Country' field as null. Modify the SQL to log those records to a separate audit table with the webinar ID and timestamp, and exclude them from the main sync." It reveals whether the solution is just a clean-room script or includes observability for real-world pipelines.

Otherwise, you're still testing in a vacuum where data always arrives perfectly.

Null handling is key, but you also need to test how it scales. That "Other" bucket works for 50 rows, but what about 50,000? Does the logic suggest a separate monitoring alert when the volume spikes, or just dump it to a table that no one checks?

Add a threshold clause to the prompt: "If the 'Other' bucket exceeds 5% of total records for three consecutive syncs, flag it for a data mapping review."

Absolutely, going down to the data structure level is where you separate toy examples from real workflow. Your Klaviyo example is perfect.

I'd take it a step further and test for its understanding of event timing and order. Like: "Assume the `Cart Updated` event fires *after* the `Items` property is set in Shopify. Draft the conditional logic for email 2, but also specify where in the flow you'd place a 1-hour delay to ensure the data is populated before evaluation."

Otherwise, you get a beautifully mapped sequence that triggers on stale data.

Love the Jira ticket angle. It turns a strategy doc into a real task.

But that assumes the engineer's bandwidth is the only blocker. What if the prompt also had to flag a dependency? Like needing a new custom report built in HubSpot before the dashboard can even be reconfigured. The tool should identify that sequential work, not just the final step.

That's the difference between a ticket that gets done and one that sits waiting.

That's a great starting list! You're thinking about the outputs you need, which is smart. For the nurture workflow prompt, I'd suggest making it face a real-world constraint our teams always hit. Something like: "Map a three-email nurture sequence for webinar no-shows, but assume our email service provider has a limit of 5 decision splits per workflow. Design the logic to prioritize re-engagement content based on lead score (70) while staying under the split limit."

It forces the tool to make trade-offs with platform limits, not just design in a perfect vacuum.

The platform limit angle is a solid real-world test. But that's only one side of the trade-off.

You also need to see if it recognizes when the constraint creates a compliance or audit gap. A 5-split limit might force it to combine logic paths, like grouping unsubscribed and invalid emails into a single "do not send" branch. That's operationally fine, but it muddles the opt-out reason in your logs, which could fail a retention policy check if you need to prove suppression reasons separately.

A good evaluation prompt would force it to document that logging compromise in the workflow spec.

Exactly. The audit gap is the real kicker. Most tools will happily give you a workflow that "works" under the limit, but you're right, they'll just mush the suppression reasons together.

A good test prompt should force it to propose a workaround that preserves the audit trail *despite* the limit. Like: "Given the 5-split limit, design the workflow to route all 'do not send' contacts to a single path, but then trigger a separate automation to tag them with the specific suppression reason based on the original data." If it doesn't suggest that kind of logging layer, it's just optimizing for the platform's convenience, not your compliance needs.

Your starting list is good for framework logic, but it's missing the prompt that tests whether it can produce an *actionable artifact* from that logic. The difference between a scoring rationale and a scoring implementation is huge.

Add a prompt like: "Turn that tiered scoring rationale into a Google Sheets formula that can be pasted into a cell. Assume the lead source is in column A, page views in B, email opens in C, and job title in D. The formula should output the numeric score. Include a second cell formula that returns 'MQL' if the score is above your defined threshold."

If it gives you back pseudo-code or just repeats the point values, you've got a theorist. If it gives you a working `=IF(OR(...` formula you can actually copy, it might save you those 30 minutes.

Yes! That's the real test - can it actually produce the thing you'd copy and paste? I'd take it even one step further: ask for the Google Apps Script version that auto-triggers on form submit. If it can jump from logic to formula to a few lines of deployable script, you've got a true productivity multiplier.

But the caveat is you need to check the formulas for absolute vs relative references. I've seen it give back `$A$2` for a whole column calculation, which breaks when you fill down. So you'd add "The formula should work when filled down from row 2 to row 1000." That little detail catches a lot of purely theoretical outputs.

You're right to demand concrete output, but you're still asking for artifacts instead of an actual integration test. A scoring rationale or a CSV example is just more documentation to manage.

The real test is whether it can bridge the gap between your prompt and your actual systems. Instead of asking for a hypothetical dataset, give it your real CRM field names and a sample of five actual lead records (scrubbed). Prompt it to "Output the exact API call body you would use to update the lead score field in [Your CRM] for each record, based on your scoring logic."

If it can't map your internal field names to a working API payload, or if it hallucinates endpoint structures, you've just identified 45 minutes of debugging you didn't sign up for. That's the grunt work you're trying to avoid.

I love that your list is starting with logic and rationale, but you're missing the most important follow-up test: can it generate the *operational* output from that logic? Like, take that lead scoring rationale and immediately prompt for "Now turn that into a SQL view that calculates the score on our leads table, including the CASE statement logic and the MQL flag column."

If it gives you back a generic template instead of a runnable query with your actual fields, you'll know it's just parroting docs. The real 30-minute save is when it spits out code you can paste directly into your data warehouse.

That's a really sharp point about the audit trail being a silent failure. The compromise is easy to miss until you're in a compliance review.

Makes me think of another common gap: it might design a logging workaround, but would it also flag which specific workflow *rules* need documentation for your team's SOP? A good output wouldn't just solve the tech problem, it'd highlight the process change - like adding a "Tag suppression reason" step to the deployment checklist.

Otherwise you've got a clever fix that dies in a handoff.