A Website Should Know What You Can Do

Originally published on LinkedIn

TL;DR

Most digital businesses run a marketing site that explains the promise and a separate product that fulfills it - and context disappears between them. People can browse across that gap; agents cannot. The fix is one journey on a shared record of facts, eligibility, and authority, with different presentations for people and agents. Clicks still matter for humans; usefulness and trust matter for agents. Separate codebases can stay. Separate answers cannot.

---

The idea is simple: one platform that informs, sells, and does.

For most digital businesses, their website explains the value of a product. A visitor clicks through, hopefully creates an account, and enters a separate application that knows little to nothing about why they came.

The site that made the brand promise kept the context. The system that could fulfill the promise never received it.

The website saw the search, the content, the questions, and perhaps the path to conversion. The product sees the account and the work that follows.

Somewhere between the two, context disappeared.

A different kind of visitor

A person may come to a website to understand a company and its services, compare options, see a product, and decide whether or not to trust it.

Good design, explanation, and evidence all matter.

That person can also tolerate a gap or 2. The public site is built for that patience. The product is built for the moment after they have already crossed over.

An agent acting for that person arrives with a more specific job. It needs to establish:

• what is available
• whether it applies to that person or organization's situation
• what it is permitted to do
• how to confirm that the job was completed

An agent will not browse its way across a gap, and it will not create an account just to find out whether the business can help.

Imagine an agent trying to replace a part in my dishwasher. It needs the model number, the correct part, evidence of compatibility, current stock, a price, delivery options, and a way to order. It also needs to know how current and reliable those answers are.

A product page may help a person make that decision. The agent needs the underlying facts and relationships in a form it can use.

Once the answer is clear, it needs an authorized path to act and a reliable record of the outcome.

These requirements do not begin when someone signs in. They begin at discovery.

A workaround was holding the two sites together

That handoff always came at a cost.

A person works around gaps by reading, asking, clicking, and trying again. Because a person will do that, a marketing site and a product site can look like a reasonable split.

One explains the promise. The other does the work. The visitor carries the context across.

An agent does not. Each gap adds uncertainty. When it cannot establish the answer, or the authority to act, it stops or hands the problem back to the person.

This is when the agent moves on to a competitor's site where it can complete its job.

The audience and the architecture are the same problem.

• The public site assumes a visitor who can finish an incomplete answer.
• The product assumes a visitor who has already signed in.

Neither is built for a visitor that shows up at discovery with a job to finish.

The split was survivable for a person. For an agent, it is where the journey ends.

One record, two views

Many companies already have APIs and structured product data, in their product, not on their website.

Their websites, product applications, commerce systems, and support systems may still describe the same capability differently.

• A price on one surface lags another.
• An eligibility rule is clear in the application and absent from the public site.
• The marketing language promises a result the product can deliver only under particular conditions.

A person can notice the mismatch and ask. An agent treats the mismatch as doubt, and doubt stops the job.

Take the dishwasher example one step further. The job is not "learn about parts."

The job is specific: can I order the correct part for this model and have it delivered by Friday?

Suppose the record says the model matches a pump that is in stock, and the earliest delivery to that address is Tuesday. Friday is not available.

What a person should see

A page that names the model, the part, the price, and Tuesday. The action on the page should be an order for Tuesday delivery. There should be no Friday button that fails after they click.

What an agent should receive

The same determination. The part is compatible. It is in stock. It costs $86. Delivery by Friday is no. The earliest date is Tuesday, and ordering for that date is authorized.

The page and the response are two presentations of one set of facts.

A person may need the page. An agent may need the structured answer, and then a callable action. Neither presentation is allowed to know something the other cannot check.

If the person looked up the model before signing in, that context stays with them. The product does not meet them as a stranger. The agent does not have to rediscover what the site already established.

The website belongs with the product

The question I keep coming back to is this: Why would our website understand what someone wants, while our applications understand what they are capable of, if neither can use the other's knowledge?

A business should be able to explain its promise, substantiate it, and fulfill it across the same journey, whether the next interaction comes from a person or an agent acting on their behalf.

A large company can keep commerce, support, and product logic in separate repositories.

Multiple codebases are not the failure. A website that sits outside that ecosystem is the failure. It describes capabilities it cannot read, and it points at actions it cannot take.

The practical path is the same discipline already used to connect those other systems. The site has to draw on the record that knows the price, the limit, and the permission.

That is a clearer job than trying to make a standalone HTML website smart enough to not just inform, but allow action.

A person and an agent still need different experiences. The architecture should support both without forcing either through the other's interface.

What they share is the facts, the scope, and the authority to act.

We are rebuilding our website as a Node.js application so it can do exactly that.

The site will keep informing people about what we do. As functionality moves into it, the same environment can help assess a need, use a tool, and get a result.

• Some capabilities will appear as interfaces for people.
• Others will be exposed as structured data or callable services for agents.

Not everything we offer is available there yet, nor will it be.

Most of what we do is about human interaction.

Measurements

Clicks and conversion rates are still useful for understanding how people find us and move through the site.

For an agent, we also want to know:

• Did it get an accurate answer?
• Could it determine whether the capability applied?
• Was an action authorized?
• Did the requested outcome happen?
• Could the person understand and verify what happened?

Those are measures of usefulness and trust, not simply traffic.

One journey, not two sites

A website where we market, sell, and inform, and a product site where the work happens, was a practical way to build. Each had a clear job. A person was willing to cross from one to the other and supply what got lost on the way.

That is the shape we are leaving. Not because the human work should move into an application. Most of what we do is still a conversation and a judgment. We are leaving it because the two entities cannot use what the other knows.

The website holds the reason someone came. The product holds what we are able to do. Measured apart, one side counts the visit and the other side sees the work. The distance between them looks like a funnel. It is lost context.

Separate codebases can stay. Separate answers cannot.

Informing, selling, and doing the work can live on one journey, for a person reading the page and for an agent acting on their behalf.

-Ben Cornelius