Scoping & Pricing KT

How to use this guide: Use the IDP Scope or Anypoint Scope tabs as your call reference. Score complexity first, then go to Pricing. For live calls, open Live Checklists and tick items in real time.

Product Lines

Document AI

MuleSoft IDP

Extracts structured data from unstructured documents (PDF, image, Word, Excel, scans, faxes) and classifies document types for downstream delivery or human review.

Integration / iPaaS

Anypoint Platform

Core integration layer — connects source → target systems via API, database, file, or event-driven flows. Moves, transforms, and delivers data between systems.

Salesforce-native

MuleSoft for Flow

Lightweight automation letting Salesforce admins invoke MuleSoft-published APIs directly from Flow Builder — no full Anypoint Studio development required.

Critical rule: Most real deals blend IDP + Anypoint together — e.g. "extract data from a document, then push it into a target system." Never assume a customer request maps cleanly to one product.

When to use each tab

Document extraction deal

Open IDP Scope tab. Run 12-question checklist. Score complexity. Go to Pricing → IDP table.

System-to-system integration

Open Anypoint Scope tab. Run 9-question checklist. Score source + target separately. Go to Pricing → Anypoint mechanics.

Blended IDP + Integration

Run both checklists. Score and price each separately. IDP = per document type. Anypoint = per flow.

MuleSoft for Flow

Start with Anypoint Scope tab §4.4. Confirm trigger is inside Salesforce Flow Builder. Verify licensing separately.

4-Step Call Flow

Identify the trigger

What business pain or event is driving this project right now — compliance deadline, manual labor cost, error rate, new system rollout?

Map source → target

For every data point in scope, name the exact source system and exact target system. Never leave this as "the CRM" or "our ERP" — get the product name and version/deployment.

Run the complexity checklist live

IDP deals → IDP Scope tab. Anypoint/Flow deals → Anypoint Scope tab. Do this on the call or immediately after from the recording/transcript.

Flag open items explicitly

Get unresolved items into an SOW "Open Items & Decision Points" section rather than guessing. Unconfirmed ingestion channel / unconfirmed API access = #1 source of scope creep post-go-live.

Rules of Thumb

Record every call

Use a passive AI transcript tool (e.g. Krisp AI). Always ask for the recording/transcript before the call ends — rebuild scope from transcript, not memory.

Never assume ingestion channel

EAC inbox vs. Outlook vs. Gmail vs. fax-to-email vs. SharePoint — almost never confirmed on discovery. Flag as explicit SOW assumption. Always nail down the literal endpoint.

Bi-directional = 2 flows

If a customer says "bi-directional" and can't tell you what writes back and when — park it as Phase 2. Exception: closed-won Opp in SF → create SO in QB → write back SO# = one flow.

Cloud vs. on-prem = #1 cost driver

Confirm deployment before pricing connectivity. Cloud vs. on-prem of source/target is the single biggest cost driver — not the data model.

Legacy systems need connector strategy

QuickBooks Desktop, Sage 100, IQMS — needed workarounds (Web Connector, ODBC, file-based polling). Ask if the system exposes REST APIs natively or only legacy protocols.

Template variance multiplies IDP effort

Each vendor PDF template requires its own extraction prompt. Always ask "how many distinct source templates exist?" — not just "what document types?"

Large docs need splitting strategy up front

PDFs >40 pages can run into thousands of pages (EliteExperts case). Custom chunking + monitoring needed. Treat >40-page and bundled files as an architecture decision.

Use this for any deal involving document extraction or classification. Ask every question even if the answer seems obvious — the answer directly changes t-shirt size and price.

Discovery Checklist — 12 Questions

1What is the source system the documents are picked up from? Email inboxSharePointEAC/fax bridgeScanning deviceSecure portalSFTP

2What file extensions are in scope? PDFImage/scanExcelWordOther

3What distinct document types are in scope? Each is scoped and priced separately. e.g. invoice, PO, sales order, driver's license, prescription, lab report, insurance policy, inspection report, handwritten notes

4Is any document type routinely longer than 40 pages? → Complex if yes

5Are document formats standard/consistent or variable? Standard → Simple Some variance → Medium High variance → Complex

6Are there multiple source systems/channels (multiple inboxes, portals, carriers)?

7How many fields to extract per document type? <10 Simple 10–15 Medium >15 Complex

8Do documents contain checkboxes? None → no impact ≤5 → Medium >5 → Complex

