Original KT Document — Sections 0–3

MuleSoft Practice — Scoping & Pricing Knowledge Transfer Guide

Covering MuleSoft IDP · MuleSoft Anypoint Platform · MuleSoft for Flow

0. Purpose of This Document

This guide is the handover reference for scoping MuleSoft engagements — MuleSoft IDP (Intelligent Document Processing), MuleSoft Anypoint Platform (integration/iPaaS), and MuleSoft for Flow — the way scoping has actually been done on live customer calls to date. It captures the discovery question set, the complexity-scoring logic used to translate customer answers into a t-shirt size (Simple / Medium / Complex), and pricing patterns pulled from real deals we've scoped.

Treat this as a living checklist to bring into every scoping call, not a static reference to read once. Update it after every new deal — new document types, new source/target systems, and new pricing data points all belong here.

How to use this document

Print or duplicate Section 3 (IDP) and Section 4 (Anypoint) as your live call checklist. Use Section 6 (Pricing Framework) only after complexity is scored — never quote price before scoring complexity.

1. Product Line Overview

We scope three related but distinct MuleSoft products. Do not assume a customer request maps cleanly to one product — most real deals (see case studies in Sections 3 and 4) blend IDP + Anypoint together, e.g. "extract data from a document, then push it into a target system."

1.1 MuleSoft IDP (Intelligent Document Processing)

Extracts structured data out of unstructured or semi-structured documents (PDF, image, Word, Excel, scans, faxes) and classifies documents by type, so the extracted data can be handed off to a downstream system or human review queue.

1.2 MuleSoft Anypoint Platform

The core iPaaS / integration layer — connects a source system to a target system via API, database, file, or event-driven flows. This is where extracted IDP data (or any system-to-system data) actually gets moved, transformed, and delivered.

1.3 MuleSoft for Flow

A lighter-weight, Salesforce-Flow-native automation capability that lets Salesforce admins invoke MuleSoft-published APIs/processes directly from Flow Builder, without a full Anypoint developer build.

2. General Scoping Methodology

Regardless of product, every scoping call follows the same shape. This is the muscle memory to build before diving into the product-specific checklists.

2.1 The Four-Step Call Flow

1. Identify the trigger: what business pain or event is driving this project right now (compliance deadline, manual labor cost, error rate, new system rollout)?
2. 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" — we need to get the product name and version/deployment (see Section 4).
3. Run the relevant complexity checklist (Section 3 for IDP, Section 4 for Anypoint/For Flow) live on the call, or immediately after from the recording/transcript.
4. Flag open items explicitly and get them into an SOW "Open Items & Decision Points" section rather than guessing — unresolved items (e.g. unconfirmed ingestion channel, unconfirmed API access) are the #1 source of scope creep after go-live.

2.2 Rules of Thumb

• Get an AI Transcript or Meeting Recorder: All Calls and conversations Need to be strictly recorded in our Local or personal AI Transcript recorder or Meeting recorder — make sure this tool is passive or non-invasive. Example: Krisp AI
• Get a transcript or recording: Several deals required scoping strictly off the call transcript. Always ask for the recording/transcript before the call ends which helps you rebuild the scope precisely instead of from memory.
• Never assume the ingestion channel: The ingestion source (EAC inbox vs. Outlook vs. Gmail vs. fax-to-email bridge vs SharePoint) will almost never be confirmed on the discovery call and will need to be flagged as an explicit SOW assumption. Always nail down the literal endpoint IDP or Anypoint will listen to or source of the document.
• Bi-directional sync doubles the surface area: On most of the deals, "bi-directional" requirements will be sounded like one flow to the customer but is really two integration patterns. If a customer says "bi-directional" or "two-way sync" and can't immediately tell you what writes back and when, park it as a Phase 2 / change order rather than pricing it into Phase 1 — but for example if the Opportunity is closed won in Salesforce which needs to create a sales order inside QuickBooks and we need to write back the sales order number from QuickBooks into Salesforce then this is considered as one Flow.
• Confirm deployment before pricing connectivity: On few of the deals we need to confirm the Target and source System deployment availability to be on-cloud or on-prem to confirm the connectivity — this will be the single biggest cost driver was cloud vs. on-prem deployment of the source/target system — not the data model. Always ask this before any other technical question.
• Desktop / legacy systems need a connector strategy: QuickBooks Desktop (vs. Online), Sage 100 (ProvideX/legacy), and IQMS on older on-prem builds all needed a workaround (Web Connector, ODBC/DB connector, file-based polling) instead of a clean REST call. Ask specifically whether the system exposes REST APIs natively or only legacy protocols (ODBC, SOAP, flat file, EDI).
• Template variance multiplies IDP effort: On most of the deals, each of the document can be a different PDF template, meaning each vendor/Client effectively required its own extraction prompt to be written. Always ask "how many distinct source templates/formats exist across all your document sources?" — not just "what document types."
• Large or bundled documents need a splitting strategy up front: On the EliteExperts deal, some inbound PDFs ran into the thousands of pages and required a custom chunking workaround; chunking failures needed monitoring/alerting. Treat >40-page and bundled/multi-document files as an architecture decision, not a footnote.

