Pre-Sales Demo Playbook

Three buyer-type demo scenarios — what to show, what order, what to avoid

ReferencePre-Sales
🚨 Before Any Demo

Run through the Known Limitations page before every demo. Confirm the customer is not a hard-stop case (BYOK/AWS, >8 dimensions, public sector). Do not proceed to a product demo with a disqualified prospect.

⚠ Data Must Be Loaded

Never demo IFP with an empty or freshly generated application. Load the demo data set first — an empty planning grid is a deal-killer. Allow 30–60 minutes for demo environment prep before any customer call.

Scenario 1 — CFO / Executive

Audience: CFO, VP Finance, Chief Accounting Officer, executive sponsor

What they care about: Time-to-deploy, risk, ROI, and whether the plan integrates across the business.

Show in This Order

  1. IFP landing page — show the 6-module grid; establish that this is a complete suite, not a point solution. Name each module in one sentence.
  2. Top-Down Planning — open TD – Planning and show executive targets vs. bottom-up in the TD – Summary view. Lead with: "You set the target here. Your teams plan bottom-up. This page shows the gap — live."
  3. Executive Dashboard — show the Reporting pack summary page. Highlight that it auto-generates from the planning data — no export, no manual copy-paste.
  4. Time-to-deploy story — verbally cover: Application Framework generates the full suite in hours; partner configures in 8–10 weeks; upgrades are centrally deployed — no rebuild.

What NOT to Show (Before Data Is Loaded)

Three Key Proof Points

  1. 8–10 week deployment via Application Framework — not a 6-month custom build
  2. Single connected suite — Revenue, OpEx, HC, CapEx, BS, and CF in one platform; no reconciliation spreadsheets
  3. Centrally-managed upgrades — future releases deploy without manual rebuilds; customer stays current automatically

Common Objections + Factual Responses

ObjectionFactual Response
"We already have Excel / EPM tool X."IFP replaces spreadsheet-based consolidation by connecting all plan inputs in one model. Version comparison and variance analysis are built in — no manual reconciliation between tools.
"8–10 weeks sounds fast. What's the catch?"The Application Framework generates the model structure — the time savings come from not building custom models from scratch. Configuration and data load are still real work; 8–10 weeks assumes a clean, in-scope implementation.
"We're public sector / we use a private cloud."IFP v2.0+ requires ADO, which runs on AWS. Public sector and sovereign cloud customers cannot use IFP currently. Let's discuss what options exist — [stop and engage Apps team].
"What about headcount planning?"IFP includes job-level headcount planning with pay bands and cost sync to the financial plan. For employee-level detail, it integrates with Operational Workforce Planning. Most FP&A teams find job-level sufficient for budget planning.

Scenario 2 — FP&A Manager

Audience: FP&A Manager, Senior Financial Analyst, Planning Manager, Budget Owner

What they care about: Planning workflow, data freshness, version comparison, how they replace their current process.

Show in This Order

  1. OpEx Planning page — show Progressive Disclosure: select a GL account, switch between methods. Demonstrate that only the relevant inputs appear per method. "Your team doesn't see line items that don't apply to their account."
  2. Line Item Detail — show vendor/functional area tagging on one account. "This is where they get granular — without a separate spreadsheet."
  3. Data load story — describe ADO: actuals come in from the ERP on a schedule via ADO pipelines. "The prior period closes, ADO runs, actuals are in — no manual upload."
  4. IS Variance Analysis — open the two-version comparison. Show how to switch versions and read the variance. "This is your AOP vs. forecast comparison. Already built."
  5. Version comparison workflow — briefly explain how versions are created in Admin and mapped across all 4 models.

What NOT to Show (Before Data Is Loaded)

Three Key Proof Points

  1. Progressive Disclosure — planners only see the inputs relevant to their account's method; fewer errors, less training
  2. Automatic actuals refresh via ADO — no monthly upload task; prior period actuals flow in on schedule
  3. Built-in version comparison — AOP vs. forecast, forecast vs. prior forecast — no separate reporting layer needed