9Do documents contain diagrams or images with data to extract? If yes → Medium minimum

10What is the target system the extracted data lands in? Salesforce, Workday, database, Sage, Pioneer Rx, Cerner — confirm cloud/on-prem per Anypoint §4.2

11Multi-record processing: will every document arrive as its own single PDF, or can one email/upload contain multiple attachments/records?

12Will any inbound file bundle multiple distinct documents together? (e.g. one PDF = invoice + packing slip + PO) If yes → Complex

Complexity Scoring Matrix

Factor	Simple	Medium	Complex
Document length	<40 pages	—	>40 pages (splitting + aggregation)
Format consistency	Standard, consistent	Some variance	High variance / different template per source
Fields extracted per doc type	<10 fields	10–15 fields	>15 fields
Checkboxes to extract	None	≤5 checkboxes	>5 checkboxes
Diagrams/images with data	None	Present (→ at least Medium)	Present + high field count
Source systems/channels	Single source	2–3 sources	4+ sources / per-source templates
Bundled/multi-doc files	Not present	—	Present — bundle-splitting logic required

Common Source Systems

Email inbox (Outlook / Gmail)

IDP can monitor an inbox directly as the ingestion point.

Scanning device / service

File-creation event triggers IDP processing automatically — useful during a digitization rollout.

Secure document portals

e.g. SecureDocs-style portals — usually require an RPA layer to log in and download on a schedule, since these portals rarely expose a public API.

Existing file server / SharePoint

Used for retroactive/backfill processing of existing documents, plus new incoming documents.

Non-Negotiable Technical Call-Outs

Confidence thresholds & human review: Every IDP scope includes a confidence threshold (e.g. <80%) that routes low-confidence extractions to a human review queue. Always scope this explicitly — it is a distinct configuration line item, not free with extraction.

Deduplication logic: Needed whenever the same document could arrive more than once (fax retries, multi-channel submission). Scope as part of the integration logic, not IDP extraction.

Large-document workaround: For huge files (thousands of pages), expect a custom chunking component (e.g. Mule PDFBox module) plus monitoring/alerting for chunking failures — call this out as its own effort line. It is fragile and needs support.

Additional Discovery Questions

1Any document type legally restricted from AI processing (NDA, regulatory rules)? Flag as out-of-scope / human-only in SOW.

2Ask for volume AND average page count together (e.g. "~1,200 docs/year, ~40 pages average") — both combine to drive effort differently than either alone.

3For every document type, separate "must-have" fields from "nice-to-have" fields — scope an MVP field set, not everything day one.

4Are documents always in one language or multiple languages? Multi-language changes the extraction/OCR model, not just volume.

5How do documents currently arrive — email attachment, portal download, or scanned physical mail? Each has a different ingestion architecture even if the document type is identical.

6Never quote IDP effort without 3–5 real sample documents per distinct format/template variant. A verbal description is not enough.

7Ask what confidence threshold the business is comfortable with AND who operationally owns the human-review queue day to day. A threshold without a named owner is an incomplete scope item.

8Does any inbound file mix a structured form with free-text/handwritten notes in the same doc (hybrid document)? Needs splitting/dual-extraction step — score above a plain structured document.

9If customer has a manual second-person verification step, ask whether they want it preserved as human-in-the-loop post-automation or fully eliminated. This is a business decision, not a technical default.

10Does extracted data need to trigger downstream automation (renewal reminders, compliance flags, approval workflows)? If yes → that logic is Anypoint scope, price separately.

11When an engagement mixes structured/templated sources with unstructured freeform sources, score and price them separately even if the customer calls them "the same document."

12Confirm whether downstream delivery needs full Anypoint Platform or lighter native Salesforce Flow ingestion path. Choosing Anypoint over Flow when Flow would suffice adds ~half-day of avoidable configuration effort.

Core principle: Anypoint scoping is two questions asked twice — once for the source system, once for the target system — plus the business logic that sits between them.

Discovery Checklist — 9 Questions

1What is the source system?

2Is the source system API-enabled? If not, what protocols does it expose? ODBCSOAPFlat file/SFTPEDIDatabase direct

3Is the source system cloud-hosted or on-prem?

4What is the target system?

5Is the target system API-enabled?

6Is the target system cloud-hosted or on-prem?

