Why I want marketing to happen through text

Marketing through text would be useful if a busy owner could bring a rough thought, get help filling in missing facts, review an understandable draft, and know what happens next. That's the direction I'm building toward with Protocol Text. A text box alone doesn't make that a good experience.

By Eric Yim, Protocol Text

Why I care about the small interaction details

There are small details that I feel really opinionated about: design, experience, the way that people interact with my software. I am trying to make the entire thing through text. I want to make that a really good experience.

Poke.com is an example I admire because the interaction feels novel and good to me. That's a personal reference for the kind of care I value, not a partnership or a claim that it's the right product for every owner.

I think the way a product feels and looks matters. I want real thought and real-life reasoning behind why it was built that way, with a lot more time spent on it than just telling AI to make something.

For a text-driven product, that care has to reach beyond the screen. Does the reply help the owner move forward? Does it notice an unanswered factual question? Can the owner tell whether they're looking at a suggestion, a draft, or something ready for approval?

What a useful text-driven task could look like

Consider a hypothetical service owner who wants a post explaining what customers should send when requesting an estimate. Here's how I'd evaluate that exchange. These are criteria for the experience I'm building toward, not a list of features I'm claiming are all live.

Start with the owner's raw thought. The owner shouldn't need to write a marketing brief before getting help. They might explain that estimate requests often arrive without enough information. That's a useful starting point, but it doesn't establish what this particular business needs.

Ask for the missing fact. The tool should find out which details the business actually requires. Photos, measurements, and a description of the work are possible examples, not facts it should assume. If the request is ambiguous, a focused question is better than confidently writing the wrong thing.

Show a draft the owner can judge. Once those facts are supplied, the tool could turn them into a customer-facing post. I'd want the owner to see the actual wording and its intended destination, with the draft status made clear. Preparing a post shouldn't silently become publishing it.

Make correction straightforward. Suppose the owner explains that measurements are optional. The revision should reflect that distinction everywhere it appears. The owner should be able to review the updated wording without reconstructing the entire conversation or wondering which version is current.

Explain the next step. The exchange should say whether it needs another fact, a review, or approval for a specific action. If something important is still unresolved, it should stay unresolved visibly. A polished paragraph shouldn't hide an unanswered question.

Why ordinary language matters for busy owners

I think people are really overwhelmed by the entire concept of marketing. They hear buzzwords, software recommendations, and advice about all the things they should be doing. Sometimes they end up doing nothing at all.

A lot of the time, doing a little is better than doing nothing at all. That doesn't mean any post will produce a result. It means the interaction shouldn't make a small, useful task harder to begin.

In the estimate example, the owner already understands the problem: customers aren't sending enough information. The software should help turn that knowledge into clear communication. Requiring the owner to learn a new marketing vocabulary first would add work before helping with the work they came to do.

What I'd ask to see before choosing a tool

I care about combining technology with a personal connection to the founder. In my view, some technology-led businesses miss that connection, while some businesses with a higher personal touch lack the technology. I want both in Protocol Text.

For an owner evaluating software, I'd suggest asking for a demonstration that includes an unclear request and a correction. A clean first draft shows only part of the experience. Watch what happens when you change a fact or ask what has actually been approved.

Also ask how you reach a person and what context they receive. Ideally, you shouldn't have to explain the whole task again. Text can keep a task moving, but when the exchange stops resolving uncertainty, there needs to be a sensible handoff rather than another round of guessing.

Questions about using text for marketing work

Do I need to know marketing terminology to make a useful request?

No. Start with the facts you know, what your customer asks, and what you want the communication to accomplish. For example, you might want customers to understand what information to send before an estimate. That gives the exchange a useful direction without requiring marketing jargon.

How should a tool handle a photo that includes private customer information?

It should flag the issue for owner review before the photo moves toward publication. Submitting a photo shouldn't automatically make it public. The owner should choose material they have permission to use and check for visible names, addresses, documents, or other details that shouldn't be shared.

When is a human conversation better than another text prompt?

When the goals, facts, or judgment calls remain unclear after clarification, a person may be better able to work through the context. I'd also favor a conversation when the owner needs to explain a sensitive concern that the exchange hasn't captured. Repeated prompts shouldn't substitute for understanding.

Is a text interface suitable for every creative project?

No. Text can help coordinate many tasks, but a complex creative project may need visual references, richer source material, or a longer discussion. I'd assess the actual work and the decisions involved. The interface should support those needs rather than require every project to fit one kind of exchange.