No setting matches that search. Clear the box to return.
Overview
A read-only snapshot. Select a tile to jump to that section.
Assistant & Capabilities
Configure Atlas outside the phone-triage call flow.
Text model
Booking defaults
Applies to every reservation and change Atlas submits. Users are never asked about it and cannot override it per trip.
Phone & Triage
Follow the caller journey from greeting through routing and follow-up.
Slack (triage records)
Where each triage call record posts. The default channel catches every
call unless a more specific rule overrides it. Per-team routing is optional: set a channel
on a category card above for a named route, or use the route map below;
escalate and unsure have no category and always use the default.
The Triage bot must be a member of any channel named here, or the post fails with
channel_not_found. The bot token is set under Integration keys.
Phone self-service posts two further cards, each to its own channel and only when that channel is set: a registration card when a caller completes self-enrollment (name, account, email, calling number's last four, attestation, whether bookings are active or delayed), and a booking card when a verified phone client books or requests a quote (confirmation number, name, email, pickup, from, to, passenger, vehicle). The email address is shown to staff on these cards; the code and PIN never are.
Conversation engine
The speech model the PHONE triage agent runs on — this is the setting that changes
what callers talk to. Separate from the panel voice below. Every call logs its
resolved engine (journalctl | grep "engine for"), so a change here is
verifiable on the next test call.
Turn taking. How the engine decides the caller finished speaking. semantic_vad judges by meaning (one built-in setting, already at its most patient); server_vad uses the numeric controls below — the documented choice when callers get cut off mid-sentence on a noisy line. Idle timeout makes the agent re-prompt a silent caller (server_vad only; 0 = off). Noise reduction runs before turn detection: near_field matches a phone handset; far_field is for speakerphones.
Panel voice
Applies to the assistant panel's voice sessions ONLY — the phone triage agent is configured above. Users see none of this — their only per-session choice is the voice itself (the one set below is the default they start on).
Channels & Integrations
Manage credentials and the places where people use Atlas.
API credentials
Keys are stored encrypted and are write-only: the console shows the last four characters, never the value. A replaced key is used from the next request — no restart.
Telegram
The Telegram channel is the same assistant over a bot chat: every tool call runs through the same gateway, capabilities and confirmation binding. Users link themselves with the Link Telegram button in the app — nobody is enrolled from here. Disabling the channel stops the bot within one poll cycle.
| Telegram account | Atlas user | Linked | Last used | Expires |
|---|
Groups
Every trip Urbanride returns carries the id of the group it belongs to. Turning this on lets staff filter a trip list down to one group — the way to answer "show me the rest of this group". Off by default, and staff-only: it is not grantable on a client invitation.
Two limits are worth knowing before you enable it. Urbanride exposes no group directory, so a group is an id with no name behind it — it has to come from a trip you already have. And the search returns in-preparation reservations unless other statuses are asked for, so a group reads as empty once its trips complete. Group booking has no Urbanride endpoint Atlas calls and is not switchable here.
Group creation lets staff create a group from the conversation — either
a bare shell (name and PO) or one carrying the event: dates, expected numbers, venues with
their pickup instructions, planner and onsite contacts, requirements. That distinction
matters, because Urbanride has no endpoint that adds any of it to a group later —
whatever is not captured at creation is re-keyed by hand at the desk. Either way the desk
still configures airports, greet procedures, pricing and vendors in Urbanride. It is a real
record on a real customer account, so it is previewed and explicitly confirmed like any
other write. Off by default, staff-only, and never grantable on a client invitation.
It needs a Urbanride with the group/create and rfp/create endpoints;
older environments refuse it and say so.
Status updates let staff move a group between the manual statuses —
RFP, Proposal, Accepted, Rejected, Completed, Priced — from the conversation. The
billing statuses (Proforma, Invoiced, Invoice Sent, CC Charged, Paid) stay
system-managed and cannot be set this way. Accepted is the status trips get booked
into, so this changes what an existing customer record means; it is previewed and
explicitly confirmed like any other write. Off by default, staff-only. It needs a
Urbanride with the group/update-status endpoint; older environments
refuse it and say so.
Connectors (ChatGPT & Claude)
Remote MCP connectors authorize through OAuth: the user consents from a signed-in Atlas session, and the host holds a rotating refresh token from then on. Every tool call still runs through the same gateway, capabilities and confirmation binding. Revoking a grant cuts the connector off at its next call.
| Connector | Atlas user | Kind | Created | Last used | Expires |
|---|
System & Access
Control operating mode, enrollment, permissions, and administrative history.
Identity & Access — phone clients
Every row is one explicitly enabled person, created here by an administrator or self-enrolled in-call under an account's self-enrollment policy. Caller ID only locates the candidate; the caller must enter this user’s DTMF PIN followed by pound. Five failed entries across calls freeze phone access. A restore revokes older sessions, preserves the evidence, and requires an administrator reason. STIR/SHAKEN never replaces the PIN.
Organization: Urbanride is the Atlas/PBX tenant for the whole Urbanride operation. An account is a customer company inside Urbanride, and a booker is the individual profile inside that account. Organization is configured once and is not selected per user.
Source says who admitted the person: an administrator here, or self-enrollment under a policy (version at enrollment shown). Binding assurance is attested only when the enrolling call carried STIR/SHAKEN A; unattested bindings never take the immediate-mutation branch. Mutations activate at is when book/cancel switch on under the policy's activation rule; Revalidation is the nightly directory check (ok / due / failed).
| User | Phone | Account / booker | Source | Status | Phone access |
|---|
One policy per Urbanride account is the class-level approval a caller enrolls under: the account, its allowed email domains, the routes that may offer enrollment, the capabilities granted and when mutations activate. Every save bumps the policy version so a code minted under an older version cannot complete. Edits affect new enrollments only, except the explicit bulk actions below. Atlas is authoritative for the domain list; the PBX receives a copy on every save.
| Account | State | Binding | Email domains | Offer routes | Booking | Enrolled | 7-day funnel | Actions |
|---|
New self-enrollment policy
One row per code challenge, real or dummy: every refusal mints a dummy so the caller's experience is identical for a hit and a miss. Reason codes explain a dummy; the address is shown masked and the code and PIN are never stored in clear.
| Time | Account | Reason | Outcome | Attestation | Masked email | Booker | Subject |
|---|
Enrollment code email
The one-time code a self-enrolling caller receives at the address Urbanride already holds for them. Email only, no links, no itinerary. The PBX can send only this saved template; the server fills the two placeholders per delivery. The calling number's last four digits are what let the mailbox owner vouch for the phone.
Must contain both {{verification_code}} and {{calling_number_last4}}; no other placeholders and no links. Only the server replaces them.
Flight research
Research tools for staff — find a flight by route and rough time, or resolve a flight number that will not validate. Research only: every booking still verifies through Urbanride. Several providers can serve these tools; each is billed by its upstream, so everything here is a spending control. The API keys themselves are stored under API keys.
Priority decides who answers when more than one is on — lowest number first. The next provider is reached only when the one before it cannot answer (off, no key, over budget, over quota, past its horizon, or failing upstream), so enabling several buys fallbacks rather than double spend.
This is a stated policy, not a capability: Atlas ships no web-search tool, so for its own text and voice agents there is nothing to reach for. A connected host (ChatGPT, Claude) brings its own search to the conversation, and what this setting does there is tell it, in the one prompt it reads, that flight facts are not its to look up.
The largest saving available, because a reused answer costs nothing. A published schedule for next Wednesday does not change between two people asking, so it is held for hours; today's board moves, so it is held for minutes. The cache is shared across staff and sessions — the second person to ask the same route pays nothing.
Side-by-side comparison: AeroDataBox vs the provider that answered
Every flight-number lookup answered by a selected provider is asked of AeroDataBox as well, in the background, and both answers are recorded. The user never waits for it, it does not count against anyone's daily lookups, and it is billed against its own monthly cap below — never the AeroDataBox backup budget. It needs an AeroDataBox key, not AeroDataBox being enabled. When the same flight later passes Urbanride validation, each provider is scored against Urbanride's scheduled time.
To switch over once the scorecard supports it: give AeroDataBox a priority number lower than AirLabs (for example 2) and enable it, then disable AirLabs. Comparisons against AirLabs stop by themselves, because AirLabs no longer answers. To roll back, re-enable AirLabs and restore the priorities. AeroDataBox's own values are deleted from comparisons and traces after 7 days, as its terms require; the verdicts are kept.
Users
The registry lives in config/pilot-users.json on the server. Sign-in matches the host token's subject against each user's email. Admin access is granted by the host application's token (role: "admin"), not by anything in this list — gate it where you gate the rest of your app (ATLAS_ADMIN_EMAILS is the bootstrap exception).
Only users listed individually appear here, and an empty table is the normal state: everyone your app signs in gets the default profile. List someone to give them less — tighter capabilities, or a max environment of test, which is a ceiling rather than a label and refuses them while the mode switch is in production.
| Name | Capabilities | Max environment |
|---|
Quality & Incidents
Review observed behavior and investigate problems without changing the live call flow.
Instruction adherence
Rule violations observed in the last 7 days, from the deterministic gateway checks (caught before the user saw anything) and the nightly transcript audit (what a conversation actually showed). Counts by provider are the adherence half of the voice-model comparison.
| Provider | Findings |
|---|
| Rule | Findings |
|---|
Phone-triage QC
A separate instrument from the adherence findings above: softer quality checks on the phone-triage channel — did the assistant read the caller's name back, confirm the callback number, avoid repeating itself, stay concise. Scored on a daily pass over the redacted call transcripts. The master switch gates transcript capture, this scan, and the incidents it opens; it never changes the prompt — corrective fixes ship as reviewed pull requests.
| Dimension | Findings |
|---|
Caller routing
Review what the model may choose and the effective hand-off for each team. Open only the categories you need to change; routing is based on what the caller asks for, never their number.
How classification and hand-off work
The model-facing description distinguishes one team from another; the staff label appears in Slack. Park holds the caller for staff, Transfer sends the call to a selected destination, and Use PBX default defers to the phone-system widget. Disabled categories route to a person. The fixed “unsure” choice always routes to a person as the safe outcome.
No caller category matches these filters.
Follow-up automation — prospective supplier application
Offer a public supplier-application link during calls classified as prospective suppliers. The assistant can invoke only this saved template and URL; it cannot compose a different message or substitute another link. "After a successful send" decides the call: route it to the category's configured hand-off as usual, or end it once the caller needs nothing else — a failed or declined send always routes normally, so the team hears about every call with an issue.
Turn on a delivery option to configure the application link and message.
Use {{application_url}} exactly once. Urbanride and opt-out wording should remain visible.
Optional. When the active carrier supports registered templates, the application URL is supplied as template variable 1; otherwise the SMS message above is used.
Shown in the recipient's inbox. The verified no-reply email address remains fixed.
Use {{application_url}} exactly once. Only the server replaces this placeholder.
Greeting & entry
The greeting is compliance text spoken on every call, and the live voice engine has garbled it ("Urban Red", "Rubenright"). Generate the recording once here — same voice as the assistant — listen to it, and deploy only after confirming. Calls then play the recording verbatim; regenerating creates a new draft and never touches the deployed recording until you confirm. Without a deployed recording, the assistant speaks the greeting itself.
Must contain the monitoring notice ("monitored and recorded for quality and training") before the automation disclosure ("automated assistant").
Reported problems
Filed by the people using the assistant, against the conversation they were having. Unlike the findings above, a report is not scored against a known rule — it is a claim that something was wrong, including failure modes no rule covers yet. Open one to read the turns around it.
Cost & Usage
Understand spend and maintain the rates used to value usage.
Model cost
What the conversations cost, and what each completed operation cost to produce. Text spend is measured from the Anthropic response; voice spend is reported by the browser, which is the only party the speech providers send usage to — treat it as an estimate. This is model cost at list price, not your invoice, and not the full cost of a booking.
| Figure | Amount | What it means |
|---|
| Model | Leg | Source | Calls | Cost |
|---|
Most expensive completed operations, and the sessions that produced none.
| Operation | URCN | Session | Cost |
|---|
Rate card
Anthropic rates ship built in and are effective-dated. Voice rates are not — each provider prices audio and text tokens differently, and a guessed price would report with the same confidence as a real one. Until a rate is entered here, voice usage is recorded and shown as unpriced rather than as zero, because zero reads as free.
Prices are dollars per million tokens, entered the way the provider publishes them — 5.00 means $5.00/MTok. Leave a field blank if the model has no such token type. A model billed by the minute (GPT-Live's voice layer) takes Per minute in dollars instead — 0.05 means $0.05/min. Stored as whole micro-dollars, so nothing is lost to rounding.
Recent admin activity
Operating mode
Test mode talks to the test Urbanride; production mode talks to the live one and bookings are real. Switching voids every open preview and ends every active session for every user. Each mode uses its own Urbanride Bot API key (below) — production cannot be entered until its key is stored.
This switch is the whole change: users move with it, and nothing on the server has to be edited or redeployed to follow it.