Here is what happens once your Volaris contact invites you. You get a private workspace and share what you already have. Then you answer a few questions at a time. You decide what happens at every step.
Your Volaris contact will invite you. There is no public sign-up.
THE PATH, IN ORDER
Six steps. No surprises.
Each step says what you do, what we do and what happens next.
STEP 01 · INVITATION
Your Volaris contact invites you
Access starts with a personal invitation from your Volaris business development contact. There is no form to fill in and no account to apply for. You open the link, sign in, and land in the workspace set up for your company. If you sign in before an invitation arrives, a simple page tells you your contact will send one.
STEP 02 · YOUR WORKSPACE
A private space for your company
Your company gets one workspace of its own. Before you share anything, you sign an NDA digitally. After that, only you, the colleagues you invite and the Volaris deal team can see what is inside.
STEP 03 · SHARE WHAT YOU HAVE
Send it as it is
There are no templates to fill in. Drag files in, pick them from your computer or take a photo with your phone. Send as many as you like.
Spreadsheets, CSV exports, Word documents and plain text
PDFs, scans and photos of paper records
Links to folders you already keep elsewhere
Very large files: your Volaris contact can add them for you
STEP 04 · A FEW QUESTIONS
Only what matters, in small rounds
We read what you sent first. Then we ask only about what is still unclear, a few questions at a time. You answer in your own words. Each question comes with a one-line reason, so you know why we ask.
STEP 05 · CHECK-INS
A real person keeps it moving
You and your Volaris contact check in regularly. You see what has arrived, what comes next and what is still outstanding. Their phone number, email and booking link are inside your workspace, so you can reach them without searching for their details.
STEP 06 · AFTER AN OFFER
You decide what happens next
When we have what we need, your Volaris contact talks you through an offer. You can take it forward or take your time. If the conversation ends, you can ask for everything to be permanently deleted and receive a written deletion record.
Each prospect company gets its own workspace, and every procedure, background job and entry route is scoped to exactly one workspace. Staff need a product role (BD, Finance reviewer, Knowledge owner or Admin) plus staff membership of that specific workspace. A seller is attached to exactly one workspace as a plain member holding the seller role, and nobody can promote a seller to admin or owner. The people list shows a seller only their own company's people, never staff accounts.
Only the people and procedures the product allows. Each prospect company gets its own workspace with two dedicated AES-256-GCM data keys, one for uploads and one for derived content. Every file is sealed with that workspace's uploads key and processed in the background for that workspace only. Workspace keys and sealed tables are reachable only through Volaris PIR's own procedures, never through generic data surfaces such as the REST API, MCP server or AI chat tools. No generic tool can list or export them.
Each workspace gets two AES-256-GCM-wrapped data keys, one for uploads and one for derived content. The platform's managed key service wraps those keys. Every content payload is written through a seal/unseal envelope, and tests cover round-trip, tamper and plaintext-marker cases. Unwrapped keys stay in memory for at most five minutes. Destroying a workspace's keys crypto-shreds its data. The wrapped keys and sealed tables are reachable only through the product's own procedures. Generic surfaces such as the REST API, the MCP server and AI Worker controllers cannot reach them, so no generic tool can list or export them.
Volaris PIR is built for crypto-shredding. Each workspace's data keys are wrapped by the platform's managed key service. Unwrapped keys stay in memory for at most five minutes. Destroying a workspace's keys leaves its sealed content unreadable. For the full deletion workflow and retention details, details are available on request.
Sellers can upload any number of files of any type by drag and drop, file picker or phone camera. Files over 25 MB get a plain message asking them to send the file to their BD. BDs and Admins can upload on the prospect's behalf, and those files are tagged 'Added by <name>'. Each file is sealed with the workspace's uploads key and processed in the background for its own workspace only. Pasted file-sharing links are listed for the BD. For current limits on staff uploads, details are available on request.
Staff hold product-wide roles: BD, Finance reviewer, Knowledge owner or Admin. For workspace actions, they also need staff membership of that specific workspace. The server enforces a permission matrix across these roles and the Seller role, with an automated test for every cell. A seller is attached to exactly one prospect workspace and can never be promoted to admin or owner. Sellers see only their own company's people, never staff accounts. Staff actions are recorded in a staff-only audit log that never appears in a seller's activity history.
Before any seller-facing text is shown, or handed to a BD to send, it passes a wording guard. The guard checks the text against a product-wide internal-terms list of 31 default terms in six groups, and only the Knowledge owner can edit that list. It rejects exclamation marks, urgency and blame. If generated text fails, an AI model rewrites it once. If the rewrite still fails, the text is held for a BD to review. Tone rules T1–T5 are enforced by an automated test over every registered seller string.
Sellers can upload any number of files of any type by drag and drop, file picker or phone camera. Files over 25 MB get a plain message asking the seller to send them to their BD. BDs and Admins can upload on the prospect's behalf, and those files are tagged 'Added by <name>'. If a seller pastes a file-sharing link, it is listed for the BD to follow up.
A product-wide knowledge registry holds rules, reference mappings, definitions, question wording and Q&A flags. Each entry has a code, statement, example, source, confidence and a draft or approved status, and every edit is versioned. Only the Knowledge owner can approve, edit or reject entries. Every rule application records the rule it used, and any use of a draft rule is flagged for review until that rule is approved. Plain-language definitions written in the founder's language must pass the wording guard, and sellers see them through 'What do we mean?'.
Not if the wording guard catches it. Before any text is shown to a seller or handed to a BD to send, it is checked against an internal-terms list of 31 default terms in six groups, which only the Knowledge owner can edit. The guard rejects exclamation marks, urgency and blame. It rewrites AI-generated text once, and anything that still fails is held for a BD to review. Tone rules T1 to T5 are enforced by an automated test over every registered seller string.
Yes, staff actions are audited. They are recorded as staff-only audit entries that never appear in a seller's activity history. Permissions follow a server-enforced action-by-role table, and each cell of that table has its own automated test. A separate coverage test fails if any procedure lacks a matrix action. Uninvited or role-less users are sent to a single page saying 'Your Volaris contact will send you an invitation'.
Volaris PIR keeps a knowledge registry of rules, reference mappings, definitions, question wording and Q&A flags. Each entry has a code, statement, example, source, confidence and draft/approved status, and every edit is versioned. Every rule application records its rule ID. Any use of a draft rule is flagged for review until the Knowledge owner approves that rule. Plain-language definitions reach sellers through 'What do we mean?' only after passing the wording guard.
