Not by default. SleekAI reads your published WordPress content, which doesn't typically include live bus locations. The bot points riders to your official tracker (app, SMS, web tracker) for live ETAs, which is the authoritative source. If you expose a GTFS-RT or AVL feed through a WordPress endpoint or REST plugin, SleekAI can be configured to call it via tool calls, but the default architecture keeps live-tracking on your existing tracker.

No. Paratransit eligibility is determined by an in-person or remote assessment, often with medical documentation, which requires human review. The bot can quote your published eligibility criteria, surface the application form, and explain the assessment process and timeline, but it does not approve, deny, or pre-screen applications. The clean handoff routes the rider to your paratransit coordinator with the right form and required documentation listed.

Yes, if your service alerts are published as WordPress posts, a custom post type, or pulled into the CMS from a feed. SleekAI reads them as context so a rider asking about Route 23 service today gets the active alerts surfaced. For acute service disruptions, the bot points riders to your primary alert channel (SMS alerts, app push, social media) as the live source of truth and does not invent disruption details.

Each route's weekend and holiday schedule is read as part of the route's page or schedule data. The bot answers "does Route 7 run Sunday" with the published Sunday schedule or honestly says "this route is weekday-only." For holiday-specific service (typically Sunday-level service on major holidays), the bot quotes the published holiday service policy. Honesty over guessing is enforced by the instruction.

Yes. SleekAI Multibot supports per-page scope: a general rider bot scoped to /routes and /fares can handle the high-volume schedule and fare questions, while an accessibility-focused bot scoped to /accessibility and /paratransit can be tuned for those riders' specific needs (form-heavy, slower, more empathetic). Each bot has its own instruction and presets, and display conditions keep the experience focused.

The bot can quote your lost-and-found procedure from your published page, including the contact email, in-person window, and what info to provide (route, date, time, description of item). It does not search a lost-and-found database itself; that lookup requires staff to physically check. The bot's role is to set the right expectation (how long lost items are held, where to retrieve them) and route the rider to the right office.

Yes. SleekAI uses general-purpose LLMs via your own API key (OpenAI, Anthropic, Google, OpenRouter), so the bot answers in whatever language the rider writes in. For transit authorities serving multilingual cities (Spanish, Cantonese, Vietnamese, Tagalog, Russian, and more), this is a significant access improvement at zero per-language translation infrastructure on your side. Schedules and forms are still returned in whatever languages your site publishes them.

On your WordPress install, in the database, with model name, token usage, and page URL stored with each transcript. For transit authorities, this also functions as rider intelligence: aggregate the questions and you see which routes get the most questions (often a sign the schedule page is confusing), which fare topics need clearer copy, and which accessibility pages have unmet demand. Data stays in your database, under your retention policy, not on a third-party dashboard.