# Touchpoints

The six ways your agent and the OU AI app meet: short links, QR codes, the widget, the Discover feed, handover, and push.

Source: https://docs.omazy.ai/how-to/app/touchpoints/

Six places your agent and the app touch. Five of them you control directly. One
of them you do not, and knowing which is which saves a printing bill.

| Touchpoint | You control it | Needs the app installed |
|---|---|---|
| Short link `ou.chat/{handle}` | Yes | No |
| QR code | Yes | No |
| Widget on your site | Yes | No |
| Handing over to a person | Yes | No |
| Push notification | Partly | Yes |
| The app's Discover feed | **No** | Yes |

## Short links

Every published agent is reachable at a bare path on `ou.chat`. It opens in any
browser, on any phone, with no install and no account.

The path resolves in a fixed order, and all three forms are globally unique so a
bare path is never ambiguous:

| Form | Example | Use it for |
|---|---|---|
| Widget key | `ou.chat/w/wgt_…` | A specific deployment. Stable, opaque, ugly. |
| App slug | `ou.chat/your-app-slug` | A second brand in the same workspace |
| Workspace handle | `ou.chat/yourbrand` | **Your main link.** The most brandable form. |

Your app **handle** is not in that list, and cannot be. Handles are unique only
within a workspace, so a bare path built from one would be ambiguous across
workspaces. The console shows you the right link to share, so copy it from there
rather than assembling one.

### Words you cannot have

A handful of paths belong to the marketing site and can never be claimed as a
handle: `features`, `marketplace`, `business`, `creators`, `enterprise`,
`download`, `support`, `contact`, `privacy`, `terms`. Handle creation rejects
them. If a name you want is refused, this is usually why.

## QR codes

A QR code that encodes your short link is the highest-value physical touchpoint
we have, because it works with the stock camera app on every phone. No install,
no scanner, no instructions under the code.

The app also has a built-in scanner for people who already have it, which opens
the agent directly rather than routing through a browser.

Two rules, both learned the expensive way:

**Print the workspace-handle form.** `ou.chat/yourbrand` reads as a brand and
survives being retyped by hand. `ou.chat/w/wgt_8f21c…` does not.

**Test the printed artwork, not the link.** Scan the actual proof with two
phones before it goes to print. A code on a table tent, a receipt, or a shop
window cannot be reissued, and a wrong one is permanent.

## The widget on your site

Covered in [Widget](/how-to/widget/). It matters here for one reason: a visitor who
starts in the widget and later opens the same agent from a link or a code is
continuing, not starting over.

## The Discover feed

This is the one you do not control.

The app has a Discover list where people browse and search agents. It is
**curated**. Publishing an agent does not put it there. The feed is scoped to
agents in the platform's own curated workspace, and agents in an ordinary
customer workspace stay invisible to it by design, which is also what stops one
tenant's agents appearing next to another's.

So do not plan a launch around appearing in the feed, and do not tell customers
to search the app for you. Give them the link or the code. If a listing is
something you want, it is a conversation with us and not a setting in the
console.

When an agent is listed, the feed shows its name, tagline, description,
category, icon, presence, and location, and can be filtered by search text,
country, city, and kind. Those fields come from the agent's own profile, so they
are worth filling in properly whether or not you are ever listed. They are the
same fields the widget and the short link use.

## Handing over to a person

A person talking to your agent can ask for a human. The app checks whether
anyone is available, then moves the conversation into your inbox with the whole
thread attached. The operator replies over the same channel and the customer sees
it in the same place they were already reading.

Nothing extra is required in the app for this. It follows the handover rules on
the agent, so what you set in the brief is what happens on the phone. See
[Inbox](/how-to/engage/inbox/).

The personal assistant has no equivalent. It never hands over to anyone.

## Push notifications

If the person has the app installed and notifications enabled, a reply that
arrives while they are away is pushed to their device, and tapping it opens the
conversation where they left it.

You do not compose these and there is no broadcast in the app. The trigger is a
reply on a thread the person is part of, which is why this is only partly yours:
you control whether your operator answers, not whether the phone rings.

## What carries across

The conversation is the unit, not the surface. A thread keeps its history when
someone moves between a browser link, a scanned code, the app, and a human
operator. That is the property worth designing your touchpoints around, because
it is the one customers notice.

## Before you commit a touchpoint

Worth ten minutes, in this order:

1. Open your short link in a private browser window on a phone. Confirm it is
   your agent, your brand colour, and your opening question.
2. Ask it the three questions you actually get most. Fix the brief, not the link.
3. Ask for a human. Confirm the conversation lands in your inbox and someone sees
   it.
4. Scan the printed proof of any QR artwork with two different phones.
5. Only then order the print run.