Presentation

[Audio] Welcome, Robin. This presentation is your private tutorial for understanding the Google Sites pilot home before you approve it. You are not being trained to become the site builder. The goal is for you to know what participants will see, how the parts connect, which decisions belong to you, and what must be tested before launch. The pilot is completely self-paced. AI Robin provides the instruction. Your appearances, if used, are limited to selected prerecorded or static moments such as the welcome, Founder Story, closing, or thank-you..

[Audio] Google Sites is a simple website-building tool inside the Google ecosystem. For this pilot, it becomes the participant-facing home. It does not need to store every course asset itself. Instead, it gives each asset a clear place and a clear purpose. A participant can open one link, see where to begin, move to the next page, watch AI Robin, open a workbook, and complete a form. Remember this distinction: the Site organizes the experience; Drive and Forms hold much of the working content..

[Audio] This slide separates tools that can feel like one large Google system. Chrome is simply the browser—the window through which Robin or a participant opens the Site. Gemini is an AI assistant. Drive is the storage system. Docs and Slides are file types that can appear within or open from the Site. Forms collects information. Sites is the experience layer that arranges these pieces. Orion Ledger can help with Google and Gemini intelligence and source integrity, but that does not mean every Google product belongs to Orion. Team responsibilities still follow the actual work being done..

[Audio] Google Sites is being tested because it can give a small pilot group a clean, guided experience without adding an LMS or new paid system. This decision is intentionally limited. We are not declaring Google Sites to be MJA Academy's permanent learning platform. We are using it to deliver the existing program professionally, observe what works, and gather evidence. The key approval question is whether the Site makes the participant journey easier and more coherent than sending separate links and files..

[Audio] This is the experience we are designing for. The participant receives access, opens the Site, begins at Start Here, follows AI Robin's prerecorded instruction, uses the materials, completes required forms or activities, and moves forward at their own pace. The design must never make the participant wonder whether a live class is coming. Robin is not waiting on Zoom and does not teach the program live. Each page must clearly state the current step and the next action..

[Audio] When reviewing the actual build, look at three layers. First, the header establishes location and identity. Second, the page body contains the teaching and action for that page. Third, navigation helps the participant move between pages. Google Sites also provides a preview function so the production team can inspect common device views before publishing. Robin's role is to judge clarity and appropriateness, not to drag and resize every element..

[Audio] A page is one destination within the Site, such as Start Here or Completion. Navigation is the menu that exposes those destinations. Pages can be arranged and nested so the participant sees a manageable structure rather than a long, confusing list. Robin should review the wording and order. Technical page creation can be handled by the production workflow. The best navigation uses participant language, not internal production language..

[Audio] Drive is the underlying file cabinet. A Drive item can be embedded so participants see it within the page, or linked so it opens separately. The correct choice depends on readability and the action expected. An embedded workbook may be difficult to use on a smaller screen, while a separate copy may be clearer. The most important operational rule is permissions: access to the Site does not automatically guarantee access to every embedded Drive file. The team must test each file as a participant, not only as the owner..

[Audio] Google Forms handles structured participant input. For Pilot #1, that includes assessments, selected activities, feedback, and completion evidence. The Form can appear inside the Site or open from a button. Robin should focus on whether the form asks the right questions and arrives at the right moment. Production must verify who can submit, whether sign-in is required, what confirmation appears after submission, and where responses are stored. The Site itself is not being used as a progress database or dashboard..

[Audio] AI Robin is the primary instructor throughout the self-paced program. Her prerecorded segments should teach, orient, transition, and encourage. We will consider Google Drive video first because it stays within the approved pilot system. Before launch, we must test that the video opens, plays smoothly, has usable audio, and is accessible to the participant account. We do not add YouTube simply because it is familiar. We consider another host only if actual testing shows that Drive cannot deliver the needed experience. Founder Robin does not become the live instructor. Her presence remains strategic and prerecorded or static..

[Audio] Behind the scenes, the build is governed rather than improvised. Kai Nova leads architecture and integration. Victoria reviews the participant journey. AI Robin supplies instruction. Orion verifies sources and supports Google or Gemini intelligence where relevant. Ava protects brand and visual clarity. Normie supports human implementation. Amara Vision, Pulse Nexus, and Atlas Vale are routed when strategic alignment, market intelligence, or scope accountability is relevant. Robin remains the authority who approves the experience. No new team members are created for the project..

[Audio] This is the division to remember. Robin personally decides whether the Site serves the Academy, represents the brand correctly, protects the program's scope, and provides an acceptable participant experience. Robin does not need to carry the production burden of assembling pages, embedding every asset, or solving each permissions problem. The team should bring review-ready work and clear approval questions. This structure preserves Founder authority while respecting accessibility and reducing unnecessary physical tasks..

[Audio] Accessibility here is practical. A participant should not struggle with small text, weak contrast, hidden navigation, cramped buttons, unclear instructions, or media that cannot be understood. Google Sites provides features such as alt text for images and device preview, but accessibility still depends on our choices. For prerecorded instruction, plan for captions or a transcript approach and confirm that sound is clear. The production team must test the published experience, because an editor view can hide problems a participant will face..

[Audio] The site must be tested after publishing, while signed in as a participant or using a separate test account. Owner access can make every file look correct even when a participant will be blocked. Test the Site, each Drive item, each Form submission, every video, navigation, device views, and the final completion path. Also remember that editing and publishing are separate actions: a change made in the editor does not become visible to participants until it is published. Google Sites supports reviewing changes before publishing, which helps the team catch unintended edits..

[Audio] Use this checklist at the approval stage. The goal is not to make Google Sites behave like a full LMS. The goal is a clear, professional, accessible pilot experience for approximately four to five working professionals. After the tutorial, the next review sequence is straightforward: first approve the proposed site map, then review the working build in participant view, then authorize access only after the test checklist passes. If something is confusing, blocked, or out of scope, it returns to production before launch..