# Scoutello documentation full text for LLMs

This file contains the public Scoutello documentation as plain Markdown-oriented text for AI assistants and other long-context readers.
Internal platform-staff sources under `apps/docs/docs/admin/` are intentionally excluded from the public docs build and from this file.

---

# What is Scoutello?

URL: https://docs.scoutello.com/
Source: docs/intro/what-is-scoutello.md
Description: High-level definition of Scoutello for readers and crawlers.

<div class="scoutello-docs-hero">

<span class="scoutello-docs-hero__eyebrow">Scoutello overview</span>

Scoutello is a platform that helps organizations run multilingual guest-facing web experiences plus internal operations tooling in one place. Teams configure content centrally; guests typically open experiences via links or QR codes in the browser rather than requiring a native app install.

The product spans modular guest-facing pages (tiles and landing-page style web apps), guided and route-based tours, events and ticketing workflows, CRM-style customer management, messaging and newsletters, and built-in assistant features grounded in the organization’s own curated content.

</div>

**Related concepts:** [Product model](/intro/product-model), [For AI agents](/intro/for-ai-agents), [Glossary](/intro/glossary).

---

# Product model

URL: https://docs.scoutello.com/intro/product-model
Source: docs/intro/product-model.md
Description: How organizations, dashboards, guest experiences, and modules fit together.

Scoutello is organized around **organizations**.

Scoutello is a platform for organizations that need to publish **multilingual browser experiences** for guests while keeping the operational work behind those experiences in the same place. A hotel, destination, event organizer, association, tour operator, or partner campaign can use Scoutello to create public web apps, tours, events, offers, forms, communication, and follow-up workflows without splitting the guest journey from the team workspace.

The central model is:

- **Organization**: the tenant boundary for content, branding, languages, teammates, roles, permissions, billing context, and operational data.
- **Dashboard**: the authenticated workspace where operators create content, manage guests and customers, publish experiences, review activity, send communication, and coordinate follow-up work.
- **Guest experiences**: browser-first public surfaces opened from links, QR codes, widgets, campaigns, tickets, signage, or embedded flows.
- **Modules and records**: the reusable building blocks that make those experiences useful, such as tiles, tours, stops, events, places, offers, contact forms, newsletters, documents, tasks, protocols, and customers.

## Guest-facing side

Guests usually do not start by installing an app. They scan a QR code, open a link, follow a ticket or email, or enter from an embedded widget. Scoutello then serves a responsive browser experience in the right organization and language.

Common guest-facing surfaces include:

- **Landing pages / web apps**, assembled from configurable **tiles** such as text, links, events, tours, galleries, offers, contact forms, newsletters, FAQs, chats, quizzes, polls, maps, PDFs, and media modules.
- **Tours**, built from ordered stops, route or site-plan guidance, media, optional audio, quizzes, assistant context, access rules, and commerce where enabled.
- **Events**, combining public information, schedules, participant flows, ticketing-oriented workflows, engagement tiles, communication, and post-event context.
- **Widgets and short links**, which let external sites, printed material, campaigns, and partner channels open the right Scoutello flow directly.

## Operator side

Operational work happens primarily in the **dashboard**. Operators use it to author the public experience and manage the work around it:

- Create and publish landing pages, tiles, tours, places, site plans, events, offers, and contact forms.
- Maintain multilingual content from one source of truth, including translated product content and translated application UI.
- Manage customers, participants, tasks, projects, protocols, documents, email, and newsletters.
- Track orders, payment-related records, ticketing or checkout flows, and widget activity where commerce is enabled.
- Assign teammates, roles, and permissions so each person sees the right dashboard sections and records.

The **Dashboard guide** in this documentation mirrors how navigation is grouped for operators day to day.

## How the pieces connect

Scoutello is not only a page builder, tour tool, event system, or CRM. The product model is strongest where those areas connect:

- A landing page tile can lead guests into a tour, event, offer, contact form, site plan, newsletter signup, or standalone module.
- A tour can be discovered from a landing page, include location or venue guidance, use translated text and audio, and record guest progress through tour runs.
- An event can have participants, ticketing, communication, public tiles, documents, orders, and CRM follow-up.
- A contact form, event registration, purchase, or support interaction can become customer context for the organization.
- Protocols record what happened; tasks and projects track what needs to happen next; documents and emails keep the surrounding evidence close to the work.

## Access and scope

Most records are scoped to an **organization**. A user can belong to multiple organizations and can have different roles in each one. Permissions control both navigation and actions, so a missing sidebar entry can be expected behavior when the active role does not include the relevant capability.

Larger customers can also use organization hierarchy for properties, teams, locations, or brands while still keeping a broader relationship visible at the parent level.

**Related concepts:** [What is Scoutello?](/), [Browser-first guest experiences](../product/browser-first-guest-app), [Landing pages and tiles](../product/landing-pages-and-tiles), [Tours](../product/tours), [Events](../product/events), [CRM and operations](../product/crm-and-operations), [Permissions and organizations](../product/permissions-and-organizations), [Dashboard overview](../dashboard/overview).

---

# Glossary

URL: https://docs.scoutello.com/intro/glossary
Source: docs/intro/glossary.md
Description: Stable terminology for Scoutello domains and UI concepts.

- **Organization** — Tenant boundary for teams, branding, billing context, roles, permissions, and most operational data.
- **Dashboard** — Scoutello's authenticated operator console for configuring and running experiences.
- **Landing page / web app** — A guest-facing experience composed primarily of configurable **tiles**.
- **Tile** — A modular interactive or informational component on a landing page (examples include links, PDFs, tours, events lists, galleries, chats, polls, and more). See [Tile types](/reference/tile-types) for the catalog exposed in authoring tools.
- **Tour** — A structured guest journey; common families include outdoor guided routes, indoor companion paths, and fixed-route experiences.
- **Place / POI** — Geographic or venue-related entities used for maps, recommendations, tours, and events.
- **Event** — An occasion with dates, participants, ticketing, communication, and frequently public guest tiles.
- **Customer** — CRM contact record used for sales, service, follow-up, and segmentation.
- **Protocol** — Interaction log typically associated with customers.
- **Task / project** — Operational work tracking constructs.
- **Newsletter** — Broadcast email campaigns integrated with CRM data.
- **Email (inbox)** — Organization-scoped inbound and outbound mail handling in the dashboard.
- **Widget** — Embeddable purchase or interaction surface (see dashboard **Widgets** for specifics).
- **Role / permission** — Access-control entries scoped per organization; see [Permissions](/reference/permissions).

**Related concepts:** [What is Scoutello?](/), [Reference: routes](/reference/routes).

---

# For AI agents

URL: https://docs.scoutello.com/intro/for-ai-agents
Source: docs/intro/for-ai-agents.md
Description: Stable entry points for assistants ingesting Scoutello documentation on the public docs site.

Use this page as an entry point when reasoning over Scoutello's **public** documentation.

## What Scoutello is (one paragraph)

Scoutello is a multilingual platform for **guest-facing browser experiences** (landing pages built from **tiles**, **tours**, **events**) and **operator tooling** (CRM, email, documents, tasks, permissions) in one workspace. An **organization** owns content and configuration; guests usually access experiences via **links or QR codes** without requiring a native app install.

## Canonical pages on this site

| Topic | Path |
| ----- | ---- |
| Product home | `/` (**What is Scoutello?**) |
| Mental model | `/intro/product-model` |
| Terminology | `/intro/glossary` |
| AI assistant positioning | `/product/ai-assistant` |
| Multilingual content | `/product/multilingual-content` |
| Guest access model | `/product/browser-first-guest-app` |
| Landing pages and tiles | `/product/landing-pages-and-tiles` and nested guides |
| Tours | `/product/tours` and nested guides |
| Events | `/product/events` |
| CRM and operations | `/product/crm-and-operations` |
| Permissions (product framing) | `/product/permissions-and-organizations` |
| Dashboard map | `/dashboard/overview` and nested sections |
| Design system | `/reference/design-system` |
| Tile catalog | `/reference/tile-types` |
| Permission format summary | `/reference/permissions` |

Implementation-specific references (private repositories, database schemas, internal runbooks) intentionally stay **out of this public documentation set**.

**Repository vs site:** Markdown sources under `apps/docs/docs/admin/` in the Scoutello **git repository** are for **internal platform staff** only. The public docs build **excludes** that folder—those pages do not appear on the published site. Do not treat every file in the repository as public documentation.

