How it learns your product

Syncanix does not need you to describe your product to it. Once the widget is on the page, it works out what your software can do by looking at the screens it is made of — the same way a new colleague would, by using it. This page is what it looks at, what it deliberately does not, and what happens to the result.

Two ways it reads

You do not choose between these. The first is something you do once, deliberately, to get a full picture quickly. The second happens on its own from then on.

As people use your product

The widget reads whichever screen the visitor is on. This is quiet, continuous, and covers the parts of your product people actually use — which is usually not the parts anybody would have thought to describe first.

A guided map you run yourself

You click through your own product with recording on, and it writes down each screen as you go. This is the fast path to a complete picture, because you know where the important screens are and a visitor does not.

Mapping your site

One pass is usually enough to get a catalog worth reviewing. Visit the screens your customers ask about most, and open the forms rather than only looking at them — a form that is never opened is a form nobody has read.

1. 1
   Start mapping from the dashboardOpen your own product in a tab, signed in as yourself. Mapping runs in that tab only, on your own session — nothing connects to your product from anywhere else, and we never hold a password to it.
2. 2
   Click through the product as a user wouldSettings, billing, the team page, the export dialog — anywhere a customer might need help. You are not performing actions for it to copy; you are showing it where things are.
3. 3
   Stop when you have covered enoughEnd the run and what it found becomes your site map and your agent's manual. You can map again later — a second pass adds what the first one missed rather than replacing it.

What it reads

It reads the structure of a page — the things that tell it what a person could do there.

• Forms, and the fields in them: what each one is called, whether it is required, and what kind of value it expects.
• The pages your product is made of, as addresses rather than as content.
• Where the links go, so it can take somebody to a screen rather than describe it.
• Any structured description your site already publishes for search engines.

What it never reads

These are structural exclusions, not settings — there is no configuration that turns them off.

• Passwords, card numbers and one-time codes. Those fields are excluded at capture; only the fact that the form has one is recorded.
• What anybody typed. It records that a field exists and what it is for, never what is in it.
• Anything pointing at another company’s site. A form that submits somewhere that is not yours is dropped entirely rather than proposed.
• Anything inside a region you have excluded. A blocked area contributes nothing at all — not even a note that something was skipped there.

Reviewing what it found

Everything lands in one queue in the dashboard, and four things are true of every entry in it.

• It is off. You enable it deliberately, one at a time or in a batch you have read.
• It is described in plain language — “refund an order”, not an address — so the person approving does not have to be the person who built it.
• Once enabled, it always asks the person before it runs. That is not a setting on a discovered capability — nobody labeled its risk, so it confirms every time whatever else your workspace has configured.
• Its risk level is assessed on our side, not claimed by anything on your page — and it can only be raised, never lowered, by what was found.

Keeping up with your product

You do not have to re-run anything when you ship. A screen that changes is read again the next time somebody visits it, and a new screen is picked up the same way. If something the agent knew about disappears, it stops offering it rather than failing in front of a customer.

When to add the code scan

Reading a screen tells the agent what a person can do there. Reading your source tells it exactly what your software accepts. Many products never need the second, and three situations are where it earns its cost.

• You want exact argument shapes — the precise names, types and requirements your software will accept.
• Parts of your product are rarely visited, so nobody has walked them and no visitor will.
• You want to be told when your own team changes something the agent depends on, before a customer finds out.

Next steps