The Simple Workflow Might Be the Product

I was talking to a probable customer, and they said they wanted a ticketing system. I offered automation. They said no. Automation felt too far fetched to them; they wanted a copy-paste flow from email into tickets.

We are talking about, like, four, five emails. They wanted to read the email, copy the useful text, paste it into one place, and have the system generate a ticket with reminders and future follow-ups.

Our problem as builders is that we see “simple to build” and translate it into “not a real requirement.” But what we think is simple is not what people are actually thinking is as simple, and they want it as a product. The gap is not the model. The gap is that I am looking at build difficulty, and they are looking at the thing they repeat day to day.

That simple thing was the requirement

The useful signal in that conversation was not the ticketing system itself. They can already read the email, copy it, and manually create a ticket on something like Monday or Jira or whatever tool they are planning to use.

The useful signal was their no.

They did not want a full automation pitch. This was not exactly automation automation. They wanted a simple copy paste on their emails.

So the product was not a ticketing system in the abstract. It was email text becoming a ticket with reminders attached.

In theory, it is simple. But that was still the requirement.

They read the email, copy the useful part, create the ticket in another tool, set a reminder, and still have to manually track the follow-up. It is not a big AI automation story. It is just a chore they want removed.

flowchart TD
  A[Read email] --> B[Copy useful text]
  B --> C[Create ticket]
  C --> D[Set reminder]
  D --> E[Track follow-up]
  E --> F[Risk of missed follow-up]

I think we dismiss this kind of chore too quickly.

We think it is too simple, so we think it is not a requirement

I keep catching myself doing this too. If it does not require some deep technical machinery, I assume it cannot be a real product, or at least not a product worth charging for.

That was the wrong filter in this call.

I was judging it like a builder: if anyone can build it, maybe it is not worth building.

The customer was not paying for difficulty. They were trying to get rid of the same small follow-up risk day to day.

For the customer, the existing option was not impossible. They could read the email, copy the text, and manually create a ticket in something like Monday or Jira or whatever tool they planned to use. That is exactly why a builder might ignore it. So technically, yes, there was already a way to do it.

But just because Monday or Jira exists does not mean this specific job is solved for them.

If the user still has to manually track, set reminders and things, and carry the follow-up when something is missed, the product is not done for them. Monday or Jira can exist, and the person can still be doing the boring part manually.

For them, it was genuine. For me, it looked too easy. That gap is the mistake.

Not every copy-paste flow is a product

I am not saying every copy-paste task is a product. Some of it is just process.

Sometimes it is just setup. Sometimes the team has not committed to the tool they already have. I still have to check that before calling it a product.

That is not the rule I took from the call.

Now I look for two things: is it happening again and again, and does the person still feel pain even after using the obvious tool?

In this case, the customer was not starting from an AI demo. They were reacting to a day-to-day chore. Four, five emails does not sound like volume to a builder. But if each one creates a ticket and a follow-up risk, the count is misleading.

In that call, I was thinking about AI capability. They were thinking about the next follow-up they might miss.

Start from the copy-paste part

The better product question is not, “how much can the agent automate?” That question would push me toward the exact demo they had already rejected.

So now I ask about the copy-paste part first.

I want to know what they copy, where they paste it, and what breaks if they forget. If I had started with their copy-paste step, I would have reached the requirement faster.

They did not need an agent pitch. They needed email text to become a ticket with reminders attached, so the follow-up did not disappear.

The line I wrote down after the call was this: easy for me to build does not mean small for them.

If it removes a repeated loop, the build difficulty is not the main question.

The gap is where I want to look

In the next customer conversation, I want to start with the copy-paste step before I pitch the agent.

Not the biggest agent demo. Just the part where an email turns into a ticket and a reminder without someone babysitting it.

Maybe the thing we are calling too simple is exactly the requirement.