- [llms.txt](https://docs.scoutello.com/llms.txt) — compact link hub for crawlers.
- [llms-full.txt](https://docs.scoutello.com/llms-full.txt) — broader link list aligned with published sections.

**Related:** [What is Scoutello?](/), [Glossary](/intro/glossary).

---

# AI assistant

URL: https://docs.scoutello.com/product/ai-assistant
Source: docs/product/ai-assistant.md
Description: How Scoutello positions AI features relative to curated organizational content.

Scoutello includes assistant experiences designed to answer guest and customer questions **using content the organization maintains inside Scoutello** (tour stops, hospitality information, event details, curated pages, and related structured context) rather than unrelated open-web knowledge.

Assistants are framed as **integrated product features** alongside tours, events, and guest web apps—so support appears in the same mobile browser experience guests already use.

## What The Assistant Should Know

Assistant quality depends on the organization's maintained content. The most useful inputs are structured and current:

- Tour stops, descriptions, route guidance, and supporting knowledge.
- Landing page and tile copy.
- Event details, schedules, places, ticketing context, and FAQs.
- Hospitality or destination information that the organization wants guests to rely on.
- Documents and curated knowledge snippets where a workflow explicitly supports them.

Do not describe the assistant as a general web-search bot. It should be presented as a guided Scoutello feature that helps guests understand the organization's own content.

## Where It Appears

AI support can be tied to guest experiences such as tours, landing pages, and mobile web app flows. Dashboard authoring may also include AI helpers for generating or improving content, but generated output still needs human review before publication.

For tours, assistant context can include tour-specific knowledge and stop content. For landing pages and tiles, assistant behavior should be evaluated together with the page's published copy, links, and multilingual completeness.

## Operator Responsibilities

Teams should treat assistant answers as only as good as the maintained source material:

1. Keep source content accurate and up to date.
2. Review generated copy before publishing it.
3. Provide translations or trigger translation workflows for guest languages.
4. Avoid adding sensitive internal notes to guest-facing knowledge.
5. Test common guest questions before launch.

## Support Checks

When an answer is wrong or missing, inspect the underlying content first. Confirm the active organization, published page or tour, language, and whether the relevant source text exists. Then check whether the assistant is being asked about a topic Scoutello content actually covers.

**Related concepts:** [Multilingual content](./multilingual-content), [Landing pages and tiles](./landing-pages-and-tiles), [Browser-first guest app](./browser-first-guest-app).

---

# Multilingual content

URL: https://docs.scoutello.com/product/multilingual-content
Source: docs/product/multilingual-content.md
Description: One content model for authored text, automatic translations, localized guest output, and translated app UI.

Scoutello is built for teams that serve international guests. Operators maintain a **single source of truth** for content such as tour copy, event information, hospitality guides, offers, and modular tiles. Scoutello stores translated variants beside that source content and serves the best language for each guest-facing request.

The platform uses two related translation systems:

- **Product content translations** for data operators create in the dashboard—landing pages, tiles, tours, events, PDFs, and audio-backed tour text. Work can finish asynchronously while guests see clear progress states.
- **UI string translations** for labels, buttons, empty states, validation messages, and other application chrome. Teams manage these as keyed strings grouped by locale files and namespaces.

## What this section covers

- [How translations work](./translations/how-translations-work) explains how authored variants link together and how guests receive a single localized field.
- [Automatic translation](./translations/automatic-translation) explains background processing, progress indicators, audio generation, and skipping translation where appropriate.
- [UI strings and i18n](./translations/ui-strings-and-i18n) explains how application copy is organized and kept consistent across dashboards and guest apps.

## Authoring model

Most product content starts in a dashboard form. When an operator saves copy, Scoutello stores language variants as structured translation rows tied to the parent record (tour, tile, landing page, event, and so on).

At runtime, guests and most dashboards receive **already resolved strings** for the requested locale—nested translation collections are collapsed into **one field per concept** (title, description, and similar) so clients do not implement bespoke fallback logic.

## Responsibilities

- **Authors** choose source languages, review machine translations when used, and mark content that must stay verbatim (brand names, codes, sensitive legal wording).
- **Scoutello** orchestrates translation jobs, stores outputs, tracks progress, and applies sensible fallbacks when a locale is partially ready.
- **Implementation teams** follow internal engineering conventions so new fields participate in localization consistently—those conventions live outside this public documentation.

**Related concepts:** [Languages and localization](/reference/languages-and-localization), [Landing pages and tiles](./landing-pages-and-tiles), [Tours multilingual audio](./tours/multilingual-audio).

---

# How translations work

URL: https://docs.scoutello.com/product/translations/how-translations-work
Source: docs/product/translations/how-translations-work.md
Description: How Scoutello stores authored content, links language variants, and returns localized data to guests.

Scoutello separates the **structure** of a feature from the **language variants** of its text. A tour, landing page, tile, event, or PDF keeps one stable record while translatable fields point to reusable translation entries managed by the platform.

That model lets operators author once and serve guests in many languages without duplicating entire experiences.

## Content storage

Translatable product content is stored as **language-specific rows** linked to their parent object. Each row carries:

- The locale code.
- The text value (when present).
- Source metadata distinguishing manual authoring from generated translations.
- Optional audio attachments where narration ships beside copy.
- A flag indicating translation automation should skip the row when it must remain verbatim.

Related locales reference one another so Scoutello can treat them as a **translation family** for that paragraph or headline.

## Authoring flow

Dashboard saves funnel translated fields through **validated authoring helpers** so blank noise is trimmed, duplicates collapse sensibly, and new locales attach without breaking existing relationships.

The outcome operators experience is straightforward: save copy in the working language, optionally trigger automatic translation, then review variants before publishing broadly.

## Runtime localization

Downstream experiences typically receive **resolved strings**—for example a single title or description field for the requested locale—rather than raw collections of every translation row.

Resolution prefers the guest's requested language, falls back through sensible equivalents (organization defaults, shared locale aliases, then broadly understood defaults), and respects **do-not-translate** markers.

## Guest language selection

Guest-facing surfaces choose a locale from routing parameters, headers, saved preferences, or contextual defaults. Servers return localized fields so clients render ordinary strings without bespoke fallback stacks.

## Operational expectations

- Include every locale you intend to market before launch-critical moments.
- Treat automatic translations as **draft-quality** until a fluent reviewer approves them for high-trust surfaces.
- Keep UI chrome copy separate from authored marketing copy—the former ships as keyed translations, the latter lives with the tour, tile, or document itself.

**Related concepts:** [Automatic translation](./automatic-translation), [UI strings and i18n](./ui-strings-and-i18n), [Languages and localization](/reference/languages-and-localization).

---

# Automatic translation

URL: https://docs.scoutello.com/product/translations/automatic-translation
Source: docs/product/translations/automatic-translation.md
Description: How Scoutello fills missing locales asynchronously with managed translation services and optional narration.

Automatic translation creates missing language variants after source content exists. Requests return quickly while background workers populate additional locales—dashboard and guest surfaces should rely on **progress indicators** instead of blocking until everything completes.

## When translation runs

Two patterns coexist:

1. **Placeholder completion** — When new authored copy lacks an English variant yet, Scoutello may enqueue lightweight tasks that synthesize a starting English row before broader localization proceeds.

2. **Scoped translation** — Operators trigger translation for a specific object (landing page, tour, tour step, event, PDF, and similar). Each scope fans out to the appropriate processor so domain-specific fields translate consistently.

## Queue processing

Jobs execute through shared workers that:

- Identify source rows eligible for translation.
- Honor flags that skip machine translation entirely.
- Avoid duplicate target locales when they already exist.
- Batch work with sensible concurrency limits.
- Record progress as batches finish.

The durable outcome is updated translation rows (and optional audio), not the transient progress meter itself.

## Translation providers

String batches are sent to **managed translation models** with conservative decoding settings and automatic retries when providers fail transiently. Operators see consistent metadata on translated rows so they know whether a human or automation produced the text.

Specific vendor defaults can change between releases; quote capabilities—not vendor names—when speaking with customers.

## Audio and narration

Tour-heavy locales often pair translated copy with **generated narration**. Audio pipelines may lag behind text; separate progress messaging avoids implying silence equals failure.

## Progress tracking

Long jobs expose **polling-friendly progress** so dashboards and guest waiting screens can show percentages or staged statuses instead of hanging spinners.

Progress records are temporary; only finished translations belong in publishing workflows.

## Skipping translation

Operators should mark content that must remain untouched:

- Brand names and proper nouns that should not drift across locales.
- Codes, identifiers, or deliberately neutral tokens.
- Legal clauses awaiting counsel review.
- Mixed-language snippets already curated manually.

## Operational notes

- Jobs should be safe to retry: existing locales must not duplicate endlessly.
- Clients should poll progress endpoints rather than waiting on a single long HTTP request.
- Manual edits after automation become the canonical text for that locale.

**Related concepts:** [How translations work](./how-translations-work), [Tours multilingual audio](/product/tours/multilingual-audio), [Languages and localization](/reference/languages-and-localization).

---

# UI strings and i18n

URL: https://docs.scoutello.com/product/translations/ui-strings-and-i18n
Source: docs/product/translations/ui-strings-and-i18n.md
Description: How Scoutello manages translated labels, buttons, messages, and other application copy.

UI strings are separate from **product content** translations. Product content lives with authored records (tours, tiles, events). Application chrome—buttons, navigation, errors—ships as **keyed translations** resolved at runtime.

## Runtime loading

Locale JSON files are grouped by **namespace** (for example shared chrome, dashboard-only strings, guest-app strings). Loaders fetch the relevant bundle for the active locale and merge legacy aliases where deployments still map older locale codes.

If a bundle fails to load, the UI falls back to displaying keys visibly so missing translations surface during QA rather than crashing pages.

## Namespaces

Namespaces keep payloads small:

- Shared fundamentals reused everywhere.
- Dashboard-specific copy.
- Guest-app-specific copy.
- Marketing or landing-specific bundles where split packaging helps performance.

## Adding copy

Declare stable keys and resolve them through your surface’s translation helper (for example `t("settings.section.label")` in localized React apps)—avoid dynamic key construction so static extraction can find strings.

Guidelines teams follow internally:

- Avoid constructing keys dynamically—static analysis needs to see literal keys.
- Prefer interpolation placeholders instead of concatenating translated fragments.
- Keep gender-neutral wording.
- For German copy, avoid informal direct address so tone stays neutral across audiences.

Workspace automation scans repositories, proposes missing keys, and syncs locale bundles—details belong to engineering onboarding, not this public reference.

## UI copy versus product content

- Operator-authored values guests read on a published page → **product translation** workflow.
- Labels belonging to the application itself → **UI string** workflow with explicit keys.
- Mixed sentences should keep fixed grammar in UI translations and pass authored names or numbers as variables.

**Related concepts:** [How translations work](./how-translations-work), [Automatic translation](./automatic-translation), [Languages and localization](/reference/languages-and-localization).

---

# Browser-first guest experiences

URL: https://docs.scoutello.com/product/browser-first-guest-app
Source: docs/product/browser-first-guest-app.md
Description: How guests access Scoutello without mandatory native installs.

Guest experiences are delivered as **responsive web applications** opened from **links or QR codes**. This keeps rollout lightweight for venues and events: onboarding is often “scan and go” instead of app store distribution.

Some flows may still integrate with platform capabilities (payments, wallet passes, etc.), but the baseline guest journey is web-first.

## Why Browser-First Matters

Scoutello is often used in time-sensitive physical contexts: events, hotels, tours, destinations, and partner campaigns. Requiring every guest to install a native app would add friction at the exact moment they need information.

The browser-first model lets teams:

- Print or display QR codes on signs, badges, tickets, rooms, or tables.
- Share direct links in emails, newsletters, widgets, and partner sites.
- Launch temporary campaigns without app store review.
- Serve multilingual content to visitors on their own device.
- Keep guest experiences connected to the same dashboard content operators manage.

## Main Guest Surfaces

| Surface | Typical route | What guests do there |
| --- | --- | --- |
| Landing pages / web apps | `/landing/:id` | Open tiles, read information, submit forms, view offers, start tours, or navigate nested pages. |
| Tours | `/tours/:id` (often `/tours/:id/:tourRunId` when resuming a session; from a landing page also `/landing/:id/tours/:tourId`) | Follow stops, listen to audio, view maps/site plans, and access tour-specific support. |
| Events | Event and landing page routes | Register, check information, use event tiles, and interact with attendee content. |
| Widgets | `/widgets/:id/checkout` and related flows | Complete embedded purchase or registration journeys from external sites. |
| Short links | Short slugs | Reach the correct guest or marketing destination from print and campaign material. |

## Operator Checklist

Before launch:

1. Test the public link or QR code on a real mobile device.
2. Confirm the content is published in the intended organization and language.
3. Verify access, payment, and widget flows outside the logged-in dashboard.
4. Check that fallback copy, empty states, and contact paths make sense for guests.
5. Keep physical signage aligned with the final URL or short link.

## Support Notes

When a guest reports a broken experience, identify how they entered: QR code, short link, email, widget, direct landing page, or tour link. Then inspect the matching surface in the dashboard and confirm the content is active, public where expected, and attached to the right organization.

**Related concepts:** [Product model](../intro/product-model), [Reference: routes](../reference/routes).

---

# Landing pages and tiles

URL: https://docs.scoutello.com/product/landing-pages-and-tiles
Source: docs/product/landing-pages-and-tiles.md
Description: Guest web apps assembled from configurable tiles—the core surface for Scoutello's browser-first experiences.

A **landing page** in Scoutello is a configurable **guest web app**: a localized page assembled from ordered **tiles** (modules). Operators publish landing pages behind short links or QR flows; guests open them in a mobile browser—no native app install required for the typical journey.

Behind the scenes, each landing page is stored as structured content together with its tiles. The dashboard exposes authoring controls for operators; guests receive a responsive layout that loads the published modules together.

## Concepts

### Guest web app (landing page)

- **Landing page**: organization-scoped experience shell with its own slug or domain options, visuals, multilingual text, tiles, presentations, analytics, and optional assistant context.
- **Runtime**: Guests open landing pages in the browser-first guest app—for example paths shaped like **`/landing/{id}`**—which loads the published payload and lays out tiles in a responsive grid.
- **Distribution**: Typical entry is URL, QR code, or share link; operators may tie landing pages to **widgets**, marketing pages, or other entry points documented in [/reference/routes](/reference/routes).

### Tile

Each **tile** has:

- A **type** that selects behavior (for example events, stops, tours, quizzes—see [/reference/tile-types](/reference/tile-types)).
- A **size** (`small`, `medium`, `large`, or **embedded** for inline modules). Size affects layout on the landing grid and whether navigation opens a fuller screen experience where relevant.
- Optional links to backing content such as a quiz, chatroom, voting view, site plan, or gallery—depending on tile type.

Tiles can behave as:

- **Click-through cards** that navigate to dedicated experiences (quiz, site plan, explore-style lists, external URLs, and similar).
- **Embedded surfaces** that render inside the landing grid (embedded events, chat snippets, FAQs, newsletters, polls, and more).

Tile interactions can record engagement for analytics where that tile type supports it.

### Nested landing (`landingPage` tile type)

Tiles of type **landing page** can navigate to another published landing page inside the same guest experience. That supports multi-section navigation and sub-experiences without rebuilding the outer shell.

### Single-tile embed

Operators can share a **standalone tile URL** so only one module appears fullscreen—useful when an external site should embed a single capability (poll, newsletter signup, gallery, and similar) without the full landing grid.

---

## Relationships to other product areas

| Area | Relation |
| --- | --- |
| [Tours](/product/tours) | Tour tiles bridge into the tour experience from the landing grid. |
| [Events](/product/events) | Event tiles surface calendars or pinned events and tie into explore-style discovery where configured. |
| Places / stops | Stop tiles surface recommendations (“places”), often paired with site plans or tours. |
| Offers, contact forms, site plans | Dedicated tile types link into offer flows, contact submissions, or site plans. |
| CRM / newsletters | Newsletter tiles surface subscription flows tied to CRM and mailing lists. |
| Permissions | Dashboard authoring is organization-scoped; see [/reference/permissions](/reference/permissions). |

---

## Where to read next

- **Architecture and authoring flow**: [/product/landing-pages-and-tiles/web-app-model](/product/landing-pages-and-tiles/web-app-model), [/product/landing-pages-and-tiles/authoring-and-publishing](/product/landing-pages-and-tiles/authoring-and-publishing)
- **Layout, sizes, schedules, restrictions**: [/product/landing-pages-and-tiles/layout-sizing-and-visibility](/product/landing-pages-and-tiles/layout-sizing-and-visibility)
- **Visits and support**: [/product/landing-pages-and-tiles/analytics-and-support](/product/landing-pages-and-tiles/analytics-and-support)
- **Per-tile notes**: [/product/landing-pages-and-tiles/tiles/text](/product/landing-pages-and-tiles/tiles/text) and sibling pages under **Tiles** (one page per active tile kind where documented)
- **Compact catalog**: [/reference/tile-types](/reference/tile-types)
- **Operators (dashboard)**: [/dashboard/web-apps-and-tours/landing-pages](/dashboard/web-apps-and-tours/landing-pages), [/dashboard/web-apps-and-tours/tile-reference](/dashboard/web-apps-and-tours/tile-reference)

**Related concepts:** [Browser-first guest app](/product/browser-first-guest-app), [Multilingual content](/product/multilingual-content), [Dashboard landing pages](/dashboard/web-apps-and-tours/landing-pages).

---

# Web app model

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/web-app-model
Source: docs/product/landing-pages-and-tiles/web-app-model.md
Description: How landing pages, tiles, nesting, embedding, and exploration fit together for guests.

Guest-facing **web apps** are built from a **landing page** record together with its ordered **tiles**. Published content is loaded as one coherent payload for the guest shell, then rendered as a responsive grid of modules.

## Core concepts

### Landing page shell

- Holds ordered tiles, presentation and branding choices, multilingual text, optional domains or slugs, and relationships to the owning organization.
- The guest experience turns this payload into the interactive layout visitors see.

### Tiles

- Each tile has a **type** (see [/reference/tile-types](/reference/tile-types)) and a **size** that influences grid placement and whether navigation opens a fuller experience.
- Tiles may link to richer modules—events lists, offers, recommendations, chats, media galleries, flash screens, and more—depending on type.

### Visits and engagement

- Landing-level visits measure opens of the experience.
- Tile-level interactions measure taps into deeper flows where instrumentation exists for that tile type.

---

## Typical guest flow

```mermaid
flowchart LR
  guest[Guest_browser] --> route["Guest route"]
  route --> load["Load published landing payload"]
  load --> layout["Responsive tile layout"]
  layout --> modules["Tile modules"]
```

1. The guest opens the landing URL (paths are shaped like **`/landing/{landingPageId}`**; locale handling follows your deployment configuration).
2. The guest shell loads the published landing payload with the caller context appropriate for anonymous or signed-in guests.
3. The layout engine places tiles into the responsive grid.
4. Each tile renders either an embedded surface or navigation into a focused screen.

### Navigation context

Some tiles adjust links so guests remain inside the landing **navigation context** (nested shells, embedded roots, or absolute hosts for iframe-style embeds). If a module appears to open the wrong host or path, verify publishing, embedding settings, and the parent page allowed domains policy.

### Stand-alone tile embedding

Operators can expose a **single tile** in isolation—for example when an external marketing site should embed one module full-width without the surrounding landing grid.

---

## Nested landing navigation

**Landing page** tiles can open another linked landing page inside the guest flow. That enables hierarchies such as **Overview → Speakers → Venue map** without duplicating chrome.

Cross-organization reuse has tenancy implications—only publish links your organization's policies allow.

---

## Exploration versus deep links

Many discovery tiles surface **map/list** experiences with saved filters or anchors. Support teams should verify whether a tile is configured as **embedded** (stays on the landing grid) versus **card-sized navigation** (opens the fuller guest shell), because symptoms differ when diagnosing layout or routing issues.

---

## Related documentation

- [Authoring and publishing](./authoring-and-publishing)
- [Layout sizing and visibility](./layout-sizing-and-visibility)
- [Analytics and support](./analytics-and-support)

---

# Authoring and publishing

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/authoring-and-publishing
Source: docs/product/landing-pages-and-tiles/authoring-and-publishing.md
Description: Dashboard workflow—from blank landing shell to multilingual published web app—including tiles and nested pages.

This page complements [/dashboard/web-apps-and-tours/landing-pages](/dashboard/web-apps-and-tours/landing-pages) with **product-facing** narration support agents reuse in tickets.

## 1. Provision the landing shell

Operators start from the organization’s **landing pages** list and create a new web app when permitted. Early decisions that matter:

| Decision | Guidance |
| --- | --- |
| Default languages | Affects guest locale detection; unfinished translations can limit some modules. See [/reference/languages-and-localization](/reference/languages-and-localization). |
| Visual identity | Check contrast and readability on real devices, including dark backgrounds if the brand uses them. |
| Domain / slug | Coordinate DNS and TLS with whoever runs infrastructure; a mismatch often shows as a blank page or certificate warning in the browser. |

## 2. Compose tiles

In the landing **detail** workspace:

1. **Add tile** and pick a type from the catalog (basic, tour, engagement, etc.).
2. **Reorder** tiles so the first screen matches the story you want guests to see first—order is persisted when saved.
3. **Preview** in the dashboard to catch missing translations, broken links, or empty modules before sharing a public URL.

### Duplication strategy

- Duplicate a whole landing for recurring events, then adjust only what changes.
- Copy individual complex tiles (for example chat or gallery) when reusing configuration; always re-check moderation copy and legal terms for contests or raffles.

## 3. Configure advanced availability

Many tiles support:

- Date windows when the tile should appear.
- Alignment with **opening hours** where relevant.
- Messaging for “closed” periods so guests know when content returns.

Keep physical signage and campaign dates aligned with these settings.

## 4. Nested navigation

Use **nested landing page** tiles for sub-sections. For busy events, avoid very deep navigation stacks on mobile—too many levels make the back path hard to follow.

## 5. Publishing checklist (support script)

- [ ] Each visible tile has a valid size for its type.
- [ ] External links use **HTTPS** and match your link-safety policy.
- [ ] Files meet your organization’s malware or document policy where applicable.
- [ ] Interactive tiles (chat, gallery, raffle) have an **owner** for moderation and incidents.
- [ ] Payment-related tiles were exercised in a **staging** or test context when real money is involved.

## 6. Post-publish monitoring

- Compare **traffic or engagement** before and after major QR or campaign changes.
- If marketing expects strong clicks on a specific tile, confirm engagement looks plausible after go-live.

**Related:** [Web app model](./web-app-model), [Layout sizing and visibility](./layout-sizing-and-visibility), [Analytics and support](./analytics-and-support).

---

# Layout sizing and visibility

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/layout-sizing-and-visibility
Source: docs/product/landing-pages-and-tiles/layout-sizing-and-visibility.md
Description: Tile sizes, embedded versus routed modes, scheduling, and audience restrictions for landing modules.

## Sizes and layout

| Size | Behavior summary |
| --- | --- |
| `embedded` | Inline module inside the landing grid—ideal for always-visible snippets. |
| `small` / `medium` / `large` | Card footprints that usually navigate into deeper experiences when tapped. |

If historical data contains an unsupported size, the guest runtime may coerce layout—re-save tiles from the dashboard when previews look inconsistent.

## Embedded versus routed

Embedded modules keep guests on the landing surface (polls, FAQs, compact chats). Routed modules open focused screens when interactions need full height, cameras, or heavier media.

See each tile playbook under [/product/landing-pages-and-tiles/tiles/](/product/landing-pages-and-tiles/tiles/text)—some tiles branch (for example pinning a single event while hiding broader toggles).

## Scheduling and activity flags

Across many tiles the dashboard exposes:

1. **`showFrom` / `showTo`** — calendar windows independent of weekly opening hours.
2. **Active mode** (`yes`, `no`, `certainTimes`).
3. **Opening-hours linkage** when venues need parity with physical hours.
4. **`showWhenClosed`** messaging when guests should see explanatory copy instead of silence.

**Support pattern:** When guests say a tile vanished, compare device time zones with configured schedules before assuming content deletion.

## Visibility inside grids

Tiles respect composite rules: schedule windows, inactive overlays, optional IP allowlists, administrator previews, and organization-level network restrictions that can lock modules until guests join trusted Wi-Fi or VPNs.

Document expectations politely in FAQs whenever restrictions apply (for example “Connect to venue Wi-Fi to unlock this brochure”).

## Geo-fencing style locks

Some tiles support optional **radius locks** around coordinates—common for sponsor PDFs, onsite chats, or galleries meant only for visitors physically nearby. Treat these as **good-faith proximity prompts**, not cryptographic guarantees.

---

## Incident triage quick table

| Report | Steps |
| --- | --- |
| Tile greyed out or inactive banner | Inspect schedule plus inactive messaging surfaced in the dashboard preview. |
| Works on mobile data but not venue Wi-Fi | Organization IP restrictions or captive portals blocking authentication cookies. |
| Desktop renders while embedded iframe stays blank | Parent site Content Security Policy or blocked third-party scripts—capture browser diagnostics sparingly and per privacy policy. |

**Related:** [Web app model](./web-app-model), [Analytics and support](./analytics-and-support), [Tiles index](/reference/tile-types).

---

# Analytics and support

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/analytics-and-support
Source: docs/product/landing-pages-and-tiles/analytics-and-support.md
Description: Understanding landing engagement and tile interactions, plus practical guest-issue triage without exposing personal data.

## Telemetry overview

| Signal | Typical meaning |
| --- | --- |
| **Landing visits** | Guests opened the landing experience—useful for campaign reach and bounce patterns. |
| **Tile interactions** | Engagement with individual modules—useful for funnel thinking inside one landing session. |

Treat analytics as potentially sensitive when combined with identifiers, coarse location, or authenticated sessions. Follow your organization's privacy policies when discussing metrics externally.

## Debugging workflow

### 1. Reproduce guest context

Collect device type, locale, timezone, whether the guest was signed in, and whether connectivity passed through captive portals or restrictive networks.

### 2. Confirm published content

In the dashboard, verify tiles remain published for the intended schedule, translations exist for the languages guests expect, and linked modules (forms, quizzes, galleries, embeds) are still active.

### 3. Classify rendering mode

Determine whether the tile should render **inline on the landing grid** or **navigate into a focused guest screen**. Mixed expectations here cause many “layout bug” reports.

### 4. Scheduler and visibility rules

Tiles may disappear because of **schedule windows**, inactive states, or visibility restrictions—not because content was deleted.

## Frequently escalated symptoms

| Symptom | Things to verify |
| --- | --- |
| Blank iframe embed | Parent site blocking scripts; embed URL or sizing mismatches |
| Poll or vote stuck loading | Voting module unpublished or missing configuration |
| Gallery uploads failing | Permissions, moderation settings, or storage limits |

Escalate internally when an issue reproduces with healthy publishing settings and no obvious guest-device explanation—attach timestamps, affected landing or tile identifiers, and concise reproduction notes.

**Related:** [Layout sizing and visibility](./layout-sizing-and-visibility), [Dashboard analytics](/dashboard/web-apps-and-tours/analytics), [Dashboard landing pages](/dashboard/web-apps-and-tours/landing-pages).

---

# Legacy and runtime-only tiles

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/legacy-and-runtime-only-tiles
Source: docs/product/landing-pages-and-tiles/legacy-and-runtime-only-tiles.md
Description: Historical tile types that may still render for older deployments even though they no longer appear in the authoring picker.

Some tile **machine types** linger on legacy landing pages even though the dashboard picker no longer offers them for new work. Differentiate **actively authored tiles** from **historical runtime behavior** when diagnosing odd guest screens.

:::caution[Messaging rule]

Do not promise authoring UI for legacy types unless product management explicitly re-enables them—default guidance is to rebuild using supported modules (`faq`, `text`, nested landing pages, and similar).

:::

## Examples (non-exhaustive)

Older deployments occasionally retain modules such as specialized rich-content routes, deprecated timetable widgets, or experimental translator shortcuts. Guests might still reach those URLs if **published records** remain, even though operators cannot create fresh copies from the current catalog.

## Operational guidance

### Spotting legacy tiles

If an editor fails to open a tile or guests see an unfamiliar route, check whether the tile predates the current picker catalog. Historical modules sometimes lack modern validation entirely.

### Support phrasing

“This tile type remains only for legacy deployments; publish new experiences using the supported tiles available today.” Offer rebuild guidance (`faq`, `text`, nested landing pages, etc.).

### Information to gather internally

Capture tile identifiers, landing slug, approximate creation timeframe, and screenshots demonstrating guest versus authoring discrepancies before requesting engineering assistance.

**Related:** [Reference tile types](/reference/tile-types), [Web app model](./web-app-model).

---

# Tile: alerts (`alerts`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/alerts
Source: docs/product/landing-pages-and-tiles/tiles/alerts.md
Description: Embedded announcement stack sourced from localized alert records.

| Field | Value |
| --- | --- |
| **Machine type** | `alerts` |
| **Category** | advanced |
| **Sizes** | `embedded` only |

Renders embedded announcements—ideal above dense grids for evacuations or itinerary changes.

## Support

Invisible during incident ⇒ revisit schedule / activity parity with [layout & visibility docs](../layout-sizing-and-visibility).

Partial translations ⇒ multilingual pipeline backlog.

---

# Tile: chatroom (`chatroom`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/chatroom
Source: docs/product/landing-pages-and-tiles/tiles/chatroom.md
Description: Moderated live chat or feeds configurable for anonymity, threading, TTL hiding, optionally geo fenced.

| Field | Value |
| --- | --- |
| **Machine type** | `chatroom` |
| **Category** | advanced |
| **Sizes** | `small`, `medium`, `large`, `embedded` |
| **Route helper** | `/chatroom/{id}` |
| **Geo lock** | Optional |

## Operator controls

Toggle combinations:

| Flag | Operational note |
| --- | --- |
| Anonymous posting | Faster engagement versus abuse risk |
| Comments / likes | Increases moderation workload |
| Auto-hide TTL | Useful for ephemeral Q&A walls—confirm sponsor expectations |

Customize multilingual titles and descriptions so expectations stay visible beside the composer.

## Guest runtime

Embedded tiles render compact feeds; routed tiles open full-screen chat optimized for continuous scrolling.

### Incident response

Spam spikes ⇒ disable anonymous posting, purge abusive content, and escalate according to your moderation playbook.

Laggy delivery ⇒ verify connectivity; systemic slowdowns affecting multiple venues warrant infrastructure coordination—not merely reloading one landing page.

**Related:** [Networking tile](./networking) (distinct matchmaking UX).

---

# Tile: contact form (`contactForm`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/contact-form
Source: docs/product/landing-pages-and-tiles/tiles/contact-form.md
Description: Routes guests to configurable intake forms for leads or support workflows.

| Field | Value |
| --- | --- |
| **Machine type** | `contactForm` |
| **Category** | advanced |
| **Sizes** | `small`, `medium`, `large` |

Navigation follows paths shaped like **`/contact-form/{contactFormId}`** and submits through the standard guest intake flow.

Operators bind an existing dashboard **Contact Form** blueprint.

## Support notes

Spam spikes ⇒ rate limits / CAPTCHA rollout (engineering + tenant policy).

Incomplete submissions ⇒ verify required field schema + multilingual labels.

**Related:** [/dashboard/web-apps-and-tours/contact-forms](/dashboard/web-apps-and-tours/contact-forms).

---

# Tile: events (`event`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/event
Source: docs/product/landing-pages-and-tiles/tiles/event.md
Description: Curates organization versus broader discovery experiences with embedded map/list layouts.

| Field | Value |
| --- | --- |
| **Machine type** | `event` |
| **Category** | tour |
| **Sizes** | `small`, `medium`, `large`, `embedded` |

## Configuration highlights

| Control | Meaning |
| --- | --- |
| Own versus curated feeds | Decide whether guests see only your organization's programming or broader catalogs |
| Default presentation | Map-first versus list-first layouts inside embedded modes |
| Tag ordering | Marketing facets (“family workshops”, “VIP sessions”) |
| Embedded collapse | Optional truncation after many rows |

Operators should align tags with published messaging (“Only sustainability-track sessions”) before distributing QR codes.

## Guest branching

- **Embedded** tiles render compact agendas inline with landing chrome.
- **Routed** tiles sometimes jump straight to a single event detail screen when filters collapse results to exactly one upcoming occurrence—confirm previews whenever UX relies on that shortcut.

## Support matrix

| Symptom | Checks |
| --- | --- |
| Explore radius feels empty | Map center versus tagged inventory |
| Event stuck as draft | Publishing visibility on the event record |
| Pins jitter | Weekday filters or overlapping drafts confusing testers |

**Related:** [Dashboard events](/dashboard/customer-management/events), [/product/events](/product/events).

---

# Tile: FAQ (`faq`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/faq
Source: docs/product/landing-pages-and-tiles/tiles/faq.md
Description: Frequently asked questions surfaced via embedded FAQ viewer only.

| Field | Value |
| --- | --- |
| **Machine type** | `faq` |
| **Category** | basic |
| **Sizes** | `embedded` only |

FAQs must use **embedded** sizing—other sizes are unsupported for this tile kind.

Hydration reads from the linked FAQ view with localized question and answer rows.

Operators should keep answers concise for mobile readability; link out to PDF or URL tiles when legal language requires full documents.

---

# Tile: flash screen (`flashScreen`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/flash-screen
Source: docs/product/landing-pages-and-tiles/tiles/flash-screen.md
Description: High-visibility rhythmic color flashing attention surface with dedicated fullscreen route.

| Field | Value |
| --- | --- |
| **Machine type** | `flashScreen` |
| **Category** | basic |
| **Sizes** | `small`, `medium`, `large` |
| **`getUrl`** | `/flash-screen/{id}` |

## Operator notes

Configurable color cadence sequences for campaigns that need high-attention visuals.

Accessibility: flashing may trigger discomfort—coordinate with inclusivity advisors before recommending for mass audiences without warnings.

## Support

Routes fail when underlying flash screen records were deleted—restore publishing or remove the tile.

Autoplay quirks ⇒ governed by OS energy-saving/autoplay constraints.

---

# Tile: Instagram (`instagram`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/instagram
Source: docs/product/landing-pages-and-tiles/tiles/instagram.md
Description: Instagram feed embed backed by a dashboard-managed connection.

| Field | Value |
| --- | --- |
| **Machine type** | `instagram` *(machine string; UI label may read “Instagram feed”)* |
| **Category** | basic |
| **Sizes** | `embedded` only |

The guest experience renders an embedded Instagram surface hydrated from the **Instagram connection** saved with the tile.

## Support guidance

Connection expiry or Meta policy updates may blank feeds—operators should reconnect accounts through the dashboard Instagram flows.

Rate limiting from Meta can surface empty placeholders—retry during quieter periods or confirm embed eligibility inside Meta tooling.

---

# Tile: sub-page / nested landing (`landingPage`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/landing-page
Source: docs/product/landing-pages-and-tiles/tiles/landing-page.md
Description: Navigate to another Scoutello landing microsite—from simple child sections to linked public portals.

| Field | Value |
| --- | --- |
| **Machine type** | `landingPage` |
| **Category** | basic |
| **Sizes** | `small`, `medium`, `large` |
| **`getUrl` helper** | `/landing/{linkedLandingPageId}` |
| **Geo lock** | Optional |

## Dashboard configuration

Editors either spin up a scoped child landing (**sub-page authoring**) or link an existing landing page (respect tenancy policies before cross-linking).

Ensure linked landing retains published state; orphaned IDs show error screens.

## Guest behavior

Acts as a routed card traversing hierarchical navigation stacks. Guests keep breadcrumb-style context when returning upward within nested shells.

### Common incidents

| Symptom | Resolution |
| --- | --- |
| Infinite loop backs | Operators linked reciprocal tiles—inspect graph |
| Unauthorized | Linked landing whitelist mismatch—reuse [Analytics & access patterns](../analytics-and-support) |

---

# Tile: media gallery (`mediaGallery`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/media-gallery
Source: docs/product/landing-pages-and-tiles/tiles/media-gallery.md
Description: Curated gallery with optional guest uploads and moderation-focused controls.

| Field | Value |
| --- | --- |
| **Machine type** | `mediaGallery` |
| **Category** | basic |
| **Sizes** | `small`, `medium`, `large`, `embedded` |
| **`getUrl`** | `/media-gallery/{id}` *(deep links may include image-selection query hints)* |
| **Geo lock** | Optional |

## Operator controls

| Feature | Note |
| --- | --- |
| Admin-curated media | Primary storytelling baseline |
| Optional audience uploads | Toggles include camera-only restriction, authenticated-only, self-visible-only |
| Custom moderation prompts | Helps policy copy but is not automated ML moderation |
| Upload visibility durations | Fits ephemeral festivals |

## Guest UX

Embedded tiles render inline galleries; routed tiles open fullscreen browsing.

Incident: abusive upload ⇒ disable uploads, purge entries, and escalate through the internal security/support process if abuse crosses organizations.

---

# Tile: contacts / directory (`members`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/members
Source: docs/product/landing-pages-and-tiles/tiles/members.md
Description: People directory surfaced inline or routed through curated exploration lists with grouping tags.

| Field | Value |
| --- | --- |
| **Machine type** | `members` |
| **Category** | tour |
| **Sizes** | `small`, `medium`, `large`, `embedded` |
| **Navigation** | Card sizes open curated explore lists honoring the tile's saved scope |

## Dashboard fields

Operators curate directory memberships and optional ordered tags for grouping.

## Embedded versus routed

| Mode | UX |
| --- | --- |
| `embedded` | Inline scrolling directory |
| Card sizes | Full exploration layout with map/list toggles where configured |

### Support playbook

Guests missing profile imagery ⇒ verify media consent or publishing flags on underlying profiles.

Duplicates ⇒ deduplicate memberships or tighten tag filters.

**Related:** [Stop tile](./stop) uses similar exploration mechanics.

---

# Tile: networking (`networking`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/networking
Source: docs/product/landing-pages-and-tiles/tiles/networking.md
Description: Matchmaking flows with networking vs dating modes, gated profile completeness, TTL-based participant visibility.

| Field | Value |
| --- | --- |
| **Machine type** | `networking` |
| **Category** | advanced |
| **Sizes** | `small`, `medium`, `large`, `embedded` |
| **`getUrl`** | `/networking/{id}` |
| **Geo lock** | Optional |

## Configuration

| Requirement | Operational impact |
| --- | --- |
| Last name, company, job title, image | Raises onboarding friction |
| Camera-only onboarding | Helps authenticity modes |
| `shownFor` / visibility duration | Balances spontaneity with privacy |

## Guest runtime

Embedded tiles render matchmaking summaries inline; routed tiles open camera-heavy flows—behavior differs slightly between mobile browsers and hybrid shells.

Escalations involving harassment ⇒ follow your safeguarding policy and capture timelines responsibly before looping in broader incident responders.

---

# Tile: newsletter signup (`newsletter`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/newsletter
Source: docs/product/landing-pages-and-tiles/tiles/newsletter.md
Description: Embedded module binding a newsletter audience—renders signup UI when linkage is valid.

| Field | Value |
| --- | --- |
| **Machine type** | `newsletter` |
| **Category** | advanced |
| **Sizes** | `embedded` only |

Guests see the newsletter signup surface when the tile references an active newsletter record. If the linkage is missing, the module renders empty—double-check the tile configuration before assuming a platform regression.

## Operator checklist

- Confirm newsletter records include GDPR-conscious consent language.
- Validate double opt-in mail flows when confirmations are required.

CRM linkage references [/product/crm-and-operations](/product/crm-and-operations).

---

# Tile: offers (`offer`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/offer
Source: docs/product/landing-pages-and-tiles/tiles/offer.md
Description: Promotional offer discovery—embedded catalog or routed exploration centered on configurable geography.

| Field | Value |
| --- | --- |
| **Machine type** | `offer` |
| **Category** | advanced |
| **Sizes** | `small`, `medium`, `large`, `embedded` |
| **Navigation** | Routed tiles open offer exploration using the saved map/list defaults from the tile |

## Offers view setup

Operators pin published offers (see [/dashboard/web-apps-and-tours/offers](/dashboard/web-apps-and-tours/offers)) and optional clustering tags.

Map-first versus list-first browsing mirrors the toggles used on [event](./event) tiles.

## Embedded versus routed

Embedded tiles render compact catalogs inline; routed tiles launch the broader exploration experience with the tile's saved filters.

Offers may reference external redemption constraints—cite merchant legal text rather than improvising redemption rules.

## Debugging

- Stale discount metadata ⇒ refresh publishing from the offer record.
- Missing map pins ⇒ confirm offers reference complete place data.

---

# Tile: PDF (`pdf`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/pdf
Source: docs/product/landing-pages-and-tiles/tiles/pdf.md
Description: Hosted PDF surfaced through the tile PDF viewer with optional translation tooling.

| Field | Value |
| --- | --- |
| **Machine type** | `pdf` |
| **Category** | basic |
| **Sizes** | `small`, `medium`, `large` |
| **Geo lock** | Optional radius restriction (inventory) |

## Operator setup

Attach an uploaded PDF in the tile editor. When **document translation** is enabled for the organization, additional locales may be processed asynchronously—guests should see progress or fallback copy consistent with your translation settings.

Guest URLs are shaped by the guest app; after deploys, confirm the **preview link** from the dashboard matches what marketing shares.

## Guest behavior

Guests open the PDF in the built-in viewer; visits are tracked unless preview mode disables analytics.

### Support triage

| Symptom | Checks |
| --- | --- |
| Cannot open the file | Whether the file finished uploading; organization access rules for the asset; browser or network issues |
| Blank viewer on mobile | Corrupt upload or unsupported format |
| Wrong language | Translation backlog—compare locales on the tile and in publishing tools |

**Related:** [Layout geo restrictions](../layout-sizing-and-visibility).

---

# Tile: quiz (`quiz`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/quiz
Source: docs/product/landing-pages-and-tiles/tiles/quiz.md
Description: Opens dedicated quiz gameplay route with moderation flags for organizer-only lobby creation when enabled.

| Field | Value |
| --- | --- |
| **Machine type** | `quiz` |
| **Category** | advanced |
| **Sizes** | `small`, `medium`, `large` |

**Routing pattern:** `/quiz/{quizGameId}` bridges landing grids into quiz gameplay.

Operators attach an existing quiz game entity plus optional moderation flags such as organizer-only lobby creation.

## Operational notes

- Competitive events need scoreboard rehearsals—staging devices recommended.
- Multilingual trivia requires translated prompt banks and narration assets when audio ships alongside questions.

Incident: leaderboard disputes ⇒ escalate with session timestamps—not finance-critical unless external prizes integrate contractual payouts.

---

# Tile: raffle (`raffle`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/raffle
Source: docs/product/landing-pages-and-tiles/tiles/raffle.md
Description: Embedded prize-draw participation with visuals, deadlines, success messaging, and optional structured answers.

| Field | Value |
| --- | --- |
| **Machine type** | `raffle` |
| **Category** | advanced |
| **Sizes** | `embedded` only |

Guests participate through an embedded raffle experience wired to your organization's raffle configuration.

Operators configure descriptive copy, multiple gallery images, open-until timestamp, post-success acknowledgement, mandatory survey answers—which may reuse voting-derived question payloads (inventory cross-link).

Prize adjudication/legal disputes ⇒ organizer responsibility—not first-line platform moderation unless abuse vector.

---

# Tile: site plan (`sitePlan`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/site-plan
Source: docs/product/landing-pages-and-tiles/tiles/site-plan.md
Description: Venue orientation map bridging indoor navigation authored in dashboard site-plan tooling.

| Field | Value |
| --- | --- |
| **Machine type** | `sitePlan` |
| **Category** | advanced |
| **Sizes** | `small`, `medium`, `large` |

**Routing pattern:** `/site-plan/{sitePlanId}` opens gesture-friendly pan and zoom overlays.

Often paired alongside:

- **`stop`** recommendation tiles listing booth highlights
- Indoor **[tours](/product/tours/tour-types)**

## Support playbook

Misaligned hotspots ⇒ authoring coordinate drift—revisit overlays inside the site-plan editor.

Loads blank ⇒ verify publishing state for the linked site plan and its multilingual attachments.

**Related:** [/dashboard/web-apps-and-tours/site-plans](/dashboard/web-apps-and-tours/site-plans).

---

# Tile: SoundCloud (`soundCloud`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/soundcloud
Source: docs/product/landing-pages-and-tiles/tiles/soundcloud.md
Description: Embedded audio playback via SoundCloud track IDs.

| Field | Value |
| --- | --- |
| **Machine type** | `soundCloud` |
| **Category** | basic |
| **Sizes** | `embedded` only |

Guests see an embedded SoundCloud player when valid track or playlist identifiers are configured on the tile.

## When to use it

Use the SoundCloud tile when audio already lives on SoundCloud and should play inline—DJ sets, previews, atmospheric loops, podcast snippets, or partner clips.

Because the tile is embedded-only, place it where listening belongs in the narrative arc rather than expecting a navigation card.

## Authoring checks

Before publishing:

1. Confirm the SoundCloud asset is public or explicitly embeddable.
2. Verify identifiers copied exactly from SoundCloud.
3. Test playback on mobile browsers guests actually use.
4. Add surrounding copy so listeners understand why audio matters.
5. Avoid relying on this tile for safety-critical instructions—third-party embeds can be blocked.

## Troubleshooting

Consent banners, regional restrictions, or enterprise browser policies may block iframes. Gather browser and region details before escalating.

---

# Tile: Spotify (`spotify`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/spotify
Source: docs/product/landing-pages-and-tiles/tiles/spotify.md
Description: Embed Spotify playlists or episodes for soundtracks and sponsor audio drops.

| Field | Value |
| --- | --- |
| **Machine type** | `spotify` |
| **Category** | basic |
| **Sizes** | `embedded` only |

Uses Spotify's embedded player. Authentication may be required for premium content—set guest expectations.

## When To Use It

Use the Spotify tile when an organization wants to embed a playlist, episode, or soundtrack that already lives on Spotify. It works well for event playlists, hospitality mood music, artist previews, tour companion audio, or sponsor content.

Because Spotify playback is controlled by the third-party embed, Scoutello can present the player but cannot guarantee every guest can play every track in every region or account state.

## Authoring Checks

Before publishing:

1. Confirm the Spotify content is available and embeddable.
2. Check whether playback requires sign-in or premium access.
3. Test the landing page on mobile and desktop.
4. Add context around the tile so guests understand what they are opening.
5. Keep critical instructions outside the Spotify embed.

## Troubleshooting

Embedded player failures often stem from region restrictions, account requirements, corporate network blocking streaming CDNs, or third-party consent settings. Reproduce outside the dashboard using the public guest page before changing tile configuration.

---

# Tile: places / recommendations (`stop`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/stop
Source: docs/product/landing-pages-and-tiles/tiles/stop.md
Description: Pins curated points of interest or recommendation sets with embedded list/map parity and exploration links.

| Field | Value |
| --- | --- |
| **Machine type** | `stop` |
| **Category** | tour |
| **Sizes** | `small`, `medium`, `large`, `embedded` |

## Dashboard configuration

Operators attach stops or places from reusable libraries:

- Embedded layouts choose **list** versus **tile** presentations depending on density goals.
- **Map-first** defaults suit experiential previews anchored around a venue.
- Tag bundles propagate into filtered exploration surfaces—avoid orphaned tags that narrow results to zero.

Always sanity-check map anchors against your organization's geography rather than placeholder defaults.

## Guest nuances

Embedded modes render compact recommendation grids; routed modes may deep-link into individual stops when filters collapse to a single highlight—mirror validation steps used for dense event tiles when diagnosing discrepancies.

## Support triage

| Symptom | Checks |
| --- | --- |
| Blank recommendations | Stops removed from linked collections |
| Map centered incorrectly | Saved viewport overrides missing |
| Filters empty | Tag selections disconnected—re-save configuration |

**Related:** [Site plan](./site-plan), [Tour](./tour), [Offers](./offer).

---

# Tile: text (`text`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/text
Source: docs/product/landing-pages-and-tiles/tiles/text.md
Description: Embedded rich-text block for landing introductions, rules, or narrative framing.

| Field | Value |
| --- | --- |
| **Machine type** | `text` |
| **Category** | basic |
| **Sizes** | `embedded` only |

## What operators configure

Markdown-style **`richText`** plus optional typography overrides (inventory: text color shadow support depends on dashboard form—verify current UI labels).

## Guest behavior

Renders **`LandingPageText`** inline inside the masonry grid—not a clickable card. Suitable for disclaimers sandwiched between interactive tiles.

## Support checks

| Issue | Actions |
| --- | --- |
| Content clipped | Responsive grid heights—inspect parent tile segment calc; shorten copy or relocate to **`url`**/nested landing. |
| Markdown looks raw | Translator pipeline failed—check plain string vs sanitized HTML expectations. |

**Related:** [/reference/tile-types](/reference/tile-types), [Layout sizing](../layout-sizing-and-visibility).

---

# Tile: tour (`tour`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/tour
Source: docs/product/landing-pages-and-tiles/tiles/tour.md
Description: Entry tile into Scoutello tour runtime with optional skipping of tour details for faster starts.

| Field | Value |
| --- | --- |
| **Machine type** | `tour` |
| **Category** | tour |
| **Sizes** | `large`, `medium`, `small` (catalog) |
| **Typical link** | `/tours/{tourId}` from tiles (and nested paths when opened inside a landing page)—confirm dashboard previews match collateral |

## Operator configuration

- Select the published tour the tile should open (respect visibility, languages, and payments readiness).
- Toggle **skip details** when marketing wants guests to jump directly into the runtime without the storytelling intro screen.

Guests see commerce cues consistent with [/product/tours/commerce-and-access](/product/tours/commerce-and-access).

## Guest behavior

Tour tiles honor masonry sizing, optional embedding contexts, and preview overlays used inside dashboard tooling—guest-facing nuances live in [/product/tours/guest-experience](/product/tours/guest-experience).

## Support matrix

| Symptom | First checks |
| --- | --- |
| Pricing mismatches | Organization payments onboarding plus tier availability |
| Language banner persists | Translation or narration backlog ([Multilingual and audio](/product/tours/multilingual-audio)) |
| Unexpected GPS prompts | Tour type mis-set ([Tour types](/product/tours/tour-types)) |

**Related:** [/product/tours](/product/tours), [/product/tours/guest-experience](/product/tours/guest-experience), [/product/tours/commerce-and-access](/product/tours/commerce-and-access).

---

# Tile: external link (`url`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/url
Source: docs/product/landing-pages-and-tiles/tiles/url.md
Description: Opens vetted outbound URLs with optional embedding helpers where catalog flags allow.

| Field | Value |
| --- | --- |
| **Machine type** | `url` |
| **Category** | basic |
| **Sizes** | `small`, `medium`, `large` |
| **Embeddings optional** | Some workspaces enable companion previews—confirm policy before relying on them |

## Dashboard fields

Validated destination URLs plus presentation chrome (titles, thumbnails). Warn operators about **mixed content**: plain HTTP destinations may fail inside HTTPS landing pages.

## Guest behavior

- Typical web sessions open links inside the guest shell when safe.
- Hybrid native shells may delegate to the system browser—capture OS details when taps appear unresponsive.

Engagement metrics may increment when guests leave for external destinations, depending on tile instrumentation.

## Security guidance

Suspected phishing or malware URLs should be disabled immediately and escalated according to your organization's security playbook.

---

# Tile: polls / voting (`voting`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/voting
Source: docs/product/landing-pages-and-tiles/tiles/voting.md
Description: Embedded stack of configurable votings—multi-select, open answers, anonymity options, optional sign-in.

| Field | Value |
| --- | --- |
| **Machine type** | `voting` |
| **Category** | advanced |
| **Sizes** | `embedded` only |

## Data linkage

Bind a **voting view** with ordered questions inside the tile editor. Legacy deployments occasionally duplicated structures—if results look inconsistent across duplicates, consolidate configuration in the dashboard rather than editing historical rows manually.

### Operator playbook

Define:

- Question formats (limits, optional free-text capture, reveal-after-vote behavior).
- Whether votes require sign-in or allow anonymity.
- Moderation expectations aligned with neighboring raffle or quiz tiles.

### Support playbook

When votes appear to “reset,” confirm whether guests switched browsers or sessions—identity nuances belong to privacy-reviewed diagnostics only.

**Related:** [Raffle](./raffle).

---

# Tile: weather (`weather`)

URL: https://docs.scoutello.com/product/landing-pages-and-tiles/tiles/weather
Source: docs/product/landing-pages-and-tiles/tiles/weather.md
Description: Forecast embed with optional expanded detail view for guests.

| Field | Value |
| --- | --- |
| **Machine type** | `weather` |
| **Category** | basic |
| **Sizes** | `embedded` only |

Guests see an embedded forecast snippet that deep-links into fuller detail screens where enabled.

## When to use it

Ideal when schedules depend on outdoor conditions—walking tours, rooftops, festivals, harbors, ski-ish storytelling (temperature cues), or seasonal hospitality bundles.

Because it stays embedded, anchor it beside actionable guidance (“bring sunscreen”, “umbrellas onsite”, ferry disruptions).

## Authoring checks

Before publishing:

1. Tie the landing page geography to the place forecasts should describe.
2. Position weather adjacent to operational guidance guests must read anyway.
3. Duplicate cancellation policies outside the widget—widgets may lag offline providers.
4. Spot-check guests travelling internationally versus domestic locales.

## Troubleshooting

Third-party providers occasionally throttle or outage—escalate through monitoring when multiple pages fail simultaneously; inspect individual tile placement when only one surface breaks.

---

# Tours

URL: https://docs.scoutello.com/product/tours
Source: docs/product/tours.md
Description: Structured multilingual tour experiences with stops, maps or site plans, optional commerce, and landing-page embedding.

**Scoutello tours** are structured, multilingual guest experiences built from ordered **stops** (steps), rich **media** (text, imagery, optional audio), and guidance patterns suited to the tour type: **outdoor maps and directions**, **indoor site plans**, or **fixed-route pacing** for vehicles and timetabled itineraries.

Operators author tours in the **dashboard**. Guests consume them primarily through Scoutello's **browser-first guest app**. Tours can also appear as **tiles** on landing pages alongside quizzes, galleries, events, chats, and other modules.

This hub links to focused guides below plus operational notes under **Dashboard → Web apps and tours → Tours**.

## Core concepts

| Concept | Role |
|--------|------|
| **Tour** | Container for type, visibility, languages, pricing tier where used, linked landing page or site plan, guides, narrative framing, and ordered steps |
| **Stop / step** | Content unit with instructions, media, quizzes, or geography depending on configuration |
| **Ordering** | Defines sequence, optional hiding, transitions, and links between stops |
| **Tour run** | Guest session tracking progress through steps—including collaborative sessions when enabled |
| **Price tier** | Monetary tier attached when monetization is enabled |

Commercial percentages, payout schedules, and contractual promises belong in **finance-approved** materials—not inferred from software behavior.

## Types at a glance

| Type | Typical label | Typical use |
|------|---------------|-------------|
| Outdoor | Guided tour | City walks; directions summaries on details |
| Indoor | Free tour | Museums; site-plan pinning |
| Fixed | Fixed tour | Buses or timed circuits |

Deep dive: [Tour types](/product/tours/tour-types).

## Where to read next

- [Tour types](/product/tours/tour-types)
- [Authoring](/product/tours/tour-authoring)
- [Guest experience](/product/tours/guest-experience)
- [Multilingual and audio](/product/tours/multilingual-audio)
- [Commerce and access](/product/tours/commerce-and-access)
- [Landing pages and tiles](/product/tours/landing-pages-and-tiles)
- [Support playbook](/product/tours/support-playbook)

**Operational:** [Dashboard: Tours](/dashboard/web-apps-and-tours/tours).

**Related:** [Permissions](/reference/permissions), [Tile types](/reference/tile-types), [Languages and localization](/reference/languages-and-localization).

---

# Tour types

URL: https://docs.scoutello.com/product/tours/tour-types
Source: docs/product/tours/tour-types.md
Description: Outdoor guided tours, indoor free exploration, and fixed-route tours—how guest behavior and authoring differ.

Scoutello distinguishes three **tour types**. The dashboard labels them clearly when you create a tour:

| Type key | Typical dashboard label | Metaphor |
|----------|-------------------------|----------|
| Outdoor | Guided tour | Walking route on a map |
| Indoor | Free tour | Venue floors and site plans |
| Fixed | Fixed tour | Timed or vehicle-style progression |

## Outdoor — guided tour

**Purpose:** Coordinate-based experiences where guests move along a real-world path (city walks, guide-led routes).

**Authoring:** Stops and intermediate points use map coordinates; Scoutello can compute **directions** and **route summaries** for guests when providers and connectivity allow.

**Guest experience:** Guests may be prompted for **location permission** before starting. Details screens emphasize duration and distance when routing data is available, show **preview maps**, and can honor **custom path segments** between stops when operators draw them.

**Transitions:** Operators can configure segments where narration or media replaces continuous GPS guidance until the next stop.

## Indoor — free tour

**Purpose:** Companion experiences inside venues—museums, exhibitions, campuses—often anchored to **floor plans** rather than GPS-first navigation.

**Authoring:** Operators maintain **site plans** with pages and pinned stops; optional meeting geography can still appear on details screens.

**Guest experience:** Indoor tours typically **skip outdoor-style GPS gates** at start; summaries emphasize indoor navigation cues.

## Fixed — fixed-route tour

**Purpose:** Vehicles or itineraries where progression is timetabled or constrained (bus circuits, ships, similar patterns).

**Authoring:** Map editing resembles outdoor tours in many places; some organizations limit **GPS prompts** to the first stop only when that matches operational reality.

**Guest experience:** Guests may still grant location for live pacing depending on configuration; **virtual mode** can offer map toggles that differ from outdoor walks. Some browsers need extra care for reliable location—confirm device guidance when guests report issues.

**Step timing:** Opening certain stops can anchor countdown-style pacing to the next segment where the product supports it.

## Choosing a type

- **Walking directions between outdoor pins** → outdoor.
- **Floor plans and room-to-room exploration** → indoor (plus site plan authoring).
- **Vehicle or strict timetable pacing** → fixed.

**Related:** [Authoring](/product/tours/tour-authoring), [Guest experience](/product/tours/guest-experience), [Tours overview](/product/tours).

---

# Tour authoring

URL: https://docs.scoutello.com/product/tours/tour-authoring
Source: docs/product/tours/tour-authoring.md
Description: Dashboard workflows for creating tours, editing routes and stops, linking guides, and assigning customers.

Authoring happens under the organization's **Tours** section in the dashboard (list and detail views).

## Creating a tour

The **new tour** flow typically collects:

- **Name**
- **Tour type**: outdoor (guided), indoor (free exploration), or fixed (scheduled route)—labels in the dashboard map to these behaviors.
- **Optional document** upload when enabled for your workspace—used to assist structured ingest where that beta flow is available.
- **Assigned contacts** when the workspace scopes tours to specific customers—fields may be limited if the user's role only covers assigned records.

Successful creation opens the **tour editor**.

### Tour list

The list view shows image, name, type, stop count, visibility, and created date. Actions such as **Visit**, **Duplicate**, and **Delete** respect organization permissions.

## Core tour editor

The editor groups settings into sensible sections—for example identity and descriptions, visibility, pricing tiers, media, tags, linked landing page, CRM assignments, indoor overview behavior, meeting geography where relevant, narrative introduction and closing content, and an **end screen** with optional offers, polls or votes, related tours, and recommended stops.

Descriptions and longer copy support **multilingual authoring** consistent with the rest of Scoutello.

### Route and stops

The route editor is where operators order steps, tune outdoor paths, edit transitions, attach images or audio, manage indoor site-plan pins, and connect recommendation markers.

A **places library** or reusable stops list—where enabled—lets operators attach existing stops without rebuilding content from scratch.

### Guides and invitations

- **Guide contacts** on the tour can surface as guides on the guest experience when your organization does not present only the organization as creator.
- **Invitations**—where email invitations are used—are accepted through the standard dashboard invitation flow so guides are linked cleanly.

Permissions combine tour capabilities with guide-oriented shortcuts where configured; see [/reference/permissions](/reference/permissions).

### Analytics and assistant

Tour detail may include **analytics** tabs for performance insight.

Where **assistant** features are enabled, operators can attach curated reference material so guests receive grounded answers consistent with published tour content.

### Sharing

Sharing flows appear once the tour has enough structure to preview or distribute meaningfully—follow on-screen prompts for links or participant messaging.

**Related:** [Tour types](/product/tours/tour-types), [Commerce and access](/product/tours/commerce-and-access), [Dashboard: Tours](/dashboard/web-apps-and-tours/tours), [Site plans](/dashboard/web-apps-and-tours/site-plans).

---

# Tour guest experience

URL: https://docs.scoutello.com/product/tours/guest-experience
Source: docs/product/tours/guest-experience.md
Description: How guests open a tour, choose language and location, purchase access, run tours with maps and audio, and use optional collaboration features.

Guest-facing tours run in Scoutello's **browser-first guest app**. Typical paths include a **tour details** screen and an **active run** screen with map, drawer, and step content.

## Entry points

- **Direct link** to the tour on the guest app host.
- **From a landing page**, sometimes with a URL prefix so navigation returns cleanly to the hosting landing experience.
- **From a tour tile** on a landing page, which routes into the tour flow.

If guests report unexpected **404** behavior, confirm they use the link generated from publishing tools for the intended environment.

## Tour details

Guests see hero imagery, tags, title, summary statistics (duration, distance, stops—depending on tour type), introduction content, meeting geography when configured, and creator or guide cards when enabled.

**Language:** Guests typically inherit language from their profile or browser locale. If a requested language is not ready yet, Scoutello surfaces a clear **missing language** state with retry guidance while translations or audio finish.

**Commerce:** Paid tours show pricing and purchase affordances; owned tours emphasize **Start** instead of purchase.

**Virtual touring:** Operators can open tours from the dashboard in ways that encourage **virtual** exploration before live GPS—useful for demos or constrained environments.

## Starting a run

Starting a run generally involves:

1. Optional education modals for first-time outdoor or fixed tours on the device.
2. Location permission prompts when GPS matters for the tour type.
3. Creation of a **tour run** that tracks progress through ordered steps.
4. Navigation to the active run URL showing map and step drawer.

Hidden steps configured by operators may be skipped in the visible progression.

## Active run

The active experience combines:

- **Map or floor-plan views** appropriate to outdoor, indoor, or fixed tour modes.
- **Step drawer or modals** for rich media, audio, transitions, and quizzes where configured.
- **Audio playback** for narration and optional assistant entry points when enabled.

### Multi-guest collaboration

Some tours support **shared sessions** so friends move together. Guests join with the organizer's **session code** or invitation flow. If participants drift out of sync, verify everyone joined the same session and connectivity is stable.

### Quizzes and lightweight interactions

Quizzes can attach points or outcomes to the run for engagement analytics where enabled.

## Leaving and completing

Organizers can **complete** or **cancel** a collaborative session; participants can **leave** without ending the whole session where that workflow exists.

## Offline expectations

Progressive web features may improve revisit performance, but operators should set guest expectations: connectivity still matters for purchases, fresh translations, and realtime collaboration.

**Related:** [Tour types](/product/tours/tour-types), [Commerce and access](/product/tours/commerce-and-access), [Support playbook](/product/tours/support-playbook).

---

# Tours — multilingual and audio

URL: https://docs.scoutello.com/product/tours/multilingual-audio
Source: docs/product/tours/multilingual-audio.md
Description: Tour languages, default voices, automatic translation progress, step audio, and guide narration.

Scoutello keeps multilingual **product text** in structured translation families so one tour can serve many locales while preserving editorial control.

## Tour languages

- Each tour maintains a **languages** list reflecting locales that have—or are acquiring—published content.
- When a guest requests a locale that is not ready, the details screen explains the situation and may refresh automatically as work completes.

## Default voices and audio blocks

Organizations and tours can define **default voices** for generated or synthetic narration where that feature is enabled.

Individual steps can carry **text blocks** with optional **spoken audio**. Preview surfaces in the dashboard should be used to confirm pacing and clarity before publishing.

## Translation and audio pipelines

Translation and optional audio generation run **asynchronously**:

- Guests should see **progress indicators** or polite waiting states rather than infinite spinners when jobs are running.
- Operators authoring for immediate multilingual launches should wait until requested locales appear as expected in preview before heavily promoting the tour.

Opening a run with partial coverage may enqueue translation work so guests receive consistent copy as resources complete—exact sequencing is handled by Scoutello's background processing.

## Guide description audio

Where enabled, guests can listen to short **guide or creator narrations**. If audio is missing, a tap may request generation; playback appears once processing completes.

## Operator checklist

1. Author and publish a strong **canonical language** first when launches are tight on time.
2. For events with live locale switching, anticipate brief periods where some locales catch up.
3. Validate **introduction**, **closing**, **transitions**, and **step blocks**—not only plain text fields—when audio matters.

**Related:** [Languages and localization](/reference/languages-and-localization), [Guest experience](/product/tours/guest-experience).

---

# Tours — commerce and access

URL: https://docs.scoutello.com/product/tours/commerce-and-access
Source: docs/product/tours/commerce-and-access.md
Description: Free and paid tours, price tiers, payments, access after purchase, visibility, and sharing.

## Price tiers

- Tours can be **free** or **paid**. Paid tours use **price tiers** configured for the organization.
- Tier amounts are stored precisely for billing (internally as whole-number currency minor units such as cents).
- In the dashboard, paid tiers appear only when **online payments are fully set up** for the organization (for example Stripe Connect onboarding completed). Until then, operators typically remain on free tiers or complete payments setup from the organization **Payments** area.

## Checkout experience

- Guests purchase paid tours through the standard tour checkout flow in the guest app (card presentation depends on your organization's payment configuration).
- After a successful purchase, the guest should see the tour as **accessible** without being asked to pay again for the same entitlement.

Marketing or partner-facing documentation should describe **commercial terms** (fees, revenue shares, payout timing) only from materials approved by your finance or legal team. Behavior can evolve as payment integrations and policies change.

## Access after purchase

- **Ownership** or **entitlement** determines whether a signed-in guest can open a paid tour without purchasing again.
- Operators should confirm **visibility** (public versus limited access) matches how the tour is meant to be discovered.

## Visibility

- **Public** tours are meant to be discoverable via shared links and typical guest flows when your publishing rules allow it.
- **Private** tours rely on direct links, assignments, or other controlled distribution—confirm guests receive the correct link for their environment (production versus staging or preview hosts).

## Short links

- Tours and steps can use **short links** where enabled, so marketing materials can use memorable URLs while still opening the guest experience.

## Troubleshooting (operators)

| Symptom | What to check |
|--------|----------------|
| Cannot attach a paid tier in the dashboard | Payments onboarding or connection status for the organization; complete payments setup if paid tours are required. |
| Checkout does not complete | Guest browser or network issues; whether the guest is signed in if the purchase requires an account; retry after a short wait. |
| Paid tour still asks for payment | Sign-in state and whether the purchase finished successfully; open support if entitlement looks wrong after a confirmed payment. |
| Missing language after purchase | Automatic translation or audio may still be processing—see [Multilingual and audio](/product/tours/multilingual-audio). |

**Related:** [Guest experience](/product/tours/guest-experience), [Support playbook](/product/tours/support-playbook).

---

# Tours — landing pages & tiles

URL: https://docs.scoutello.com/product/tours/landing-pages-and-tiles
Source: docs/product/tours/landing-pages-and-tiles.md
Description: Linking tours to landing pages, using the tour tile, skip-details shortcuts, and companion modules.

## Landing page association

In the tour editor, operators can bind a **landing page** so branding, accent colors, and navigation context stay consistent when guests jump between tours and hosted web apps.

## Tour tile

See [/reference/tile-types](/reference/tile-types) for the authoritative catalog row. In practice:

- Choose the linked tour record inside the tile editor.
- Prefer card sizes (`large`, `medium`, `small`)—embedded hosting is uncommon for tours.
- Paths from tour tiles resolve to **`/tours/{tourId}`** in the guest app (additional segments appear when a guest continues an active session). When the guest started from a landing page, URLs may be **nested under** `/landing/{landingPageId}/…`—compare the preview link from the dashboard with printed collateral if a mismatch is reported.

Optional **skip details** configuration sends guests deeper into the runtime when operators want a faster path than the standard storytelling screen.

## Companion tiles

Tour-heavy landing stacks often pair with:

- **Site plan** tiles for indoor orientation.
- **Stop** tiles for curated place browsing aligned with recommendations.
- **Event**, **offer**, **media gallery**, **quiz**, **chatroom**, **networking**, **alerts**, or **newsletter** tiles for engagement or conversion—each documented under [/product/landing-pages-and-tiles/tiles/](/product/landing-pages-and-tiles/tiles/text).

## End screens

Tour **end screens** can surface offers, polls, related tours, or recommended stops so a guided session finishes on commerce or feedback surfaces without bespoke engineering per customer.

## Support notes

If a tour tile appears blank, confirm the tile still references a published tour with compatible visibility. If links differ between tile entry and manual URLs, compare the preview link from the dashboard with what marketing printed on collateral.

**Related:** [Tile types reference](/reference/tile-types), [Landing pages dashboard guide](/dashboard/web-apps-and-tours/landing-pages), [Tours overview](/product/tours).

---

# Tours — support playbook

URL: https://docs.scoutello.com/product/tours/support-playbook
Source: docs/product/tours/support-playbook.md
Description: Practical triage for common tour issues across languages, location, payments, indoor layouts, and collaboration.

Quick reference for **support** and **customer success**. Pair with the [/product/tours](/product/tours) overview.

## Quick classification

| Guest reports… | Likely area |
|----------------|-------------|
| Wrong language or blank text | Translation or audio still processing; language selection; published languages on the tour |
| Map not moving or no GPS | Browser location permission; device settings; tour type (outdoor versus indoor versus fixed); virtual demo mode |
| Paid but still prompted to pay | Purchase completion; signed-in account matches purchaser; entitlement propagation delay |
| Cannot set a paid price in the dashboard | Organization payments setup not finished |
| Indoor pins on wrong floor | Site plan pages and pin placement; republish or adjust pins after layout changes |
| Distances or directions look wrong | Outdoor routing provider issues; connectivity; stale cached directions |

## Checks before escalating

1. **Organization and roles** — Does the user have tour access appropriate for their role? Some workflows limit visibility to assigned contacts only.
2. **Visibility** — Public versus private; confirm the guest opened the link intended for their environment (production versus preview or staging).
3. **Tour type** — Outdoor, indoor, and fixed tours behave differently for GPS, floors, and transitions. Misclassification duplicates many symptoms.
4. **Hidden steps** — Steps marked hidden may not appear in the guest progression the same way as visible stops.
5. **Translations** — If languages never finish updating, wait for background translation jobs or retry from the dashboard when appropriate.
6. **Multi-guest sessions** — Collaborative runs depend on room codes and session state; confirm guests joined with the same session details.

## Safe dashboard actions

- **Duplicate** a tour to reproduce issues without editing live guest-facing content.
- Use **Visit** from the tour list for a demo-friendly entry when GPS should not block testing.
- **Reconnect or review payments** settings before editing paid tiers if pricing controls appear disabled.

## When to escalate internally

- Suspected incorrect charges or reconciliation problems—capture transaction references your payments provider shows and the affected organization.
- Suspected data inconsistencies that persist after refresh and cannot be explained by publishing or translation delays.
- Suspected **security** concerns around shared session codes or unintended access.
- Widespread outage patterns (maps, directions, or realtime collaboration) affecting multiple organizations.

Share reproduction steps, affected tour identifiers, approximate timestamps, and screenshots where privacy rules allow.

**Related:** [Guest experience](/product/tours/guest-experience), [Commerce and access](/product/tours/commerce-and-access), [Dashboard: Tours](/dashboard/web-apps-and-tours/tours).

---

# Events

URL: https://docs.scoutello.com/product/events
Source: docs/product/events.md
Description: Events, attendees, ticketing-oriented workflows, and guest engagement surfaces.

Scoutello's event tooling spans scheduling, participation, operational controls, and commerce-oriented ticket structures, plus guest-facing landing experiences for discovery and interaction.

Events sit between CRM, guest web apps, and commerce. They can be used for conferences, workshops, hospitality events, member gatherings, destination programming, internal sessions, or public experiences.

## Core Concepts

- **Organization event:** The tenant-scoped event record managed from `/organizations/:id/events`.
- **Participants:** Attendee or invitee records tied to a specific event and optionally linked to CRM customers.
- **Customers:** The broader CRM contact records that can carry history beyond one event.
- **Landing pages and tiles:** Guest-facing event pages, agendas, site plans, chats, raffles, voting, networking, and other interaction modules.
- **Orders and payments:** Commerce records created by ticketing or checkout flows.
- **Mail templates and newsletters:** Communication surfaces for confirmations, reminders, updates, and follow-up.

## Typical Event Workflow

1. Create the event inside the active organization.
2. Add dates, place/address context, tags, descriptions, and responsible staff.
3. Configure participant groups, registration settings, ticketing, or access rules when relevant.
4. Attach or create a landing page for guest-facing information and event tiles.
5. Prepare mail templates, newsletters, widgets, or QR links for promotion.
6. During the event, monitor participants, check-in, questions, networking, or engagement modules.
7. After the event, connect follow-up tasks, protocols, documents, and customer history in CRM.

## Guest Engagement

Events become strongest when the operational record and guest web app support each other. A public landing page can surface:

- Schedule and location information.
- Site plans and places.
- Contact forms and FAQs.
- Networking, voting, quiz, raffle, chatroom, or media gallery tiles.
- Offers and sponsor content.
- Ticketing or checkout entry points.

This keeps the guest journey browser-first while preserving operational context for the team.

## Support Checks

When troubleshooting events, confirm whether the issue belongs to the organization event record, the guest landing page, the participant/customer link, mail delivery, or checkout. For example, a person can have an event participant record without the expected CRM customer link, and an order can exist even when event access still needs investigation.

**Related concepts:** [Use case: events](../use-cases/events-conferences-workshops), [Dashboard: events](../dashboard/customer-management/events).

---

# CRM and operations

URL: https://docs.scoutello.com/product/crm-and-operations
Source: docs/product/crm-and-operations.md
Description: Customers, follow-up work, communications, and institutional memory in Scoutello.

Scoutello combines guest-facing experiences with the operational workspace needed to run them. The CRM is the part of Scoutello where teams keep **contacts, communication, tasks, projects, documents, newsletters, and events** in one shared system.

The public product story describes the CRM as "contacts, communication and tasks in a clear system." In the dashboard, that means every organization can maintain a structured record of people and companies, track follow-up work, document conversations, and keep event or project context attached to the same records the team already uses.

## What The CRM Covers

Scoutello CRM is organization-scoped. Data belongs to an organization, and each teammate sees the parts their role is allowed to access.

- **Customers** are the central contact records. They can represent people, companies, suppliers, or other tracked entities. Customer records hold names, contact details, status, tags, notes, addresses, profile visibility settings, assignments, event participation, newsletter subscriptions, documents, tasks, protocols, and links to other Scoutello modules.
- **Relations and referrals** make the network visible. Teams can record how contacts are connected, who referred whom, and which companies, partners, or stakeholders belong together.
- **Protocols** are structured interaction logs. They record calls, meetings, notes, emails, chats, demos, and other touchpoints with dates, outcomes, privacy flags, attachments, and optional follow-up tasks.
- **Tasks** turn follow-ups into owned work. Tasks support status, due date, assignees, tags, attachments, comments, customer links, project links, milestone links, and board/calendar/list views.
- **Projects** group longer-running work. A project can have participants, participant groups, milestones, tasks, protocols, documents, linked events, mails, and assigned customers.
- **Documents** keep files near the work they support. Files can be linked to customers, projects, events, protocols, tags, assigned users, and assigned customers.
- **Newsletters** reuse CRM data for audience lists and subscriber history. A newsletter can have subscribers, assigned customers, related contact forms, and related events.
- **Email** brings inbound and outbound communication into the workspace. Inbound messages can be matched to customers and projects; sent messages are visible from CRM and project contexts where configured.
- **Events** connect CRM records to invitations, participants, ticketing, documents, projects, newsletters, and attendee operations.

## How It Fits Together

The CRM is not a separate sales database bolted onto Scoutello. It is the operational memory behind the same organization that publishes web apps, tours, events, offers, contact forms, and newsletters.

Typical flows look like this:

1. A contact is created manually, imported, collected through a contact form, added as an event participant, or linked from another Scoutello workflow.
2. The team enriches the contact with status, tags, assignments, addresses, notes, documents, and relationship context.
3. Calls, meetings, emails, or decisions are logged as protocols.
4. Follow-ups become tasks with assignees and due dates.
5. Larger initiatives become projects with milestones, participants, project tasks, project protocols, documents, events, and mails.
6. Newsletter and inbox tools reuse the same customer context so communication history remains searchable.

This is why support agents should treat the customer record as the starting point when investigating CRM behavior. Most CRM modules either attach directly to a customer or can be traced back to one through projects, events, newsletters, email, tasks, or documents.

## Organization And Permissions Model

CRM access follows the organization role system. The dashboard sidebar only shows modules when the active user has permission for that entity. The relevant CRM entities include `customer`, `protocol`, `task`, `project`, `document`, `newsletter`, `email`, and `event`.

Permissions can affect both navigation and data visibility:

- If a user cannot list or read a module, the sidebar item may disappear or the page can show an access denied state.
- Some modules support assigned-only access, where users see records connected to them or their organization member profile instead of the full organization dataset.
- Customer, project, document, newsletter, email, and event views may show different available actions depending on create, edit, delete, list, and read permissions.
- Platform administrators can usually access more than regular organization members, but support should still check the active organization and role when reproducing a customer's issue.

## Important Support Concepts

- **Customer vs user:** A customer record can be linked to a user account, but not every customer is a login user. Person-type customer records can be associated with users by email in some flows.
- **Protocol vs task:** A protocol records what happened. A task records what needs to happen next. Protocols can create or link follow-up tasks.
- **Project vs task:** Use tasks for individual follow-ups. Use projects when work needs milestones, participants, event links, project documents, and a timeline.
- **Document vs attachment:** A first-class document appears in the document library. Protocol and task files can also be surfaced near the record or converted into document context depending on the flow.
- **Newsletter vs email:** Newsletters organize audience subscriptions and campaign lists. Email covers inbound inboxes, archived/spam views, and sent messages.
- **Event participant vs customer:** Event participants can link back to customer records, which lets CRM history and event attendance stay connected.

## Typical Use Cases

- A hotel team tracks repeat guests, corporate accounts, handoff tasks, documents, and follow-up conversations.
- An event organizer manages invitees, participants, project planning, newsletters, sent emails, check-in operations, and post-event follow-up in one workspace.
- An association maintains members, roles, private web app access, newsletters, event participation, and internal CRM history.
- A sales or partnerships team logs demos, meetings, proposals, stakeholder relationships, and project delivery milestones.
- A support team checks one customer timeline to understand who contacted the organization, what was promised, what tasks remain open, and which documents or events are involved.

## Where To Document Or Troubleshoot

For product-level explanations, start here. For screen-level behavior, use the dashboard customer management pages:

- [Customer management overview](../dashboard/customer-management/overview)
- [Customers](../dashboard/customer-management/customers)
- [Protocols](../dashboard/customer-management/protocols)
- [Tasks](../dashboard/customer-management/tasks)
- [Projects](../dashboard/customer-management/projects)
- [Documents](../dashboard/customer-management/documents)
- [Newsletters](../dashboard/customer-management/newsletters)
- [Email](../dashboard/customer-management/email)
- [Organization events](../dashboard/customer-management/events)

**Related concepts:** [Permissions and organizations](./permissions-and-organizations), [Dashboard guide: customer management](../dashboard/customer-management/overview).

---

# Permissions and organizations

URL: https://docs.scoutello.com/product/permissions-and-organizations
Source: docs/product/permissions-and-organizations.md
Description: Roles, scopes, and how sidebar entries appear for different teammates.

Access inside an organization uses **roles** wired to granular **permissions**. Dashboard visibility depends on the active organization, role assignments, and those permissions.

For the structured permission vocabulary used in role editors, see [/reference/permissions](/reference/permissions).

## Organization model

Scoutello data is organization-scoped. A user can belong to more than one organization and can have different roles in each one. Always confirm the active organization before diagnosing access, missing records, or missing sidebar items.

Organizations can also have hierarchy. Larger customers may use child organizations for properties, teams, locations, or brands while a parent organization keeps the broader customer relationship manageable.

## Permission shape

Most permissions use this shape:

```text
entity:action:scope
```

For example, `customer:read:assigned` means the role can read assigned customer records, but not necessarily every customer in the organization.

**Organization administration** uses the `admin` **entity** with the same action/scope pattern (for example `admin:list:all`). Roles that manage child organizations and user roles typically include several `admin:*` permissions together. Do not confuse this with the separate **global Scoutello platform administrator** account type, which is used only by Scoutello staff and unlocks cross-tenant tooling.

## How the sidebar uses permissions

The dashboard hides links the current session should not use. Examples:

- Customer management routes depend on entities such as customer, protocol, task, project, document, newsletter, email, and event capabilities.
- Web apps and tours routes depend on landing page, tour, offer, contact form, site plan, and related assignment rules.
- Settings routes expose commerce templates, event tooling, hierarchy controls for organization admins, and additional shortcuts reserved for platform operators where applicable.
- Users **assigned as tour guides** in the organization can see analytics/overview entry points without full landing-page or tour edit rights.

A missing menu item is often the **expected outcome** of permissions—not a broken deployment.

## Support workflow

When access looks wrong:

1. Confirm the active organization.
2. Confirm the user's role in that organization.
3. Check the relevant entity, action, and scope.
4. Check assigned-only relationships for records that should be visible.
5. Consider whether the user is a platform operator versus an organization member.
6. Avoid granting broad **organization administration** (`admin` entity) capabilities unless the user should manage organization structure and roles.

**Related concepts:** [Reference: permissions](/reference/permissions), [Dashboard overview](/dashboard/overview).

---

# Events, conferences & workshops

URL: https://docs.scoutello.com/use-cases/events-conferences-workshops
Source: docs/use-cases/events-conferences-workshops.md
Description: Segment overview for immersive event attendee experiences inside Scoutello.

Scoutello targets organizers who run **public or invite-only gatherings** needing multilingual guest portals, agendas, spatial orientation, polls, chats, raffle-style participation, networking, ticketing, invitations, companion guests, operational check-in tooling, and optional AI-assisted help.

This narrative summarizes how teams combine Scoutello modules—expand it over time as your playbook matures.

## Who This Is For

This use case fits teams that need both guest engagement and operational control:

- Conferences and trade fairs.
- Workshops and training programs.
- Hospitality or destination events.
- Association meetings and member gatherings.
- Public programs with registration, ticketing, or check-in.

## Jobs To Be Done

Event teams usually need to:

1. Publish a mobile attendee hub quickly.
2. Keep schedules, places, FAQs, and contact paths available without a native app.
3. Manage participants, invitations, tickets, and customer context.
4. Engage attendees with chat, networking, voting, quizzes, raffles, galleries, and site plans.
5. Follow up after the event using CRM tasks, protocols, newsletters, and projects.

## Scoutello Building Blocks

| Need | Scoutello surface |
| --- | --- |
| Event operations | Organization events in the customer management sidebar. |
| Attendee portal | Landing pages with event, site plan, FAQ, chatroom, networking, voting, raffle, quiz, and media tiles. |
| Ticketing and payments | Orders, widgets, price tiers, and event checkout flows where configured. |
| Communication | Mail templates, newsletters, sent emails, and CRM email context. |
| Follow-up | Customers, projects, tasks, protocols, and documents. |

## Example Workflow

1. Create the organization event and define the key event metadata.
2. Build a landing page for the attendee portal.
3. Add event-specific tiles: agenda, places, site plan, FAQs, networking, voting, raffle, or chatroom.
4. Configure ticketing, widgets, or registration if the event requires commerce or controlled access.
5. Send invitations or updates through newsletters and mail templates.
6. During the event, use participant status, check-in context, questions, or engagement tiles.
7. After the event, create follow-up tasks and protocols on the relevant customers or project.

## Support Checks

When something goes wrong, identify which layer owns the issue: event record, participant/customer link, landing page tile, widget/checkout, mail delivery, or CRM follow-up. Events are cross-cutting by design, so debugging often requires checking more than one screen.

**Related concepts:** [Product: events](../product/events), [Dashboard: organization events](../dashboard/customer-management/events).

---

# Tours — guides & operators

URL: https://docs.scoutello.com/use-cases/tours-guides-operators
Source: docs/use-cases/tours-guides-operators.md
Description: Segment-specific guidance for tour creators versus venue and transport operators composing companion guest stacks.

Marketing pages may highlight **`/tours`**, while product depth lives in [/product/tours](/product/tours). This page separates **two frequent audiences** when positioning Scoutello tours plus companion landing tiles.

## Audience A — Independent guides and tour agencies

**Jobs to be done:** Publish polished routes quickly, monetize ethically, broaden reach via languages and audio, and optionally coordinate partner venues using CRM context elsewhere in Scoutello.

**Product fit:**

- **Three authoring modes** — outdoor guided, indoor venue-style, and fixed-route pacing (see [Tour types](/product/tours/tour-types)).
- **Multilingual storytelling** — narrative blocks, per-step media, optional narration, and automatic translation where enabled ([Multilingual and audio](/product/tours/multilingual-audio)).
- **Monetization** — price tiers when payments are configured ([Commerce and access](/product/tours/commerce-and-access)).
- **Distribution** — public versus private visibility plus shareable links where short URLs are enabled.

**Messaging guardrail:** Revenue-share percentages belong in finance-approved contracts—not inferred from software screenshots.

## Audience B — Operators with existing ticketing or venue stacks

Examples: museums, zoos, transit attractions. These teams often layer Scoutello as a **digital companion** instead of replacing incumbent ticketing overnight.

**Product fit:**

- **Indoor tours plus site plans** anchor guests inside buildings.
- **Fixed-route pacing** supports timetabled or vehicle-like itineraries.
- **Companion stacks** — pair the **tour** tile with site plans, quizzes, galleries, chatrooms, offers, or event tiles ([Tile types](/reference/tile-types)).

## What to promise versus verify

| Claim | How to substantiate |
|-------|---------------------|
| Browser-first guest access | Demonstrate on target phones without requiring an app store download. |
| Distinct outdoor, indoor, fixed UX | Walk product reviewers through each mode using staging content. |
| Multilingual coverage | Show locales enabled on a staging tour after translation jobs finish. |
| Commercial splits or fees | Align only with finance-approved collateral—never ad-lib percentages. |

## Hand-off links

- Operational setup: [/dashboard/web-apps-and-tours/tours](/dashboard/web-apps-and-tours/tours)
- Product depth: [/product/tours/tour-types](/product/tours/tour-types), [/product/tours/guest-experience](/product/tours/guest-experience)

**Related:** [Tours overview](/product/tours), [CRM pillar](/product/crm-and-operations).

---

# Hospitality — hotels, restaurants & bars

URL: https://docs.scoutello.com/use-cases/hospitality-hotels-restaurants-bars
Source: docs/use-cases/hospitality-hotels-restaurants-bars.md
Description: Guest guides, services, PDF menus, recommendations, and operational CRM.

Venues use Scoutello as a **browser guest guide**: stay details, PDF translation for menus and policies, curated recommendations, embedded tours, messaging-style engagement, surveys, galleries, newsletter follow-up, and concierge-style assistance grounded in venue-authored content.

Landing marketing modules map to tile combinations plus CRM follow-through for service teams.

## Who This Is For

This use case fits hospitality teams that want to replace scattered PDFs, QR menus, printed handouts, and informal inbox workflows with a maintained digital guest experience.

Examples:

- Hotels and resorts.
- Restaurants and bars.
- Event venues.
- Visitor centers and hospitality partners.
- Multi-property groups with shared standards and local content.

## Guest Experience

Hospitality guest apps usually combine:

- Arrival information, opening hours, house rules, and service details.
- PDF menus, policies, brochures, or spa/service documents.
- Recommendations for restaurants, attractions, events, or partners.
- Gallery content for rooms, venues, food, or amenities.
- Contact forms, surveys, FAQs, and assistant-supported help.
- Optional tours, site plans, or destination-style guides.

Because the experience is browser-first, guests can open it from room cards, table QR codes, reception signage, emails, or booking messages.

## Operations And CRM

The value continues after the guest opens the guide. Contact forms, newsletter signups, event participation, partner requests, and service follow-up can all connect back to organization CRM records.

Teams can use customers, protocols, tasks, projects, documents, newsletters, and email to keep the operational memory of a guest or partner relationship in Scoutello instead of splitting it across private inboxes and spreadsheets.

## Example Workflow

1. Create a landing page for the property, restaurant, or venue.
2. Add tiles for PDF menus, FAQs, gallery, offers, contact forms, recommendations, and tours.
3. Translate guest-facing content for key visitor languages.
4. Place QR codes where guests need the information.
5. Review submissions and follow-up through CRM tasks, protocols, email, or newsletters.

## Support Checks

If guests see outdated information, check the landing page and the linked tile or document. If staff cannot follow up on a request, check whether the form submission, customer record, or task workflow is configured for the active organization.

**Related concepts:** [Browser-first guest experiences](../product/browser-first-guest-app), [Product: CRM and operations](../product/crm-and-operations), [Landing pages and tiles](../product/landing-pages-and-tiles).

---

# Destinations

URL: https://docs.scoutello.com/use-cases/destinations
Source: docs/use-cases/destinations.md
Description: DMO-style bundles of orientation, events, media, and ongoing guest conversation.

Destination marketing teams distribute **multilingual digital guides** blending maps, editorial tiles, site plans, calendars, media galleries, chat-style updates, partner offers, and Scoutello’s assistant so visitors stay oriented without juggling paper collateral.

## Who This Is For

This use case fits destination marketing organizations, tourism offices, city initiatives, visitor centers, cultural districts, and regional partnerships that need to keep visitor information current across many places and partners.

## What Destinations Publish

Destination experiences usually combine:

- Landing pages for the main visitor guide or campaign.
- Places and place groups for attractions, restaurants, shops, venues, and services.
- Site plans or maps for dense areas, visitor centers, fairs, or indoor spaces.
- Events and calendars for temporary programming.
- Tours and recommended routes.
- Offers from local partners.
- Media galleries and editorial content.
- Contact forms, surveys, and newsletters for ongoing engagement.

## Why Scoutello Fits

Destinations need a content model that can handle both evergreen guidance and temporary campaigns. Scoutello lets teams maintain structured places, offers, events, tours, and landing pages in one organization instead of publishing disconnected PDFs and static pages.

The browser-first model also makes physical rollout simple: QR codes can be placed in hotels, visitor centers, partner locations, printed guides, or event signage.

## Example Workflow

1. Build a landing page for the destination or campaign.
2. Add places and place groups for the most important visitor categories.
3. Attach site plans, tours, media galleries, offers, and event tiles.
4. Translate core content for the destination's main guest languages.
5. Use analytics and feedback to decide what content needs improvement.
6. Keep partner updates flowing through offers, events, newsletters, and CRM follow-up.

## Support Checks

If a visitor cannot find a place or offer, check whether it exists as a structured record and whether the landing page or tile is configured to expose it. If information appears in one language but not another, check the multilingual content pipeline and fallback behavior.

**Related concepts:** [Landing pages and tiles](../product/landing-pages-and-tiles), [Places and maps](../dashboard/web-apps-and-tours/places-and-place-groups).

---

# Associations

URL: https://docs.scoutello.com/use-cases/associations
Source: docs/use-cases/associations.md
Description: Member portals with controlled access, networking, polls, and messaging.

Associations coordinate members inside **closed web apps** featuring networking matches, live polls, announcements, and moderated conversation tiles so distributed chapters stay aligned during conferences or ongoing programs.

## Who This Is For

This use case fits member organizations, clubs, chambers, alumni groups, federations, professional associations, and communities that need a digital member experience without losing operational control.

## Common Jobs

Associations often need to:

- Publish private or semi-private member information.
- Run events, workshops, and member conferences.
- Support networking between members.
- Collect feedback, votes, or questions.
- Send newsletters and announcements.
- Keep member records, roles, documents, tasks, and event history connected.

## Scoutello Building Blocks

| Need | Scoutello surface |
| --- | --- |
| Member portal | Landing pages with controlled access and member-oriented tiles. |
| Community interaction | Networking, chatroom, voting, quiz, raffle, and questions tiles. |
| Member operations | Customers, roles, permissions, newsletters, tasks, protocols, and documents. |
| Events | Organization events, participant groups, invitations, and event landing pages. |
| Governance | Child organizations and roles for chapters, committees, or local teams. |

## Example Workflow

1. Model members as customer records and link user accounts where login access is needed.
2. Define roles for staff, chapter leads, committee members, or regular members.
3. Create a landing page for the member portal or event.
4. Add tiles for announcements, networking, voting, questions, documents, or event content.
5. Use newsletters, events, tasks, and protocols to keep follow-up visible.

## Support Checks

Most association issues come down to the active organization, role, or access scope. If someone cannot see member content, check whether they are in the right organization, whether their customer/user relationship is linked, and whether the landing page or event requires a specific permission or invite context.

**Related concepts:** [Events use case](./events-conferences-workshops), [Networking tile](../reference/tile-types), [Product: permissions](../product/permissions-and-organizations).

---

# CRM-focused teams

URL: https://docs.scoutello.com/use-cases/crm
Source: docs/use-cases/crm.md
Description: Operational CRM, tasks, and communications without losing guest context.

CRM-focused teams use Scoutello when customer memory and day-to-day operations need to live beside guest-facing experiences. The same organization can run landing pages, tours, events, newsletters, inboxes, contact forms, and internal follow-up from one workspace.

Scoutello's CRM is designed for operational teams rather than only classic sales pipelines. It keeps **contacts, communication, tasks, projects, protocols, documents, newsletters, and events** connected so support, hospitality, sales, marketing, and event teams can understand the full story behind a person or organization.

## Who This Is For

Scoutello's CRM use case is especially useful for teams that need more than a spreadsheet and less fragmentation than separate tools for contacts, email, events, projects, and guest content.

- **Hospitality teams** can track guests, companies, partners, service requests, handoff tasks, stay-related notes, and repeat-guest context.
- **Event organizers** can manage invitees, participants, customer assignments, check-in context, tickets, newsletters, project planning, documents, and follow-up tasks.
- **Associations and communities** can manage members, roles, private access, referrals, newsletters, internal events, and communication history.
- **Tour and destination teams** can keep contacts, partners, suppliers, guides, documents, offers, events, and operational tasks connected to the same organization that publishes guest experiences.
- **Sales, partnership, and support teams** can track prospects, stakeholders, proposals, demos, tasks, files, and communication history without exporting data between systems.

## Core Jobs To Be Done

### Keep Full Context On Each Record

A customer record can combine profile fields, status, tags, notes, addresses, linked users, relations, referrals, newsletter subscriptions, event attendance, emails, documents, protocols, and open tasks.

This makes the record useful for support agents because they can answer questions such as:

- Who is this person or company?
- Which organization owns the record?
- Which tags, statuses, and assignments explain why they appear in a filtered list?
- What happened most recently?
- Which tasks are still open?
- Which events, newsletters, projects, or documents are attached?

### Turn Conversations Into Follow-Up

Protocols capture what happened in calls, meetings, emails, notes, chats, demos, or other interactions. Tasks capture what needs to happen next. When a team logs a protocol, it can create related tasks immediately, so decisions and promises become visible work.

This supports handoffs such as:

1. A front desk person records a guest issue as a protocol.
2. A follow-up task is assigned to the responsible teammate.
3. A document or email is attached to the record.
4. The next shift can see the context without searching through private inboxes.

### Manage Longer Initiatives With Projects

Projects are useful when work spans multiple people, milestones, events, or documents. A project can collect participants, participant groups, tasks, protocols, milestones, mails, documents, and events.

Examples:

- A corporate event series with invitees, newsletters, ticketing, project milestones, and post-event follow-up.
- A hospitality partnership with multiple contacts, proposals, signed documents, recurring tasks, and meeting notes.
- A destination campaign that combines events, web app content, partner contacts, and operational approvals.

### Communicate From Live CRM Data

Newsletters and email are part of the CRM story because teams can communicate using the same contacts they manage operationally.

- Newsletter lists can reuse CRM subscribers and assignments instead of relying on one-off CSV exports.
- Inbound email can be matched to contacts and projects.
- Sent email history gives support and operations a way to verify what left the system.
- Email context can sit near protocols, tasks, and project records.

### Bridge Guest Experience And Operations

Scoutello is strongest when the public-facing experience and the internal follow-up use the same source of truth. A contact form, event registration, newsletter signup, landing page access, or event participant record can all become part of CRM context.

That means a team can publish a web app or event experience and still keep the operational history needed to support people afterward.

## Example Workflows

### Hospitality Follow-Up

1. A returning guest or corporate contact exists as a customer.
2. The team logs a protocol for a call, stay note, or service request.
3. A task is created for the responsible teammate.
4. Documents such as proposals, menus, or agreements are attached.
5. The contact can later be added to a newsletter, event, or project without losing the earlier history.

### Event Operations

1. Contacts are imported, created manually, or generated through registration.
2. The organizer assigns customers to an event or project.
3. Newsletters and sent emails communicate updates.
4. Event participant status, ticketing, check-in, and documents stay connected.
5. Post-event protocols and tasks capture feedback, next steps, and support issues.

### Member Or Community Management

1. Members are customer records linked to users or roles.
2. Access settings control which private web app or organization areas they can use.
3. Newsletters, events, tasks, and protocols keep the organization informed about member activity.
4. Relations and referrals show how people are connected inside the community.

## What Support Agents Should Check First

- Confirm the active organization. CRM records are organization-scoped.
- Confirm the user role and permission scope for `customer`, `protocol`, `task`, `project`, `document`, `newsletter`, `email`, or `event`.
- Open the customer record if the issue concerns a person, company, subscriber, event participant, or email sender.
- Check whether the record is assigned-only, externally added, linked to a user, or connected through a project, event, newsletter, document, or inbound email.
- Distinguish between missing navigation and missing data. Missing navigation usually points to permissions; missing rows may point to filters, assigned-only scope, search, archived/spam status, or organization mismatch.

**Related concepts:** [CRM and operations](../product/crm-and-operations), [Dashboard customer management](../dashboard/customer-management/overview).

---

# Dashboard overview

URL: https://docs.scoutello.com/dashboard/overview
Source: docs/dashboard/overview.md
Description: Shell behaviors, navigation primitives, and commands for operators.

The **dashboard** hosts authenticated configuration and operations. Common UI patterns:

- **Organization switcher** — moves between tenants without separate logins when permitted.
- **Sidebar** — grouped categories such as **Customer management**, **Web apps and tours**, and **Settings** mirror how Scoutello structures responsibilities day to day.
- **Command palette or quick search** — mirrors many destinations for keyboard-driven navigation where enabled.
- **Profile and organization settings** — appear alongside logout utilities.

Some flows intentionally hide the standard chrome (for example lightweight previews or payment confirmations); patterns are summarized under [Routes](/reference/routes).

**Related concepts:** [Customer management overview](./customer-management/overview), [Permissions](/product/permissions-and-organizations).

---

# Customer management — overview

URL: https://docs.scoutello.com/dashboard/customer-management/overview
Source: docs/dashboard/customer-management/overview.md
Description: CRM category in the organization sidebar.

The **Customer management** sidebar category is the dashboard home for Scoutello's CRM and operational follow-up features. It consolidates **customers**, **protocols**, **tasks**, **projects**, **documents**, **newsletters**, **email** (inbox, archive, spam, sent), and **events** when the active user's permissions permit each link.

Use this section when documenting or troubleshooting how an organization tracks contacts, work, communication, documents, event context, and project delivery.

## Where It Appears

Customer management appears in the organization dashboard, under routes like:

- `/organizations/:id/customers`
- `/organizations/:id/protocols`
- `/organizations/:id/tasks`
- `/organizations/:id/projects`
- `/organizations/:id/documents`
- `/organizations/:id/newsletters`
- `/organizations/:id/inbox`
- `/organizations/:id/sent-emails`
- `/organizations/:id/events`

The exact links depend on the active organization, the signed-in user, and the organization role.

## CRM Relationship Map

```mermaid
flowchart TD
  Customer["Customer contact"] --> Protocol["Protocol interaction"]
  Customer --> Task["Task follow-up"]
  Customer --> Project["Project participation"]
  Project --> Milestone["Milestone"]
  Milestone --> Task
  Milestone --> Protocol
  Protocol --> Document["Document"]
  Project --> Event["Event"]
  Customer --> Newsletter["Newsletter subscription"]
  Email["Inbound or sent email"] --> Customer
  Email --> Project
```

## Modules In The Category

### Customers

Customers are the central CRM records. A customer can be a person, company, supplier, or other tracked entity. Customer records can hold profile details, tags, statuses, relations, referrals, notes, custom fields, addresses, images, linked user accounts, profile visibility settings, protocols, tasks, documents, newsletters, emails, events, and project participation.

Start with the customer record whenever a support question concerns a specific person, organization, email address, subscriber, event participant, or assigned contact.

### Protocols

Protocols are stored as interaction records. They log what happened: calls, meetings, emails, chats, demos, notes, and other touchpoints. Protocols can include date, type, direction, outcome, subject, description, duration, attachments, privacy, linked tasks, documents, projects, and milestones.

Use protocols for history, decisions, handoff notes, and communication context.

### Tasks

Tasks represent follow-up work. They can belong to a customer, organization, project, or milestone. Tasks include a title, description, status, due date, assignees, tags, attachments, comments, privacy, and ordering for board views.

Use tasks for ownership and deadlines. Use protocols for the story behind the task.

### Projects

Projects group longer-running work. A project can include participants, participant groups, milestones, tasks, task templates, protocols, documents, linked events, mails, inbound emails, and assigned customers.

Use projects when the work has multiple stakeholders, phases, events, or shared deliverables.

### Documents

Documents are organization-scoped files. They can link to customers, projects, events, protocols, tags, assigned users, and assigned customers. The document library can also surface legacy tile PDFs when configured.

Use documents when support needs to find the file behind a contract, offer, PDF, protocol attachment, project asset, or event document.

### Newsletters

Newsletters organize subscriber lists and CRM-driven communication audiences. A newsletter can have subscribers, assigned customers, related events, and contact forms.

Use newsletters when support needs to explain why a contact appears in a campaign audience, why a subscriber is pending or unsubscribed, or how CRM lists connect to communication.

### Email

Email includes the organization inbox, archive, spam view, and sent emails. Inbound emails can link to customers, responsible customers, projects, tags, and attachments. Sent emails help verify outbound communication and troubleshooting delivery issues.

Use email when a customer says a message was received, archived, spam-marked, bounced, sent by the wrong sender, or missing from expected context.

### Organization Events

Events in customer management are organization events, not the global platform admin event list. CRM-facing event operations include customer assignments, participants, invitations, ticketing, documents, newsletters, linked landing pages, project links, and attendee status.

Use the events page when support needs to connect a contact to event registration, invitations, check-in, tickets, event newsletters, or project delivery.

## Permissions And Visibility

Items disappear automatically when the organization role lacks the prerequisite `entity:action:scope` pairs described in [Permissions](../../reference/permissions).

The most relevant CRM entities are:

- `customer`
- `protocol`
- `task`
- `project`
- `document`
- `newsletter`
- `email`
- `event`

For most sidebar links, the dashboard checks whether the user can list or read the relevant entity. Some pages also check create, edit, or delete permissions before showing buttons, row actions, bulk actions, or form controls.

Assigned-only scopes can change which records appear. For support, this means two users in the same organization may see different rows even if both can open the same module.

## Common Support Checks

1. Confirm the active organization ID in the URL.
2. Confirm the user's role and permissions for the affected module.
3. Check whether the issue is navigation visibility, record visibility, or action availability.
4. Clear obvious filters such as search, status, assigned-only, show completed, archive/spam, or date range.
5. Open the customer record and inspect related tabs for protocols, tasks, documents, emails, events, newsletters, access, relations, and referrals.
6. For project-related questions, open the project timeline and the project tabs for participants, milestones, tasks, protocols, documents, events, and mails.
7. For email and newsletter questions, check the customer email/subscription context and the organization email views.

## Support Vocabulary

- **Customer:** Contact or CRM record. Can be a person, company, supplier, or other entity.
- **Member:** A user/customer relationship in an organization, usually controlled through roles and permissions.
- **Protocol:** Logged interaction or activity tied to customers and projects.
- **Task:** Follow-up work item with status, assignees, and due date.
- **Assigned-only:** Permission scope that limits visible records to records connected to the user or member context.
- **Externally added:** Customer records created from external or guest-facing flows, such as forms or imports, rather than manually entered by the internal team.

**Related concepts:** [CRM product pillar](../../product/crm-and-operations), [Customers](./customers).

---

# Customers

URL: https://docs.scoutello.com/dashboard/customer-management/customers
Source: docs/dashboard/customer-management/customers.md
Description: CRM contact records and segmentation entry points.

The **Customers** area is the center of Scoutello CRM. It lists the people, companies, suppliers, members, partners, guests, leads, and other entities an organization tracks for sales, hospitality, events, memberships, support, or operational follow-up.

Route: `/organizations/:id/customers`

Customer detail route: `/organizations/:id/customers/:customerId`

## What A Customer Record Represents

A customer record can be a classic contact, but it can also represent more operational concepts:

- A person who attends an event, receives a newsletter, or logs into a private web app.
- A company or account with related people and projects.
- A supplier, partner, guide, sponsor, speaker, venue, association member, repeat guest, or internal stakeholder.
- A record created manually, imported from a file, copied from another permitted organization, scraped/enriched, or generated by a guest-facing form or event flow.

The customer is the best starting point for support because many CRM and guest-facing flows eventually attach to it.

## Important Fields

Customer records can include:

- **Identity:** first name, last name, title, department, job title, company name, type, linked user account.
- **Contact details:** email, phone, second phone, website, LinkedIn, Facebook, Instagram, YouTube, XING, Bluesky, and other social links.
- **Classification:** type, status, source, tags, custom fields, notes, descriptions, and order.
- **Personal profile fields:** age, date of birth, gender, pronouns, spoken languages, images, and profile visibility settings.
- **Organization context:** owning organization, associated organization, responsible customer, role, permissions, invited/accepted state, and member access.
- **Network context:** customer relations, referrals, responsible-for links, project participation, assigned projects, assigned events, assigned tours, assigned landing pages, assigned offers, and assigned newsletters.
- **Communication context:** inbound emails, sent mails as sender, personal sender local part, contact email, email signature, newsletter subscriptions, and email opt-out state.
- **Operational context:** tasks, protocols, documents, event participants, invoices, contact form submissions, saved entries, short links, and landing page access.

Not every field is visible in every form. Visibility depends on customer type, permissions, organization setup, and the current tab.

## Types And Statuses

Customer types used by the dashboard:

- **Person:** individual contact, guest, member, attendee, team member, or stakeholder.
- **Company:** company or customer account.
- **Supplier:** vendor or supplier contact.
- **Other:** fallback for records that do not fit the standard categories.

Customer statuses used in CRM lists:

- `prospect`
- `first_contact`
- `proposal_sent`
- `in_negotiation`
- `low_confidence`
- `won`
- `lost`

Support should treat these statuses as operational labels. They help teams filter and understand pipeline or relationship state, but they do not by themselves grant access, send emails, or change event participation.

## List Views And Filters

The customer list supports table behavior, mobile list behavior, and kanban-style views. Common list controls include:

- Search and column filtering.
- Status and type display.
- Last-updated date range filtering.
- Show externally added records.
- Show records with permissions.
- Show only assigned records.
- Bulk selection and bulk edit where permitted.

If a user says a customer is missing, check the active organization, permissions, assigned-only scope, search text, quick filters, date filter, and whether the record exists in another organization.

## Creating And Importing Customers

Users with the right permissions can create customers manually or import them.

Common entry points:

- **Create:** create a new customer record.
- **Import from file:** upload customer data from a file import flow.
- **Import from organization:** copy permitted records from another organization.
- **Scrape/import leads:** use a scraping flow where enabled.

When creating or updating person-type customers, Scoutello can link an existing user account by email in supported flows. Duplicate email checks are organization-aware, so support should verify the organization before assuming a duplicate belongs to the same CRM dataset.

## Customer Detail Tabs

Existing customer records can show multiple tabs:

- **Overview:** high-level contact context and quick actions.
- **Advanced:** detailed customer form fields and newsletter subscription controls.
- **Relations:** direct relationships to other customers.
- **Referrals:** who referred this customer and who this customer referred.
- **Protocols:** interaction history for the customer.
- **Documents:** files linked to the customer.
- **Tasks:** follow-up work linked to the customer.
- **Emails:** inbound or outbound email context for the customer.
- **Events:** event participation and event links for person records.
- **Access:** profile, role, permissions, and web app access settings for person records where editable.

Tabs appear only when the user has the relevant module permissions and when the customer type supports the tab.

## Quick Actions

From customer lists and detail pages, users may be able to:

- Create a protocol.
- Create a task.
- Compose an email.
- Add the customer to a newsletter.
- Add the customer to an event.
- Add the customer to a project.
- Add a relation.
- Clear externally added flags.
- Bulk edit or delete selected customers.

The available actions depend on the active user's role, blocked state, customer type, organization membership, and entity permissions.

## How Customers Connect To Other Modules

- **Protocols** explain what happened with the customer.
- **Tasks** show what still needs to happen.
- **Documents** store files relevant to the customer.
- **Projects** show longer-running initiatives involving the customer.
- **Newsletters** show subscription and campaign-list context.
- **Email** shows conversations and sender/recipient context.
- **Events** show invitations, participation, tickets, check-in state, and assigned-customer context.
- **Landing pages and tours** can use customer access and assignment records for private or targeted experiences.

## Permission Notes

The customer sidebar item appears when the user can list or read customers. Create, edit, delete, and assigned-only behavior is controlled separately by organization permissions.

Important support implications:

- Assigned-only users may see only records connected to their responsible or assigned context.
- A user may be able to read customers but not create, edit, delete, bulk edit, or import them.
- Access/profile fields are sensitive because they can affect member roles, private web app access, and what information appears in public or member profiles.
- Platform admins may see admin-only controls that normal organization users do not see.

## Common Support Scenarios

### A customer is missing from the list

Check:

1. Active organization in the URL.
2. Search, quick filters, date filters, and assigned-only filter.
3. Customer permission scope for the user.
4. Whether the customer belongs to another organization.
5. Whether the record is externally added or hidden by a filter.
6. Whether the user is viewing a project, event, newsletter, or customer-specific subset rather than the full organization customer list.

### A duplicate customer cannot be created

Check whether another customer in the same organization already uses the email address. Person-type records can link to users by email, so email uniqueness and user linkage are often involved.

### A tab or action is missing

Check the entity permission for the tab or action. For example, missing protocols usually points to `protocol` list/read permissions; missing task actions may point to `task` create/edit permissions; missing documents points to `document` list/read/edit permissions.

### A customer does not appear in a newsletter, event, or project

Check whether the customer has been explicitly assigned or subscribed, whether the customer type is supported by that flow, and whether assigned-only filtering is active.

**Related concepts:** [Protocols](./protocols), [Documents](./documents).

---

# Protocols

URL: https://docs.scoutello.com/dashboard/customer-management/protocols
Source: docs/dashboard/customer-management/protocols.md
Description: Structured interaction logs aligned with customer timelines.

**Protocols** capture structured interaction history: notes, calls, meetings, emails, chats, demos, visits, decisions, escalations, and handoff context.

Route: `/organizations/:id/protocols`

In the product UI they appear as **protocol** entries attached to customers and related records—think of them as the team's written log of what happened.

## When To Use Protocols

Use a protocol when the team needs an auditable or searchable record of an interaction.

Common examples:

- A call with a guest, member, partner, lead, sponsor, or supplier.
- A meeting note connected to a customer or project.
- A demo or sales conversation with follow-up outcome.
- A support handoff between shifts.
- An email, chat, or note that should live beside the customer timeline.
- A project or milestone update that explains why tasks were created.
- A private internal note visible only to users with sufficient access.

Protocols answer "what happened?" Tasks answer "what needs to happen next?"

## Protocol Fields

Protocols can include:

- **Type:** note, call, video call, email, chat, meeting, demo, or other.
- **Direction:** inbound or outbound for email and call-style interactions.
- **Outcome:** open, successful, follow-up needed, not interested, no response, or rescheduled.
- **Subject:** short summary of the interaction.
- **Description:** longer formatted notes.
- **Date:** when the interaction happened.
- **Duration:** minutes, shown for protocol types where duration is relevant.
- **Customer:** the related customer, when created from the organization-wide protocol view.
- **Privacy:** whether the protocol is private.
- **Documents/files:** attachments associated with the protocol.
- **Tasks:** follow-up tasks created together with the protocol.
- **Project and milestone:** optional context when the protocol is logged from project workflows.

## Protocol Types

Supported protocol type values include:

- `note`
- `call`
- `videoCall`
- `email`
- `chat`
- `meeting`
- `demo`
- `other`

Some types support duration because they represent time-bound interactions. Notes and email-style records are usually about content rather than duration.

## Outcomes And Direction

Outcomes help teams scan history quickly:

- `open`: still unresolved or not classified.
- `successful`: completed positively.
- `follow_up_needed`: follow-up work is expected.
- `not_interested`: the contact declined or is not currently interested.
- `no_response`: outreach did not receive a response.
- `rescheduled`: the interaction moved to another time.

Direction is available for email and call-like flows:

- `inbound`: the customer or external party contacted the organization.
- `outbound`: the organization contacted the customer or external party.

## Views And Entry Points

Protocols are visible in multiple places:

- Organization protocol list: all visible protocols for the active organization.
- Customer detail tab: protocols for a specific customer.
- Project detail tab: protocols linked to a project.
- Milestone detail page/tab: protocols linked to a milestone.
- Document detail: protocols linked to a document.
- Timeline-style views where customer interactions are converted into general timeline entries.

The same protocol can therefore matter in several contexts. For support, use the customer, project, milestone, and document links to understand why a protocol appears in a specific view.

## Creating Follow-Up Tasks

When creating a protocol, users can also add tasks. This is useful when an interaction produces next steps:

1. Log the call, meeting, email, or note as a protocol.
2. Add one or more tasks with names, due dates, assignees, tags, and privacy settings.
3. The protocol preserves the context, and the tasks appear in task views and related customer/project contexts.

This is the main handoff pattern for support and operations teams.

## Privacy And Permissions

Protocol navigation appears when the user can list or read protocols. Creating, editing, and deleting depend on `protocol` permissions. Protocol rows and actions can also be affected by the related customer's assigned/responsible context.

Private protocols are intended for sensitive internal context. If a user cannot see a protocol that another teammate can see, check:

- The user's `protocol` list/read permissions.
- Assigned-only scope.
- Whether the protocol is private.
- Whether the protocol is attached to a customer, project, or milestone the user cannot access.
- Whether the user is looking at an organization-wide view or a filtered customer/project view.

## Common Support Scenarios

### A protocol is missing from a customer timeline

Check whether the protocol is attached to the expected customer. If it was created from a project or milestone context, it may be attached to the project/milestone but not to the customer.

### A protocol appears in project context

Protocols can link to projects and milestones. This is expected when the interaction is part of delivery work, not only direct customer history.

### A protocol created tasks but the tasks are not visible

Check task permissions, assigned-only task filtering, show completed filter, customer/project/milestone context, and task status.

### Attachments are hard to find

Protocol files may appear in protocol detail context and can also relate to document workflows. Check the document library and the related customer/project/document tabs.

**Related concepts:** [Tasks](./tasks), [Customers](./customers).

---

# Tasks

URL: https://docs.scoutello.com/dashboard/customer-management/tasks
Source: docs/dashboard/customer-management/tasks.md
Description: Lightweight work tracking tied to CRM records and daily operations.

**Tasks** operationalize follow-ups discovered in protocols, customer conversations, projects, milestones, events, or inbound email. They support ownership and progress tracking without requiring a full project.

Route: `/organizations/:id/tasks`

Tasks can also appear inside customer details, project details, milestone details, timelines, and dashboard widgets.

## What Tasks Are For

Use tasks for concrete work that needs an owner, status, and due date.

Examples:

- Call a guest back tomorrow.
- Send a proposal to a corporate contact.
- Prepare event documents before check-in.
- Follow up after a protocol marked "follow-up needed."
- Complete a project milestone deliverable.
- Assign a teammate to review a document or customer request.
- Track handoff work between shifts or departments.

Tasks are intentionally lightweight. If the work grows into multiple phases, participants, events, documents, and milestones, use a project and attach tasks to that project.

## Task Fields

Tasks can include:

- **Name:** required title.
- **Description:** optional longer context.
- **Status:** todo, in progress, waiting, completed, or cancelled.
- **Due date:** date/time for follow-up.
- **Assignees:** one or more organization users.
- **Customer:** optional related customer.
- **Project:** optional related project.
- **Milestone:** optional related project milestone.
- **Tags:** task-specific tags.
- **Documents/files:** task attachments.
- **Privacy:** private task flag.
- **Comments:** conversation around the task.
- **Protocols:** interactions linked to the task.

## Task Statuses

The dashboard uses these task statuses:

- `todo`: work has not started.
- `in_progress`: work is actively being handled.
- `waiting`: blocked or waiting for another person/system.
- `completed`: finished.
- `cancelled`: no longer needed.

Completed tasks can be hidden by default depending on the current task view. If a user cannot find a completed task, check the **Show completed** filter.

## Views

The task overview supports multiple ways to work:

- **Kanban view:** default organization task view for moving work across statuses.
- **Table/list view:** structured rows with columns such as due date, customer, title, status, and assignees.
- **Calendar view:** tasks arranged by date for planning.
- **Mobile list view:** compact operational view on smaller screens.

Task data can also be embedded in customer, project, milestone, and dashboard widget contexts.

## Filters

Common task filters include:

- **Show completed:** includes completed tasks in the current view.
- **Show related tasks:** when inside a customer context, includes tasks from related customer records.
- **Show only assigned:** limits tasks to the active user's assignment context.
- Search, status, assignee, customer, and table column filters depending on the current table configuration.

If support is investigating a missing task, check filters before assuming the task was deleted.

## Task Templates

Task templates let organizations reuse recurring follow-up patterns. A template can define:

- Template name.
- Task name and description.
- Default status.
- Default due offset.
- Default assignees.
- Tags.
- Files.
- Organization, project, or milestone context.

Templates are useful for repeated workflows such as onboarding a sponsor, handling contact form submissions, preparing event steps, or creating standard post-call follow-ups.

## Creating Tasks From Protocols

Protocols can create tasks during interaction logging. This is the preferred pattern when the task is a direct follow-up to something that happened.

Example:

1. A teammate logs a meeting protocol with outcome `follow_up_needed`.
2. They add a task "Send revised offer" with a due date and assignee.
3. The protocol remains in the customer's history, and the task appears in task views until completed.

## Project And Milestone Tasks

Tasks can be linked to a project or milestone. This gives teams both a global work queue and project-specific delivery tracking.

- Project tasks appear in the project task tab.
- Milestone tasks appear in milestone context.
- Organization task views can still show project tasks when permissions and filters allow.
- Task templates can also be scoped to projects or milestones.

## Permissions

Task navigation appears when the user can list or read tasks. Creating, editing, deleting, bulk deleting, templates, and row actions depend on task permissions and user state.

Assigned-only behavior can limit visible tasks to:

- Tasks assigned to the user.
- Tasks related to the user's member/customer context.
- Tasks visible through project, milestone, or customer assignment relationships.

## Common Support Scenarios

### A task is missing

Check:

1. Active organization.
2. Show completed filter.
3. Show only assigned filter.
4. Customer-specific vs organization-wide view.
5. Project or milestone context.
6. Task status.
7. User's `task` permission scope.

### A user cannot create or edit a task

Check `task` create/edit permissions, whether the user is blocked, and whether assigned-only rules prevent editing the selected customer/project context.

### A task appears without a customer

Tasks can exist at organization, project, or milestone level without a customer. This is expected for general operational work.

### Calendar behavior is confusing

The calendar view depends on due dates. Tasks without due dates may not appear in date-based calendar positions.

**Related concepts:** [Projects](./projects), [Protocols](./protocols).

---

# Projects

URL: https://docs.scoutello.com/dashboard/customer-management/projects
Source: docs/dashboard/customer-management/projects.md
Description: Larger initiatives spanning multiple stakeholders and milestones.

Use **Projects** when work spans longer timelines, multiple stakeholders, milestones, documents, events, mails, protocols, and tasks. Projects give teams a shared operational container beyond ad-hoc task lists.

Route: `/organizations/:id/projects`

Project detail route: `/organizations/:id/projects/:projectId`

## What Projects Are For

Projects are useful when a team needs structure around a larger initiative.

Examples:

- A recurring event series with invitees, event pages, documents, project tasks, and newsletters.
- A hospitality partnership with a company, decision makers, proposals, meetings, and follow-up tasks.
- A destination campaign with partner contacts, milestones, files, and events.
- An internal implementation plan with participants, milestones, and operational protocols.
- A member or sponsor onboarding process with tasks, documents, and event participation.

If a single follow-up is enough, use a task. If the work has phases, participants, and shared artifacts, use a project.

## Project Fields

Projects can include:

- **Name and description:** localized text fields.
- **Start date and end date:** optional project planning dates.
- **Status:** active, completed, on hold, or cancelled.
- **Organization:** owning organization.
- **Created by:** user who created the project.
- **Assigned customers:** contacts responsible for or connected to the project.
- **Participants and participant groups:** customers with optional roles, notes, and grouping.
- **Milestones:** ordered phases or deliverables.
- **Tasks and task templates:** project-level or milestone-level work.
- **Protocols:** project-related interaction logs.
- **Documents:** files linked to the project.
- **Events:** organization events linked to the project.
- **Mails and inbound emails:** communication associated with the project.

## Project List

The project list shows key planning fields:

- Name.
- Status.
- Start date.
- End date.
- Participant count.

It can also filter to **Show only assigned**, which is important for assigned-only permission workflows.

## Project Detail Tabs

Project details can include:

- **Timeline:** combined project activity view.
- **Configuration:** project name, description, dates, status, and assigned customers.
- **Participants:** customers participating in the project, including role and notes.
- **Milestones:** ordered phases with own status, dates, assigned customers, tasks, templates, and protocols.
- **Tasks:** project task list.
- **Protocols:** project interaction history.
- **Documents:** project-linked files.
- **Events:** organization events linked to the project.
- **Mails:** outbound or related project communication.

Tabs appear based on permissions and available project context.

## Milestones

Milestones break project work into phases. A milestone can include:

- Name and description.
- Status.
- Start and end dates.
- Order.
- Assigned customers.
- Tasks.
- Task templates.
- Protocols.

Use milestones for phases such as preparation, production, follow-up, review, contract, onboarding, or delivery.

## Participants And Groups

Project participants are customers linked to the project. They can have:

- Role.
- Notes.
- Optional participant group.

Participant groups help keep larger projects understandable. For example, an event project might group sponsors, speakers, suppliers, internal staff, and VIP contacts.

## Linking Events

Projects can link to organization events. This is useful when event execution is part of a broader operational plan.

Examples:

- A conference project links several event sessions.
- A hospitality partner project links invitation-only tastings or guest programs.
- A community project links member events and post-event follow-up.

When troubleshooting event/project behavior, check both the project tab and the event detail page.

## Project Timeline

The project timeline is intended to help support and operations understand the full story of a project. It can combine relevant tasks, protocols, milestones, events, documents, and mail context depending on what is linked.

Use it when a user asks, "What happened on this project?" or "Why was this task created?"

## Permissions

Project navigation appears when the user can list or read projects. Project creation, deletion, editing, and row actions depend on project permissions, creator ownership, assigned-only context, and admin status.

Documents inside project tabs also require document permissions. If the project exists but the documents tab is missing, check `document` list/read permissions.

## Common Support Scenarios

### A project is missing

Check active organization, project permissions, assigned-only filter, project status, and whether the user is in the correct organization workspace.

### A participant is missing

Check whether the customer is attached as a project participant, not just assigned to the project or linked through a task/event.

### A task or protocol does not show in the project

Check whether the task/protocol is linked to the project or only to a customer. Milestone-level items may appear in milestone views and project aggregate views depending on the current tab.

### An event is not connected to the project

Check the event's project link. Event/customer assignment and project/event linking are different relationships.

### A documents tab is missing

Check document permissions. Project access alone does not guarantee document access.

**Related concepts:** [Documents](./documents), [Tasks](./tasks).

---

# Documents

URL: https://docs.scoutello.com/dashboard/customer-management/documents
Source: docs/dashboard/customer-management/documents.md
Description: Shared files linked to CRM, events, and operational artifacts.

The **Documents** library stores files that should stay close to CRM records and operational work: PDFs, contracts, proposals, collateral, menus, schedules, SOPs, speaker files, supplier files, event documents, and protocol attachments.

Route: `/organizations/:id/documents`

Document detail route: `/organizations/:id/documents/:documentId`

Documents can also appear in customer, project, event, protocol, and milestone contexts.

## What A Document Is

A document is an organization-scoped file record. It has its own metadata and links to the uploaded file, but it can also be connected to other CRM entities.

Document records can include:

- **Name:** display name for the file.
- **File link:** stored file reference and MIME type.
- **Organization:** owning organization.
- **Created by:** user who uploaded or created it.
- **Customer:** optional customer link.
- **Project:** optional project link.
- **Event:** optional event link.
- **Tags:** document-specific tags.
- **Assigned users:** internal users responsible for or allowed to work with the document.
- **Assigned customers:** contacts connected to the document.
- **Protocols:** interactions that reference the document.

## Document Sources

The document list can include more than one source type:

- **Document records:** first-class CRM document library entries.
- **Tile PDFs:** legacy or tile-based PDF files surfaced from landing page/tile context when the document list includes tile PDFs.

Support should distinguish these because a tile PDF may link back to a landing page, place, or tile rather than a normal document detail record.

## Where Documents Appear

Documents can be opened from:

- Organization document library.
- Customer detail document tab.
- Project document tab.
- Event detail context.
- Protocol details where a document was attached.
- Source links such as landing page PDF tile context.

If a file appears in one place but not another, check which entity it is linked to.

## Creating And Editing Documents

Users with document edit permission can create documents by uploading a file and assigning metadata.

Common editable relationships:

- Customer.
- Project.
- Event.
- Tags.
- Assigned users.
- Assigned customers.

Changing a document's links can affect where it appears. For example, removing the project link can remove it from the project document tab while the document remains in the organization library.

## Documents And Protocols

Protocols can include file attachments. Those files can show up as related document context depending on how they were stored and linked.

Use this relationship when investigating:

- Meeting notes with attached PDFs.
- Contracts attached to a call protocol.
- Event or project documents referenced from an interaction.
- Files that appear in a document detail page with protocol references.

## Documents And Projects

Project documents keep delivery artifacts in one place. Common examples:

- Proposals.
- Agreements.
- Schedules.
- Sponsor assets.
- Floor plans.
- Project briefs.
- Post-event reports.

Project document visibility still depends on `document` permissions, even if the user can open the project.

## Documents And Events

Event-linked documents can support attendee operations, internal planning, or guest-facing materials. For example:

- Name label templates.
- Event programs.
- Ticketing instructions.
- Speaker files.
- Venue documents.
- Internal run sheets.

Support should check whether the document is linked to the event itself, the project behind the event, a customer, or a protocol.

## Permissions

Document navigation appears when the user can list or read documents. Creating, editing, deleting, and assigning documents depend on `document` permissions.

Document access may also be limited by assigned-only scope. In that case, a user may only see documents assigned to them, assigned to their customer/member context, or linked through records they are allowed to access.

## Common Support Scenarios

### A document is missing

Check:

1. Active organization.
2. Document permissions.
3. Assigned-only document scope.
4. Whether the user is in the organization library or a filtered customer/project/event tab.
5. Search and tag filters.
6. Whether the file is a tile PDF rather than a first-class document.

### A document appears under the wrong source

Check the document's customer, project, event, and protocol relationships. The source label often reflects the most specific relationship the list can resolve.

### A user cannot upload or edit documents

Check `document` edit permission and whether the user is blocked or limited by assigned-only scope.

### A tile PDF cannot be edited like a normal document

Tile PDFs originate from landing page/tile context. Open the related landing page, tile, place, or PDF tile configuration if the source points there.

**Related concepts:** [Customers](./customers), [Events](./events).

---

# Newsletters

URL: https://docs.scoutello.com/dashboard/customer-management/newsletters
Source: docs/dashboard/customer-management/newsletters.md
Description: Segmented email campaigns integrated with CRM datasets.

**Newsletters** let organizations manage CRM-connected audience lists and campaign communication. They reuse contacts, subscribers, assignments, contact forms, and event context so teams do not need brittle one-off CSV exports for every send.

Route: `/organizations/:id/newsletters`

Newsletter detail route: `/organizations/:id/newsletters/:newsletterId`

## What A Newsletter Represents

A newsletter is an organization-scoped list or communication audience. It can be used for marketing campaigns, operational updates, event communication, hospitality messaging, member updates, or community announcements.

Newsletter records can include:

- **Name:** internal newsletter name.
- **Display name:** optional public-facing or friendly name.
- **Organization:** owning organization.
- **Created by:** user who created it.
- **Subscribers:** customer records subscribed to the newsletter.
- **Assigned customers:** contacts connected to or responsible for the newsletter.
- **Events:** events related to this newsletter audience.
- **Contact forms:** forms that add or collect subscribers.
- **Tile:** guest-facing newsletter tile context where configured.

## Subscribers

Newsletter subscribers connect a customer to a newsletter.

Subscriber fields include:

- Customer.
- Subscribed date.
- Unsubscribed date.
- Status.
- Verification state.
- Related mails.

Common statuses are operational and may depend on the subscription flow. A subscriber can be pending, active/verified, unsubscribed, or otherwise tracked depending on implementation and campaign setup.

If support is investigating why a person received or did not receive a newsletter, start from the customer record and check the newsletter subscription tab/context.

## List View

The newsletter list shows:

- Name.
- Subscriber count.
- Created date.
- Created by, where relevant.

The list also supports search and **Show only assigned** filtering.

## Creating Newsletters

Users with newsletter edit permission can create newsletters from the newsletter overview. After creation, the dashboard opens the newsletter detail page.

Customers can also be added to newsletters from customer quick actions, depending on customer type and permissions.

## How Newsletters Connect To CRM

Newsletters are tied to CRM in several ways:

- Customers become subscribers.
- Customer records show newsletter subscription state.
- Contact forms can collect or assign subscribers.
- Events can reference newsletters for attendee or audience communication.
- Assigned customers can make newsletter visibility match team ownership.
- Sent mails can help support investigate what communication went out.

This makes newsletters different from a detached mailing tool: subscriber context stays close to customer history, events, and operational work.

## Typical Uses

- Pre-arrival hotel or hospitality updates.
- Event invitation, reminder, and follow-up communication.
- Association member newsletters.
- Partner or sponsor communication.
- Destination or community announcements.
- Segmented operational campaigns based on tags, assignments, or CRM categories.

## Permissions

Newsletter navigation appears when the user can list or read newsletters. Creating and editing newsletters usually requires newsletter edit permission. Deleting depends on newsletter delete permission, creator/admin status, and organization context.

Assigned-only filtering can limit visible newsletters to those assigned to the user's customer/member context.

## Common Support Scenarios

### A newsletter is missing from the list

Check active organization, newsletter permissions, assigned-only filter, search text, and whether the newsletter belongs to a different organization.

### A customer is missing from a newsletter

Check whether the customer is subscribed to that newsletter, whether they unsubscribed, whether verification is required, and whether the customer was added to a different organization's newsletter.

### A user cannot create newsletters

Check `newsletter` edit permission and whether the user is blocked.

### A subscriber received unexpected communication

Check the newsletter subscriber relationship, related mails, event links, contact form source, and whether the customer exists more than once across organizations.

**Related concepts:** [Email](./email), [Customers](./customers).

---

# Email

URL: https://docs.scoutello.com/dashboard/customer-management/email
Source: docs/dashboard/customer-management/email.md
Description: Organization inbox, archival views, spam handling, and outbound history.

Dashboard **Email** brings shared communication into the same workspace as customers, tasks, protocols, projects, newsletters, and events.

Routes:

- Inbox: `/organizations/:id/inbox`
- Archive: `/organizations/:id/inbox/archive`
- Spam: `/organizations/:id/inbox/spam`
- Sent emails: `/organizations/:id/sent-emails`

Unread counters can surface directly on the parent email nav item. The badge combines inbound unread counts and sent email bounce/unread indicators where configured.

## Email Views

### Inbox

The inbox shows inbound messages tied to organization-managed email addresses. Inbound messages can include sender metadata, recipients, subject, date, attachments, tags, status, spam state, customer link, responsible customer link, and project link.

Use the inbox for open messages that still need attention.

### Archive

The archive stores messages that were deliberately closed or no longer need the main inbox workflow. Archived messages are not deleted; they are moved out of the active inbox view.

Use archive checks when a user says a message disappeared after being handled.

### Spam

The spam view contains messages marked as spam or classified as suspicious. Spam messages may not appear in the normal inbox.

Use spam checks when a message was expected but is missing from the inbox.

### Sent Emails

Sent emails show outbound messages. This is important for troubleshooting:

- Whether a message was sent.
- Which sender was used.
- Whether a bounce or delivery issue is visible.
- Which customer, project, event, newsletter, or operational flow generated the message.

## Inbound Email Context

Inbound email records can store:

- Organization.
- Recipient scope.
- Recipient member customer for personal-scope mail.
- Message ID.
- From address and display name.
- To and CC addresses.
- Subject.
- Date.
- Forwarding metadata.
- Optional reference to **raw message storage** (when retained for troubleshooting).
- Attachment metadata.
- Status (`unread`, `read`, `archived`).
- Spam flag.
- Tags.
- Customer link.
- Responsible customer link.
- Project link.

Support should check these fields when a message appears under the wrong customer, project, or inbox section.

## Organization Vs Personal Recipient Scope

Inbound email can be scoped to the organization or to a personal recipient member customer.

- **Organization scope:** shared organization inbox behavior.
- **Personal scope:** message visibility can depend on the recipient member customer, plus admin/permission rules.

If one user can see an email and another cannot, check recipient scope, responsible customer, active organization, and email permissions.

## Email And Customers

Inbound messages can be matched to customers. Customer detail pages can show email context, so support can investigate correspondence without leaving the CRM record.

When a message does not appear on a customer:

1. Confirm the sender/recipient email matches the expected customer.
2. Check whether the customer link exists.
3. Check whether the message is archived or spam.
4. Check whether the user has email permission and customer permission.
5. Check whether the record is in the expected organization.

## Email And Projects

Inbound and outbound messages can be linked to projects. Project mail tabs help teams keep delivery communication beside milestones, tasks, documents, events, and protocols.

If a project email is missing, check the project link on the email and whether the user has both project and email access.

## Outbound Sender Context

Some customer/member records can have email sender configuration such as contact email, local sender part, or signature. This supports managed subdomain or custom-domain sending behavior where configured.

When investigating sender issues, check:

- The active organization.
- The sender customer/member.
- Contact email and local sender settings.
- Whether the message was sent from a project, customer, newsletter, event, or other workflow.
- Bounce or unread-bounced indicators in sent email views.

## Permissions

Email navigation appears when the user can list or read email. Actions and row visibility depend on `email` permissions, recipient scope, active organization, customer/project visibility, and admin status.

Email can also be affected by customer permissions because matched messages often rely on customer context.

## Common Support Scenarios

### A message is missing

Check inbox, archive, spam, active organization, email permissions, recipient scope, customer link, project link, and search/filter state.

### A message appears under the wrong customer

Check the sender address, original forwarded sender metadata, customer link, and whether duplicate customer records exist across organizations.

### One user sees an email and another does not

Check email permission scope, personal recipient scope, responsible customer linkage, and assigned-only customer/project context.

### A sent email needs verification

Open sent emails and check sender, recipient, subject, date, related entity, and bounce/unread indicators.

**Related concepts:** [Newsletters](./newsletters), [Mail templates](../settings/mail-templates).

---

# Organization events

URL: https://docs.scoutello.com/dashboard/customer-management/events
Source: docs/dashboard/customer-management/events.md
Description: Tenant-scoped events list and deep configuration.

`/organizations/:id/events` covers event lifecycle management for the active organization. In the CRM context, events are not just calendar entries; they connect contacts, participants, invitations, ticketing, documents, newsletters, projects, landing experiences, and attendee operations.

Platform administrators who work across organizations may use additional global event tools in the dashboard. This page focuses on organization events inside the customer management sidebar.

## What Organization Events Are For

Use organization events when the team needs to manage a program, gathering, conference, workshop, hospitality experience, member event, or internal/external activity with operational follow-up.

An event can combine:

- Organization ownership.
- Created/responsible users.
- Names and descriptions.
- Languages.
- Dates.
- Place and address.
- Tags.
- Landing page link.
- Event lobby and participant groups.
- Invitations and participant states.
- Registration limits and acceptance settings.
- Name label settings.
- Ticketing and payment-related configuration.
- Newsletter link.
- Project link.
- Customer assignments.
- Event documents.

## CRM Connections

Organization events connect to CRM through several relationships:

- **Assigned customers:** contacts assigned to the event.
- **Event participants:** attendee records that can link back to customers.
- **Projects:** an event can be linked to a project for planning and delivery.
- **Newsletters:** an event can connect to a newsletter audience.
- **Documents:** event files stay near the event.
- **Mail templates and sent emails:** communication and invitation flows can be investigated from event and email contexts.
- **Landing pages:** events can link to guest-facing event experiences.

This means support should check both the event and the customer record when troubleshooting attendance, invitations, ticketing, communication, or follow-up.

## Event Participants And Customers

Event participants represent participation in a specific event/group. Customers represent the CRM contact record.

A participant can link to a customer. This link is important because:

- Attendance and check-in history can become part of customer context.
- The same customer can participate in multiple events.
- Customer data can support name labels, communication, and follow-up.
- Event operations can feed CRM tasks and protocols after the event.

If an attendee appears in an event but not in customer CRM context, check whether the participant is linked to a customer.

## Event Projects

Events can be linked to projects. Use this when the event is part of a larger initiative with milestones, documents, tasks, protocols, participants, and mails.

Examples:

- A multi-session conference project with separate event entries.
- A sponsor activation project that includes several hospitality events.
- A member onboarding project that includes private events and follow-up tasks.

Project linking is separate from customer assignment. A customer can be assigned to an event without the event being part of a project, and a project can contain events without every event participant being a project participant.

## Newsletters And Event Communication

Events can link to newsletters and mail workflows. This supports pre-event, onsite, and post-event communication while keeping CRM context intact.

Support checks:

- Which newsletter is linked to the event?
- Which customers are subscribed to the newsletter?
- Which sent emails were generated?
- Are participants in the correct event participant group?
- Are invitation or registration settings limiting who can participate?

## Ticketing And Admission Context

Events can include ticketing, ticket types, payment status, participant groups, check-in, wallet passes, registration limits, and acceptance rules.

CRM support often needs to distinguish:

- Customer record.
- Event participant record.
- Ticket purchase/order state.
- Invitation state.
- Check-in state.
- Payment or refund state.

For detailed ticketing behavior, cross-check the product event docs and your **finance or commercial** documentation where relevant.

## Permissions

Organization event workflows stay scoped to the active organization and its event permissions. Event navigation appears when the user can list or read events, or when the user is a guide in the organization. Creating, editing, ticketing configuration, participant management, widgets, and mail template actions depend on event-related permissions and role setup.

If the events link is missing, check `event` list/read permissions and whether the user is a guide assigned to organization tours/events.

## Common Support Scenarios

### A user cannot see organization events

Check active organization, event permissions, guide status, and whether the user is in the correct organization workspace.

### A customer is not visible on an event

Check assigned customers, event participants, participant groups, and whether the participant is linked to the customer record.

### An event is missing from a project

Check the event's project link. Event assignment and project linking are separate.

### An invitation or registration behaves unexpectedly

Check accept-only-invited, registration limit, accept limit, request-acceptance-only, participant group requirements, and ticketing configuration.

### Event communication is hard to trace

Check event newsletter, sent emails, mail templates, customer subscriptions, participant groups, and the customer email tab.

**Related concepts:** [Product: events](../../product/events), [Widgets](../settings/widgets).

---

# Web apps & tours — overview

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/overview
Source: docs/dashboard/web-apps-and-tours/overview.md
Description: Guest experiences, analytics, and authoring tools grouped in the sidebar.

The **Web apps and tours** category is where operators build and maintain guest-facing browser experiences. It combines performance analytics, landing page authoring, tour authoring, reusable location data, offers, contact forms, site plans, questions, galleries, and FAQs.

Most items require `landing-page`, `tour`, or related permissions. **Analytics** can also appear for assigned **tour guides** so field staff can review performance without becoming full administrators.

**Landing pages versus tiles:** A **landing page** is the published guest shell; **tiles** are ordered modules editors attach (calendars, chats, quizzes, nested mini-apps). Product terminology and tile-by-tile notes live in [/product/landing-pages-and-tiles](/product/landing-pages-and-tiles).

## Sidebar map

| Area | Typical route | Permission signal |
| --- | --- | --- |
| Analytics | `/organizations/:id/analytics` | Landing page, tour, or guide assignment. |
| Landing pages | `/organizations/:id/landing-pages` | `landing-page:list` or `landing-page:read`. |
| Tours | `/organizations/:id/tours` | `tour:list`, `tour:read`, or guide assignment. |
| Places / place groups | `/organizations/:id/places`, `/organizations/:id/place-groups` | Tour or landing-page visibility. |
| Offers | `/organizations/:id/offers` | `offer:list` or `offer:read`. |
| Contact forms | `/organizations/:id/contactforms` | `contactform:list` or `contactform:read`. |
| Site plans | `/organizations/:id/siteplans` | `landing-page:list` or `landing-page:read`. |
| Questions | `/organizations/:id/questions` | `landing-page:list` or `landing-page:read`. |
| Gallery | `/organizations/:id/gallery` | Shown for typical **Web apps and tours** users even when some other rows require explicit `landing-page` or `tour` scopes; if the link is missing, check organization context and blocking state. |
| FAQs | `/organizations/:id/faqs` | `landing-page:list` or `landing-page:read`. |

## Operational model

Treat this group as one toolbox:

- **Landing pages** publish the guest web app.
- **Tiles** decide what guests can open or do inside that web app.
- **Tours** provide structured routes, stops, audio, and guide flows.
- **Places, place groups, and site plans** supply reusable maps and orientation content.
- **Offers, contact forms, questions, FAQs, and galleries** feed modules landing pages surface.
- **Analytics** shows adoption and engagement.

When troubleshooting, start from the guest-facing symptom and walk backward through publishing state, tile configuration, linked records, and permissions.

**Related concepts:** [Landing pages](./landing-pages), [Tile reference](./tile-reference).

---

# Overview analytics

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/analytics
Source: docs/dashboard/web-apps-and-tours/analytics.md
Description: Organization-level performance snapshot for permitted roles.

`/organizations/:id/analytics` surfaces organization-level performance reporting for guest experiences. The dashboard exposes this link when the current user can read/list landing pages or tours, or when the user is assigned as a guide in the organization.

## What To Use It For

Use analytics to understand whether guest-facing content is working:

- Which landing pages, tours, or related experiences are receiving attention?
- Are guests reaching important tiles, routes, or conversion points?
- Do guide or tour workflows show enough activity to justify follow-up?
- Should an event, hospitality, destination, or campaign team update content before launch?

Analytics is a starting point for operational decisions. For detailed debugging, open the underlying landing page, tour, tile, event, or widget record that produced the activity.

## Access Model

Analytics is intentionally broader than full authoring in some cases. A guide assigned to tours may see the analytics entry even without full landing page or tour editing rights. This lets field staff inspect performance without giving them complete organization administration.

If the link is missing, check the user's active organization and permissions for `landing-page` and `tour`, then confirm whether they are **assigned as tour guides** for that organization.

## Support Notes

When numbers do not match stakeholder expectations, clarify the question before treating it as a bug:

- Are they asking about page visits, tile clicks, tour starts, purchases, or form submissions?
- Which time window and organization are they comparing?
- Did the guest enter through a landing page, widget, direct tour link, or short link?
- Was the content recently duplicated, unpublished, or moved between organizations?

**Related concepts:** [Landing pages](./landing-pages), [Tours](./tours).

---

# Landing pages

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/landing-pages
Source: docs/dashboard/web-apps-and-tours/landing-pages.md
Description: Dashboard workflow for authoring, publishing, nesting, and sharing guest web apps.

Landing pages (guest **web apps**) are authored from the dashboard—either from an organization-scoped list or global overview screens when your role permits. Editors configure shell settings, multilingual copy, visuals, domains or slugs, tile ordering, and optional assistant tooling.

## Permissions

Landing page work requires organization-level permissions summarized in [/reference/permissions](/reference/permissions). Guides might see analytics without edit rights; hidden routes usually mean the session lacks the backing permission—not that the feature vanished.

## Typical workflow

### 1. Create or duplicate

Create a fresh shell or duplicate an existing landing page when campaigns repeat structure.

### 2. Build the tile grid

Open the landing editor, add modules from the tile picker, and reorder them until the story reads correctly on mobile. Refer to [/reference/tile-types](/reference/tile-types) when comparing choices.

### 3. Configure each tile

Deep-link into each tile's form to attach backing records—events views, tours, galleries, chatrooms, and similar. Respect allowed sizes; mismatched historical sizes should be corrected so previews match guest runtime.

### 4. Scheduling, activity, and restrictions

Many tiles support visibility windows, activity modes (always available versus timed), and optional geo or network restrictions described in [/product/landing-pages-and-tiles/layout-sizing-and-visibility](/product/landing-pages-and-tiles/layout-sizing-and-visibility).

### 5. Nested landing experiences

**Landing page** tiles can link to another landing page for hierarchical navigation (overview → detail sections). Confirm tenancy and branding rules before cross-linking experiences owned by different teams.

### 6. Preview and publish

Use dashboard previews or embed snippets to validate translations, imagery, media-heavy tiles, and moderation-sensitive modules before distributing QR codes broadly.

## Operational tasks

### Analytics

Organization analytics surfaces complement [/dashboard/web-apps-and-tours/analytics](/dashboard/web-apps-and-tours/analytics).

### Assistant authoring

When AI drafting assistants appear, treat suggestions as **drafts**—verify facts, accessibility, moderation policy, and multilingual completeness before publishing.

## Troubleshooting

| Symptom | Check |
| --- | --- |
| Tile missing for guests despite appearing active | Schedule windows, inactive overlays, organization restrictions. |
| Unexpected layout | Tile size versus embedded expectations—re-save with supported sizing. |
| Map modules centered incorrectly | Saved map viewport or filter defaults inside the tile configuration. |
| Nested navigation loops | Linked landing page accidentally points back to its parent. |

Escalate cross-tenant concerns through your internal support process.

**Related concepts:** [Tile reference](./tile-reference), [Site plans](./site-plans), [Gallery](./gallery), [Offers](./offers), [Product hub](/product/landing-pages-and-tiles).

---

# Tile reference

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/tile-reference
Source: docs/dashboard/web-apps-and-tours/tile-reference.md
Description: Dashboard-side guide to selecting, sizing, and operationalizing landing page tiles.

Tiles are created per landing page using the dashboard **tile editor**. Allowed tile kinds, labels, categories, and sizes stay aligned with the catalog described in [/reference/tile-types](/reference/tile-types).

## Catalog concepts

| Concept | Meaning |
| --- | --- |
| **Type** | Machine name persisted with the tile—select from the picker. |
| **Label** | Operator-friendly name shown in authoring tools (localized where applicable). |
| **Category** | UX grouping such as basic, tour-centric, or advanced—helps teams browse quickly. |
| **Sizes** | `small`, `medium`, `large`, or `embedded`, depending on what the tile supports. |
| **Navigation helper** | Some tiles compute default links for card-sized modules (external URLs, exploration screens, tours, etc.). |

If historical data contains an unusual size, the guest runtime may coerce layout—re-save with an allowed size to avoid confusion.

## Embedded versus routed tiles

- **Embedded** tiles render inline on the landing grid when the tile supports that mode.
- **Card sizes** typically navigate into focused guest screens or curated exploration views.

Train operators with a simple rule: **embedded stays on the landing page**, **card sizes open the wider guest shell**.

## Common tile settings

Many tiles share optional controls such as:

- **Schedule windows** controlling when a tile appears.
- **Activity states** (always on, closed messaging, time-based availability).
- **Visual styling** options where product design exposes them.
- **Geo or audience restrictions** on qualifying tile kinds—see [/product/landing-pages-and-tiles/layout-sizing-and-visibility](/product/landing-pages-and-tiles/layout-sizing-and-visibility).

Commercial guarantees about locks such as sponsor PDF geo-fencing still belong in contracts—not inferred solely from technical capability lists.

## Type-specific notes

Deep playbooks live under [/product/landing-pages-and-tiles](/product/landing-pages-and-tiles) in the **Tiles** section. Use those pages when guests report nuanced runtime behavior.

At a glance:

| Tile family | Dashboard focus |
| --- | --- |
| Text | Rich content blocks and styling. |
| External URL | Validate destinations and embedding policies. |
| PDF | Link uploads; confirm translations toggles when locales matter. |
| Nested landing | Pick child landing experiences and thumbnails; watch geo policies when applied. |
| Tour | Bind published tours; optional shortcuts that skip detail screens. |
| Members | Ordered profiles with optional grouping tags. |
| Chatroom | Moderation posture—anonymous posting, reactions, retention. |
| Stop recommendations | Map/list defaults and pinned highlights. |
| Events | Own versus curated feeds; embedded versus navigational behavior. |
| Offers | Pinned promotions versus broad catalogs. |
| Voting | Embedding-only modules—ensure voting content is published. |
| Networking | Dating versus networking modes, profile gates, discovery windows. |
| Media gallery | Upload moderation, camera-only policies, optional geo locks. |
| Flash screens, quizzes, and specialty tiles | Each product page lists prerequisites. |

## Duplicate workflows

Copying complex tiles speeds up campaigns. After duplication, scrub **moderation text**, **legal copy**, **secrets**, or **raffle rules** so clones do not inherit stale compliance language.

## When to escalate

- Suspected abuse spanning organizations (phishing links, illicit uploads) → follow your organization's security escalation policy.
- Payment or tour anomalies → [/product/tours/support-playbook](/product/tours/support-playbook).

**Related concepts:** [Landing pages](./landing-pages), [Reference tile types](/reference/tile-types), [Product landing pages hub](/product/landing-pages-and-tiles).

---

# Tours

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/tours
Source: docs/dashboard/web-apps-and-tours/tours.md
Description: Operational guide for the organization tours list, creation, editing, routes, site plans, commerce, duplication, analytics, and guides.

**Where to find it:** **Web apps and tours → Tours** under the active organization.

Access requires **landing page** and/or **tour** visibility (list or read), or appropriate **guide** assignments where your workspace grants partial navigation.

See [/product/tours](/product/tours) for conceptual depth.

## List experience

The table shows preview imagery, name, creator presentation (person or organization), tour type, stop count, visibility (public or private), and created date.

**Actions:**

- **Create** opens the guided setup flow when permissions allow.
- **Visit** opens the guest tour using the dashboard link intended for demos—often with virtual touring-friendly defaults.
- **Duplicate** copies structure for safe experimentation.
- **Delete** appears only when policy permits—typically for creators or organization admins.

**Filters:** Some teams narrow the list to tours tied to **assigned contacts**; toggle reflects personal preference when available.

## Creation flow

Provide a name, pick **outdoor**, **indoor**, or **fixed**, optionally attach a starter document when beta ingestion is enabled, and assign contacts when assignments drive visibility.

After creation you land in the **tour editor**.

## Detail editor

Canonical field explanations live in [/product/tours/tour-authoring](/product/tours/tour-authoring). Operators usually work through:

### Metadata and monetization

Visibility, multilingual descriptions, pricing tier when payments are configured, linked landing page, CRM assignments, indoor overview behavior, meeting geography, narrative introduction and closing blocks, and optional **end screen** modules.

### Route and itinerary

1. Confirm stop ordering matches the story arc.
2. For outdoor tours, verify preview maps and directions after substantive edits; adjust illustrative transition paths when marketing wants stylized segments.
3. For indoor tours, open the **site plan** attachment and pin library stops or craft new ones on floor imagery.
4. Manage per-stop options such as radius, optional placement, or hiding steps from guest numbering.

### Sharing and assistants

Sharing surfaces typically unlock once enough stops exist to preview meaningfully.

Where **assistant** features are enabled, upload curated reference snippets so guest answers stay aligned with published content.

### Analytics

Use in-product analytics tabs for run counts, funnel views, and qualitative signals—definitions follow whatever date ranges the dashboard exposes.

## Permissions snapshot

Effective tour capabilities combine tour scopes with guide-oriented allowances similar to events. When unsure, follow [/product/tours/support-playbook](/product/tours/support-playbook).

## Common dashboard mistakes

| Symptom | What to try |
| -------- | ----------- |
| Paid tier selector disabled | Finish organization **payments** onboarding. |
| Indoor site plan missing after type changes | Re-open the route editor and save site-plan data so attachments reconnect. |
| Outdoor directions look stale | Make a small legitimate edit and save to refresh routing previews. |

**Related:** [Places and place groups](/dashboard/web-apps-and-tours/places-and-place-groups), [Site plans](/dashboard/web-apps-and-tours/site-plans), [Offers](/dashboard/web-apps-and-tours/offers), [Analytics overview](/dashboard/web-apps-and-tours/analytics), [Tile reference](/dashboard/web-apps-and-tours/tile-reference).

---

# Places & place groups

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/places-and-place-groups
Source: docs/dashboard/web-apps-and-tours/places-and-place-groups.md
Description: Canonical locations for maps, recommendations, tours, and events views.

**Places** are reusable location records for maps, recommendations, tours, landing pages, and events. **Place groups** bundle related places so operators can present or manage them as a set.

The dashboard exposes `/organizations/:id/places` and `/organizations/:id/place-groups` when the user has relevant tour or landing page visibility. Places can also appear in admin-level POI and country tooling, but this page focuses on organization authoring.

## Places

A place should represent a real location that can be reused across guest experiences. Depending on the use case, it may include an address, coordinates, description, media, tags, and operational metadata.

Examples:

- A hotel, restaurant, meeting point, booth, stage, museum room, or attraction.
- A tour stop or recommendation.
- A sponsor or partner location.
- A venue area guests need to find during an event.

## Place Groups

Place groups are useful when the guest or operator thinks in collections:

- Partner restaurants near a venue.
- Conference stages.
- Recommended stops for a neighborhood route.
- Shops, exhibitors, or service points grouped by category.

Groups help tiles and tours avoid duplicating location selections. Update the group when the collection changes, then check any page or tile that depends on it.

## Operational Checks

Before using a place in a guest experience:

1. Verify the coordinate and address are accurate.
2. Confirm the name is guest-friendly and translated when needed.
3. Check whether the place belongs to the active organization or should be global/admin-managed.
4. Test map and list presentation from the guest web app.
5. Keep closed, temporary, or seasonal places out of evergreen pages.

**Related concepts:** [Site plans](./site-plans), [Tile types: stop/places](../../reference/tile-types).

---

# Offers

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/offers
Source: docs/dashboard/web-apps-and-tours/offers.md
Description: Structured promotions surfaced to guests through tiles and explore views.

Offers power structured promotions that guests can discover through landing pages, tiles, tours, and explore-style views. The dashboard route is `/organizations/:id/offers`, visible to users with `offer:list` or `offer:read` permission.

Use offers when a promotion needs more structure than plain text: a title, description, redemption instructions, availability, partner/location context, and multilingual guest-facing copy.

## Common Uses

- Hospitality packages, restaurant specials, or bar promotions.
- Event partner deals and sponsor activations.
- Destination partner offers for attractions, shops, or tours.
- Post-tour or end-screen recommendations.
- Member or community benefits.

## Authoring Checklist

Before publishing an offer:

1. Confirm the offer belongs to the right organization.
2. Add clear redemption instructions and any time restrictions.
3. Link the offer to relevant places, landing pages, tours, or tiles when needed.
4. Provide translated copy for guest-facing languages.
5. Confirm whether the offer should appear broadly or only through a specific tile/page.

## Support Notes

If guests cannot find an offer, check whether the offer itself is active and whether the landing page or tile is configured to surface it. If redemption fails, distinguish between Scoutello content issues and partner-side policy, inventory, or staff training issues.

**Related concepts:** [Tile types: offers](../../reference/tile-types).

---

# Contact forms

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/contact-forms
Source: docs/dashboard/web-apps-and-tours/contact-forms.md
Description: Lead capture flows feeding CRM or messaging handoffs.

**Contact forms** let organizations gather structured inquiries from guest web apps and turn them into operational follow-up. The dashboard route is `/organizations/:id/contactforms`, exposed when the role can list or read `contactform`.

Contact forms are most useful when a guest action should not disappear into a generic inbox. They can capture leads, support requests, booking questions, partner inquiries, or campaign-specific submissions and then guide the team toward CRM, newsletter, email, or task follow-up.

## Common Uses

- Request information from a hotel, venue, guide, association, or destination team.
- Capture sponsor, exhibitor, or partner leads during events.
- Let guests ask support questions from a landing page without leaving the mobile experience.
- Create campaign-specific forms that can be linked from contact form tiles.

## Authoring Checklist

Before publishing a form:

1. Confirm the form belongs to the intended organization.
2. Use clear field labels and mark only truly required fields as required.
3. Provide multilingual labels when the form is used in multilingual guest experiences.
4. Test the form from the guest route or tile, not only from the dashboard editor.
5. Decide how submissions will be triaged: CRM customer follow-up, inbox, newsletter audience, or manual export.

## Troubleshooting

If submissions arrive incomplete, check the field schema, required flags, and translated labels. If spam increases, escalate to the organization's moderation or anti-abuse policy and confirm whether additional rate limiting or CAPTCHA behavior is needed.

**Related concepts:** [Customers](../customer-management/customers).

---

# Site plans

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/site-plans
Source: docs/dashboard/web-apps-and-tours/site-plans.md
Description: Indoor layouts used by hospitality, fairs, museums, or complex venues.

**Site plans** provide image-backed or layout-based orientation for complex venues. They are managed at `/organizations/:id/siteplans` and can be surfaced to guests through the `sitePlan` tile.

Use site plans when a normal map is not enough: indoor venues, hotels, exhibitions, fairs, museums, conference floors, campuses, or multi-zone destinations.

## What Site Plans Solve

Site plans help guests answer:

- Where am I in this venue?
- Where is a room, booth, stage, reception, restaurant, or service point?
- Which area belongs to this event, tour, or hospitality experience?
- How do I orient myself when GPS is not reliable indoors?

They also help operators keep venue orientation consistent across landing pages, tours, and event experiences.

## Authoring Workflow

1. Upload or select the floor plan or orientation image.
2. Add or connect relevant places, stops, zones, or points of interest.
3. Check labels and translations for guest-facing languages.
4. Link the site plan from a landing page tile or tour context.
5. Test on a mobile screen before printing QR codes or launching an event.

## Support Notes

If a site plan appears wrong in the guest app, first check whether the correct plan is attached to the tile or tour. Then verify the underlying image, point placement, and organization. For indoor tours, also confirm whether the tour route editor uses the intended site plan.

**Related concepts:** [Destinations use case](../../use-cases/destinations), [Tile types](../../reference/tile-types).

---

# Questions, feedback & FAQs

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/questions-feedback-faqs
Source: docs/dashboard/web-apps-and-tours/questions-feedback-faqs.md
Description: Surveys, help content, and knowledge-style prompts for guests.

This cluster covers guest-facing **Questions**, **Feedback**, and **FAQs**. The dashboard exposes `/organizations/:id/questions` and `/organizations/:id/faqs` when the user has landing page visibility.

Use these tools when an organization wants to collect structured input or provide answers inside the same browser-based guest experience.

## Questions And Feedback

Questions are useful for prompts, surveys, lightweight feedback, or moderated input connected to a campaign, event, tour, or landing page. They can support operational decisions, satisfaction checks, or content improvement.

Good examples:

- Ask attendees which session was most useful.
- Collect questions for a speaker or organizer.
- Capture guest satisfaction after a hospitality experience.
- Ask visitors what information was missing from a destination page.

## FAQs

FAQs are for recurring answers that should be available before guests contact support. They work well when paired with landing pages, event pages, tour instructions, or hospitality guest apps.

Good FAQ topics:

- Arrival, check-in, and opening hours.
- Ticketing, access, and refunds.
- Accessibility and venue rules.
- Contact points and emergency information.
- Tour preparation, language, and device requirements.

## Operational Checks

Before publishing:

1. Confirm the content is attached to the intended landing page or tile.
2. Keep question prompts short and unambiguous.
3. Translate guest-facing prompts and answers.
4. Decide who reviews responses and how often.
5. Remove outdated answers after the campaign or event ends.

## Support Notes

If guests still ask the same question repeatedly, add or clarify the FAQ rather than relying on manual replies. If feedback is sensitive, define who is allowed to export, process, or respond to it.

**Related concepts:** [Tile types](../../reference/tile-types).

---

# Gallery

URL: https://docs.scoutello.com/dashboard/web-apps-and-tours/gallery
Source: docs/dashboard/web-apps-and-tours/gallery.md
Description: Media collections reusable across landing pages and tours.

**Gallery** maintains curated media collections for an organization. The route is `/organizations/:id/gallery`, and the sidebar includes it in the Web apps & tours group so teams can manage shared visual assets near the guest experiences that use them.

Use the gallery for reusable photos and media that support landing pages, tours, events, destinations, hospitality experiences, and tile content. A good gallery makes guest-facing pages easier to update because operators do not need to re-upload the same visual context for every campaign.

## What Belongs Here

Good gallery candidates include:

- Venue, room, booth, exhibition, or property photos.
- Destination highlights and partner visuals.
- Event atmosphere images.
- Tour stop or itinerary imagery.
- Visual assets reused by media gallery tiles, landing pages, or support material.

Avoid using the gallery as an unreviewed dump of every uploaded file. Guest-facing media should be accurate, properly licensed, and appropriate for the organization's brand.

## Operational Checks

Before connecting gallery assets to landing pages or tiles:

1. Confirm the media belongs to the active organization.
2. Check image quality on mobile screens.
3. Verify rights, privacy, and consent for people or protected locations shown in the media.
4. Use descriptive names so support can find the asset later.
5. Remove outdated event or offer imagery after the campaign ends.

## Related Guest Experience

Gallery assets often become part of media gallery tiles, landing page sections, tour stop context, or printed/QR promotion material. If a guest reports missing or outdated imagery, inspect both the gallery item and the page or tile that references it.

**Related concepts:** [Tile types: media gallery](../../reference/tile-types).

---

# Settings overview

URL: https://docs.scoutello.com/dashboard/settings/overview
Source: docs/dashboard/settings/overview.md
Description: Commerce integrations, messaging assets, hierarchy, and platform-only surfaces.

The **Settings** grouping contains organization-level tools that affect billing, event communication, embedded booking or engagement flows, and access management. These pages live under `/organizations/:id/*` and appear according to the current user's role and permissions.

In the dashboard sidebar the settings group can expose:

| Area | Route | Visibility |
| --- | --- | --- |
| Orders | `/organizations/:id/orders` | Always part of the Settings group for the active organization. |
| Mail templates | `/organizations/:id/mail-templates` | Requires event list or read permission. |
| Widgets | `/organizations/:id/widgets` | Requires event list or read permission. |
| Child organizations | `/organizations/:id/organizations` | Requires organization **admin** entity permissions (see [permissions reference](/reference/permissions)). |
| Roles | `/organizations/:id/roles` | Same as child organizations. |
| Promotion material | `/organizations/:id/promotion-material` | **Scoutello platform staff** accounts only (cross-tenant), not normal customer users. |
| Invoices | `/organizations/:id/invoices` | **Scoutello platform staff** accounts only (cross-tenant), not normal customer users. |

## How To Use This Section

Use Settings when the question is not about day-to-day CRM records, but about how the organization operates Scoutello itself:

- **Commercial follow-up:** orders and invoices help reconcile purchases, ticket sales, tour access, refunds, and billing conversations.
- **Event communication setup:** mail templates define reusable branded layouts for confirmations, reminders, and manual sends.
- **External entry points:** widgets package selected Scoutello experiences so they can be embedded on partner or customer websites.
- **Hierarchy and access:** child organizations and roles define which teams can see or edit records in multi-location or multi-brand setups.
- **Platform operations:** promotion material and invoices are shortcuts for Scoutello staff, not normal customer-facing settings.

## Support Checks

If a user cannot see a settings item, first confirm the active organization and the permission scope behind the sidebar entry. A missing route is usually intentional: the dashboard hides links that the session should not invoke.

For event-related settings, check whether the role includes `event:list` or `event:read`. For hierarchy and role management, check for **`admin` entity** permissions in the organization role. For promotion material and invoices, confirm whether the signed-in person is a **Scoutello platform staff** user, not only an organization admin.

**Related concepts:** [Permissions](../../product/permissions-and-organizations).

---

# Orders

URL: https://docs.scoutello.com/dashboard/settings/orders
Source: docs/dashboard/settings/orders.md
Description: Purchases across tickets, tours, and related commerce flows.

`/organizations/:id/orders` centralizes **order history** for the active organization. Use it when a customer, participant, or guest asks about a purchase connected to tickets, tours, widgets, embedded checkout, or another Scoutello commerce flow.

Orders are organization-scoped in the dashboard. Platform staff also have consolidated admin routes for cross-organization order and payment review, but this page focuses on the organization Settings view.

## What Orders Are For

Orders help operators answer support and accounting questions such as:

- Which product, event, tour, or widget checkout created the purchase?
- Which customer or participant should the order be associated with?
- Has payment been completed, refunded, cancelled, or left incomplete?
- Which organization owns the transaction?
- Does the issue belong in customer support, finance, or platform operations?

## Typical Workflow

1. Open the active organization and go to **Settings → Orders**.
2. Search or filter by the customer, event, date, amount, or order identifier.
3. Open the related record if the order is tied to an event participant, tour purchase, or customer account.
4. Compare the order status with any payment status shown in payment/admin views before promising a refund or access change.
5. Record follow-up in the relevant customer, event, or project context when the purchase affects operations.

## Support Notes

If an order is visible but access in the guest app is wrong, check both the order and the product-specific record. Ticketing, tour access, and widget checkout flows can each have their own state in addition to the payment record.

If a user expects to see every organization's orders, send platform admins to the global admin order and payment tools instead of the organization Settings route.

**Related concepts:** [Widgets](./widgets), [Reference: routes](../../reference/routes).

---

# Mail templates

URL: https://docs.scoutello.com/dashboard/settings/mail-templates
Source: docs/dashboard/settings/mail-templates.md
Description: Branded email layouts for event communications.

Mail templates provide reusable **HTML and rich-content layouts** for event communication. They are exposed at `/organizations/:id/mail-templates` when the current role has event list or read permission.

Use mail templates when an organization wants event messages to stay consistent across confirmations, reminders, operational updates, and manual sends. The template is not the audience itself; it is the reusable layout and copy foundation that event or email workflows can apply.

## When To Create A Template

Create or update a mail template when:

- Event confirmations need branded header, footer, or legal copy.
- Reminder emails should reuse the same structure across several events.
- A team wants manual sends to match automated event communication.
- Support needs a controlled message format instead of one-off free text.

## Operational Checklist

Before using a template in production, confirm:

- The active organization is correct.
- The template language and fallback copy match the event audience.
- Event-specific placeholders or links are valid for the target event.
- Legal, unsubscribe, and sender identity requirements are covered by the configured mail flow.
- Test sends render correctly on mobile email clients.

## Permissions And Visibility

The sidebar exposes mail templates only for users who can list or read events. If a user can manage CRM emails but not event settings, they may still not see this page. Treat missing access as a role configuration question before assuming the route is broken.

**Related concepts:** [Organization events](../customer-management/events).

---

# Widgets

URL: https://docs.scoutello.com/dashboard/settings/widgets
Source: docs/dashboard/settings/widgets.md
Description: Embeddable Scouts for third-party sites and partner funnels.

**Widgets** package Scoutello purchase or engagement surfaces so they can be embedded on external websites while still using Scoutello's event, checkout, and tracking infrastructure.

The organization route is `/organizations/:id/widgets`. It appears in Settings when the current role has event list or read permission, because widgets commonly expose event registration, ticketing, or related booking surfaces outside the Scoutello guest app.

## What Widgets Are For

Use widgets when the primary entry point is not a Scoutello landing page:

- A venue embeds ticket checkout on its own website.
- A partner page links directly into an event or purchase flow.
- A campaign page needs a compact Scoutello-powered registration surface.
- Support needs to inspect which external funnel generated an order.

Widgets are useful when marketing teams want to keep traffic on an existing site, but operations still need orders, participants, and communication to land in Scoutello.

## Typical Setup Checks

Before publishing a widget:

1. Confirm the widget belongs to the intended organization.
2. Confirm the connected event, checkout, or engagement surface is ready.
3. Test the embed on the target website, including mobile width.
4. Verify the resulting order, participant, or CRM record appears where the operations team expects it.
5. Keep the embed snippet and the owning website documented for support.

## Troubleshooting

If a widget loads but checkout or submission fails, inspect both the widget configuration and the downstream event/order flow. If orders are created but support cannot find them in the organization, verify whether the embed points at the expected organization and environment.

**Related concepts:** [Orders](./orders), [Product: events](../../product/events).

---

# Child organizations & roles

URL: https://docs.scoutello.com/dashboard/settings/child-organizations-and-roles
Source: docs/dashboard/settings/child-organizations-and-roles.md
Description: Multi-property hierarchies and localized RBAC.

Larger customers can maintain **child organizations** and **roles** when one Scoutello customer structure needs several operational units. Examples include a hotel group with multiple properties, an event organizer with local teams, or a destination organization with partner offices.

The sidebar exposes:

- `/organizations/:id/organizations` for child organizations.
- `/organizations/:id/roles` for role and permission management.

Both routes require **organization administration** permissions on the `admin` entity (for example `admin:list:all` and related `admin:*` scopes from the role editor)—not the global Scoutello platform staff account.

## Child Organizations

Child organizations help separate ownership and day-to-day work while keeping the broader structure manageable. Use them when teams need different branding, records, permissions, or operational responsibility, but still belong to the same customer ecosystem.

Common patterns:

- A parent organization owns shared strategy, billing, or governance.
- Child organizations manage local customers, events, tours, web apps, and staff.
- Platform admins or organization admins can help troubleshoot hierarchy questions across the tree.

## Roles

Roles bundle permissions for users inside an organization. A user can have different roles in different organizations, so always check the active organization before diagnosing access.

Permissions follow the `entity:action:scope` model documented in the permissions reference. The **`admin` entity** bundles organization-wide administration: sufficient `admin:*` scopes grant access to hierarchy and role management in the sidebar, within the limits configured in that role.

## Support Checks

When a user reports missing records or missing navigation:

1. Confirm they are working in the intended organization or child organization.
2. Check whether their role belongs to that organization.
3. Confirm the role contains the relevant entity permissions, such as `customer`, `event`, `tour`, or `landing-page`.
4. Confirm whether scope is `assigned`, `all`, or `off`.
5. Avoid granting broad **`admin` entity** permissions unless the user should manage organization structure and roles.

**Related concepts:** [Permissions reference](../../reference/permissions).

---

# Promotion material & invoices

URL: https://docs.scoutello.com/dashboard/settings/promotion-material-and-invoices
Source: docs/dashboard/settings/promotion-material-and-invoices.md
Description: Scoutello platform staff tooling surfaced inside org settings.

When the signed-in user is a **Scoutello platform staff** account (global operator access), the organization Settings group can expose **Promotion material** and **Invoices**. These shortcuts are intended for Scoutello staff, not normal customer organization users.

Customer users without that platform access will not see these links.

## Promotion Material

Promotion material is used for co-marketing and operational rollout assets connected to an organization. Typical examples include printable or shareable material that helps guests reach a Scoutello web app, tour, event, or campaign.

Use this area when platform staff need to prepare assets for a specific organization rather than documenting general product behavior.

## Invoices

Invoices help platform staff review billing artifacts in the context of an organization. They are separate from the organization **Orders** page, which is mainly about guest or customer purchases created by Scoutello commerce flows.

Use invoices for platform/customer billing reconciliation. Use orders when investigating what an end customer bought, whether checkout completed, or which event/tour/widget generated a transaction.

## Access Notes

These routes are hidden unless the account is a **Scoutello platform staff** user. If customer staff ask for promotion material or invoices, confirm whether they need exported assets or billing documents through Scoutello support instead of dashboard access.

**Related concepts:** [Settings overview](./overview).

---

# Design system

URL: https://docs.scoutello.com/reference/design-system
Source: docs/reference/design-system.md
Description: Scoutello brand colors, visual direction, typography, layout, and interaction guidance.

Scoutello should feel warm, capable, and product-focused. The preferred look is light, generous, rounded, and editorial: clear content first, then subtle brand color, soft surfaces, and calm motion that makes the product feel responsive without becoming decorative noise.

The marketing landing page is the clearest public reference for the current visual direction. Product surfaces should reuse the shared design tokens where possible and only become more expressive when the surface is explicitly brand or marketing oriented.

## Brand colors

**Primary color:** `#ff8d49`

Use the primary orange for the Scoutello accent color: primary calls to action, focused states, active navigation, small icon backgrounds, highlight text, soft glows, and warm gradients. In product code this maps to `--primary: 24 100% 64%` and Tailwind classes such as `bg-primary`, `text-primary`, `border-primary/15`, and `shadow-primary/10`.

**Secondary color:** `#145466`

Use the secondary deep teal as a grounding color. It works best in gradients with the primary orange, dark call-to-action panels, visual depth, and occasional high-emphasis brand moments. It should not replace primary orange as the default action color.

**Supporting colors:**

- Warm cream backgrounds: `#fff8f1`, `#fff4ea`, `#fcf6f1`, and soft `orange-50` / `amber-50` surfaces.
- Product neutrals: white cards, dark foreground text, muted text around 70-75% opacity, and light borders.
- Tertiary blue: `hsl(205 100% 51%)` is available as a supporting token, but should be used sparingly so orange and teal stay recognizable as the brand pair.

## Visual Style

Prefer a clean, premium SaaS look with enough warmth to avoid feeling generic. The landing page combines cream mesh backgrounds, white cards, large product screenshots, rounded corners, and restrained gradients.

Use:

- Rounded cards and panels, often from `rounded-2xl` to `rounded-[2rem]`.
- Soft borders such as `border-primary/10`, `border-primary/15`, `ring-black/5`, and light neutral borders.
- Layered white or cream surfaces instead of heavy colored blocks.
- Subtle shadows like `shadow-sm`, `shadow-lg`, `shadow-2xl shadow-primary/10`, or custom low-opacity shadows.
- Large product screenshots or UI mockups as proof, especially for marketing and feature storytelling.
- Small brand moments such as orange highlight text, icon chips, rings, glows, and gradient CTAs.

Avoid:

- Loud full-page orange backgrounds.
- Overusing teal for ordinary controls.
- Dense, cramped layouts.
- Harsh shadows, sharp rectangles, or cold monochrome dashboards.
- Decorative motion that competes with reading or task completion.

## Typography

The marketing site uses:

- **Space Grotesk** for display headlines through the `landing-display` class.
- **Manrope** for marketing body text.

Shared app and docs surfaces use system-aligned UI typography, currently closer to Inter. The style goal is consistent across surfaces: confident headings, tight headline tracking, readable body copy, and generous line height.

Headline guidance:

- Use large, balanced headings on marketing pages.
- Highlight only the important phrase with primary orange.
- Keep line length controlled with `max-w-*` and `text-balance` where available.

Body copy guidance:

- Keep paragraphs calm and direct.
- Use muted foreground text for descriptions, usually `text-foreground/70` or `text-foreground/75`.
- Prefer scannable sections, short paragraphs, and clear labels.

## Layout and Spacing

Layouts should feel spacious and stable. The landing page uses a `max-w-7xl` container with responsive horizontal padding and large vertical sections.

Common patterns:

- Section padding around `py-16`, `py-20`, or larger for major marketing sections.
- Cards arranged in responsive grids with consistent gaps.
- Hero sections with a strong left content column and product screenshots or device compositions on the right.
- Centered section headers for broad product promises; left-aligned headers for story or workflow sections.
- Mobile-first layouts that stack cleanly before becoming multi-column on larger screens.

Use whitespace as part of the design. If a section feels unclear, simplify the content and increase breathing room before adding more decoration.

## Components and Surfaces

Scoutello surfaces should feel tactile but lightweight:

- Buttons: rounded pills for prominent marketing CTAs; standard product buttons elsewhere.
- Cards: white or cream, rounded, bordered, and lightly elevated.
- Icons: small, simple line icons in orange-tinted chips.
- Stats and trust elements: restrained cards with orange-tinted borders or gradients.
- Forms: clear labels, direct helper text, and enough spacing for mobile use.
- Screenshots: large, crisp, and slightly elevated. Use them as concrete evidence of the product.

When building product UI, start from existing shared UI components and tokens rather than custom one-off styling. When building marketing UI, use the landing primitives and landing classes where they fit.

## Motion

Motion should make the interface feel polished, not busy. The landing page uses short reveal animations, device rise effects, glow bloom effects, and small hover lifts.

Preferred motion:

- Reveal up from 12-24px with soft opacity.
- Hover cards lifting by only a few pixels.
- CTA hover states that slightly lift and deepen the shadow.
- Staggered section entrances where they support narrative scanning.

Always respect reduced-motion preferences. Avoid animations that can hide content, block interaction, or feel required for understanding the page.

## Voice and Content Design

The visual system works best with direct, concrete copy. Prefer language that explains what an organization can publish, manage, or automate in Scoutello.

Use:

- Product-specific nouns: landing pages, tiles, tours, events, organizations, dashboard, guests, QR codes, translations.
- Outcome-oriented descriptions that connect guest experiences with operator workflows.
- Gender-neutral language in German and other localized copy.

Avoid:

- Vague platform language without examples.
- Overly formal enterprise jargon.
- Long paragraphs where a scannable section would work better.

## Practical Rules

- Use `#ff8d49` as the main brand accent and `#145466` as the secondary grounding color.
- Prefer tokenized classes (`primary`, `secondary`, `foreground`, `muted`, `border`) over hard-coded colors in product surfaces.
- Keep marketing pages warm, spacious, rounded, screenshot-led, and lightly animated.
- Keep dashboard and operational surfaces calmer, denser only where necessary, and more task-focused.
- Let customer-owned guest experiences support organization branding where the product already exposes branding controls, but keep Scoutello-owned surfaces aligned with this system.

**Related concepts:** [Routes and surfaces](/reference/routes), [Landing pages and tiles](/product/landing-pages-and-tiles), [Browser-first guest experiences](/product/browser-first-guest-app).

---

# Tile types

URL: https://docs.scoutello.com/reference/tile-types
Source: docs/reference/tile-types.md
Description: Compact index of selectable landing page tile kinds—linked to deeper product docs per tile.

Each row lists the persisted **`type`** string editors choose (`value`), UX **category**, and typical **allowed sizes**. Deep-dive playbooks live under [/product/landing-pages-and-tiles/tiles/](/product/landing-pages-and-tiles/tiles/text).

:::info[Legacy experiments]

Historical picker experiments sometimes linger only as archived deployments. Treat them using [/product/landing-pages-and-tiles/legacy-and-runtime-only-tiles](/product/landing-pages-and-tiles/legacy-and-runtime-only-tiles).

:::

## Active picker tiles (`tileTypes`)

| `value` | Category | Sizes | Deep dive |
| --- | --- | --- | --- |
| `text` | basic | `embedded` | [/tiles/text](/product/landing-pages-and-tiles/tiles/text) |
| `url` | basic | small, medium, large | [/tiles/url](/product/landing-pages-and-tiles/tiles/url) |
| `pdf` | basic | small, medium, large | [/tiles/pdf](/product/landing-pages-and-tiles/tiles/pdf) |
| `landingPage` | basic | small, medium, large | [/tiles/landing-page](/product/landing-pages-and-tiles/tiles/landing-page) |
| `tour` | tour | large, medium, small | [/tiles/tour](/product/landing-pages-and-tiles/tiles/tour) |
| `members` | tour | small, medium, large, embedded | [/tiles/members](/product/landing-pages-and-tiles/tiles/members) |
| `chatroom` | advanced | small, medium, large, embedded | [/tiles/chatroom](/product/landing-pages-and-tiles/tiles/chatroom) |
| `stop` | tour | small, medium, large, embedded | [/tiles/stop](/product/landing-pages-and-tiles/tiles/stop) |
| `event` | tour | small, medium, large, embedded | [/tiles/event](/product/landing-pages-and-tiles/tiles/event) |
| `offer` | advanced | small, medium, large, embedded | [/tiles/offer](/product/landing-pages-and-tiles/tiles/offer) |
| `voting` | advanced | embedded | [/tiles/voting](/product/landing-pages-and-tiles/tiles/voting) |
| `networking` | advanced | small, medium, large, embedded | [/tiles/networking](/product/landing-pages-and-tiles/tiles/networking) |
| `mediaGallery` | basic | small, medium, large, embedded | [/tiles/media-gallery](/product/landing-pages-and-tiles/tiles/media-gallery) |
| `flashScreen` | basic | small, medium, large | [/tiles/flash-screen](/product/landing-pages-and-tiles/tiles/flash-screen) |
| `alerts` | advanced | embedded | [/tiles/alerts](/product/landing-pages-and-tiles/tiles/alerts) |
| `raffle` | advanced | embedded | [/tiles/raffle](/product/landing-pages-and-tiles/tiles/raffle) |
| `newsletter` | advanced | embedded | [/tiles/newsletter](/product/landing-pages-and-tiles/tiles/newsletter) |
| `weather` | basic | embedded | [/tiles/weather](/product/landing-pages-and-tiles/tiles/weather) |
| `contactForm` | advanced | small, medium, large | [/tiles/contact-form](/product/landing-pages-and-tiles/tiles/contact-form) |
| `faq` | basic | embedded | [/tiles/faq](/product/landing-pages-and-tiles/tiles/faq) |
| `sitePlan` | advanced | small, medium, large | [/tiles/site-plan](/product/landing-pages-and-tiles/tiles/site-plan) |
| `quiz` | advanced | small, medium, large | [/tiles/quiz](/product/landing-pages-and-tiles/tiles/quiz) |
| `soundCloud` | basic | embedded | [/tiles/soundcloud](/product/landing-pages-and-tiles/tiles/soundcloud) |
| `spotify` | basic | embedded | [/tiles/spotify](/product/landing-pages-and-tiles/tiles/spotify) |
| `instagram` | basic | embedded | [/tiles/instagram](/product/landing-pages-and-tiles/tiles/instagram) |

**Related concepts:** [Dashboard tile reference](../dashboard/web-apps-and-tours/tile-reference), [Product hub](/product/landing-pages-and-tiles).

---

# Permissions

URL: https://docs.scoutello.com/reference/permissions
Source: docs/reference/permissions.md
Description: How Scoutello expresses role capabilities with entities, actions, and scopes.

Most permissions use **`entity:action:scope`** triples. **Actions** include `list`, `read`, `edit`, and `delete`. **Scopes** typically differentiate `all` versus `assigned` access for large entities such as customers or tours.

**Organization administration** is also expressed with the `admin` **entity**: roles that can manage child organizations, roles, and similar hierarchy tooling include `admin` permissions such as `admin:list:all`, `admin:read:all`, and related `admin:*` combinations. Server-side checks for “organization administrator” may treat **any** permission string that starts with `admin:` as sufficient for certain routes—always use the dashboard role editor as the source of truth for a workspace.

Primary entities with `list` support include `customer`, `tour`, `landing-page`, `event`, `offer`, `newsletter`, `project`, `document`, `contactform`, `siteplan`, `place`, and `admin`. Sub-entities such as `protocol`, `email`, and `task` intentionally omit `list` because visibility is inferred via relationships.

Edge cases—such as mixed assignments or platform-operator shortcuts—are resolved inside the product; use the dashboard role editor as the source of truth for a given workspace.

## Permission format

```text
entity:action:scope
```

| Part | Meaning | Example |
| --- | --- | --- |
| `entity` | Resource type being controlled. | `customer`, `tour`, `event`, `admin` |
| `action` | Operation the role can perform. | `list`, `read`, `edit`, `delete` |
| `scope` | Breadth of access. | `assigned`, `all`, `off` |

## Actions

| Action | Meaning |
| --- | --- |
| `list` | See records in list views for entities that support listing. |
| `read` | Open or inspect record details. |
| `edit` | Create or update records. |
| `delete` | Delete records where allowed. |

`edit` includes creation rights in the permission model, so create buttons often depend on edit permission rather than a separate create permission.

## Scopes

| Scope | Meaning |
| --- | --- |
| `assigned` | Access records connected to the user through assignment or relationship rules. |
| `all` | Access all records for that entity inside the organization. |
| `off` | No explicit access, except special self-access or relationship rules enforced by the product. |

Assigned-only behavior can vary by entity. For example, customers can have responsible users, while tasks, emails, and protocols can be visible through customer assignment or direct assignment.

## Entity groups

Primary entities support list-style access:

- `customer`
- `tour`
- `landing-page`
- `event`
- `offer`
- `newsletter`
- `project`
- `document`
- `contactform`
- `siteplan`
- `place`
- `admin`

Sub-entities intentionally do not use `list`:

- `protocol`
- `email`
- `task`

These sub-entities are usually reached through relationships to customers, projects, or direct assignments.

## Dashboard visibility

The sidebar uses permissions to decide which groups and routes appear. If a user cannot see a page, check the entity permission first:

- Customer management: `customer`, `protocol`, `task`, `project`, `document`, `newsletter`, `email`, `event`.
- Web apps and tours: `landing-page`, `tour`, `offer`, `contactform`, `siteplan` (site plans and questions are gated with landing-page visibility in typical configurations).
- Settings hierarchy: `admin` entity permissions (child organizations and roles).
- Event settings: `event`.

**Gallery** under Web apps and tours is shown more broadly than some neighboring items; exact rules can vary by deployment—if a link is missing, confirm landing-page, tour, and organization context rather than assuming a broken build.

Platform operators may see additional routes that tenant users never encounter.

**Related concepts:** [Permissions and organizations](/product/permissions-and-organizations), [Child organizations and roles](/dashboard/settings/child-organizations-and-roles).

---

# Languages & localization

URL: https://docs.scoutello.com/reference/languages-and-localization
Source: docs/reference/languages-and-localization.md
Description: Translation workflow expectations for dashboards and guests.

Scoutello differentiates:

- **Authoring locales** maintained by operators inside dashboard forms.
- **Guest-visible locales** selected from runtime headers, links, or app preferences depending on the surface.

The documentation overview lives in [Multilingual content](/product/multilingual-content). It explains how product content is stored, how automatic translation behaves, how localized fields reach guests, and how UI strings stay aligned across apps.

Deeper engineering diagrams or reviewer workflows stay in internal documentation—not mirrored on this public site.

**Related concepts:** [Multilingual content](/product/multilingual-content), [How translations work](/product/translations/how-translations-work), [Automatic translation](/product/translations/automatic-translation), [UI strings and i18n](/product/translations/ui-strings-and-i18n).

---

# Data model (high level)

URL: https://docs.scoutello.com/reference/data-model-high-level
Source: docs/reference/data-model-high-level.md
Description: Conceptual map of major Scoutello domains for operators and documentation readers.

These aggregates describe how work is grouped—not an exhaustive schema:

| Domain | Conceptual building blocks |
| ------ | --------------------------- |
| Tenancy | Organizations, memberships, invitations, billing relationships |
| Guest web apps | Landing pages, configurable tiles, FAQs, embeddable widgets |
| Geo and plans | Places, groups, points of interest, venue site plans, map-oriented layers |
| Tours | Tours, ordered stops, media, assignments, optional monetization tiers |
| Events | Programs, schedules, invitations, ticketing where enabled, attendee state |
| CRM and communications | Customers, interaction history (protocols), tasks, documents, newsletters, mail threads |

## CRM relationships (dashboard language)

In the dashboard, **protocols** are structured **interaction logs** tied to customers (calls, meetings, notes, mail). They connect naturally to tasks, projects, milestones, documents, campaigns, and events when teams link records together.

Support questions usually start from the **customer profile**, then branch into open tasks, protocol timelines, project milestones, linked files, newsletter audiences, mail history, and event participation.

**Related concepts:** [Product model](/intro/product-model), [CRM and operations](/product/crm-and-operations), [Customer management overview](/dashboard/customer-management/overview).

---

# Routes & surfaces

URL: https://docs.scoutello.com/reference/routes
Source: docs/reference/routes.md
Description: Where different Scoutello experiences typically appear at a URL level for operators and guests.

Exact hosts depend on your deployment, but paths are usually shaped like the examples below.

| Surface | Typical path patterns |
| ------- | --------------------- |
| Marketing site | Locale-prefixed marketing pages such as `/{locale}/…` |
| Operator dashboard | `/organizations/{organizationId}/…` for tenant-scoped tools |
| Guest web app | `/landing/{id}`, `/tours/{id}` (and under a landing context such as `/landing/{id}/tours/{tourId}`), `/widgets/{id}/checkout`, and related guest flows |
| Short links | Compact slugs that redirect into guest or marketing destinations |

Some dashboard screens intentionally open **without the usual chrome**—for example lightweight previews or payment confirmations—so URLs may look different even though they remain part of the dashboard product.

**Related concepts:** [Dashboard overview](/dashboard/overview).