How to use AI assistance in Onomi 360

AI assistance in Onomi 360 takes repetitive work off the people who request, approve, and run events, while keeping every decision human. The assistance layer has been available since the 2026.01 release. It adds AI-assisted request creation, date suggestions, approver summaries, natural-language insight over your portfolio, and translation drafting for a portal language your administrators add. This guide covers enablement, each flow by persona, the messages you may meet, and AI governance. For what arrived in which release, see the AI assistance release notes.

Overview

Every AI feature in Onomi 360 follows one rule: the output is presented for review, applied only on a human's confirmation, and logged. Nothing is submitted, approved, sent, or built on a person's behalf. You can always trace what was suggested, where, and what the human decision was. The flows in this guide all close the same way: a person checks the AI's work and confirms it.

The assistance layer works across the request-to-close flow:

• Requesters describe meetings in plain language and get date suggestions.
• Approvers get summaries and risk flags.
• Event records carry an attendance forecast.
• A portal language your administrators add arrives as a complete translation draft for your reviewers.
• The portfolio calendar and reports carry a panel that answers questions about your program data in plain language, for the assignments that open those surfaces.

Six roles meet AI in this guide.

Before you start

Check the following before you enable or use AI features:

• AI assistance in Onomi 360 is enabled at the organization level. The assistance layer is optional and off until enabled. Its features cover the meeting request portal, Event requests, event records, portal-language drafting, the portfolio calendar, and reports. Enablement is therefore organization-wide. If you do not see the AI features described in this guide in Onomi 360, please contact your SpotMe Account Manager to enable AI assistance for your organization. Where a colleague reaches an AI feature from a saved link before it is enabled, Onomi 360 answers "AI assistance is not enabled for your organization. Ask your organization Admin to request it." instead of opening an empty panel.
• Attendance forecasting comes with that same organization-level enablement. It arrived with the 2026.02 release. The Attendance forecast panel appears on the event record in Onomi 360 once AI assistance is enabled for your organization. It has no switch of its own.
• Translation drafting comes with the same organization-level enablement. It arrived with the 2026.02 release. It appears wherever your administrators add a portal language, in Onomi 360 under Policies > Languages. It has no switch of its own. Where AI assistance is not enabled for your organization, a language you add starts with an empty translation column. Your administrators then supply it with the export and import cycle documented in Running multilingual events across global markets.
• Rollout. To plan which teams adopt AI assistance first, please contact your SpotMe Account Manager.

AI-assisted requests and approvals

The flows in this section run in Onomi 360's request and approval suite and appear once AI assistance is enabled for your organization. For the module itself, the request form, the routing rules, and the approval flows, see How to set up and use meeting requests and approvals. This section covers only what AI adds to it.

AI-assisted request creation

AI-assisted request creation is conversational intake: a request is created from a plain-language description rather than typed field by field. Requesters work in the meeting request portal, as for any request.

1. In the meeting request portal, select New request and choose the request category. With AI assistance enabled, the form opens with a Describe your meeting panel above it.
2. Describe the meeting in plain language: what it is for, roughly when and where it should happen, who attends, and how large it will be. The AI fills the request form from your description.
3. Review the prefilled form. Every field the AI filled is marked as a suggestion until you confirm or edit it. Fields your description did not cover stay empty, and required fields stay marked, so a thin description produces a thin draft rather than invented answers.

   

4. Adjust anything, complete the remaining fields, and select Submit. Nothing is submitted on your behalf: the request enters routing only through this action, and from there it follows the same lifecycle as a request typed field by field.
5. To verify, open your My requests list: the request shows status Submitted, the record shows your confirmed values, and the log notes that intake was AI-assisted.

Getting date suggestions with explained trade-offs

1. In the request form, in the Proposed dates field, select Suggest dates.
2. Suggested dates appear, each with its trade-offs explained. The inputs are named and bounded: conflicts with other planned events on your organization's portfolio calendar, public holidays for the meeting's country, and attendance baselines from comparable events in Onomi 360. Those comparable events are the completed events that ran a registration journey, so meetings your organization runs as record-only contribute none. Where a speaker program is involved, the engagement counts the request form's faculty step holds for each speaker are a further input, available since the 2026.03 release. The suggestions read your own program's data. No personal calendars are read.

   

3. Optionally, select a suggestion to fill it into Proposed dates, or keep the dates you had in mind. A suggestion is never applied until you select it.
4. To verify, check the Proposed dates field: it shows the date you chose, and the suggestions and your choice are logged with the request.

Reviewing a request with the summary and risk flags

