Nudge Theory Revisited: Writing Tickets for Humans and Machines
Using ideas from behavioral economics to improve ticket writing, especially now that large language models are reading your tickets as…
Nudge Theory Revisited: Writing Tickets for Humans and Machines
Using ideas from behavioral economics to improve ticket writing, especially now that large language models are reading your tickets as well.
The way you write a ticket affects how quickly someone responds, and behavioral economics explains why. Thaler and Sunstein’s 2008 book Nudge showed that small changes in how choices are presented can influence behavior without limiting options. In many ways, a ticket is a choice architecture problem. The words you choose, the structure, and what you include or leave out all influence whether someone acts on the ticket right away or ignores it.
I've discussed this topic before, but something has changed recently that makes it worth revisiting.
The person reading your ticket might no longer be human. Engineers now paste Jira links into coding assistants. Platform teams use LLMs to summarize ticket queues. Some teams even have workflows where a model reads the ticket and tries to fix the issue without any human involvement.
This means that now, your ticket text has two jobs. It needs to motivate a human to take action, which is where nudge theory comes in. It also has to give a machine enough context to act correctly without inventing details, which is a newer challenge.
How Nudges Work in Tickets
If you’ve worked with ticket queues, you know the main issue: people don’t sort tickets rationally. They scan titles, feel urgency or not, pick tickets that seem quick to close, and avoid ones that look like they’ll take a lot of research. Behavioral economics has terms for all these behaviors.
Loss aversion is probably the most important concept. People are more motivated to avoid a loss than to gain something of equal value. For example, “SLA expires in 48 hours, unremediated findings block SOC 2 certification” is more urgent than “please remediate this vulnerability.” The first tells you what you could lose, while the second just makes a polite request.
Defaults are important as well. A ticket that says “fix the misconfiguration in the IAM policy” gives someone a problem, but no clear solution. A ticket that says “remove the wildcard permission on line 34 of iam-policy.tf and replace it with the scoped permissions listed below" gives them a specific action to take. Thaler's research found that people usually follow the expected path, so make sure to provide one.
Social proof is often overlooked. For example, saying “87% of teams in your org have already remediated this class of finding” nudges engineers by showing that taking action is normal. Security or compliance teams rarely use this, even though the data is usually available.
Friction is a major factor. Every extra step between reading the ticket and finishing the work is a chance for someone to get distracted. If the engineer has to look up the repo, find the file, read the policy, figure out the fix, and then implement it, there are many opportunities to lose focus. The more context you include in the ticket, like links, code snippets, file paths, or a suggested patch, the fewer reasons they have to leave the ticket.
None of these ideas are new. They are well established in behavioral science. But they all assume the reader is human, someone who might procrastinate, respond to social pressure, or take the easiest path. What happens when a model reads the ticket instead?
When an LLM Picks Up the Ticket
A model won’t procrastinate, feel social pressure, or react to loss framing. However, it can fail in ways that humans do not, and these failures often relate to how the ticket was written.
The biggest issue is hallucination. If a ticket says “fix the security issue in the auth service” and gives no other details, a human would likely ask for clarification. A model, on the other hand, will just continue and fill in the blanks with whatever seems reasonable, which can lead to mistakes. Vague input leads to confident but incorrect output.
A related issue is the lack of specificity. If a ticket says “update the TLS configuration to meet compliance requirements” but doesn’t mention which compliance framework, which config file, or what the final state should be, the model has to do extra research. Each step in this process is a chance to pick up incorrect information. It might find an outdated Stack Overflow answer or invent a configuration parameter that doesn’t exist. The more the model has to guess beyond what’s in the ticket, the less likely it is to produce a correct fix.
Structure is helpful, but not for the same reasons it helps humans. People can read a block of text and still understand the meaning. LLMs work better when the problem, affected resource, fix, and acceptance criteria are in separate labeled sections. This reduces the chance of the model confusing what went wrong with what the desired outcome should be. It may seem unlikely, but this confusion happens often, especially when everything is in one paragraph.
What Actually Helps
There isn’t a universal template that solves every problem. The details depend on your tools, your organization, and the types of tickets you handle. Still, there are a few key points I always return to.
Make sure the title describes the action needed, not just the category. Remove wildcard S3 permissions in prod-data-bucket IAM policy This approach tells both a human and a model what needs to be done. Security finding in production A vague title tells neither audience what to do.
Divide the ticket body into sections, such as what happened, why it matters, and how to fix it. The “why it matters” section is for humans, where you include loss framing and urgency. The “how to fix it” section is for models, with concrete steps, file paths, and the expected end state. Keeping these sections separate helps each audience find what they need quickly.
Include context directly in the ticket instead of linking to it. This is one of the biggest gaps right now. A ticket that says “see the policy document here” and points to a link works for a human who has access and time, but it’s a dead end for an LLM. If you reference a policy, include the relevant lines in the ticket body. Do the same for code, show both the current and desired states, rather than just describing the change.
Write acceptance criteria. “Resolved when the IAM policy grants only s3:GetObject, s3:PutObject, and s3:ListBucket to the application role, and a plan is applied without error." For humans, this acts as a commitment device, you can see the finish line, so you're less likely to do a partial fix and close the ticket. For models, it's a verification target. An agentic system with clear acceptance criteria can check its own work. One without criteria is guessing about what "done" means.
Be consistent with your terms. If you call it a “finding” in one sentence and a “vulnerability” in the next and an “issue” in the title, a human won’t care because we handle synonyms fine. But LLMs that are aggregating or cross-referencing across tickets can treat those as different things. Just pick one term and use it.
Use numbers for severity, not just labels. “Critical” is subjective. “CVSS 9.1, actively exploited, internet-facing” is not. Numbers give humans a calibrated sense of urgency (instead of the “everything is critical” fatigue that makes people ignore labels). They give models an unambiguous priority signal.
Why Most Tickets Are Bad
It’s mostly a systems problem, honestly. The tools that generate tickets, like scanners, compliance platforms, and monitoring tools, are built to detect, not to communicate. They produce a “finding detected” event with metadata. Then a ticket template asks a security analyst who’s writing thirty of these a day to turn that into a useful request. They end up copy-pasting scanner output, adding a “please remediate” line, and moving on to the next one.
The result is a ticket that manages to be too technical (raw scanner output that an application engineer may not understand) and too vague (no remediation path, no file references, no acceptance criteria) at the same time.
LLM summarization makes it worse, not better. A model summarizing a vague ticket produces a clean, readable summary, but the underlying ambiguity is still there. It just got polished. The engineer reads the summary and thinks they understand the ask. Then they start working and realize there’s no actual detail behind it. If an agentic system is acting on that summary instead of the original ticket, you’ve got a game of telephone where each layer sounds more confident while containing less information.
You can’t fix bad input with better summarization. The real fix is to write the ticket properly from the start.
Patterns That Consistently Go Wrong
The “wall of CVE” ticket is 20 CVEs dumped into a single ticket with no grouping or guidance. Humans put it at the bottom of the pile. Models try to tackle all twenty at once and produce a sprawling change that conflates separate fixes, which is arguably worse than not fixing anything because now someone has to review a giant diff they didn’t ask for.
The “see attached” ticket has three sentences in the body, with all the real context in a PDF or a Confluence link. Even for humans, every click away from the ticket is a chance to get distracted. For a model, the attachment might as well not exist.
Then there’s the “urgent but unscoped” ticket, marked P1, tagged critical, escalated to leadership, but the actual description is just “auth service has a security issue.” This is bad for both audiences in different ways. Humans feel urgency but have no idea what to do. Models see the urgency as a signal to act fast, but there’s nothing specific to act on, so they start making things up.
The worst, and probably the most common, is the “assumed knowledge” ticket. It’s written by someone who knows the system well, for someone who might not. It’s full of internal shorthand and assumes the reader knows which repo, environment, and team owns what. A human might figure it out by asking around. A model fills those gaps with plausible guesses. That’s where you get made-up file paths, invented configuration parameters, and fixes applied to the wrong service.
Measuring Whether Any of This Works
One thing I like about this approach is that it’s testable. You can track the mean time to remediation before and after changing your ticket templates. You can compare first-pass success rates for LLM-assisted fixes across different ticket formats. You can even A/B test this across teams if you have enough volume.
Thaler and Sunstein were clear that nudges should be transparent and measurable. They called it libertarian paternalism: you’re shaping choices, not restricting them, and you should be able to show whether it’s working. If the new templates aren’t improving the numbers, try something else. If models are hallucinating on a certain type of ticket, look at what context those tickets are missing. The data will tell you.
So, Where Does This Leave Us
Writing good tickets has always mattered. What’s different now is that the cost of a bad ticket has gone up. It used to just mean slow remediation. An engineer would eventually get to it, maybe ask some questions, maybe figure it out from context. Now, a bad ticket might get silently picked up by a model that produces a confident, wrong fix that someone rubber-stamps in a PR review. Or it gets summarized into something that sounds clear but loses the only piece of information that actually mattered.
The good news is that optimizing for humans and optimizing for machines mostly point in the same direction. Be specific. Structure the content. Include enough context so that nobody, human or otherwise, has to guess. The dual-audience challenge can be annoying, but it leads to tickets that are better for everyone.
I don’t think this needs a massive process overhaul. Start with your ticket templates. Look at the fields, the defaults, what gets auto-populated, and what gets left to the analyst. That’s where you have leverage. It’s not glamorous work, but it’s the kind of thing that quietly adds up over time.
By Joshua McDonald on March 26, 2026.
Exported from Medium on August 26, 2026.
Reader discussion