Common Objections + Factual Responses

ObjectionFactual Response
"We need employee-level headcount, not just job levels."IFP HC plans at job/role level with pay bands — which covers 90% of budget planning needs. For employee-level detail, IFP integrates with Operational Workforce Planning. The two systems share data via ADO.
"What if we need a custom planning method?"IFP supports custom planning method extensions. The pattern is documented — add to the methods list, configure in the SYS module, wire the formula, assign to accounts. It's builder work, not custom development from scratch.
"How long does the actuals load take each month?"ADO pipelines run on schedule — typically 15–60 minutes depending on data volume. Once configured, it runs unattended. The admin just confirms the data loaded correctly.
"Can our team still export to Excel?"Anaplan supports native Excel export from any grid. For formatted reports, the management reporting pack exports to PDF. We'd scope exact export requirements during implementation.

Scenario 3 — IT / Architect

Audience: IT Director, Enterprise Architect, Integration Lead, CTO

What they care about: How it's built, how data moves, what they'll need to maintain, security and compliance.

Show in This Order

  1. Application Framework — open the Applications URL; show the wizard. "This is how the suite is deployed — a configuration wizard that generates all 4 models, UX pages, and ADO pipelines in one generation run. No model building from scratch."
  2. Four-model architecture — draw or show: Admin (central config), FP (financial planning), HC (headcount), CE (CapEx). "Admin is the hub. FP is the planning hub. HC and CE are spoke models that import into FP."
  3. ADO pipeline overview — open ADO; show the pipeline list. "Each pipeline is a lightweight extract-transform-load. No memory overhead in the Anaplan workspace — data stays in motion, not in memory."
  4. Polaris model architecture — explain: Polaris engine, 8-dimension limit, optimized for large data volumes vs. Classic engine. "This is not the same Anaplan model you may have seen in v1.x."
  5. Upgrade path — "Future versions of IFP are deployed via the Application Framework centrally. Customer doesn't rebuild — they apply the update. IT's maintenance burden is lower than a custom-built model."

What NOT to Show (Before Data Is Loaded)

Three Key Proof Points

  1. Generated architecture — not a custom model; generated from configuration; consistent structure; easier to maintain and upgrade
  2. ADO: lightweight pipelines — no memory overhead in the workspace; data moves via lightweight pipelines, not Anaplan actions loading data into workspace memory
  3. Polaris: optimized for large data volumes — the engine is purpose-built for the data volumes typical in enterprise financial planning; 8-dimension constraint is the architectural trade-off

Common Objections + Factual Responses

ObjectionFactual Response
"We can't use AWS. We're on Azure / private cloud."ADO is an AWS-native service. IFP v2.0+ requires ADO. This is a hard stop — IFP cannot be deployed in non-AWS environments currently. We should stop and clarify your cloud requirements before proceeding.
"8 dimensions isn't enough for our data model."The 8-dimension limit is a Polaris architecture constraint — it applies to all IFP models. If your implementation requires more than 8 dimensions, IFP is not the right fit. We'd need to review your dimension requirements in detail.
"How do we integrate with our ERP?"ADO connects to your source systems via flat file or API. The typical pattern: ERP exports a flat file to a cloud storage location; ADO picks it up on a schedule and loads into the Admin model. Supported connectors include Snowflake, S3, and standard REST APIs.
"What's the ALM / promotion path from Dev to Prod?"Standard Anaplan ALM — Dev model is the source; promote via the ALM UI or API to Prod. ADO pipelines are promoted separately. The Application Framework generates Dev; IT manages the ALM promotion as part of go-live.
"Who maintains this after go-live?"The customer's admin team handles monthly tasks (period updates, version creation, data load confirmation). The partner handles major changes (new modules, extensions). Anaplan releases upgrades via the Application Framework — the admin applies them.

Demo Environment Prep Checklist

← PreviousNext →