Overview

Welcome to the Omni FastFlex® Discovery & Proposal system. This playbook is your all-in-one guide to running high-velocity, high-conversion pre-sales motions for EMV L3 certification projects.

You are not here to “sell” certifications—you are here to orchestrate confidence. This playbook breaks down every tool, workflow, and tactic needed to do just that.

1. Core Philosophy

• Speed and Simplicity for the Customer: We give them a clear path to certification.
• Precision and Profitability for Omni: We only pursue deals where we have confidence in execution and margin.

Your job is to guide the customer through discovery, eliminate ambiguity, and deliver a pre-built proposal that already answers 80% of their internal questions.

2. FastFlex Process Flow (SDR View)

1. Initial Contact / Discovery Call Scheduled
2. Live Call or Email Intake Begins
3. FastFlex Discovery Checklist Completed (see Section 4)
4. Automated Proposal Generated and Shared
5. Customer Reviews and Selects Options
6. Handoff to Cert SME + PM for Deep Dive (if needed)
7. Customer Commits / Contracting
8. FastFlex Project Kickoff

3. Tooling Setup

?? Access the Discovery Checklist

Open in SharePoint

4. FastFlex Discovery Checklist Walkthrough

This checklist is the backbone of every successful FastFlex engagement. It converts early signals into deal clarity. Here’s how to walk it confidently.

1. Customer Info

Capture names, emails, and meeting dates. This is what generates the PDF title and audit trail.

2. Use Case and Terminal Info

Ask them to describe what the solution does from a business perspective (transit, retail, etc.) and when they want to go live. Check “Attended” or “Unattended”. If it’s unattended, note that the proposal must include the Unattended Add-on.

3. Customer Environment

Ask who is on the project from their side: Product Manager, Tech Lead, Compliance. Knowing this helps us tailor who needs to be looped into technical calls.

Ask if any other vendors are involved:

• A gateway service provider (a third party who facilitates the transaction flow but is not a full processor)
• A hardware distributor or Key Injection Facility (KIF)
• Any existing relationship with an ISO, VAR, or certification partner

Understanding this context helps us map the customer’s dependencies.

4. Processor Information

This is one of the most technical sections, and customers often have incomplete answers. The SDR’s job is to capture whatever information the customer knows, while flagging any uncertainty for follow-up during the deep dive phase.

Processor / Acquirer: This refers to the entity that will be responsible for authorizing transactions in the live environment. Examples include Elavon, WorldPay, TSYS, Fiserv, Chase Paymentech, Global Payments, and others. If unsure, ask: “Which company will be handling the actual card transaction approvals when this goes live?”

API / Command Set: Processors use specific developer APIs to connect POS software to their back-end. These APIs are often referred to by names like “Elavon EDC SDK”, “TSYS Sierra”, or “Fiserv Rapid Connect”. Write down what the customer says—even if vague—and we’ll validate.

Certification Toolkit: This is the testing tool that will be used to simulate and validate payment transactions during EMV Level 3 (L3) certification. Common toolkits include:

• ICC Test Tool (Omni has a direct relationship here)
• UL Brand Test Tool (BTT)
• FIME-Certification Suite

Ask: “Do you know which test tool your processor requires you to use for certification?”

Encryption Method: Card-present terminals use encryption to protect sensitive data.

• P2PE (Point-to-Point Encryption) — most common and typically mandated for secure retail environments
  • Hardware-based: encryption occurs inside the secure terminal hardware
  • Software-based: encryption happens in the POS or gateway software layer
• PIN Debit — if they plan to accept PIN-based transactions, additional encryption and device requirements apply

Take time to write this section up clearly. If the customer doesn’t know, write “TBD” and explain that Omni will guide this selection. Just capture what they think they are using. Even if this feels heavy, it’s better to over-document than under-capture. The technical team will sort it out later, but you’ll look professional by showing structure.

5. Terminal Information

Brand and model of terminals (e.g., Verifone M400, Ingenico Lane/3000). Ask:

• Do all terminals run the same OS and payment kernel?
• Who is providing and injecting the keys?
• How are they planning to configure the devices? TMS? Manual?
• Do they own the TMS or does the vendor (e.g., Verifone) control it?

6. Certification Scope

Ask what EMV methods they plan to support (Contact, Contactless, FSA, Wallets). Choose all that apply. Then ask what card brands will be supported in each region. Always clarify any unique networks (e.g., SNAP for government food cards).

7. Regulatory Readiness

This is more of a heads-up for our team. Check off any certifications they have or expect to pursue (PCI L1, L2, SSF, etc.). Ask if they have documentation like EMVCo or PCI LOAs (Letters of Approval) for their hardware/software.

8. Where Will Omni Need to Step In?

This is critical for proposal configuration.

• Acquirer Program Management: Do they want Omni to own the test plan and analyst relationship? Most customers benefit from this, especially for processors like Fiserv who move slowly without expert engagement.
• Terminal Vendor Coordination: If they use Verifone/Ingenico and need build management, check this box.
• Engineering Support: Are we expected to review logs, identify transaction issues, and coordinate functional troubleshooting?
• Tooling Support: Are they leasing test tools (UL, FIME)? Or buying outright? Or do they already own them? Mark appropriately.
• Custom Reports: Some enterprise customers need weekly dashboards, summaries, or reports to support merchant reviews or internal program management.

5. Submitting the Checklist

• Click Submit, Process & Email
• Wait for the confirmation that shows successful PDF generation
• Email will be sent to the Enterprise Sales Team shared mailbox

6. Proposal System Integration

The system will use checklist responses to pre-load the base and add-on pricing into a ready-to-share link. You can:

• Edit if needed (drop-downs in SmartPricingTable)
• Generate PDF from the proposal
• Send to customer with a short, confident email (example included later)

7. Follow-up Process

If customer pushes back on pricing or wants to remove items:

• Use the checklist responses to show what support is needed
• If unclear, tell them you’ll schedule a “certification scoping review”

That review will include:

• SDR (you)
• Sreeja (Cert SME)
• Bilal (Technical PM)

That team will do the final scope alignment before contract.

Final Notes

• Checklist submissions are archived and searchable
• Proposal system is versioned and tied to checklist output
• Every project starts here. Make this flow second nature and you’ll close fast and clean.

Next Section: FastFlex Proposal Generation & SOW Execution
Coming soon