1. When a request routes to you, open it from Event requests in Onomi 360 or from the notification email. With AI assistance enabled, the record opens with a generated Summary panel beside the full record.
2. Read the summary for the shape of the request: what is being asked for, when, at what spend, and with which attendees.
3. Check the risk flags. Each flag points at a part of the record that deserves attention, for example HCP attendees present or a budget band at the top of a routing threshold. Each also references the field it draws on, so you can check it against the record directly.

   

4. Act as you would on any request: Approve, or Decline with a reason. The panel never acts. The AI never approves, declines, or advances a request. The summary sits beside the full record and never replaces it. The submitted field values, the "why this approver" trace, and the log stay in place and stay authoritative.
5. To verify, open the request's log. It shows your action with a timestamp. The summary and flags are logged with the record, so what was flagged when you decided remains auditable.

Note: What happens after approval is not an AI step. When a request reaches Approved, the platform creates the linked event record from the approved values as standard behavior, documented in How to set up and use meeting requests and approvals.

AI-assisted content and insight

Drafting the translations of a new portal language

Translation drafting, available since the 2026.02 release, means a portal language your administrators add arrives filled rather than empty. When a language is added in Onomi 360 under Policies > Languages, AI assistance drafts every string in both key sets: the meeting request portal strings and the lifecycle notification templates. Your reviewers then work down a queue, accepting or correcting each one.

The human decision is the same one every other feature here follows. That decision carries more weight on this surface than on most, because the output is copy a market reads as your organization's own words. None of the draft is live. A string reaches a requester only when a reviewer accepts it. Until then that string falls back to your organization's default language, so a machine translation never reaches a requester unreviewed. Coverage counts reviewed strings rather than drafted ones, which is why a freshly drafted language reads 0 percent. Every acceptance and edit is recorded against the string with the reviewer and the date.

Running multilingual events across global markets documents the steps and the review queue. That article also documents the offline review path for a market reviewer who works outside Onomi 360, and how coverage is read per key set.

Asking natural-language questions over your event data

In Onomi 360, open the Portfolio calendar or a report. With AI assistance enabled, the question panel opens beside it, on the reporting surfaces themselves rather than as a section of its own. Ask a question in plain language about the event and program data those surfaces hold, and get an answer on demand. Understanding your program no longer waits on a report build.

Who the panel opens for follows the rule the rest of the program layer follows, in two parts.

Which of those surfaces opens at all is decided by the assignment a person holds, and the scope on that assignment bounds what each surface it opens shows.

A Program lead assignment opens the portfolio calendar and reports. A finance-role assignment opens the cost-facing reports: the five reports in the Financials group, the costs entity of the report builder, and the reinvoicing summaries.

An assignment that opens neither surface opens no panel. An Approver's assignment opens Event requests and no program-layer section, so an Approver gets no answers here.

Answers respect the same access controls as the rest of the platform. The scope on the assignment that opened the surface is what bounds them.

For the surfaces themselves, see How to use Onomi 360: the portfolio calendar, engagement view, and reports. For the assignments and their scopes, see Role-based access and visibility for internal and external stakeholders.

Attendance forecasting

Attendance forecasts, available since the 2026.02 release, are built from historical baselines for comparable events. Each forecast is always shown with the baseline it draws on, so you can judge it against your own knowledge of the program. A forecast is an input for planning, never an automatic action: it does not change capacity, budget, or communications on its own.

A forecast is produced per event and shown on that event's record in Onomi 360, in the Attendance forecast panel, from the moment the event record exists. Forecasts are not part of the reporting views. The portfolio calendar, the dashboards in Insights, and the reports read captured actuals, as documented in How to use Onomi 360: the portfolio calendar, engagement view, and reports.

The inputs are bounded, and all of them are your own program's data. The first is the completed events Onomi 360 holds for your organization, matched as comparable on request category, geography, and, where your organization uses them, therapeutic area or brand. The second is the attendance each of those events recorded against the registrations it took. The third, where registration is open, is the registrations this event has taken so far. No personal calendars are read, and no external or purchased data set is used.

The attendance and the registrations both rest on the registration journey, so meetings your organization runs as record-only sit outside the forecast.

A request category mapped to record-only creates an event record and no workspace. The meeting therefore has no registration page and no registrations. Its attendance state is recorded on the attendee row of the event record by a holder of the finance role, rather than against a registration. See Configuring what approval creates in From approval to execution and auditing requests, and Meetings with no workspace in Running and correcting an allocation.

