RFP Requirements for an AI Email Assistant: What to Specify

Most RFPs for AI tools are copied from a generic SaaS template with the word AI dropped into a few requirement lines. The vendor answers yes to every row, wins on price, and the risk lands on whoever signed. That is not a procurement process; it is a coin toss with a spreadsheet.

This is the AI-email-assistant version. Five requirement blocks, each written so a vendor cannot answer yes without evidence you can hold - a page, a log entry, a support reply in writing. The scoring table and the paste-ready requirement statements are below.

We build AI Emaily, so we sit inside this category. Where a section names us, we say what we do and do not clear - including the two blocks where a large-enterprise RFP would rank a different answer above us today.

The short answer#

Ask for five requirement blocks, in this order. Functional - what the assistant does inside a mailbox. Autonomy - what it may do without asking. Security - what happens to message content and OAuth tokens. Integration - which providers, which surfaces, which export format. Commercial - packaging, seat lifecycle, and wind-down.

Weight autonomy and security triple. A weak search bar is a nuisance you can live with; an agent that sent on your behalf without a click, or a vendor that trains on your mail, is a category you cannot recover from with a later setting.

Every requirement below is written so the vendor's answer is a document or a demonstrable behaviour. Yes is not an answer to an RFP.

The five requirement blocks#

These map to the sections in a standard software RFP - Functional Requirements, Non-Functional Requirements, Security and Compliance, Integration, Commercial - restated in the language a vendor's sales engineer cannot dodge.

Functional requirements you can paste#

Functional lines are the ones vendors answer with a marketing sentence and mean nothing by. Each of these forces a specific behaviour, an artifact, or a limit stated in writing.

• F1 - Triage: the assistant categorises incoming mail into named buckets (e.g. important, newsletter, notification, cold outreach). Evidence: the taxonomy documented, plus a 24-hour run on a mailbox we supply, with the resulting labels exported.
• F2 - Draft replies: the assistant writes a reply that reflects a configuration the user set - a Personal Context brain, per-client profiles, or explicit style rules - and not a persona inferred from past mail. Evidence: the setting screen and one before/after diff after a written rule change.
• F3 - Approval-gated send: no message leaves a connected mailbox without an explicit user action. Evidence: a screenshot of the queue and the Sent folder in the provider's own webmail after a triaged reply.
• F4 - Summarisation of long threads: the assistant summarises a 30-plus message thread with attachments and cites which message a claim came from. Evidence: a summary run on a thread we supply.
• F5 - Search: the assistant supports natural-language search across all connected accounts (e.g. what did the finance team send about renewals last month). Evidence: a live query, plus a stated position on whether embeddings persist and where.
• F6 - Unsubscribe and cold-email handling: bulk sender and unsolicited outreach are handled without training the user's rules for them. Evidence: a documented mechanism and a per-sender undo.
• F7 - Follow-up detection: the assistant surfaces sent messages that did not receive a reply within a stated window. Evidence: the settings page and one live example.

Autonomy requirements - the ones that stop surprises#

This block is the difference between an assistant and a liability. Write each line as a switch, an artifact, or a stop condition.

• A1 - Per-account autonomy level. The user (or admin) selects Manual, approval-required (Copilot-style), or bounded automatic (Autopilot-style) per connected mailbox, not once for the whole tenant.
• A2 - Action allowlist. Autonomous actions are drawn from a documented list. Anything not on the list requires approval, without exception.
• A3 - Send delay and cancel window. Any auto-send has a stated delay in seconds during which the user can cancel from the mail client, not from a web dashboard.
• A4 - Kill switch. A single action pauses all autonomous behaviour for a mailbox and returns everything to Manual, from the user's phone, in under 10 seconds.
• A5 - Full action log. Every autonomous action lands in an audit log with actor, target, timestamp and reason. Log is exportable to CSV or JSON. Retention is stated in days.
• A6 - Undo on destructive actions. Archive, label, move and unsubscribe each undo from the log entry, individually and in bulk, for a stated window.
• A7 - Untrusted-input handling. The vendor names, in writing, what stops a crafted email from instructing the agent - an action allowlist, output validation before rendering, blocked pixels, sandboxed links, or an equivalent that maps to OWASP's Top 10 for Large Language Model Applications.

Security requirements the questionnaire misses#

Standard vendor questionnaires - the CSA CAIQ, the Shared Assessments SIG - cover the SaaS baseline. AI email needs three more lines that neither template asks by default.