3. MuleSoft IDP — Scoping Framework

This is the standing discovery checklist for any deal involving document extraction/classification. Ask every question below on the call — even if the answer seems obvious — because the answer directly changes the t-shirt size and the price.

3.1 Discovery Checklist (ask on every call)

1. What is the source system the documents are picked up / processed from? (email inbox, SharePoint, EAC/fax bridge, scanning device/service, secure document portal, SFTP, etc.)
2. What file extensions are in scope? (PDF, image/scan, Excel, Word, etc. — for a few additional format types we would need the conversion of format effort considered)
3. What distinct document types are in scope? Each is scoped and priced separately (e.g. invoice, purchase order, sales order, driver's license, medical prescription, medical report, lab report, insurance policy summary, inspection report, handwritten field notes).
4. Is any document type routinely longer than 40 pages? If yes → splitting logic + data aggregation across chunks is required → Complex.
5. Are document formats standard/consistent, or do they vary a lot? Standard format → Simple. Some variance → Medium. High variance (e.g. different template per source/carrier) → Complex.
6. Are there multiple sources the files need to be extracted from (multiple inboxes, multiple partner portals, multiple carriers)?
7. How many fields need to be extracted per document type? <10 fields → Simple. 10–15 fields → Medium. >15 fields → Complex.
8. Do the documents contain checkboxes that must be identified/extracted? >5 checkboxes → Complex. ≤5 checkboxes → Medium. None → no added complexity.
9. Do the documents contain diagrams or images from which data must be collected? If yes → Medium (minimum).
10. What is the target system the extracted data lands in? (Salesforce, Workday, a database, Sage, Pioneer Rx, Cerner, etc. — confirm deployment per Section 4.2.)
11. Multi-record processing: will every document arrive as its own single PDF, or can one email/upload contain multiple attachments / multiple records?
12. Will any inbound file bundle multiple distinct documents together (e.g. one PDF containing an invoice + a packing slip + a PO)? If yes → Complex (bundle-splitting logic required).

3.2 Complexity Scoring Matrix

Factor	Simple	Medium	Complex
Document length	< 40 pages	—	> 40 pages (splitting + aggregation needed)
Format consistency	Standard, consistent format	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 (drives to at least Medium)	Present + high field count
Multiple source systems/channels	Single source	2–3 sources	4+ sources / per-source templates
Bundled / multi-document files	Not present	—	Present — requires bundle-splitting logic

3.3 Common Source Systems Observed

• 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 for referral packages — usually require an RPA layer to log in and download files on a schedule, since these portals rarely expose a public API.
• Existing file server / SharePoint: Used for retroactive/backfill processing of documents already on file, in addition to new incoming documents.

3.5 Non-Negotiable Technical Call-Outs

• Confidence thresholds & human review: Every IDP scope we've delivered includes a confidence threshold (e.g. <80%) that routes low-confidence extractions to a human review queue rather than auto-committing bad data. Always scope this explicitly — it is a distinct configuration line item, not something that comes 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 consistently huge files (thousands of pages), expect a custom chunking component (e.g. Mule PDFBox module or equivalent) plus monitoring/alerting for chunking failures — call this out as its own effort line, it is fragile and needs support.

Original KT Document — Sections 4–9

4. MuleSoft Anypoint Platform — Scoping Framework

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

4.1 Discovery Checklist (ask on every call)

1. What is the source system?
2. Is the source system API-enabled? If not, what protocols does it expose (ODBC, SOAP, flat file/SFTP, EDI, database direct)?
3. Is the source system cloud-hosted or on-prem?
4. What is the target system?
5. Is the target system API-enabled?
6. Is the target system cloud-hosted or on-prem?
7. What business objects are being exchanged? (e.g. Account, Order, Invoice, Product, Payment — name the actual object per system, e.g. "Salesforce Opportunity" not just "deal.")
8. What actions are needed per business object? (get / extract / receive / create / update / sync — and in which direction; if bi-directional, define exactly what writes back and on what trigger.)
9. Is there business logic to apply between source and target for this object (transformation, mapping, deduplication, conditional routing, aggregation)? If yes → Complex; a straight pass-through mapping is the Medium default.

4.2 Connectivity Complexity Matrix (apply once to source, once to target)

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

4.3 Business Object & Logic Complexity

• Straight pass-through / 1:1 field mapping: No transformation logic beyond field mapping and basic validation → counts toward Medium, not Simple, per our standing rule ("if yes then complex otherwise medium" for business logic presence).
• Transformation / conditional logic present: Field-level business rules, conditional routing, currency/unit conversion, multi-object aggregation → Complex.
• Bi-directional flows: Always scope as two integration patterns, not one — this alone can double the flow count and should be reflected as two separate line items unless proven trivial.
• Multi-entity / multi-company targets: One source feeding multiple company instances/tenants in the target (e.g. one Salesforce org → 3 QuickBooks Desktop companies) adds a routing-logic layer — price as additional effort on top of the base flow, not folded in.

4.4 MuleSoft for Flow — Discovery Starting Point (validate before quoting)

MuleSoft for Flow is scoped like a lightweight Anypoint engagement, but the packaging and limits are Salesforce-Flow-native rather than full Anypoint Studio development. Until we have more deal history, treat this checklist as a draft and confirm against the current datasheet:

10. Is the requirement being triggered from inside Salesforce Flow Builder, or does it need a standalone API/process outside Salesforce's runtime?
11. Does the target/source system already have a MuleSoft-published "Flow-ready" action, or would a custom API need to be built and then exposed to Flow?
12. Same source/target complexity questions as Section 4.2 still apply — Flow does not remove the cloud/on-prem/API question, it only changes who builds and triggers the integration.
13. Confirm licensing/consumption model directly with the MuleSoft for Flow datasheet before quoting — do not assume it uses the same Flows+Messages model as core Anypoint (Section 6.1) without checking.

5. Pricing Framework

Complexity scoring (Sections 3.2 and 4.2) must always come before pricing. Below are the pricing mechanics and the actual pricing benchmarks pulled from deals we've scoped — use them as anchors, not as a rate card to copy blindly, since every customer's flow count/volume differs.

5.1 Anypoint Platform Pricing Mechanics

• Pricing unit — Flows: Each distinct integration pipeline is one flow (e.g. "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 (Section 4) before recommending a package.

5.2 IDP Pricing Pattern — Per Document Type

IDP has consistently been priced as a fixed fee per document type, scaled by the complexity tier from Section 3.2 — not as one blended project fee. Structure every IDP proposal as a document-type line-item table:

Document Type	Complexity	Illustrative Fixed Fee
Handwritten operational documents	High / 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 per carrier	$3,500 + depending on the leverage we have

5.3 Implementation Timeline Mechanics

(Section reserved for future updates.)

6. Standard SOW Structure

Every SOW we've produced from a scoping call has followed roughly this shape. Use it as the outline when you sit down to draft the deliverable after a call.

1. Executive summary / opportunity overview
2. Current-state pain points (from the discovery call — this is your ROI narrative)
3. In-scope systems and stakeholders
4. Scope — document types (IDP) and/or integration flows (Anypoint), each with a complexity rating
5. Key integration/extraction logic (dedup, confidence thresholds, error handling, audit trail)
6. Explicit out-of-scope table — name what was discussed but is NOT included, to prevent scope-creep disputes later
7. Timeline — milestone table with owners and deliverables per week/phase
8. Pricing — line-item breakdown, payment terms, ROI reference
9. RACI table
10. Assumptions & dependencies
11. Acceptance criteria
12. Change management process
13. Confidentiality / compliance requirements (HIPAA/BAA etc. if applicable)
14. Governing law and signature blocks

7. Master Discovery Checklist (Print/Copy for Live Calls)

7.1 IDP Quick Checklist

• ☐ Source system(s) for document pickup
• ☐ File extensions in scope (PDF / image / Excel / Word / other)
• ☐ Distinct document types in scope (list each by name)
• ☐ Any document type routinely > 40 pages?
• ☐ Format consistency: standard / some variance / high variance?
• ☐ Multiple source systems/channels?
• ☐ Fields to extract per document type (count)
• ☐ Checkboxes present? How many?
• ☐ Diagrams/images with data to extract?
• ☐ Target system(s) and deployment
• ☐ Multi-record handling — one doc per file, or multiple attachments/records per file?
• ☐ Bundled/multi-document files possible?
• ☐ Confidence threshold + human review queue required?
• ☐ Dedup logic required?
• ☐ Audit trail / compliance requirement (HIPAA, etc.)?

7.2 Anypoint / Integration Quick Checklist

• ☐ Source system name + version
• ☐ Source: API-enabled? Cloud or on-prem?
• ☐ Target system name + version
• ☐ Target: API-enabled? Cloud or on-prem?
• ☐ Business objects to exchange (named per system)
• ☐ Actions needed per object (get/extract/receive/create/update) and direction
• ☐ Business/transformation logic required between systems?
• ☐ Bi-directional? If so, what exactly writes back and on what trigger?
• ☐ Multi-entity/multi-company routing required?
• ☐ Realistic flow count and message volume (for licensing tier)

9. Additional Checklist Items

9.1 IDP — Additional Discovery Questions

1. Is there any document type the customer is contractually or legally restricted from processing with AI (e.g. NDA clauses that prohibit AI review, regulatory rules against AI transcription of calls)? If yes, that document type must be flagged and routed straight to human handling — never through automated extraction — and should be called out explicitly as an out-of-scope / human-only item in the SOW.
2. Beyond "what document types," ask for volume AND average page count together (e.g. "~1,200 docs/year, ~40 pages average") — the two combine to drive effort very differently than either alone.
3. For every document type, separate "must-have" fields from "nice-to-have" fields. This lets you scope an MVP field set instead of pricing every field the customer can imagine on day one.
4. Ask whether documents are always in one language or can arrive in multiple languages — this changes the extraction/OCR model, not just the volume.
5. Ask exactly how documents currently arrive: email attachment, portal download, or scanned physical mail. Each has a different ingestion architecture even if the document type is identical.
6. Never quote IDP effort without asking for 3–5 real sample documents per distinct format/template variant. Sample documents are what let you size the extraction model accurately — a verbal description of the document is not enough.
7. Ask what confidence threshold the business is comfortable with, and — separately — who operationally owns the human-review queue day to day. A threshold number without a named owner is an incomplete scope item.
8. Ask if any inbound file mixes a structured form with free-text/handwritten notes in the same document (a hybrid document). These often need a splitting or dual-extraction step before classification, and should be scored above a plain structured or plain unstructured document of the same type.
9. If the customer currently has a manual second-person review/verification step, ask explicitly whether they want that dual-control step preserved as a human-in-the-loop gate post-automation, or fully eliminated. This is a business decision that changes the confidence-threshold configuration, not a technical default.
10. Ask whether the extracted data needs to trigger any downstream business automation (renewal reminders, compliance flags, approval workflows). If yes, that logic belongs in the Anypoint/integration scope, not the IDP extraction line item — price it separately.
11. When an engagement mixes structured/templated sources (e.g. a fixed Excel template) with unstructured freeform sources (e.g. a scanned PDF) under one project, score and price them separately even if the customer thinks of them as "the same document." Structured extraction is materially cheaper to build and tune than unstructured extraction.
12. Confirm whether the downstream delivery needs full Anypoint Platform or can be met with a lighter native Salesforce Flow ingestion path. Choosing Anypoint over Flow when Flow would suffice adds avoidable ingestion-configuration effort — budget roughly an extra half-day of configuration work when Anypoint is pulled in over a Flow-native path, and confirm this is actually necessary before defaulting to it.

9.2 Anypoint / Integration — Additional Discovery Questions

1. For every shared entity (customer, account, order, etc.), ask directly: "which system is the system of record?" Get the answer in writing before building any sync logic — do not infer it from which system happens to be more modern or more central to the conversation.
2. Ask what should happen if the same record is updated in both systems at nearly the same time — which system wins? "Bi-directional" is not a complete answer until this conflict-resolution rule is defined.
3. Ask whether deletes should propagate between systems, and if so, whether that should be a hard delete or a soft delete/archive flag. Undefined delete behavior is a common source of data-loss incidents post go-live.
4. Ask whether the source system supports push-based real-time events (webhooks, Change Data Capture, Platform Events) or whether MuleSoft must poll on a schedule. This materially changes both latency expectations and licensing/message volume.
5. Ask about API rate limits on both source and target, and confirm whether a separate bulk export/import mechanism exists for the one-time historical/initial data load — a one-time backfill is a distinct effort line from the ongoing incremental sync and should be scoped and priced separately.
6. Ask how many environments are needed on each side (Dev/QA/UAT/Production) and whether the customer can actually provide non-production credentials or sandbox access for testing — do not assume anything beyond production access will be available.
7. Ask explicitly how integration failures should be handled: silent log, email alert, or retry queue — and who on the customer side owns monitoring that error queue. An error-handling design with no named owner is incomplete.
8. Ask whether the integration depends on any third party outside the customer's direct control (an external distributor, partner, or vendor feed). If so, confirm that third party is already aware of and has agreed to the integration and its timeline — external-party onboarding is one of the most common causes of stalled go-live dates.
9. Ask whether there is a hard external deadline driving the project (a board meeting, an audit, a fiscal year-end, a contract renewal). Capture it explicitly as a project dependency/driver, not just background context — it often dictates the whole timeline more than technical complexity does.
10. When a legacy on-prem system has no native REST API, map every available connectivity option before assuming custom coding is the only path: direct database/ODBC access, a vendor-specific business-object/COM interface, a third-party REST wrapper product, a dedicated connector product, or flat-file import/export. A third-party wrapper is frequently faster and cheaper to implement than fully custom code, and should be priced as the default option, not custom coding.
11. For any object with child/line-item records (invoice line items, order line items, quote line items), confirm explicitly whether the target system needs line-item-level detail or whether a header-level summary record is sufficient for the customer's reporting needs. This changes both the field count and the mapping complexity.
12. If the customer's current process syncs on a fixed cadence (e.g. a few times per week), ask whether that cadence is a deliberate business choice or simply a limitation of their current tooling. Don't assume the new integration should preserve the old cadence by default — ask what cadence they'd actually prefer if cost/technical limits were removed, then price accordingly.
13. Ask whether any personal data crossing systems triggers data-residency or privacy requirements (e.g. GDPR) — especially relevant when the source or target system, or its users, sit outside the customer's home jurisdiction.
14. Ask whether an audit trail of every synced record is required for compliance or financial reporting. This is a distinct build item (logging + retrieval) and should never be assumed to come free with the base sync.
15. If the integration touches quoting/pricing, confirm whether multiple price books or pricing tiers exist for different channels or customer segments (e.g. self-serve vs. sales-assisted, or different regions). Multiple price books multiply mapping and testing effort and must be counted as separate scope, not a variant of one flow.

9.3 Cross-Cutting Discipline

• Verify every use case against the transcript before it goes in an SOW: When building scope from a discovery call, check each proposed use case against what was actually said, and label it Confirmed, Partially Discussed, or Not Discussed. It is common for something to be mentioned once as an existing feature or a "nice to have" and later get treated as a firm build requirement by mistake — this is one of the most common sources of scope disputes after signature.
• Distinguish an existing automation from a new build: If a workflow already exists in the target system today (e.g. an existing report or automation) and the new integration just feeds it better data, don't scope it as new build effort — call it out as a beneficiary of the integration, not a deliverable.
• Treat "nice to have" language literally: If a stakeholder says something like "if it can be implemented, that'd be great" in response to a direct scoping question, treat that as an explicit signal to mark the item optional/stretch-goal in the SOW rather than a confirmed requirement — do not upgrade it to firm scope on your own initiative.
• Confirm the stated tool boundary: If a stakeholder states a boundary on tooling (e.g. "we will only use MuleSoft to insert data into the target system" or "no contract-generation automation"), treat anything outside that boundary as explicitly out of scope, even if it was discussed elsewhere in the conversation.