7What business objects are being exchanged? Name the actual object per system. "Salesforce Opportunity" not just "deal" — Account, Order, Invoice, Product, Payment

8What actions are needed per object and in which direction? If bi-directional, what exactly writes back and on what trigger? getextractreceivecreateupdatesync

9Is there business logic between source and target (transformation, mapping, dedup, conditional routing, aggregation)? If yes → Complex Pass-through → Medium

Connectivity Complexity Matrix

Apply once to source, then again to target. The higher of the two scores sets the connectivity baseline.

Deployment	API Access	Complexity
Cloud	API-enabled	Simple
On-Prem	API connectivity available	Medium
On-Prem	No API connectivity	Complex — custom coding required

Business Object & Logic Complexity

MediumStraight pass-through / 1:1 field mapping — no transformation beyond field mapping and basic validation. Standing rule: "if business logic is present then Complex, otherwise Medium."

ComplexTransformation / conditional logic — field-level business rules, conditional routing, currency/unit conversion, multi-object aggregation.

ComplexBi-directional flows — always scope as two integration patterns, not one. Can double flow count. Price as two separate line items unless proven trivial.

AdditionalMulti-entity / multi-company targets — one source feeding multiple company instances (e.g. 1 Salesforce org → 3 QuickBooks Desktop companies) adds routing logic. Price as additional effort on top of base flow.

MuleSoft for Flow — Discovery Starting Point

Scope like lightweight Anypoint, but Salesforce-Flow-native. Validate against current datasheet before quoting — do not assume it uses the same Flows+Messages model as core Anypoint.

10Is the requirement being triggered from inside Salesforce Flow Builder, or does it need a standalone API/process outside Salesforce's runtime?

11Does the target/source already have a MuleSoft-published "Flow-ready" action, or would a custom API need to be built and exposed to Flow?

12Same source/target complexity questions (§4.2) still apply — Flow does not remove the cloud/on-prem/API question.

13Confirm licensing/consumption model with the MuleSoft for Flow datasheet before quoting.

Additional Discovery Questions

1For every shared entity, ask directly: "which system is the system of record?" Get the answer in writing before building any sync logic.

2What happens if the same record is updated in both systems simultaneously — which system wins? "Bi-directional" is not complete until this conflict-resolution rule is defined.

3Should deletes propagate between systems — hard delete or soft delete/archive flag? Undefined delete behavior = common source of data-loss incidents post go-live.

4Does the source support push-based real-time events (webhooks, Change Data Capture, Platform Events) or must MuleSoft poll on a schedule?

5Ask about API rate limits on both source and target. Confirm whether a separate bulk export exists for the one-time historical data load — a backfill is a distinct effort line from ongoing sync.

6How many environments are needed (Dev/QA/UAT/Prod)? Can the customer provide non-production credentials or sandbox access for testing?

7How should integration failures be handled — silent log, email alert, or retry queue? Who on the customer side owns the error queue?

8Does the integration depend on a third party outside the customer's control (distributor, partner, vendor feed)? Confirm they are aware and have agreed to the timeline.

9Is there a hard external deadline driving the project (board meeting, audit, fiscal year-end)? Capture explicitly — often dictates timeline more than technical complexity.

10For legacy on-prem systems with no REST API, map all connectivity options before defaulting to custom code: ODBC, business-object/COM interface, third-party REST wrapper, flat-file import/export.

11For objects with child/line-item records (invoice lines, order lines), does the target need line-item-level detail or a header-level summary?

12If the customer syncs on a fixed cadence, ask whether that's a deliberate business choice or a limitation of current tooling. Don't assume the new integration should preserve the old cadence.

13Does any personal data crossing systems trigger data-residency or privacy requirements (e.g. GDPR) — especially if source/target or users sit outside the home jurisdiction?

14Is an audit trail of every synced record required for compliance or financial reporting? This is a distinct build item — never assumed to come free with the base sync.

15If the integration touches quoting/pricing, do multiple price books or pricing tiers exist? Multiple price books multiply mapping and testing effort — count as separate scope.

Cross-Cutting Discipline

Verify every use case against the transcript: Label each proposed use case Confirmed / Partially Discussed / Not Discussed before it goes in an SOW.

Distinguish existing automation from new build: If a workflow already exists and the integration just feeds it better data — call it a beneficiary, not a deliverable.

Treat "nice to have" language literally: "If it can be implemented, that'd be great" = mark as optional/stretch-goal in SOW, not a confirmed requirement.