The Attendance forecast panel is present on such an event record, as the record's other modules are. The panel reports that no forecast is produced for the meeting: "No forecast is available for this meeting. Meetings in a record-only request category take no registrations, so there is no attendance for a forecast to read."

That state has nothing to do with how much comparable history your organization holds, so it is not the not-enough-history state described below. It does not clear as the history grows either. A forecast is computed from attendance recorded against registrations, and this meeting takes none.

A completed record-only meeting is no comparable for another event either, for the same reason.

Where the meetings of a category need a forecast, an organization administrator maps that category to Create at approval or Create at Start execution in Policies > Event creation, instead of record-only. Either setting puts a registration journey behind them.

The panel opens to anyone whose access opens the event record. That is an Approver, a Compliance reviewer, a finance-role, a Sourcing, or a Program lead assignment whose scope covers the event, and the planners of the event's workspace. Those planners reach the record from the workspace or from a direct link, even where their strategic meetings management scope does not cover it.

What a reader sees has two parts.

The forecast uses completed events from the past 36 months and needs at least three comparable events in that window. With fewer, no forecast is shown, and the panel says there is not enough history. There is one figure per event, and it does not vary by reader. The panel shows every reader the number of comparable events behind it and the period they were drawn from.

View baseline is bounded by the reader instead. It lists only those comparable events the reader's own access opens, because no reader is shown a record through an AI feature that they could not open themselves.

A planner of the event's workspace who holds no strategic meetings management assignment sees the figure, the count, and the period. Their baseline list is limited to the events they can open, which may be none.

To read a forecast:

1. In Onomi 360, open the event record. The route follows the access you hold. The Portfolio calendar opens on a Program lead assignment. Event requests opens on an Approver, a Compliance reviewer, or a finance-role assignment. The planners of the event's workspace reach the record from that workspace or from a direct link.

   One assignment reaches it by neither list. A Sourcing assignment opens the event records inside its scope, and no list of its own. The holder reaches an event to source by a direct link to the event record, sent by the event's finance owner or by the planner handing sourcing over. The holder can also reach it from the event's workspace, where the holder is a member of one. The event record opens.

2. Open the Attendance forecast panel. It shows the forecast for the event, the number of comparable events behind it, and the period they were drawn from.
3. Select View baseline to list the comparable events your own access opens, with the attendance each recorded, so what the forecast rests on is visible rather than implied.

   

4. To verify that a forecast reads the right history, check that list against the events you would compare by hand. The match runs on the event's Request category, its Country and city, and, where your organization uses them, its Therapeutic area or Brand. Each of those values reaches the event record from the request behind it.

   Where the baseline is not the comparison you would make, read the forecast against the baseline the panel shows rather than re-matching it. Then correct the comparison for the events still to come.

   On the portal path the correction is on the request form. That form is where the Request category, the Country and city, and, where your organization uses them, the Therapeutic area or Brand a request carries at submission are set. See How to set up and use meeting requests and approvals.

   For events approved upstream in your CRM, the correction is on the connector's inbound field mapping. That mapping applies to the records arriving after the change. See Integration patterns: connecting Onomi to your enterprise systems.

Models and governance

AI features in Onomi 360 run on enterprise model infrastructure: Claude models and OpenAI models available through AWS Bedrock, with model choice managed per customer.

The model configuration is organization-level. You agree the provider and models your organization runs on with your SpotMe team. They apply to every assistance feature across your organization, and your administrators can see them in Onomi 360 under Policies.

Onomi also supports additional customer-approved model providers, available since the 2026.03 release.

Where your model configuration names a secondary provider, a feature falls back to it when the primary provider is unavailable. The log records which provider produced the output.

Where it names none, the panel reports "The AI service is currently unavailable. You can continue without suggestions." and the flow underneath runs manually.

Model calls run with zero data retention, and your data is never used to train models.

Those calls run on model infrastructure outside the application-data residency boundary described in Data residency at SpotMe. Where they are processed is settled with your SpotMe team as part of the model configuration above.

Prompts and outputs are logged, so AI activity in your organization is auditable.

The features that read records back to a user respect the same access controls as the rest of the platform. A user is never shown a record through an AI feature that they could not open themselves. That holds for AI answers over your event and portfolio data, for the Summary panel on a request, and for the Attendance forecast panel on an event record. The panel's View baseline list carries only the comparable events the reader's own access opens.

Date suggestions in the meeting request portal work on a different footing, because a requester holds no role assignment. A suggestion is computed over your organization's own data. It reports that a date conflict or an attendance pattern exists, without opening, naming, or showing the record behind it.

* Onomi 360 MeetingsEQ exclusive capabilities.