• S1 - No training on customer content. State it as a contract requirement: message bodies, subjects, contacts and metadata are not used to train the vendor's models or third-party models. Evidence: the contract clause and the sub-processor list.
• S2 - Zero-retention with model providers. Where cloud inference is used, the contract with the model provider (OpenAI, Anthropic, Google, or the router) is zero-retention. Evidence: a written statement naming which providers see which content.
• S3 - Envelope-encrypted secrets. OAuth tokens and any bring-your-own-key material are encrypted at rest with a KMS-managed key and never logged or returned in API responses. Evidence: a security architecture doc or a support answer describing the mechanism.
• S4 - Minimum OAuth scopes and provider certification. For Gmail, the assistant requests only the scopes it uses and holds current CASA (Cloud Application Security Assessment) at the appropriate level, per Google's API Services User Data Policy.
• S5 - Sub-processor list, published and versioned. Every third party that touches customer data is named, including model providers. Changes are notified with a stated window.
• S6 - Data residency options where legally required. State it as EU-only processing, US-only processing, or a specified region. Evidence: infrastructure diagram or contract addendum.
• S7 - DPA, SCC and breach-notification window. GDPR-aligned DPA is signable, Standard Contractual Clauses cover transfers, and the breach-notification window is stated in hours, not weeks.
• S8 - Compliance posture, stated honestly. If SOC 2 is in progress rather than complete, the vendor says so and states the target date. A vague we take security seriously is a fail, not a soft yes.

Integration and commercial - the two blocks vendors dodge#

Integration and commercial are where a compliant-looking RFP response falls apart at rollout. Write them tightly.

Scoring the responses#

Score each requirement 0-3 against evidence provided, then multiply by weight. A zero on any triple-weighted line ends the evaluation regardless of the total.

• Weight autonomy (block 2) triple. A2, A3, A5 and A7 are the ones that create outages you cannot undo with a setting.
• Weight security (block 3) triple. S1, S2 and S3 protect the confidentiality contract you make with your users.
• Weight integration double. I1, I3 and I4 decide whether the rollout runs or stalls in month two.
• Weight functional and commercial single. They matter, but they can be renegotiated at renewal in a way autonomy and security cannot.

Red flags in vendor responses#

• The autonomy level is answered as a paragraph rather than a setting. If nobody can point to the switch, the vendor picked your risk tolerance for you.
• The audit log records what the assistant suggested rather than what it changed. Those are different artifacts and only one is evidence at incident-review time.
• The training answer is in the marketing page but not the contract. Marketing pages are edited without notice; the DPA is what a court reads.
• The export runs on request via support. That is an archive-fetch process, not an exit path, and it will not run inside the last week of a contract.
• SOC 2 is mentioned without a date. Either the audit is complete and the report is available under NDA, or it is in progress with a stated auditor and target month, or it is not happening.
• The demo mailbox is the vendor's, not yours. Every functional line except F5 needs your worst thread and your least standard account to score truthfully.
• A prompt-injection question gets a blank look. An assistant that reads untrusted mail and then acts meets two OWASP LLM Top 10 risks at once - prompt injection and excessive agency - and a vendor with no answer for either is telling you something important.

What we would pick and why - honestly#

We build AI Emaily, so this is disclosed rather than reviewed. The recommendation depends on which block your organisation weighs triple.

If your triple-weighted block is autonomy - approval-gated send, per-account levels, an action allowlist, an audit log with undo - we are one of the products built specifically for that shape, and worth putting on the shortlist. Copilot (approval-first) is the v1 default and Autopilot is bounded, opt-in and reversible; every autonomous action lands in an audit log with the reasoning behind it, and destructive actions undo.

If your triple-weighted block is security fundamentals - zero-retention inference, no training on customer content, envelope-encrypted OAuth tokens and BYOK keys, a published sub-processor list, a signable DPA, minimum Gmail OAuth scopes - we clear those and publish the mechanisms on our /security page.

If your triple-weighted block is enterprise identity and formal certification - SAML SSO, SCIM provisioning, a completed SOC 2 Type II report today, an org-wide policy console - we do not clear that bar right now. SOC 2 is on our roadmap rather than in hand, single sign-on and SCIM are not shipped, and our admin story fits teams better than it fits a several-hundred-seat rollout. On that RFP, an assistant that inherits your Microsoft 365 or Google Workspace identity plane, or a competitor that has already published a SOC 2 Type II report, will rank above us. Ask them for the specific artifacts above; do not take the SOC 2 badge as the answer.

Where a competitor has built harder than we have: Superhuman ships a keyboard-first Gmail experience that our all-provider client does not match on that one axis; Shortwave has built more deeply on Gmail archive search; Missive is stronger on shared-inbox collaboration for support teams. Each of those wins on a real dimension a real reader may weight triple, and saying so is why the paragraph above about where we do fit is worth reading. See our comparison pages for the full breakdowns.

Whichever we go on your shortlist for - or don't - the discipline that carries the RFP is the same: every requirement forces evidence, and no yes is accepted without an artifact you can hold at renewal.

Handing it to procurement#

One page, one requirement per row, in the shape below. If procurement cannot lift a row into their template unchanged, the requirement is too soft.