Confirm stated tool boundary: If a stakeholder says "we will only use MuleSoft to insert data" — anything outside that boundary is explicitly out of scope.

Rule: Complexity scoring must always come before pricing. Never quote price before complexity is scored.

IDP Pricing — Per Document Type

IDP is priced as a fixed fee per document type, scaled by complexity tier. Structure every IDP proposal as a document-type line-item table — not one blended project fee.

Document Type	Complexity	Illustrative Fixed Fee
Handwritten operational documents	Complex	$3,500
Plant visit report (structured)	Medium	$3,500
VIP inspection report (structured)	Medium	$3,500
Standard invoice / PO / sales order (consistent template)	Simple	$3,500
Insurance policy summary (per carrier template)	Medium–Complex	$3,500+ Depends on leverage and carrier count

Note: Use these as anchors, not a rate card to copy blindly. Every customer's flow count and volume differs. Price is per document type — multiple document types = multiple line items.

Anypoint Platform — Pricing Mechanics

Pricing unit: Flows

Each distinct integration pipeline = one flow. Example: "NetSuite ↔ Salesforce case sync" = 1 flow. Packages include a flow allocation sized to projected need — get the customer's realistic flow count from the discovery checklist before recommending a package.

Flow count traps to avoid

• Bi-directional sync = 2 flows minimum, not 1 — price as two line items

• Multi-company routing (e.g. 1 SF org → 3 QB companies) = base flow + routing layer effort

• Historical backfill = distinct scope item from ongoing incremental sync — price separately

• MuleSoft for Flow — confirm licensing model with datasheet, do not assume same as core Anypoint

Every SOW produced from a scoping call follows this shape. Use it as your outline when drafting the deliverable after a call.

Standard SOW Structure — 14 Sections

Executive summary / opportunity overview

Current-state pain points

From the discovery call — this is your ROI narrative.

In-scope systems and stakeholders

Scope — document types (IDP) and/or integration flows (Anypoint)

Each with a complexity rating.

Key integration/extraction logic

Deduplication, confidence thresholds, error handling, audit trail.

Explicit out-of-scope table

Name what was discussed but is NOT included — prevents scope-creep disputes later.

Timeline

Milestone table with owners and deliverables per week/phase.

Pricing

Line-item breakdown, payment terms, ROI reference.

RACI table

Assumptions & dependencies

Acceptance criteria

Change management process

Confidentiality / compliance requirements

HIPAA/BAA etc. if applicable.

Governing law and signature blocks

Use this tab during live calls. Tick each item as it's confirmed. Hit "New Call" to reset before your next call.

IDP Discovery Checklist

0 / 15 confirmed

Document Basics

Source system for document pickup confirmed (email / SharePoint / EAC / portal / SFTP / scanner)

File extensions in scope confirmed (PDF / image / Excel / Word / other)

Distinct document types in scope — listed each by name

Any document type routinely >40 pages? (splitting + aggregation required if yes)

Format & Fields

Format consistency assessed: standard / some variance / high variance

Number of distinct source templates/formats confirmed (not just doc types)

Multiple source systems/channels confirmed (single / 2–3 / 4+)

Fields to extract per document type counted (<10 / 10–15 / >15)

Checkboxes present and counted (none / ≤5 / >5)

Diagrams or images with data to extract? (yes → Medium minimum)

Target & Processing

Target system and deployment confirmed (name + cloud/on-prem)

Multi-record handling confirmed (one doc per file vs. multiple attachments per email)

Bundled/multi-document files possible? (one PDF containing multiple doc types = Complex)

Technical Requirements

Confidence threshold + human review queue scoped (always required)

Deduplication logic required? Audit trail / compliance (HIPAA etc.) required?

Anypoint / Integration Checklist

0 / 10 confirmed

Source System

Source system name + version confirmed

Source: API-enabled? Cloud or on-prem? (Connectivity complexity scored)

Target System

Target system name + version confirmed

Target: API-enabled? Cloud or on-prem? (Connectivity complexity scored)

Data & Logic

Business objects to exchange named per system (exact object name, not generic)

Actions per object confirmed (get/extract/create/update) and direction

Business/transformation logic between systems assessed

Bi-directional? If yes — exactly what writes back and on what trigger?

Multi-entity/multi-company routing required?

Realistic flow count and message volume confirmed (for licensing tier)