# Executive Overview *Audience: C-level sponsors and decision-makers · Applies to: Auto Task via Google Meeting (`ribot`) v1.5* ## 1. The short version Real Bots — Meeting Automation is a Salesforce managed package. It reads the notes that Google Gemini already produces for your meetings, extracts the action items from those notes, and presents them to a person for review. When a reviewer approves an item, the package creates a standard Salesforce Task. Nothing reaches Salesforce as a task without a human approving it first. That last sentence is the whole product philosophy. The package is deliberately built so that artificial intelligence proposes and a person decides. It is not an autonomous agent and it is not designed to be one. > **The one-line summary** — It turns the action items buried in Gemini meeting notes into reviewed Salesforce Tasks, with a human approval step in the middle. ## 2. The problem it addresses Google Meet and Gemini are good at capturing what happened in a meeting. They produce a summary and a list of action items. But that output then sits in a Google Doc. The commitments made in the meeting are not in your system of record, nobody formally owns them, and there is no list a manager can work from. The common workarounds — someone re-typing action items into Salesforce, or copying them into a spreadsheet — depend entirely on a person remembering to do it and doing it consistently. They rarely survive a busy week. This package closes that specific gap: it carries the action items from the Gemini note into Salesforce, and it makes the review a structured step rather than an act of discipline someone has to remember. ## 3. What is included today The package, installed and configured, delivers the following: * A connection to Google that lets the package read Gemini-generated notes for meetings your team chooses to include. * Automatic extraction of action items from those notes, including a suggested owner for each item. * A review dashboard inside Salesforce where a person approves or rejects each suggested item. * Creation of a standard Salesforce Task for every approved item. * Access controls so that regular users see only their own meetings and tasks, while administrators can see everything. * An activity log that records processing and errors for troubleshooting. ### 3.1 What is not included today It is just as important to be clear about the boundaries, so expectations are set correctly: > **Project-management integration is a separate engagement** — This package creates standard Salesforce Tasks. It does not, on its own, push work into Milestones PM+ or any other project-management tool. Integrating approved items into a PM tool — so that meeting action items become PM tasks under the right project and milestone — is separate work, delivered as its own build (either custom configuration in the org or an add-on package). It is not part of this installation. The package also does not record meetings, does not generate the notes itself (Gemini does that), and does not act without the approval step. There are no executive dashboards, risk-scoring, or analytics features in this version. Those are sometimes discussed as a longer-term direction; they are not what is being installed. ## 4. How it works, from end to end The flow has five stages. A person is involved at the start (choosing which meetings to include) and in the middle (approving items). The rest is automated. | Stage | What happens | Who acts | | ---------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------- | | 1. Meeting happens | Your team meets over Google Meet as they normally do. Gemini produces its usual notes. | No change to anyone | | 2. Meeting is included | A user marks which meetings the package is permitted to read notes for. | User, one-time per meeting | | 3. Notes are read | On a schedule, the package reads the Gemini notes for included meetings and extracts action items. | Automated | | 4. Items are reviewed | Extracted items appear on the review dashboard. A person approves or rejects each one and confirms the owner. | Reviewer | | 5. Tasks are created | Each approved item becomes a standard Salesforce Task assigned to its owner. | Automated | > **Why the review step matters** — AI extraction is good but not perfect. It can occasionally misread a date, merge two action items, or attribute a commitment to the wrong person. The review step exists so a person catches those before they become tasks. Treating the package as trustworthy because it is automated would be a mistake; treating it as useful because a person stays in the loop is the correct framing. ## 5. Trust, privacy, and risk Because the package reads meeting notes, sponsors reasonably ask how exposure is controlled. The honest picture: ### Access is scoped and opt-in The package reads notes only for meetings that have been explicitly included. It does not scan a user's entire calendar or Drive by default. Connecting to Google requires your own Google Workspace credentials, configured by your administrator during installation — the connection belongs to your organization, not to a third party. ### Nothing is automated end to end There is no path by which an action item becomes a Salesforce Task without a person approving it. This is the single most important risk control, and it is structural — it is how the package is built, not a setting that can be casually switched off. ### Activity is logged Processing and errors are recorded in an activity log, so an administrator can see what was read and when, and can investigate failures. > **The risk worth watching** — The main risk is not a technical failure; it is the review step becoming a rubber stamp. If reviewers approve long lists without reading them, wrong AI-extracted items gain the authority of an approved task. The safeguard is operational: keep review lists short and current, and make sure reviewers know they are accountable for what they approve. No software setting can enforce this. ## 6. What to expect from the rollout For a new deployment, this is typically a fresh Salesforce org. A realistic rollout looks like this: | Phase | What it involves | Typical effort | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | Install & configure | Administrator installs the package, sets up the Google connection, assigns permissions, schedules processing. Covered by the Administrator Guide. | Half a day to one day | | Pilot | A small group includes a few recurring meetings and works the review dashboard for one to two weeks. | 1–2 weeks | | Adjust & expand | Refine which meetings are included and who reviews, based on what the pilot shows, then widen to more teams. | Ongoing | | PM integration | Separate, later engagement to connect approved items into a project-management tool. Scoped on its own. | Future — not part of this rollout | ### 6.1 What makes a rollout succeed * Start with recurring meetings. They produce a steady stream of action items and only need to be set up once. * Keep the reviewer group small and clearly named. Diffuse responsibility for review is how the queue goes stale. * Treat the pilot as a real test of the review habit, not just the software. The technology works; the habit is what determines value. * Decide early, and deliberately, whether and when PM integration is wanted — so it can be scoped as its own piece of work rather than improvised. ## 7. Decisions this document asks of you Three decisions belong with the sponsor rather than the administrator: | Decision | Why it is yours | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Who owns the review queue | An accountability question. The package can show items to anyone with access; deciding who is responsible for clearing them is an organizational choice. | | Which meetings are in scope | Reading meeting notes touches sensitive discussions. Confirming which categories of meeting are appropriate to include is a judgment call, not a technical setting. | | Whether PM integration is wanted | It is a separate investment. Knowing the answer early lets it be planned properly instead of bolted on. | > **In summary** — Real Bots — Meeting Automation makes meeting commitments visible and owned inside Salesforce, with a human check that keeps AI output trustworthy. It is deliberately modest in scope: it does one thing, it keeps a person in control, and it leaves project-management integration as a clearly separate decision. That modesty is a strength — it is what makes the package safe to adopt. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.realintelligence.com/overview.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.