> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Market Development Funds
> Run MDF end to end on your CRM: allocate budgets, collect proposals, approve, gather proof of spend, prove ROI, and reimburse with partner attribution.
export const Headless = ({children, intro = true}) => {
const [copied, setCopied] = useState(null);
const copy = event => {
const row = event.target.closest("li");
if (!row) return;
const text = row.textContent.trim();
try {
navigator.clipboard?.writeText(text);
} catch {}
setCopied(text);
setTimeout(() => setCopied(null), 1600);
};
return <>
{intro ?
Introw is headless by design: run everything here in plain language from Claude, ChatGPT,
Slack, Teams, or your own CRM through Introw's MCP server, with every
action written straight back to your CRM source of truth. The portal is one surface, never the only one.
: null}
{children ? :
The agentic motion - lifecycle deep dives and a Claude Code skill library that run your partner program from
Claude, ChatGPT, Slack, and your CRM.
}
;
};
export const Rail = ({children}) =>
{children}
;
export const Impact = ({children}) =>
{children}
;
export const Personas = ({children}) =>
{children}
;
export const Pains = ({children}) =>
{children}
;
> Market Development Funds is how you put co-marketing money to work and prove it paid off. Allocate budgets to partners, let them propose projects, collect proof of spend, track ROI against real pipeline, and reimburse - every step a no-code form with its own approval flow, wired to your CRM, and workable from anywhere. Most MDF programs die in spreadsheets and email threads; this one is a governed, auditable, collaborative lifecycle.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Requests arrive by email | A form with an owner and a deadline |
| Approvals depend on who replies | Approvers in order, AI clears the easy ones |
| You chase receipts for weeks | A deadline both sides can see |
| Nobody knows what it returned | Results land next to the spend |
## Impact
A partner asked to co-fund marketing is weighing your program against every other vendor's. Being the one that answers on a deadline, and where the money actually follows, is how you get their budget next quarter.
for your business
* **In your CRM**
Requests, approvals, receipts and results all land on CRM records, so the spend and the pipeline it produced sit side by side
* **Cost to run**
The lifecycle runs itself: no spreadsheet to maintain, no chasing over email, no reconciliation at quarter end
* **AI, not admin**
AI reviews the routine submissions and clears them above a threshold you set, so your team only sees the ones that need judgement
* **No new tool**
Partners request, claim and report from wherever they already work, and never have to learn your budget structure
for your partners
* **Self-serve**
One form to ask for funding, and they never need to know which of your budgets it should come out of
* **Enabled**
They can see where their request stands, what was approved and what is due next, without asking
* **Efficient**
Claims and invoices go in against a deadline that was stated up front, not a reminder email in week six
[A day in the life of a co-sell partner](/days-in-the-life/co-sell-partner)
* **Partner Marketing** - a budget they can spend and defend
* **Partner Operations** - a lifecycle that runs itself
* **Finance** - an approval trail behind every payment
* **Partners** - one form, a clear answer, and money that arrives
## How this area works
A fund holds a budget for a period and decides which steps run. A partner proposes an activity, it is approved, they run it, they submit proof of what they spent and what it returned, and they are reimbursed. Every step is a form you build without code, so the whole chain lands in your CRM as it happens.
**Where this sits in a setup.** MDF is a later-stage motion for programs with joint marketing budget. The [co-sell](/tracks/co-sell) and [distributor](/tracks/distributor) tracks add it once partners are already producing.
* 
[**Funds Allocation**](./funds-allocation)
Create funds and allocate budget to partners by segment.
[How to · 1 guide](./funds-allocation/technical)
* 
[**Projects**](./projects)
The request form, the approvers, and the shared workspace.
[How to · 2 guides](./projects/technical)
* 
[**Claims**](./claims)
Collect claims with receipts that draw down the budget.
[How to · 1 guide](./claims/technical)
* 
[**ROI**](./roi)
What it returned, on the same record as the spend.
[How to · 1 guide](./roi/technical)
* 
[**Invoices**](./invoices)
Generate reimbursement statements and mark projects paid.
[How to · 1 guide](./invoices/technical)
MDF in Introw is a full lifecycle, and each stage is its own building block you enable, customize, and govern:
Every stage is a **no-code form** with its own CRM automations and approval, and every project is a **real-time collaborative workspace** the partner and your team share.
## Every step is a form, an approval, a project, and a timeline
Four things are true of every stage, which is what makes the program governable:
Each step is a form you build without code, mapped to CRM objects and properties, so a submission lands as a clean, attributed record.
Every form can auto-approve with an AI review above a certainty threshold, and route the rest through multiple sequential human approval steps.
Every project is a shared workspace where partners and your team comment, share files, and resolve questions together, live.
Each step carries a deadline (decision, claim, ROI, invoice), so everyone knows what is due and when, with overdue warnings.
## Enable only the stages you use
MDF is not all-or-nothing. Each stage after the proposal can be turned on or off per your policy: proof of expense, ROI, invoicing. A simple program is proposal-and-approve; a strict one runs the full proof-and-reimburse chain. You decide the shape.
## One generic intake, your team picks the fund
Bigger programs run several funds at once, but a partner shouldn't have to know which budget their idea belongs to. Introw separates **intake** from **funding**:
* **A single generic intake** - embed one "Request marketing funds" block (or share one link) that isn't tied to any fund. Partners describe the activity and the amount; they never choose a budget.
* **It's just a normal request** - the submission lands in the MDF requests inbox like any proposal. A room admin **picks the marketing fund from a dropdown** on the request. **Accept stays disabled until a fund is picked**; collaborate, return and decline still work. Accepting creates the approved, fund-linked project through the same automation as a fund-specific request.
* **Change it any time** - a room admin can change the fund from the request's **Edit** dialog, on the pending submission or the running MDF request. The change cascades to its claims, ROI and invoices. Room visitors can never change the fund.
Under the hood the generic intake is still an `MDF_REQUEST` form tagged **Generic**, so its submissions flow into the same MDF inbox and lifecycle as fund-specific proposals.
## Run it from your AI assistant
* How much MDF budget does Acme still have available this quarter?
* Submit an MDF proposal for Acme: \$5k for a regional field event.
* Show every MDF proposal and claim still pending approval.
* What ROI have partners reported against the Q2 fund?
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.