Processes inside companies: how a text genre spreads with LLMs

Everyone knows LLMs have had an impact on many fields. Yet one field few people talk about is how they standardize internal processes in companies.

A skill built in a day can have a huge impact and bring standards where the rules were seen as optional. As an example, take a problem engineering had to deal with for years: badly written tickets, with missing data and information that was half there or even false.

To solve it, I built a skill that automated ticket creation. It took the information it already had in the conversation and, by asking questions, filled in whatever else was needed and missing.

The company already had a standard, and the skill was built on top of it. But people did not follow the standard, and often worked around it so the ticket author could finish quickly and move on, without stopping at questions they did not know where to find the answer to.

Picture this: you worked in the company's support team. You had five different customers asking you about different problems at the same time.

You were trying to answer them all more or less quickly. A small change here, a canned reply there, an email. In the middle of it, you found a problem you could only solve by opening a ticket for engineering.

Then your already chaotic workflow broke down. You stopped and had to answer a pile of questions, with details you started to mix up with other customers' context. Halfway through the ticket, you had to stop to deal with an angrier customer and then another, an employee of a VIP company.

The person filling in the ticket was, as a rule, someone in support with customers in their ear wanting answers. Every minute spent on it meant one more angry customer waiting for a fix and one more support ticket piling up in the queue.

The result was tickets with little information reaching the engineering teams. The engineer who owned the ticket ended up losing time chasing several people to get the minimum information needed to start work.

With the skill, we saw this change fast and sharply. The skill helped both sides. For the person creating the ticket, it took what was already in the conversation and answered several standard questions, such as:

• What is the problem?
• What is the impact on the end user?
• On which page did the user see the error?
• If it is a new feature, how will it look to the end customer?
• What is out of scope?

This made ticket authors faster: if the context was complete, they just called the skill and the ticket came out ready, with no further input. For engineers, it ensured the ticket held everything support knew about the problem.

In terms of results, the skill started as a solo project with a handful of tickets and grew to 650 tickets created by more than 10 teams and 23 different people in 3 months of use. There was no internal process and no training meeting. The skill was never even mentioned to those users and teams, yet that did not stop it from becoming the new standard and spreading. A single skill standardized something engineering had fought for years to standardize, and solved a problem support had, freeing time to deal with more customers.

What spread was not only the skill but the ticket format. Every ticket created with it had the same sections in the same order, and the people who received it, commented on it or opened the next ticket read it. Readers came to recognize the format and expect it; writers came to follow it, with or without the skill. The well-written ticket became a text genre, and you learn a genre by reading it, not in a meeting.