# The Introw-powered affiliate partner
Source: https://docs.introw.io/days-in-the-life/affiliate-partner
A day in the life of an affiliate partner on Introw: self-serve links, campaign assets, conversion visibility, and transparent payouts.
> An affiliate partner does not work your deals. They create awareness, send traffic, and earn on outcomes. Their best day is simple: choose the right campaign, get a tracked link, publish with approved creative, watch conversions, and trust that the payout will happen.
## What matters to an affiliate
Affiliates operate at volume. They may be creators, newsletters, consultants, marketplaces, communities, or content sites. They do not need deal registration, pipeline collaboration, CPQ, or certifications. They need speed, attribution, content, earnings visibility, and payment confidence.
Introw keeps the motion lightweight on purpose. The partner self-serves links and assets, the system tracks clicks and conversions, fraud rules protect margin, and payouts reconcile back to the CRM and commission data.
Set up the link-and-earn motion for affiliates.
Campaigns, tracked links, attribution, and fraud protection.
## 8:30 - Pick the campaign that fits the audience
The affiliate opens their lightweight Introw experience:
They can quickly answer: *Which active campaigns fit my audience, and what commission can I earn this month?*
The answer comes back with active campaigns, approved messaging, payout terms, and which links are already live. The affiliate does not need to ask the partner manager for a link, a brief, or a commission table.
If the vendor has segmented campaigns, the affiliate only sees what they are eligible to promote. If a campaign is paused, capped, or restricted, that is reflected before the affiliate sends traffic.
## 9:00 - Generate a link and publish with approved assets
The affiliate creates a tracked link or vanity alias, pulls approved creative, and publishes:
* A newsletter mention.
* A LinkedIn post.
* A review article.
* A webinar CTA.
* A community resource.
The asset library and campaign page act as the source of truth. The affiliate gets current positioning without waiting for a content request, and the vendor keeps brand control without manually approving every post.
* 
[**Create an affiliate campaign**](/features/affiliate/campaigns/guides/launch-an-affiliate-campaign)
Give affiliates campaigns they can join and promote.
[How to · 1 guide](/features/affiliate/campaigns/technical)
* 
[**Asset Library**](/features/content/asset-library)
Keep approved creative and messaging easy to find.
[How to · 6 guides](/features/content/asset-library/technical)
## 11:00 - Watch clicks become real conversions
As traffic starts coming in, Introw attributes clicks, conversions, and new customers to the affiliate. The affiliate can ask:
> "How many clicks and conversions came from my Q3 launch post, and which conversions are pending approval?"
That visibility matters because affiliates optimize quickly. If one audience converts and another does not, they shift content. If a conversion is pending review, they can see that it has not disappeared into a black box.
Fraud protection runs in the background: self-referrals, disposable emails, duplicate conversions, and non-new-customer conversions can be blocked or reviewed before commission is earned.
* 
[**Conversion tracking**](/features/affiliate/conversion-tracking)
Attribute traffic and conversions to the right affiliate.
[How to · 3 guides](/features/affiliate/conversion-tracking/technical)
* 
[**Fraud protection**](/features/affiliate/fraud-protection)
Protect margin as affiliate volume scales.
[How to · 1 guide](/features/affiliate/fraud-protection/technical)
## 14:00 - Self-serve earnings instead of asking finance
The affiliate checks earnings without sending a finance or partner-manager message: what they earned this month, what is pending, and when the next payout is expected.
Introw answers from commission and payout data. The affiliate sees approved earnings, pending conversions, declined lines, payout timing, and statements. The partner manager does not become a middleman, and finance does not field routine status questions.
* 
[**Payouts**](/features/commissions/payouts)
Batch approved earnings, pay them, and issue statements.
[Commissions and incentives](/headless/agentic-use-cases/commissions-and-incentives)
## 16:00 - Improve the next promotion
The affiliate reviews which campaign had the highest conversion rate this quarter and which content is worth reusing.
Instead of static reporting, the partner gets an action-oriented answer: which link performed, which audience converted, which creative generated quality traffic, and which campaign is worth promoting next.
For the vendor, this creates scale. Hundreds or thousands of affiliates can self-serve links, creative, earnings, and performance without a partner manager touching every relationship. For the affiliate, the program feels responsive because the answers are available when the work happens.
## What changes
* **Before:** the affiliate waits for links, screenshots dashboards, asks about payouts, and loses trust when attribution is unclear.
* **With Introw:** links, assets, conversions, earnings, and payout status are self-serve.
* **Partner impact:** the affiliate can promote faster and optimize based on trusted data.
* **Vendor impact:** the program scales with attribution, fraud protection, and payout automation instead of manual partner management.
## Where to go next
Build the affiliate motion end to end.
Show partners what they can do from their own connected tools.
# The Introw-powered co-sell partner
Source: https://docs.introw.io/days-in-the-life/co-sell-partner
A day in the life of a co-sell partner on Introw: account overlap, shared pipeline, CRM-native collaboration, joint tasks, and co-marketing.
> A co-sell partner works deals with your team. Their day is about finding the right shared accounts, aligning who does what, moving live opportunities forward, and proving contribution without fighting over attribution.
## What matters to a co-sell partner
A co-sell partner usually brings an alliance manager, sellers, technical experts, and customer relationships. They need to collaborate on live opportunities without a CRM seat, understand account overlap, coordinate next steps with your AE, and get credit for influence or sourcing.
Introw makes the shared CRM record the collaboration surface. The partner sees only the fields and records you expose, can comment and act where permitted, and gets the deal context, enablement, guidance, and next steps needed to work with your team.
Build shared pipeline, overlap discovery, and joint execution.
Register, collaborate, and close on shared records.
## 8:30 - Find the accounts worth working together
The co-sell partner starts with overlap:
> "Which open opportunities overlap with our customers, and where can we help this week?"
Introw brings together partner attribution, CRM pipeline, and overlap signals. The partner sees where they can add influence: an executive relationship, integration knowledge, implementation expertise, regional presence, or credibility with the buyer.
The goal is focus. Instead of a broad "let's co-sell" meeting, both teams know which accounts deserve time.
* 
[**Crossbeam**](/features/integrations/crossbeam)
Use account overlap to identify joint opportunities.
[How to · 1 guide](/features/integrations/crossbeam/technical)
* 
[**Partner analytics**](/features/reporting/partner-analytics)
See partner-sourced and influenced performance.
[How to · 3 guides](/features/reporting/partner-analytics/technical)
## 10:00 - Work the live deal without a CRM seat
The partner opens a shared deal in Introw and reviews what changed since last week, who owns each task, and what should happen next.
The view is scoped to what the partner can see. It can include stage, next meeting, visible fields, comments, tasks, shared files, and deal guidance. The partner can add a comment, upload an asset, complete a task, or request that the AE update the plan.
Because Introw writes back to the CRM, your internal team keeps using HubSpot or Salesforce. The partner gets a collaborative surface without becoming a CRM user.
* 
[**Shared pipelines**](/features/co-selling/shared-pipelines)
Let partners collaborate on live CRM records.
[How to · 7 guides](/features/co-selling/shared-pipelines/technical)
* 
[**Collaborate from your CRM**](/features/integrations/crm/guides/collaborate-from-hubspot-deals-and-tickets)
Keep internal sellers working where they already work.
[How to · 25 guides](/features/integrations/crm/technical)
## 11:30 - Get guidance that matches the joint motion
Joint deals fail when both teams assume the other side owns the next step. The partner reviews what both teams should do before the technical validation call.
Introw can surface stage-specific guidance, competitive positioning, objection handling, missing assets, and rules of engagement. It can recommend whether the partner should make an introduction, bring a technical resource, send a co-branded asset, or stay out of a direct-sales moment.
* 
[**Deal coaching**](/headless/agentic-use-cases/deal-coaching)
Give partner and internal sellers stage-specific guidance.
[Rules of engagement](/features/ai/deal-coaching/guides/set-up-an-ai-deal-coach)
## 14:00 - Turn collaboration into accountable tasks
After a partner call, notes turn into action:
* Partner AE introduces the vendor AE to the champion by Friday.
* Vendor SE shares the integration guide today.
* Partner alliance manager confirms procurement path.
* Vendor AE updates the mutual action plan.
* Partner marketing drafts a joint webinar follow-up.
Tasks live in Introw, notifications go through email, Slack, Teams, or the portal, and the deal record keeps the collaboration trail.
## 15:30 - Fund and ship joint demand
If the opportunity or account segment needs more demand creation, the partner can request MDF, pull co-branded assets, or ask for an announcement draft:
> "Draft a co-branded webinar announcement for the healthcare accounts where we overlap, and create an MDF request for paid promotion."
Introw can draft the content, route the fund request, and keep the approval and ROI tied to the same partner and pipeline context.
* 
[**Market Development Funds**](/features/mdf)
Manage MDF requests, claims, and ROI.
[Funds & allocation](/features/mdf/funds-allocation)
* 
[**Campaigns and announcements**](/headless/agentic-use-cases/campaigns-and-announcements)
Generate segmented communications from source content.
[How to · 4 guides](/features/engagement/announcements/technical)
## What changes
* **Before:** account overlap sits in a spreadsheet, deal updates travel by Slack, and attribution is argued after the fact.
* **With Introw:** both teams work a shared, scoped view of live CRM opportunities with tasks, comments, guidance, and attribution.
* **Partner impact:** co-sellers know where to help and can act without waiting for CRM access.
* **Vendor impact:** the direct team stays aligned because collaboration is governed, visible, and tied to source-of-truth CRM records.
## Where to go next
Build the co-sell motion end to end.
Turn shared activity into better partner reviews.
# The Introw-powered distributor
Source: https://docs.introw.io/days-in-the-life/distributor
A day in the life of a distributor using Introw: two-tier attribution, scoped network access, reseller enablement, sell-through visibility, and margin clarity.
> A distributor scales a vendor through a reseller network. Their day is not one deal at a time. It is about recruiting, enabling, financing, and monitoring many downstream partners while keeping credit, access, and sell-through visibility clean.
## What matters to a distributor
A distributor is both a partner to the vendor and a vendor-like operator to its own reseller network. The distributor needs to manage sub-partners, understand which resellers are active, keep registrations attributed across two tiers, support downstream sellers, and prove sell-through performance.
Introw represents the two-tier motion through multiple partner attributions on the same CRM deal. That lets the vendor credit the distributor and the reseller on one source-of-truth record while scoping what each person can see and do.
Build two-tier attribution, access, and roll-up visibility.
Credit distributor and reseller on the same CRM deal.
## 8:00 - Start with sell-through, not sell-in
The distributor channel manager starts with the network view: what changed across the reseller network since yesterday, which registrations need attention, and which resellers are at risk.
Introw summarizes open registrations, stalled reseller deals, stage changes, certification gaps, pending tasks, and pipeline movement across the distributor's scoped network. The distributor does not have to wait for a vendor report or assemble reseller updates manually.
For the vendor, the same data provides visibility below the distributor layer. Sell-through is no longer hidden behind aggregate purchase volume.
* 
[**Ecosystem performance**](/headless/agentic-use-cases/ecosystem-performance)
Ask live channel-performance questions in plain language.
[Introw AI](/features/ai/copilot)
* 
[**Partner analytics**](/features/reporting/partner-analytics)
Show performance to partners and partner teams.
[How to · 3 guides](/features/reporting/partner-analytics/technical)
## 9:30 - Let the network register cleanly
A downstream reseller submits a deal and selects the distributor. Introw attributes both tiers on the same CRM deal, screens for conflict, and routes exceptions for review:
* The reseller gets protected credit for the opportunity.
* The distributor gets visibility and attribution for network influence.
* The vendor gets a clean CRM record with both parties attached.
The distributor can review which reseller registrations are pending approval, in conflict, or missing distributor attribution.
That turns two-tier governance into a queue the distributor can help manage instead of a spreadsheet the vendor reconciles later.
* 
[**Attribute a deal to a distributor and reseller**](/features/deal-registration/multi-tier/guides/register-a-two-tier-deal)
Credit both tiers on one deal.
[How to · 1 guide](/features/deal-registration/multi-tier/technical)
* 
[**Approval workflows**](/headless/agentic-use-cases/approval-workflows)
Clear routine submissions and route the exceptions.
[AI approvals](/features/ai/approvals)
## 11:00 - Manage access without losing control
The distributor adds a new reseller manager and scopes her access to the North region reseller portfolio, so she sees only those partners and deals.
Scoped roles keep the distributor self-serve while the vendor maintains governance. Distributor users can manage the partners they are responsible for, without seeing the whole vendor program. Resellers can work their own deals without seeing the distributor's full network.
* 
[**Team management**](/features/access/team-management)
Create roles and scope access.
[How to · 5 guides](/features/access/team-management/technical)
* 
[**Limit a user to their partners**](/features/access/team-management/guides/create-an-internal-role)
Keep distributor users scoped to the right network.
[Partner team roles](/features/access/team-management/guides/set-up-partner-team-roles)
## 13:00 - Enable resellers before they stall
The distributor reviews which resellers have open pipeline but missing certification, then assigns the training or enablement needed to unblock them.
Introw can identify the gap, recommend training, enroll the right reseller contacts, and send reminders in the partner's preferred channel. If common questions appear across the network, the vendor or distributor can turn them into micro-courses, assets, or announcements.
This is how distribution scales without making the vendor's partner team chase every downstream reseller directly.
* 
[**Training**](/headless/agentic-use-cases/training)
Generate and assign courses from your knowledge base.
[AI Training](/features/ai/training)
* 
[**Activation**](/headless/agentic-use-cases/activation)
Catch quiet or blocked partners before they disappear.
[Progress tracking](/features/courses/progress-tracking)
## 15:00 - Act on the network's next best moves
The distributor reviews the five reseller opportunities the team should focus on this week, with a clear action for each one.
Introw can rank opportunities by stage, value, inactivity, close-date risk, certification status, and tier impact. It can draft comments, assign tasks, recommend an enablement asset, or request vendor help on a strategic deal.
The distributor becomes more than an aggregation layer. They become an active operator of the network, with a current action queue instead of lagging reports.
## 16:30 - Check commissions, margin, and program health
The distributor closes the day with commercial visibility: attributed pipeline, commission earned at each tier's rate, the tier discounts applied on quotes, and which resellers are close to the next tier.
Introw answers from CRM, attribution, commission, and goal data. The distributor can see what is pending, paid, projected, or blocked. The vendor can audit the same underlying records.
* 
[**Commissions and incentives**](/headless/agentic-use-cases/commissions-and-incentives)
Make tier commission rates, margin, and payout status queryable.
[Commission plans](/features/commissions/commission-plans)
* 
[**Goals and KPIs**](/features/reporting/goals)
Track progress by partner, tier, or segment.
[How to · 1 guide](/features/reporting/goals/technical)
## What changes
* **Before:** the vendor sees sell-in, the distributor manages the network in separate systems, and reseller-level demand is hard to audit.
* **With Introw:** distributor and reseller attribution live on the same CRM deal, access is scoped, and sell-through becomes visible.
* **Partner impact:** distributors can manage their network with current data and self-serve actions.
* **Vendor impact:** a small channel team can scale through distributors without losing visibility into downstream demand.
## Where to go next
Build the distributor motion end to end.
Understand how distribution fits the broader partner spectrum.
# The Introw-powered implementation partner
Source: https://docs.introw.io/days-in-the-life/implementation
A day in the life of an implementation partner on Introw: sales-to-delivery handoff, scoped account access, onboarding tracking, and customer health.
> An implementation partner does not chase the deal - it picks up after the deal is won and makes the customer succeed. Their day is about taking a clean handoff, scoping the work, driving the customer to go-live, and keeping consultants certified, while every project detail stays tied to the same CRM record the sale closed on.
## What matters to an implementation partner
An implementation partner is a delivery organisation, not a sales one. A practice lead owns the vendor relationship and certification standing, while implementation consultants own scoping, configuration, and go-live for each customer. There is rarely a quota-carrying rep, because someone else - the vendor's direct team, a reseller, or a co-seller - closed the deal. That said, the same consultants are often pulled into the deal before it closes as solution architects, to scope the work and lend the delivery credibility that de-risks the purchase.
That inverts the usual risk: a bad implementation churns a customer the business already won, so a clean handoff and certified delivery, not deal registration, are what decide whether the partner protects or erodes revenue. Done well, the opposite happens - deep integrations, migrated data, and trained users embed the product into the customer's workflows, which is what makes the account stick and renew. Introw gives the implementation partner the deal and account context on the same source-of-truth record, without a CRM seat.
Set up the handoff, delivery access, and certification.
Collaborate on the won deal without a CRM seat.
## 8:00 - Start with the handoff, not the inbox
The implementation lead starts with what changed on their delivery book: which deals just closed and were handed over, which onboardings are behind, and which go-lives are at risk.
Introw summarizes newly handed-off deals, open onboarding tasks, stalled projects, certification gaps on the team, and customer-health signals across the accounts the partner delivers on. The consultant does not have to reconstruct context from a forwarded email thread - the deal, its line items, and its history are on the record.
* 
[**Collaborate on a shared deal**](/features/co-selling/shared-pipelines/guides/collaborate-on-a-shared-deal)
Take the handoff on the CRM record itself.
[Shared pipelines](/features/co-selling/shared-pipelines)
* 
[**Partner support agent**](/features/ai/partner-support)
Ask delivery questions and get answers from your content.
[How to · 2 guides](/features/ai/partner-support/technical)
## 9:30 - Scope the project on the record
A deal closed yesterday and was attributed to the implementation partner. The consultant opens it, reviews what was sold, and turns it into a scoped project: the modules to configure, the integrations to build, and the data to migrate.
Because the work lives on the CRM deal, the vendor's AE and the customer-facing team see the same plan. Nothing is hidden in a separate services tool, so expansion signals surface where the account is already managed.
* 
[**Onboarding**](/headless/agentic-use-cases/onboarding)
Turn a closed deal into a conversational onboarding journey.
[Onboarding](/features/partners/onboarding)
* 
[**View partner pipeline**](/features/co-selling/shared-pipelines/guides/view-partner-pipeline)
See the deals handed over for delivery.
[How to · 7 guides](/features/co-selling/shared-pipelines/technical)
## 11:00 - Drive go-live with tracked tasks
The consultant works the onboarding checklist: configuration tasks, a data-migration step, a customer sign-off. Each task has an owner and a due date, and reminders go out in the channel the customer and the consultant already use.
Introw keeps the go-live plan moving without status meetings. The partner self-serves the next step, the vendor sees progress on the record, and nothing stalls silently between the sale and adoption.
* 
[**Create and show partner tasks**](/features/partners/tasks/guides/create-and-show-partner-tasks)
Track onboarding and go-live steps on the deal.
[How to · 1 guide](/features/partners/tasks/technical)
* 
[**Activation**](/headless/agentic-use-cases/activation)
Catch a go-live that is quietly slipping.
[Journeys](/features/partners/journeys)
## 13:00 - Keep the delivery team certified
Before assigning a consultant to a new integration, the practice lead checks that they hold the current certification, and enrolls the ones who don't.
Certification is the gate for delivery: only qualified consultants deliver, so quality stays consistent as the team grows. Introw can identify the gap, enroll the right people, and remind them, and the certification status syncs back to the CRM so the vendor can trust who is authorised.
* 
[**Training**](/headless/agentic-use-cases/training)
Generate and assign delivery courses from your knowledge base.
[AI Training](/features/ai/training)
* 
[**Enroll partners in a course**](/features/courses/enrollments/guides/manually-enroll-partners)
Get consultants certified before they deliver.
[How to · 3 guides](/features/courses/enrollments/technical)
## 15:00 - Unblock consultants without waiting on the vendor
A consultant hits a technical question mid-configuration. Instead of opening a ticket and waiting, they ask the partner support agent and get an answer from the vendor's own runbooks and solution docs.
Self-serve answers keep delivery moving and keep the vendor's support team out of every integration detail. When the same question recurs across projects, the vendor turns it into a runbook, asset, or micro-course.
* 
[**Enablement support**](/headless/agentic-use-cases/enablement-support)
Deflect routine delivery questions 24/7, in any language.
[Knowledge base](/features/ai/knowledge-base)
* 
[**Build the asset library**](/features/content/asset-library/guides/build-the-asset-library)
Give consultants governed solution docs and runbooks.
[How to · 6 guides](/features/content/asset-library/technical)
## 16:30 - Check customer health and services visibility
The implementation lead closes the day with delivery health: which go-lives are on track, which are at risk, and how the delivered accounts are trending toward renewal and expansion.
Introw answers from the CRM, task, and certification data, so the vendor sees the same delivery signal underneath its won deals. Go-live quality becomes visible instead of hidden in a services silo, which is exactly what protects renewal.
* 
[**Read partner analytics**](/features/reporting/partner-analytics/guides/read-a-partners-analytics)
See delivery and health across your accounts.
[How to · 3 guides](/features/reporting/partner-analytics/technical)
* 
[**Ecosystem performance**](/headless/agentic-use-cases/ecosystem-performance)
Ask live delivery-health questions in plain language.
[Introw AI](/features/ai/copilot)
## What changes
* **Before:** delivery lives in a separate services tool, the handoff is a forwarded email, and the vendor loses sight of the customer between close and go-live.
* **With Introw:** the implementation partner takes the handoff on the CRM deal, tracks onboarding and go-live on the record, and stays certified to deliver.
* **Partner impact:** consultants get context, self-serve answers, and a clear go-live plan without waiting on the vendor.
* **Vendor impact:** higher go-live rates and stronger renewal and expansion, plus the stickiness that a deep implementation creates - with delivery health visible on the same record the deal closed on.
## Where to go next
Set up the implementation motion end to end.
Understand how implementation fits the broader partner spectrum.
# Days in the life
Source: https://docs.introw.io/days-in-the-life/index
How Introw shapes the daily rhythm for partner managers and every partner type: affiliate, referral, co-sell, reseller, and implementation.
> Introw is built for the real day-to-day of partner programs: a partner manager triaging a large book, an affiliate checking earnings, a referrer making a warm intro, a co-sell team working a shared deal, a reseller protecting margin, a distributor scaling through a network, and an implementation partner driving a customer to go-live. These articles show what changes when the CRM is the source of truth, partners get the right self-serve experience, and each ecosystem interaction is easier to complete.
## Start with the operator
The partner manager is the human owner of the program. Introw does not replace that judgment. It gives the partner manager a live operating layer: briefings, action queues, partner health, deal collaboration, partner communications, and scoped automation across tasks, training, commissions, and approvals.
A day built around focus, not dashboard hunting: new registrations, stalled deals, quiet partners, QBR prep, and next-best actions in one workflow.
## Then give every partner type the right day
Each partner type cares about a different job. Affiliates want links and payouts. Referrers want credit and updates. Co-sellers want shared pipeline. Resellers want protected margin and enablement. Distributors want sell-through visibility across a network. Implementation partners want a clean handoff and go-live tracking. Introw lets each type self-serve the right work without forcing them into the same portal experience.
From campaign selection to tracked links, fraud-safe conversions, earnings visibility, and payout confidence.
From a warm intro in seconds to protected credit, automatic status updates, and transparent rewards.
From account overlap to joint action plans, shared CRM deals, enablement, and co-marketing follow-through.
From deal registration to quoting, certification, partner support, margin protection, and commission clarity.
From sell-through monitoring to two-tier attribution, network enablement, scoped access, and roll-up reporting.
From a clean sales-to-delivery handoff to scoped access, onboarding and go-live tracking, certified consultants, and customer health.
## The common pattern
Across every day, the operating model is the same:
* **The CRM stays true.** Partner activity writes back to HubSpot or Salesforce instead of living in a disconnected side system.
* **Each partner gets the right experience.** Affiliates, referrers, co-sellers, resellers, distributors, and implementation partners see the workflows, content, and permissions that match how they work.
* **Partners self-serve routine work.** They submit forms, update allowed fields, check commissions, complete training, find assets, and track progress without waiting on a partner manager.
* **Automation removes the drag.** Reminders, validation, routing, notifications, and reporting happen in the background, with AI used where it adds speed or context.
* **Humans keep judgment.** Approvals, exceptions, negotiation, strategic planning, and relationship moments stay with the people who own the partnership.
See how Introw supports affiliate, referral, co-sell, reseller, distributor, and implementation motions.
Explore where automation and AI accelerate the partner lifecycle.
# The Introw-powered partner manager
Source: https://docs.introw.io/days-in-the-life/partner-manager
A day in the life of a partner manager on Introw: partner health, pipeline visibility, self-serve workflows, and automated follow-up in your CRM.
> A partner manager owns relationships, pipeline, enablement, performance, and the daily blockers that sit between partners and revenue. Introw changes the job from "hunt through dashboards and chase updates" to "review the right signal, approve the right action, and spend time where judgment matters."
## The role Introw is built around
A partner manager, PAM, CAM, PDM, or partnerships lead usually owns a portfolio of partners and a revenue number. The daily work spans partner recruitment, onboarding, enablement, joint business planning, pipeline reviews, channel-conflict resolution, partner communications, performance reporting, and internal coordination with sales, marketing, RevOps, finance, and product.
That work is important, but too much of it is mechanical: checking which partners went quiet, asking for deal updates, preparing QBR data, finding the right enablement asset, following up on training, chasing commission answers, and routing simple approvals. Introw lets the partner manager operate from a live action queue instead of a scattered stack of portals, spreadsheets, CRM reports, and Slack threads.
## 8:00 - Start with the partner briefing
The day starts with one prompt:
> "Give me my partner briefing for today. What's new since yesterday, which deals need me, which partners have gone quiet, and where should I focus? For each item, suggest the action I should take."
Introw pulls from CRM, partner activity, registrations, tasks, goals, training, commissions, and engagement signals. The daily view highlights what changed overnight:
* New partner applications and deal registrations waiting for review.
* Deals with close dates in the past, stalled stages, or missing partner updates.
* Partners that completed onboarding but have not registered a first deal.
* Quiet partners with open pipeline or upcoming tier thresholds.
* Training gaps, expired certifications, and content that should be sent now.
* Commission, payout, or incentive questions that would otherwise become finance tickets.
The useful part is not just the list. It is the ability to move from signal to action without opening five systems.
* 
[**Ecosystem performance**](/headless/agentic-use-cases/ecosystem-performance)
Ask live partner-performance questions in plain language.
[Introw AI](/features/ai/copilot)
* 
[**Activation**](/headless/agentic-use-cases/activation)
Catch partners drifting before the next QBR.
[Built-in automation](/features/automation/built-in-automation)
## 9:00 - Clear the queue without becoming the queue
The partner manager works through the action queue:
* Approve a clean referral submission and notify the referrer.
* Route a questionable reseller registration to sales because conflict was detected.
* Add or draft a partner-facing comment on a stalled deal.
* Create a follow-up task for the internal AE and the partner owner.
* Enroll a partner team in the product launch micro-course.
* Move a payout question to self-serve commission visibility instead of pinging finance.
Each action follows the permissions and approval mode you set. Routine work can be automated or pre-filled. Sensitive writes, like changing deal value, updating close dates, or approving conflicted registrations, can require human approval.
* 
[**Approval workflows**](/headless/agentic-use-cases/approval-workflows)
Auto-clear routine submissions and route exceptions.
[AI approvals](/features/ai/approvals)
* 
[**Channel conflict**](/headless/agentic-use-cases/channel-conflict)
Detect overlap before partner trust is damaged.
[How to · 1 guide](/features/ai/channel-conflict/technical)
## 10:30 - Help partners self-serve instead of waiting
The best partner manager is not the one who answers every routine question fastest. It is the one who removes the need for the question.
Partners can use Introw in the portal, Slack, Teams, email, their CRM, or a connected assistant. They can:
* Check what they still need to finish onboarding.
* Register a deal or referral with the right required fields.
* Find the asset to send to a healthcare prospect asking about security.
* See how far they are from the next tier.
* Check pending commissions on closed deals.
* Review what changed in their open pipeline this week.
That self-serve layer increases partner satisfaction because the work happens in the partner's workflow, not after a portal login and a waiting period. It increases scale because the partner manager stops acting as the help desk, data clerk, and reminder bot for every partner in the book.
* 
[**Partner self-serve assistant**](/features/developer/mcp/guides/give-partners-their-own-ai-assistant)
Partners work their scoped data from their own tools.
[How to · 5 guides](/features/developer/mcp/technical)
* 
[**Enablement support**](/headless/agentic-use-cases/enablement-support)
Give partners 24/7 answers from your approved knowledge.
[Partner Support Agent](/features/ai/partner-support)
## 13:00 - Spend the relationship time where it compounds
With the mechanical work handled, the partner manager can do the actual job:
* Run a strategic pipeline review with a top co-sell partner.
* Coach a reseller on a late-stage opportunity.
* Review activation blockers for a newly onboarded cohort.
* Work with partner marketing on a segmented announcement or campaign.
* Negotiate a joint business plan with a distributor.
* Prepare an executive-ready summary for leadership without waiting on RevOps.
Introw does not turn every partner into the same kind of relationship. It helps the manager treat each partner type correctly. Affiliates get scale and payouts. Referrers get trust and updates. Co-sellers get shared execution. Resellers get margin protection and enablement. Distributors get sell-through visibility. Implementation partners get a clean handoff and delivery tracking.
## 15:00 - Let QBR prep become strategic work
Instead of spending hours assembling slides, the partner manager asks:
> "Prepare my QBR for BrightPath. Include pipeline, goal progress, engagement, training, commissions, open tasks, risks, and a recommended agenda."
Introw assembles the review from live data. The partner manager edits the narrative, adds context, and decides the agenda. After the meeting, notes or a transcript can become tasks, partner comments, and a follow-up email the same day.
* 
[**QBRs and meeting prep**](/headless/agentic-use-cases/qbrs-meeting-prep)
Generate partner reviews from live CRM and engagement data.
[Partner Analytics](/features/reporting/partner-analytics)
* 
[**Tasks**](/features/partners/tasks)
Turn decisions into assigned next steps.
[How to · 1 guide](/features/partners/tasks/technical)
## 17:00 - End with a program that moved
By the end of the day, the partner manager has not just learned what happened. The work has moved:
* Registrations are approved, routed, or conflict-flagged.
* Partners have received the right comments, tasks, and nudges.
* Stalled deals have a next action.
* Quiet partners are enrolled in a recovery play.
* Training and certification gaps are assigned.
* QBRs are prepped and closed out.
* Partner data is still clean in the CRM.
That is the point of Introw. Dashboards tell you what to look at. Introw turns the partner program into an operating system where the next action is ready, scoped, and executable.
## What changes
* **Before:** the partner manager spends the day chasing status, finding data, answering repeat questions, and preparing reports.
* **With Introw:** the partner manager reviews a live action queue, approves sensitive changes, and spends relationship time on the partners and deals that matter most.
* **Partner impact:** partners get faster answers, cleaner credit, timely updates, and fewer reasons to disengage.
* **Business impact:** the same team can manage more partners with better coverage, cleaner CRM data, faster activation, and higher partner satisfaction.
## Where to go next
See where automation and AI accelerate partner-program operations.
Match the operating model to each partner motion.
# The Introw-powered referral partner
Source: https://docs.introw.io/days-in-the-life/referral-partner
A day in the life of a referral partner on Introw: warm intros, off-portal submission, protected credit, deal updates, and transparent rewards.
> A referral partner makes a warm introduction and then lets your team sell. Their day should not revolve around a portal. It should revolve around spotting the right intro, submitting it in seconds, knowing credit is protected, and getting updates without chasing.
## What matters to a referrer
A referrer is often an advisor, consultant, customer, agency, ecosystem partner, or individual with trusted relationships. They do not quote, negotiate, or manage the opportunity. They care about four things:
* The referral must be easy to submit from wherever the conversation happens.
* Their credit must be protected against direct sales or another partner.
* They need enough status visibility to trust the process.
* Rewards need to be clear, timely, and reconciled to the deal.
Introw turns that into a self-serve, off-portal motion.
Build the capture, credit, update, and payout loop.
Lead sharing, progress updates, and rewards.
## 8:00 - Spot an introduction worth making
The referrer hears from a customer who has a problem the vendor can solve. They do not want to find a portal login or remember a form. They use email, Slack, Teams, a referral link, the portal, or a connected assistant to submit:
> "Refer Acme to Introw. Contact is Priya Patel, CRO. They are evaluating partner portals this quarter and want Salesforce-native reporting."
Introw collects only the missing required fields, validates the details, maps answers to CRM properties, and creates or updates the right records with the referrer attached.
* 
[**Ways to refer a deal**](/features/referrals/lead-sharing/guides/ways-to-refer)
Refer by link, email, Slack, Teams, an AI assistant, or the API.
[How to · 2 guides](/features/referrals/lead-sharing/technical)
## 8:05 - Get credit protected immediately
The referral is checked for duplicates, direct-sales overlap, existing opportunities, and other partner claims. Clear referrals can be acknowledged quickly. Ambiguous referrals are routed to approval with context.
The referrer sees the important message: the submission was received, attribution is recorded, and the vendor is reviewing or acting on it. That fast acknowledgement is what keeps referrers referring.
* 
[**Protect referral credit**](/features/referrals/lead-sharing/guides/build-and-share-a-referral-form)
Lock in who sourced the opportunity.
[Lead sharing](/features/referrals/lead-sharing)
* 
[**Channel conflict**](/features/referrals/channel-conflict)
Detect overlap before trust breaks.
[Channel conflict with AI](/headless/agentic-use-cases/channel-conflict)
## 11:00 - Stay informed without joining the sales cycle
The vendor's AE works the deal in the CRM. The referrer does not need a CRM seat and does not need to be copied on every internal note. They get relevant milestones:
* Referral accepted.
* First meeting booked.
* Opportunity created.
* Stage changed.
* Deal closed won or closed lost.
* Reward pending or paid.
The referrer can check what happened with the Acme referral and whether the vendor needs anything else from them.
If the AE needs more context, Introw can create a task or draft a partner-facing comment asking for the right introduction detail.
* 
[**Deal progress updates**](/features/referrals/deal-updates)
Keep referrers warm as deals move.
[How to · 1 guide](/features/referrals/deal-updates/technical)
* 
[**Tasks**](/features/partners/tasks)
Turn follow-up into accountable next steps.
[How to · 1 guide](/features/partners/tasks/technical)
## 14:00 - Check rewards in plain language
The referrer checks which referrals have closed, what they have earned, and what is still pending.
Introw answers from the attributed CRM deal and commission data. The referrer can see whether a reward is pending, approved, paid, or not eligible. Finance gets fewer routine questions. The partner manager does not have to interpret payout status manually.
* 
[**Referral rewards**](/features/referrals/rewards)
Pay referral fees and revenue share.
[Commissions and incentives](/headless/agentic-use-cases/commissions-and-incentives)
## 16:00 - Make the next intro easier
After a good referral experience, the partner asks:
> "Who else in my network looks like a good fit based on the referrals that converted?"
For a mature program, Introw can help the referrer understand which industries, regions, or problem statements convert best, then reuse that learning in the next campaign or intro request. The referrer stays in control of their relationships. Introw removes the operational drag around the introduction.
## What changes
* **Before:** the referrer sends an email, waits for acknowledgement, wonders if credit stuck, and asks about payment later.
* **With Introw:** submission, credit protection, status updates, and reward visibility are built into the workflow.
* **Partner impact:** referrers trust the program and keep making introductions.
* **Vendor impact:** more referrals arrive cleanly, with less ops cleanup and fewer trust-eroding status gaps.
## Where to go next
Set up the referral motion end to end.
See how conversational submissions work across partner motions.
# The Introw-powered reseller
Source: https://docs.introw.io/days-in-the-life/reseller
A day in the life of a reseller on Introw: deal registration, margin protection, self-serve quoting, certification, and commission visibility.
> A reseller owns the sale. They prospect, qualify, sell, quote, and often deliver to the customer. Their best day is one where the vendor is easy to work with: deals are protected, pricing is governed, answers are immediate, training is useful, and earnings are clear.
## What matters to a reseller
Resellers invest real selling time before revenue is certain. They need confidence that the vendor will protect their deal, support the sales process, govern pricing fairly, certify their team, and pay margin or incentives correctly.
Introw gives the reseller a self-serve operating layer on top of the vendor's CRM. They can register deals, update permitted fields, build quotes, get answers, complete training, and check earnings without waiting for a partner manager to relay everything.
Build the reseller motion end to end.
Register, protect, and collaborate on reseller-owned deals.
## 8:00 - Register the deal before the window closes
The reseller AE leaves a customer call and submits:
> "Register a new deal with Northstar Manufacturing for 80 seats, expected close date September 30, primary contact is [ops@northstar.example](mailto:ops@northstar.example), use the manufacturing segment."
Introw collects missing required fields, validates the submission, checks duplicates, and writes the registration to the CRM with the reseller attributed. If there is a direct-sales overlap or another partner claim, Introw flags it immediately instead of letting conflict surface weeks later.
* 
[**Deal registration**](/headless/agentic-use-cases/deal-registration)
Submit partner deals conversationally in under two minutes.
[How to · 4 guides](/features/deal-registration/registration/technical)
* 
[**Protect a reseller's margin**](/features/deal-registration/registration/guides/register-and-approve-a-deal)
Lock in the reseller's claim and discount.
[Channel conflict](/features/deal-registration/channel-conflict)
## 9:30 - Work the pipeline without a vendor CRM seat
The reseller checks their open opportunities:
> "Which of my registered deals need an update this week?"
Introw returns the reseller's scoped pipeline: visible fields, stage, close date, tasks, comments, and next action. The reseller can update fields the vendor has made editable, add comments, manage permitted line items, or complete tasks. Sensitive fields remain governed by the vendor.
The CRM stays accurate because partner updates write back to the source of truth. The reseller is not emailing spreadsheets. The partner manager is not retyping updates.
* 
[**Shared Pipeline**](/features/deal-registration/shared-pipeline)
Let resellers work their own deals, on the fields you choose.
[Editable properties](/features/deal-registration/shared-pipeline/guides/set-up-a-reseller-pipeline)
## 11:00 - Quote with governed pricing
The customer asks for a proposal. The reseller does not wait for a vendor rep to build it:
> "Build a quote for the Northstar deal using the approved manufacturing bundle and my Gold-tier discount."
Introw uses the configured product catalog, quote templates, tier-based pricing, and discount rules. The reseller can self-serve the commercial document while the vendor keeps pricing governance.
* 
[**CPQ and Products**](/features/cpq)
Govern products, pricing, quotes, and discounts.
[Product catalog](/features/cpq/product-catalog)
* 
[**Quotes**](/features/cpq/quotes)
Let partners build quotes on approved deals.
[How to · 1 guide](/features/cpq/quotes/technical)
## 13:00 - Get support while the deal is live
The customer asks a security question. The reseller asks:
> "What is the approved answer for EU data residency, and which one-pager should I send?"
Introw answers from the vendor's approved knowledge base, attaches the right asset, and can log the question against the deal. If the answer requires a human or an action outside the reseller's permissions, Introw routes it.
This is where partner satisfaction changes most visibly. The reseller can keep selling while the buyer is engaged. They do not lose a day waiting for a CAM to relay an answer.
* 
[**Enablement support**](/headless/agentic-use-cases/enablement-support)
Give partners 24/7 answers from approved content.
[Partner Support Agent](/features/ai/partner-support)
* 
[**Asset Hub**](/features/content/asset-hub)
Surface the right assets inside the partner experience.
[How to · 2 guides](/features/content/asset-hub/technical)
## 15:00 - Keep certification tied to selling rights
A reseller's technical lead asks:
> "What certifications are expiring, and what do we need to finish to keep our Gold benefits?"
Introw shows open courses, deadlines, certification status, and what each completion unlocks: tier eligibility, deal protection, MDF, discount access, or delivery authorization. Partner teams can be enrolled automatically by segment, nudged when deadlines approach, and supported with answers during the course.
* 
[**Training**](/headless/agentic-use-cases/training)
Generate and assign training that matches real selling needs.
[AI Training](/features/ai/training)
* 
[**Courses and Training**](/features/courses)
Courses, enrollments, progress, certificates, and quizzes.
[Certificates](/features/courses/certificates)
## 16:30 - Check margin and next best deal
The reseller ends the day with commercial clarity:
> "What commission or margin is pending this quarter, and which open deal gets us closest to the next tier?"
Introw answers from deal, tier, commission, and payout data. The reseller sees what has been earned, what is pending, what is projected, and which actions move the economics. The incentive structure becomes a real operating signal instead of a PDF in the portal.
## What changes
* **Before:** resellers wait for deal-reg approval, vendor answers, quote help, certification status, and commission clarity.
* **With Introw:** registration, updates, quoting, support, training, and earnings are self-serve within governed permissions.
* **Partner impact:** the reseller sells faster and trusts that margin is protected.
* **Vendor impact:** partner-owned pipeline stays clean in the CRM, with less admin load and fewer conflict escalations.
## Where to go next
Build the reseller motion end to end.
Make partner economics visible and actionable.
# Partners
Source: https://docs.introw.io/features/partners/index
Auto-detect, organize, and progress partners with your CRM as the single source of truth - management, journeys, tiers, and segments in one place.
> Partners is where your program lives: every partner is detected from your CRM, organized into phases, tiers, and segments, and moved through onboarding and activation, all without a second source of truth.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| The partner list drifts to a sheet | One list, owned by the CRM |
| Onboarding lives in someone's head | A journey every partner runs |
| Quiet partners surface at review | Stalls are visible early |
| Tiers are a slide, not a ladder | Requirements and benefits, live |
## Impact
Partners invest where they can see the ladder. A visible stage, a named owner and a next step is most of what separates a program they grow in from a logo they signed with.
for your business
* **In your CRM**
Partners are detected and synced from HubSpot or Salesforce, so there is one partner list and it is the CRM's
* **Cost to run**
Phases, tiers, journeys and segments are all configured by partner ops, with no engineering
* **Live in days**
The structure of a real program, phases, tiers and onboarding journeys, stands up in an afternoon
for your partners
* **Self-serve**
The portal opens up as they qualify, so nobody grants them access step by step
* **Enabled**
A journey gives them the next step, and a tier tells them what the step after that unlocks
* **Efficient**
One named owner, one clear stage, and a checklist instead of a monthly catch-up call
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Managers** - the relationship, without leaving
* **Partner Operations** - phases, tiers, journeys, segments
* **VP Partnerships** - activation as a leading indicator
* **Partners** - a visible ladder and next step
## How this area works
A partner program falls apart when partner data lives in a spreadsheet that drifts from the CRM. Partners keeps your CRM as the system of record and builds the program on top of it. Partners are auto-detected from the companies or records you already manage in HubSpot or Salesforce, and kept in sync both ways. They are organized with the structure a real program needs: lifecycle phases, tiers and targeting segments.
**Where this sits in a setup.** Immediately after the CRM. Every [setup track](/tracks) gets partners and their contacts in before building anything they will see.
* 
[**Partner Management**](./partner-management)
Detect partners from the CRM, and phase them.
[How to · 5 guides](./partner-management/technical)
* 
[**Journeys**](./journeys)
Onboarding and activation as a repeatable playbook.
[How to · 4 guides](./journeys/technical)
* 
[**Tiers**](./tiers)
Requirements and benefits, synced to the CRM.
[How to · 2 guides](./tiers/technical)
* 
[**Segments**](./segments)
Group partners into dynamic or static segments that target content, notifications, and more.
[How to · 4 guides](./segments/technical)
* 
[**Partner Onboarding**](./onboarding)
Onboard partners progressively, unlocking tabs, assets, and abilities as they qualify.
[How to · 1 guide](./onboarding/technical)
* 
[**Partner Team**](./team)
Assign your team to each partner and let that ownership drive the program.
[How to · 1 guide](./team/technical)
* 
[**Tasks**](./tasks)
Clear next steps, shown in the portal.
[How to · 1 guide](./tasks/technical)
From there, you progress partners deliberately. Onboarding and activation are run as repeatable journeys instead of one-off reminders, so a new partner reaches first deal faster and a quiet partner gets caught before the next review, not after. Tiers set the benefits and requirements that motivate partners to grow, and segments decide who sees what across the rest of the product.
Because everything sits on the CRM, the program stays clean: no rogue objects, no duplicate partner lists, and every status change reconciled to the record your revenue team already trusts.
## The spine the rest of the program hangs off
Partner management is not one stage of the relationship, it is the record every other stage reads from.
Partners arrive through CRM detection or an [intake form](/features/forms) you publish. [Journeys](./journeys)
run onboarding and activation. [Tiers](./tiers) and [goals](/features/reporting/goals) define what growth
looks like and what it earns. [Deal registration](/features/deal-registration) and
[visibility and collaboration](/features/co-selling) carry the business itself.
[Reporting](/features/reporting) and business reviews close the loop and set the next plan. Every one of
those reads the partner's phase, tier, and segments from here, which is why a change made once shows up
everywhere.
## The partner lifecycle, stage by stage
| Stage | What happens | The feature | What runs without a person |
| - | - | - | - |
| Recruit | New partners apply or get found | [Partner application form](/features/forms/form-builder/guides/set-up-a-partner-application-form), [Partner Directory](/features/portal/partner-directory), [Crossbeam](/features/integrations/crossbeam), [scouting from your AI assistant](/headless/agentic-use-cases/partner-acquisition) | A submitted application creates the partner, links it in the CRM, and invites them |
| Onboard | The partner gets set up and signs the paperwork | [Journeys](./journeys), [Partner Onboarding](./onboarding), [agreements](./onboarding/guides/get-partner-agreements-signed) | Tabs, assets, and abilities open up as the partner qualifies |
| Activate | The partner learns the product and takes first steps | [Tasks](./tasks), [Courses](/features/courses), [Content](/features/content), [Engagement](/features/engagement) | Courses assign by segment, and announcements and notifications go out on their own |
| Grow and co-sell | The partner brings and works deals | [Deal registration](/features/deal-registration), [Shared Pipelines](/features/co-selling/shared-pipelines), [Referrals](/features/referrals) | Conflict checks run on submission, and deal updates reach the partner automatically |
| Review | You and the partner look at results and set the next plan | [Reporting](/features/reporting), [Goals](/features/reporting/goals), QBR prep from the [AI copilot](/features/ai/copilot) or [your AI assistant](/headless/agentic-use-cases/qbrs-meeting-prep) | Goal progress and pace status update from the CRM |
| Reward | The partner earns for what they did | [Tiers](./tiers), [Commissions](/features/commissions), [Introw Pay](/features/commissions/introw-pay), [MDF](/features/mdf) | Commission lines book from CRM data, and a workflow updates the tier |
The long tail runs on the same rails. In one [workflow](/features/automation/workflows), a partner
completes a course, a [certificate](/features/courses/certificates) is issued, a one-off commission is
added for the partner, and their tier property is updated. Nobody on your team touches it, and every
step lands in the CRM.
## Every partner gets the attention of a strategic one
Most programs can only give real attention to their top ten partners. Everyone else gets a quarterly email
and a portal they rarely open, and that lack of hours, not lack of intent, is why long-tail partners
underperform. Here, progression is structural rather than remembered: phases and tiers update from the CRM
and from [workflows](/features/automation/workflows), journeys hand each partner their next step, segments
unlock the program as they qualify, and goals say who is off pace this week. The same attention then runs
across the whole base without more headcount. From the partner's side, being one of two hundred is
indistinguishable from being one of ten.
## Run it from your AI assistant
* Which Gold partners haven't registered a deal this quarter?
* Move Acme up to the Gold tier.
* Prepare a QBR for my top partner.
# Assign a journey and track progress
Source: https://docs.introw.io/features/partners/journeys/guides/assign-a-journey-and-track-progress
Apply a journey to the right partners, then follow each one through to do, in progress, and done so you can step in before anyone stalls.
## What you'll achieve
A journey applied to a selected set of partners, each with their own task progress, and a live read on where every partner sits so you can act on the ones who are stuck. Onboarding or activation actually completes, rather than quietly stalling.
## Before you start
The journey and its tasks should be ready, and the partners you want to apply it to should exist in Introw.
## Watch it
## Steps
### Apply the journey
On [Journeys](https://app.introw.io/tasks), open the journey you want to apply.
Choose **Assign to partners** to open the partner picker.
Pick the partners who should run this journey, for example a new cohort or a group that has gone quiet. You can apply to many partners at once.
Confirm to publish. Introw copies the journey's tasks onto each selected partner so they each get their own progress.
Applying a journey copies its tasks onto each partner at that moment. Editing the journey afterward does not rewrite tasks already applied, so a partner keeps the version they were given. Re-apply, or edit their tasks directly, when a later change needs to reach partners already on the journey.
### Track progress
Back on the journey, use the tabs to see partners grouped by **to do**, **in progress**, and **done**. The to do and in progress groups are where your attention is needed, since those partners have not finished.
Open a partner to see their specific tasks and how far they have gotten, so you know exactly what is blocking them. For a sequential journey, an unfinished early task blocks the rest, so look for the task they are stuck on.
Reach out to partners who have stalled, or complete a task on their behalf when that is appropriate, to keep the journey moving. Partners shift between the groups as they complete tasks, giving you a live view of journey health.
## Verify it worked
The journey's progress tabs list the partners you applied it to, starting in **to do**, and each partner sees the tasks on their own task list. As partners work through the journey, they move across **to do**, **in progress**, and **done**, so the tabs always show current journey health.
## Related
Define the tasks and order first.
Enroll partners automatically from the portal instead.
Reflect lifecycle stage on the partners list.
Full configuration options for journeys.
# Auto-apply a journey from the experience
Source: https://docs.introw.io/features/partners/journeys/guides/auto-apply-a-journey-from-the-experience
Use the tasks section in the Introw experience builder to auto-assign an onboarding or activation journey to every partner who gets that experience.
Applying a journey from the [Journeys](https://app.introw.io/tasks) page is a deliberate,
one-time push to a chosen set of partners. The tasks section in the experience builder does
the opposite: it ties a journey to an experience, so every partner who receives that
experience is enrolled automatically. Use it when onboarding should begin on its own as soon
as a partner gets the portal, instead of someone remembering to apply the journey.
## What you'll build
A tasks section in a portal experience that includes one or more journeys and auto-assigns
their tasks to each partner who gets the experience.
## Before you start
The [journey](/features/partners/journeys/guides/build-a-journey-from-scratch) and its
tasks should be ready, and you should have a portal experience you can edit.
## Watch it
## Steps
Go to [Portal](https://app.introw.io/templates) and edit the experience that partners
receive.
Add the **Tasks** block to a section of the experience.
Open the block's settings to reach the **Configure Tasks** panel.
Under **Journey**, search for and select each journey you want shown here. Turning on
**Include tasks in this widget** adds that journey's tasks to the section. Pick
**Standalone tasks** if you also want ad-hoc tasks to appear.
For each included journey, set **Auto-create tasks for partners when publishing**:
* **On** - every partner who gets this experience is automatically enrolled in the
journey and receives its tasks. This is the auto-apply behavior. On a tab restricted to
segments, only partners in those segments are enrolled, and a partner who joins one of
those segments later is enrolled the moment they do.
* **Off** - the section only displays journey tasks a partner already has; it does not
enroll anyone.
Save the configuration, then publish the experience so the rule takes effect for
partners who receive it.
## Verify it worked
A partner who receives the experience automatically has the included journey's tasks on
their task list, without anyone applying the journey by hand.
## Limits & gotchas
Auto-assignment runs when the experience is published to a partner, and, on a
segment-restricted tab, when a partner enters one of the tab's segments. A contact-level
segment does not enrol a partner, and leaving a segment hides the tab but keeps the tasks
already created. Editing the journey afterward does not rewrite tasks already created for
partners who were enrolled earlier. Auto-create is per journey; **Standalone tasks** cannot
be auto-created.
## Related
Push a journey to a chosen set of partners manually and follow their progress.
Show partners their tasks inside the portal.
# Build a journey from scratch
Source: https://docs.introw.io/features/partners/journeys/guides/build-a-journey-from-scratch
Define your own ordered or flexible set of partner tasks, with each task's assignee, due date, visibility, and auto-complete action set.
## What you'll achieve
A reusable journey whose tasks, order behavior, assignees, due dates, visibility, and auto-complete actions all match how you actually onboard or activate partners. Once built, you apply it to a cohort and each partner gets their own copy of the tasks to work through.
## Before you start
You need write access to Journeys.
Have the list of tasks a partner should complete in mind, and whether any task must be finished before the next can start.
## Watch it
## Steps
### Create the journey
On [Journeys](https://app.introw.io/tasks), choose **Add**, then **Journey**, and pick create from scratch. Give it a **Name** that says what stage it covers, like onboarding or activation, since that name identifies it to your team and in the list.
Set how partners move through the tasks:
* **Flexible** - partners can complete tasks in any order. Use it when the steps are independent.
* **Sequential** - a task only unlocks once the previous one is done. Use it when later steps genuinely depend on earlier ones, such as signing an agreement before accessing deal registration.
### Build the tasks
Add a task and give it a clear name. Open the task to set its details. Every task you add walks the same set of inputs below.
For each task, set:
* **Due date** - on a journey task this is an offset, a number of days after the journey is applied to the partner, rather than a fixed date. The task is due at the end of that calendar day in your organization's time zone (UTC when none is set), so a task applied on Friday with 3 days is due at the end of Monday. Set it so each step has a realistic deadline relative to when onboarding starts; leave it empty for no due date.
* **Assignee** - who is responsible for completing the task. Choose **your team** (anyone on your side), **Partner** (anyone on the partner's team), **Role** (anyone on the partner's team with a specific role), or **Individual** (a named person; you can dynamically assign it to the partner's assigned partner manager). Pick the level of accountability the step needs.
* **Visibility** - who can see the task: **Public** (your team and the partner), **Internal** (your team only), or **Assignee** (your team plus the assignee). A task assigned to a partner must stay visible to them, so it cannot be Internal.
* **Description** - the instructions the partner reads. Write enough that they know exactly what to do without asking.
* **Attachment** - an optional file to attach to the task for reference.
To let a task complete itself when the partner does something in the portal, use **Add action** on the task and pick the **Action type**:
* **Watch asset** - completes when the partner views a chosen asset. Select the asset.
* **Upload** - completes when the partner uploads a file.
* **Submit form** - completes when the partner submits a chosen form. Select the form.
* **Go to link** - completes when the partner opens a link. Enter the URL.
* **Complete course** - completes when the partner finishes a chosen course. Select the course.
* **Obtain certificate** - completes when the partner earns a chosen certificate. Select the certificate.
Set the **Button label** the partner sees on the task, then save the action. Auto-complete actions remove manual check-off and give you a clean signal that the partner actually did the step. **Complete course** and **Obtain certificate** finish automatically when the partner completes the course or is issued the certificate, which makes them a natural fit for certification and training journeys.
Drag the tasks into the sequence partners should follow. Order matters most for a sequential journey, since it sets the unlock path; for a flexible journey it sets the order partners see.
## Verify it worked
The journey appears on [Journeys](https://app.introw.io/tasks) with your tasks, the order behavior you chose, and each task's assignee, due-date offset, visibility, and any action. It is ready to apply to partners.
## Related
Start from a built-in playbook instead.
Apply the journey and follow partners through it.
Enroll partners automatically from the portal.
Full configuration options for journeys.
# Create a journey from a template
Source: https://docs.introw.io/features/partners/journeys/guides/create-a-journey-from-a-template
Start from a built-in onboarding, activation, or certification journey, then tailor the tasks, order, assignees, and auto-complete actions to your program.
## What you'll achieve
A new journey seeded from a built-in template and tailored to your program: the right tasks, execution order, per-task assignees and due dates, visibility, and auto-complete actions, ready to apply to a cohort.
## Before you start
You need write access to Journeys.
## Watch it
## Steps
On [Journeys](https://app.introw.io/tasks), choose **Add**, then **Journey**.
Choose the playbook that fits the moment:
* **Partner onboarding** - the steps a brand-new partner works through to get set up.
* **Partner activation** - the steps that push a signed partner toward their first win.
* **Certification journey** - the steps that drive a partner through training and certification.
The journey opens with a starting set of tasks. Read through them and keep the ones that fit your program.
Confirm the **task execution order**: **Flexible** lets partners complete tasks in any order, while **Sequential** unlocks each task only after the previous one is done. Switch it if the template's default does not match how dependent your steps are.
For each task you keep, open it and adjust the same inputs you would set when building from scratch:
* **Due date** - the offset in days after the journey is applied, so each step has a deadline relative to onboarding start. A task is due at the end of that calendar day in your organization's time zone.
* **Assignee** - your team, the **Partner**, a specific **Role** on the partner's team, or a named **Individual** (which can dynamically resolve to the partner's assigned partner manager).
* **Visibility** - **Public**, **Internal**, or **Assignee** (a partner-assigned task cannot be Internal).
* **Description** - reword the instructions to match your program's voice and specifics.
* **Action** - add or change an auto-complete action (**Watch asset**, **Upload**, **Submit form**, **Go to link**, **Complete course**, or **Obtain certificate**) so the task completes itself when the partner acts, with the **Button label** they see. **Complete course** and **Obtain certificate** are especially useful in a certification journey, since they close the task the moment the partner finishes the course or earns the certificate.
Add steps unique to your program and remove any that do not apply.
## Verify it worked
The new journey appears on [Journeys](https://app.introw.io/tasks) with its tailored tasks and order, ready to apply to partners.
## Related
Start with a blank journey instead.
Apply the journey and follow partners through it.
Full configuration options for journeys.
# Journeys
Source: https://docs.introw.io/features/partners/journeys/index
Run partner onboarding and activation as repeatable task journeys - so new partners reach their first deal faster and quiet ones get caught early.
> Journeys turn onboarding and activation from a memory exercise into a repeatable playbook: a defined set of tasks, applied to the right partners, tracked to completion.
## The problem it solves
Onboarding and activation usually live in someone's head and a pile of reminders:
| Without Introw | With Introw |
| - | - |
| First deal takes too long | One guided path for everyone |
| Quiet partners surface at review | Stalls are visible early |
| It depends on someone remembering | The journey is the process |
| No view of who is stuck | To do, in progress, done |
## Impact
The first ninety days decide whether a partner ever sells anything. A repeatable path through them is the least glamorous and most reliable advantage you can have.
for your business
* **Live in days**
Start from the onboarding, activation or certification template and adapt it, rather than designing from nothing
* **Cost to run**
Partner ops builds and changes journeys with no code, so the playbook improves without a release
* **No new tool**
Task reminders reach partners in their inbox and chat, so the playbook runs without portal logins
for your partners
* **Self-serve**
A checklist that tells them what is next, in order or in any order you allow
* **Enabled**
Every new partner gets the same guided path, so nothing depends on who onboarded them
* **Efficient**
They are nudged before they stall, rather than chased after they already have
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Managers** - who is stalling, early
* **Partner Operations** - the playbook every partner runs
* **Partners** - a clear path to productive
## See it work
* 
**Start from a template**
Partner onboarding, activation, or certification.
* 
**Set the order**
Strictly sequential, or any order they like.
* 
**Apply it**
To the partners who need it, in one pass.
* 
**Watch it move**
To do, in progress and done, per partner.
## How it works
A journey is a reusable set of tasks you apply to partners, the playbook for a stage
of the relationship. Introw ships with starting points for the moments that matter
most: partner onboarding, partner activation, and certification. You can use one as
is, adapt it, or build your own from scratch, choosing whether tasks must be done in
order or can be completed in any sequence.
Once a journey exists, you apply it to the partners who need it and watch them move
through it. Each partner's progress is visible across to do, in progress, and done,
so a partner manager can see who is stalling and step in before a new partner goes
cold or an existing one quietly disengages. Because reminders and updates reach
partners where they already work, the playbook keeps running even when no one is
logged into a portal.
Journeys make the partner lifecycle a process you run, not a set of tasks you
remember. Partner ops designs the playbook once, partner managers apply it to the
right partners, and everyone sees progress in one place. New partners get to first
deal on a shorter, more consistent path, and the partners who stall surface early
enough to do something about it.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
design["Design the playbook"] --> apply["Apply to the right partners"]
apply --> progress["Track progress in one place"]
```
## Run it from your AI assistant
* For the three partners who signed this week, create their onboarding tasks and assign the first to each.
* Which partners are stalled midway through onboarding with no task completed in 14 days?
* Draft a nudge comment for every partner behind on their activation steps.
* Show each new partner's onboarding progress - to do, in progress, and done.
* Advance Acme's lifecycle phase to active now that their onboarding tasks are complete.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Journeys are built from tasks.
Drive progressive onboarding.
Make a course a journey step.
Enroll a partner in a journey automatically, and reward them when they finish it.
# Journeys
Source: https://docs.introw.io/features/partners/journeys/technical/index
Create partner onboarding and activation journeys, apply them to segments or individual partners, and track task completion and progress in Introw.
## Where it lives
Journeys lives at [Journeys](https://app.introw.io/tasks).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Write access to Journeys | To create and apply them | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Partners in Introw | A journey is applied to one | [Detect partners](/features/partners/partner-management/guides/detect-partners-from-your-crm) |
## How it works
A journey is a reusable set of tasks. You build a journey once, then apply it to the
partners who should run it. Applying a journey copies its tasks onto each selected
partner, so every partner gets their own progress while the journey itself stays the
journey definition.
You choose how a journey's tasks behave. With a **flexible** order, partners can
complete tasks in any sequence. With a **sequential** order, a task only unlocks
after the previous one is done, which is useful when steps build on each other.
Introw provides starting templates for onboarding, activation, and certification so
you do not begin from a blank page, and you can also create a journey from scratch.
Progress is tracked per partner across **to do**, **in progress**, and **done**, and
you can view all the partners on a journey from the journey's own tabs.
### Activation best practices
Signing a partner is not the same as activating one. A few patterns, drawn from what
works across programs, turn new partners into productive ones:
* **Make the lifecycle explicit.** Put partners on a journey so the path to first value
(first deal, first certification) is a clear checklist rather than something a partner
manager carries in their head.
* **Give every step an owner and a deadline.** Use per-task assignees and due-date offsets
so each step has accountability and a realistic timeframe relative to when onboarding
starts.
* **Train early.** Pair the journey with onboarding courses so partners can sell and deliver,
not just complete admin steps.
* **Nudge and recap.** Use partner notifications to keep deals moving and to recap progress,
so a stalled partner gets a prompt instead of going quiet.
The aim is a repeatable activation motion: new partners reach their first win faster and
stall less often.
## Settings & configuration
Journeys are managed from the [Journeys](https://app.introw.io/tasks) page. Each
journey has its own configuration and progress views.
### Creating a journey
**Add** opens a chooser with built-in journeys (onboarding, activation, and
certification) and a **create from scratch** option. Picking a template seeds the
journey with a sensible set of starting tasks you can edit.
**Name** identifies the journey in the list and to your team. Give it a name that
says what stage it covers, like onboarding or activation.
**Task execution order** is the key behavior setting. **Flexible** lets partners
complete tasks in any order; **sequential** requires each task to be finished before
the next opens. Choose sequential when later steps genuinely depend on earlier ones.
### Tasks within a journey
On a journey's configuration view you add, edit, reorder, and remove the tasks
partners will complete. Order matters most when the journey is sequential, since it
sets the unlock sequence. On each task, **Add action** configures how the task
completes automatically when a partner watches an asset, submits a form, uploads a
file, opens a link, completes a course, or obtains a certificate. The course and
certificate actions pair naturally with a certification journey, closing the task the
moment the partner finishes the course or is issued the certificate.
### Applying and tracking
**Apply** publishes the journey to a chosen set of partners, copying its tasks to
each of them. The journey's progress tabs then show partners grouped by where they
are: to do, in progress, and done. You can also see and complete a partner's tasks
from that partner's own task list.
### Automate it with a workflow
A journey both starts automation and is started by it. **Enrolled in journey** and **Journey completed** are [workflow](/features/automation/workflows/technical) triggers, and **Enroll in a journey** is a workflow action, the same operation as **Apply** on the partner page, so a partner already on the journey keeps their progress.
That closes the loop at both ends: put every new partner on the onboarding journey the moment they appear, and pay the bonus, award the certificate and unlock the next stage the moment they finish it. See [Onboard a new partner automatically](/features/automation/workflows/guides/onboard-a-new-partner-automatically) and [Reward a finished journey](/features/automation/workflows/guides/reward-a-finished-journey).
A mid-flow fork can read **Journey progress right now**, which after a wait is a different answer to the one the trigger recorded, so a chase can stop as soon as the partner gets going.
## How-to guides
* 
[**Assign a journey and track progress**](/features/partners/journeys/guides/assign-a-journey-and-track-progress)
Apply a journey to the right partners, then follow each one through to do, in progress, and done so you can step in before anyone stalls.
* 
[**Auto-apply a journey from the experience**](/features/partners/journeys/guides/auto-apply-a-journey-from-the-experience)
Use the tasks section in the Introw experience builder to auto-assign an onboarding or activation journey to every partner who gets that experience.
* 
[**Build a journey from scratch**](/features/partners/journeys/guides/build-a-journey-from-scratch)
Define your own ordered or flexible set of partner tasks, with each task's assignee, due date, visibility, and auto-complete action set.
* 
[**Create a journey from a template**](/features/partners/journeys/guides/create-a-journey-from-a-template)
Start from a built-in onboarding, activation, or certification journey, then tailor the tasks, order, assignees, and auto-complete actions to your program.
## Troubleshooting
Applying a journey copies its tasks onto each partner at that moment; editing the journey afterward does not rewrite tasks already applied. A sequential journey only opens the next task once the current one is done, so an unfinished early task blocks the rest for that partner.
The journey is sequential and an earlier task is not done yet.
The partner was applied before the edit; re-apply or update their tasks directly.
It has not been applied yet; use **Apply** to publish it.
# Build a progressive onboarding path
Source: https://docs.introw.io/features/partners/onboarding/guides/build-a-progressive-onboarding-path
Plan onboarding stages, build a segment per stage, gate portal tabs and abilities by segment, and use journeys to unlock the portal as partners qualify.
## What you'll achieve
A portal that unlocks stage by stage on its own: a dynamic segment per onboarding stage, tabs, sections, and abilities gated to those segments, and a journey driving partners forward. Partners graduate automatically as they qualify, with no manual access grants.
## Before you start
You need permission to create segments and edit experiences, a published portal experience partners can reach, and a connected CRM so dynamic segments can filter on live partner data.
Identify the signal that promotes a partner into each stage, such as a completed journey, a certificate, a tier, or a CRM property value.
## Watch it
## Steps
### Plan the stages
Decide the stages a partner passes through, for example Welcome, Trained, Selling, and Established. Keep them few enough that each one is a meaningful step up.
For each stage, list the tabs, asset sections, and abilities (forms, deal registration, courses) that should become available. This is the reward a partner earns by reaching the stage.
For each stage, choose the single measurable condition that promotes a partner into it, so it can become a dynamic segment filter. One clear condition per stage keeps advancement predictable.
### Create a segment per stage
Go to [Segments](https://app.introw.io/settings/segments) and create a **dynamic** segment for each stage. A dynamic segment recomputes its membership from filters, which is what makes graduation automatic.
On the segment's **Audience** tab, add the filter that defines the stage, such as a tier reached, a certificate earned, an onboarding journey complete, or a CRM property value. Membership then tracks that milestone, so partners enter the segment the moment they qualify. Every stage segment needs at least one condition anyway, since a segment with none matches everyone and is not allowed to override your default. Stage filters do not need to exclude earlier stages: a partner in a later stage usually still matches the earlier segments, and that is safe, because when overrides overlap the most permissive one wins and every stage they have earned keeps adding up.
Use the audience preview to confirm the partners who currently match are the ones you expect, before any gating depends on the segment.
### Gate the experience
Go to [Experiences](https://app.introw.io/templates) and open the experience partners use.
On a stage's tab, restrict it to the segment for that stage so only partners who have reached it see the tab. A tab restricted to a segment is invisible to everyone else, which is the core of progressive unlocking.
Within a visible tab, restrict individual sections to a segment when only later-stage partners should see them. Do the same for ability-bearing sections such as asset libraries, forms, and deal registration, so later stages unlock real capability, not just more pages.
On each stage segment, open **Permissions**, switch on **Override the default for this segment**, and set only what that stage unlocks, such as **Invite colleagues**. See [Create a dynamic segment](/features/partners/segments/guides/create-a-dynamic-segment) for the permission options. Leave the override off on any stage that changes nothing, and it inherits your baseline. Because overlapping overrides merge most-permissive, a stage can never take back what an earlier one gave. Set your baseline on the organisation-wide **All partners · Default**.
**See all shared records** works the same way: leave it off on the default and turn it on in the stages that earn it. Because overrides merge most-permissive, a stage cannot hold a group back from something another of their segments grants, so grant narrowly rather than broadly. See [Layer segments to progressively unlock capabilities](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
### Drive partners forward and publish
Give partners an onboarding journey so they always have a concrete next step. As they complete it and hit the milestones your segments key on, they roll into the next stage's segment and the matching tabs unlock. See [Build a journey from scratch](/features/partners/journeys/guides/build-a-journey-from-scratch).
Preview the experience as partners in different stages to confirm each sees only their unlocked tabs, sections, and abilities. Catching an over-broad segment here avoids exposing content to the wrong partners.
Publish the experience to push the gating to linked partner portals. From here, unlocking happens on its own as segment membership updates.
## Verify it worked
A partner in an early stage sees only their tabs, sections, and abilities. When a test partner meets a stage's milestone, they join that stage's segment and the matching content unlocks for them with no manual step.
## Related
Build the auto-updating audience and set its permissions.
How overlapping segments resolve, and why stages only ever add.
Give partners the checklist that moves them forward.
Apply the journey and watch partners advance.
Full configuration options for progressive onboarding.
# Get partner agreements signed
Source: https://docs.introw.io/features/partners/onboarding/guides/get-partner-agreements-signed
Take a partner from accepting your terms at intake to signing your NDA and partner agreement in DocuSign, and keep every signed document in their own portal.
Paperwork is where partner onboarding stalls. The terms sit on a web page, the NDA and the partner agreement sit in DocuSign, the signed copies end up in somebody's inbox, and the partner is chased by email for all three. This guide puts that whole sequence inside the partner's own portal: a click-through acceptance during intake that lands in your CRM, a signing step for the heavier agreements where the partner already works, and every signed document back in their portal afterwards.
## What you'll achieve
A partner who accepts your terms while applying, with the acceptance written to their record in your CRM. The agreements that need a real signature reach them as a step in their onboarding rather than an email thread. The signed documents live in their portal, visible to them and to nobody else. And what an unsigned partner can do is gated automatically, instead of being tracked by hand.
## Who does what
| Step | Where it runs |
| - | - |
| Accept your terms, click-through | Introw. A checkbox on the form, mapped to a property in your CRM |
| Prepare, send, countersign and hold the legal record | Your e-signature tool. Introw does not create envelopes and does not hold the audit trail |
| Put the signing step in front of the partner | Introw. The link lives in their portal as a section, an asset, or a journey task |
| Chase it, gate on it, report on it | Introw. Journeys, segments and portal experiences, keyed on CRM data |
| Give the signed document back to the partner | Introw. A partner-specific asset in their portal |
There is no DocuSign app to install. Introw does not generate envelopes, and your e-signature tool does not notify Introw when one is signed. Everything below works the same with DocuSign, PandaDoc, Adobe Acrobat Sign, or any tool that gives you a signing URL.
## Before you start
Acceptance and signature milestones are written to CRM properties, and segments read them live. See [Connect HubSpot](/features/integrations/crm/guides/connect-hubspot).
The public URL of your terms and conditions, and from your e-signature tool either a reusable signing link for a document every partner signs, or a per-partner envelope link.
Write down which agreement gates which part of the program, for example that deal registration opens only after the partner agreement is signed. That decision drives the segments later in this guide.
## Steps
### Accept your terms at intake
Go to [Forms](https://app.introw.io/forms) and open the form partners apply through. A partner application form already carries a terms and conditions checkbox, so there is nothing to add. On any other form, add a **Checkbox** field from the **Add to form** menu. See [Set up a partner application form](/features/forms/form-builder/guides/set-up-a-partner-application-form).
In the field label, replace the placeholder URL with the link to your own terms and conditions, so an applicant can read them before agreeing. Keep the label to one sentence: this step should cost the partner one click.
A ticked box is only useful if it leaves a record. In the field's settings, map it to a CRM object and property, then open the form's **Automation** tab and set how the submission writes:
* **A boolean property** - who accepted. Map the checkbox to it on the partner's company record, so the fact sits on the account and not only on a form submission.
* **A date or date-time property** - when they accepted. Set it from the automation as the compliance record of the moment.
* **Write behavior** - **Fill in if not known** is the default and never overwrites what a rep set. Choose **Overwrite** when you want a later re-acceptance, after a terms update, to replace the earlier date.
Attribution to the partner is automatic, using the method you defined on Object Linking, so there is nothing to wire per form. See [Map form fields to your CRM](/features/forms/crm-automations/technical).
For many referral and affiliate programs, this checkbox is the entire agreement. Ask for a countersigned pack only from partners who have shown they will transact. Four documents in front of a partner who has not done anything yet is where onboarding dies.
### Put the signing step inside the portal
In your e-signature tool, produce the link that opens the document. It comes in two shapes, and they are placed differently in Introw:
* **One document, every partner** - a reusable signing link, such as a DocuSign PowerForm. The signer identifies themselves on the signing page.
* **One document, one partner** - an envelope prepared for a named signer, with a link that belongs to that partner alone.
In the experience builder, open the onboarding stage and add an **Embed anything** section with the signing URL, so the document renders inside the portal. Some signing pages refuse to be displayed inside another page; when that happens use a **Call to action button** section instead, which opens the signing page in a new tab and keeps the portal as the single starting point. See [Embed external content](/features/portal/experiences/guides/embed-external-content).
Open the partner, go to their **Assets** tab, and add the envelope link with **Web page URL**, set to **Partner Specific**. Surface it through a **Partner Specific Asset Hub** section so each partner sees only their own documents. The same hub will later hold the signed copy, which means one place in the portal covers the agreement before and after it is signed. See [Share an asset with one partner only](/features/content/asset-library/guides/share-an-asset-with-one-partner).
A link nobody is asked to click gets ignored. On the onboarding journey, add a task for the agreement and use **Add action** to close it automatically:
* **Opens a link** - the task completes when the partner opens the signing link. Use it for the light documents, where reaching the page is enough of a signal to stop chasing.
* **Uploads a file** - the task completes when the partner returns the executed copy, which then sits on their record. Use it when you need proof rather than intent.
Set the journey to **sequential** when the NDA has to be signed before anything else opens, give each task a due-date offset, and let partner notifications do the chasing. See [Journeys](/features/partners/journeys/technical).
Introw is not told by your e-signature tool when a document is signed, so **Opens a link** records that the partner reached the signing page, not that they finished. When "signed" has to be a fact, get it from one of two places: the partner uploads the executed copy on the task, or your e-signature tool's own CRM integration writes a property on the partner's CRM record, such as DocuSign writing back to Salesforce, which Introw then reads like any other CRM field. Use the second one whenever the signature gates something.
### Gate what a signature unlocks
Create a dynamic segment filtered on the property that carries the acceptance or the signature. Dynamic segments re-evaluate as CRM data changes, so a partner joins the moment the property flips. See [Segments](/features/partners/segments/technical).
In the experience, restrict the stage, tab, or section that the agreement unlocks to that segment: deal registration, pricing, marketing funds. An unsigned partner never sees it, and nobody grants access by hand. See [Build a progressive onboarding path](./build-a-progressive-onboarding-path).
Enroll every new partner in the agreements journey with a workflow when they are created, and trigger the next step on **Journey completed**, so the tier, the certificate, or the welcome email follow the signature without anyone watching for it. See [Workflows](/features/automation/workflows/technical).
### Give the signed documents back
On the partner's **Assets** tab, add the countersigned PDF as a **Partner Specific** asset and name it for the partner, for example "Reseller agreement 2026" rather than a file name from your drive.
Point the asset at the Partner Specific Asset Hub section, ideally on a Contracts or Legal stage, so a partner who needs their paperwork a year later finds it themselves instead of emailing their partner manager.
Where your team keeps the legal record does not change. If your e-signature tool files the executed copy into your CRM, it stays there for your team, and the copy in the portal is the partner's own.
## Verify it worked
Submit a test application with the box ticked, then open the partner's record in your CRM: the acceptance property is set and the date property carries the moment. Open the portal as that partner: the agreement step is on their journey and the link opens the right document. Complete the step, and check that the task closes, the segment picks the partner up, and the gated tab appears for them. Finally, upload a signed copy as a partner-specific asset and open the portal as a different partner on the same experience: the hub is there, their own documents are in it, and the first partner's file is nowhere.
## Related
Unlock the rest of the portal as partners qualify.
The mechanics behind partner-owned documents.
The intake form the terms checkbox lives on.
Full onboarding configuration options.
# Partner Onboarding
Source: https://docs.introw.io/features/partners/onboarding/index
Onboard partners progressively - start small, then unlock portal tabs, assets, and abilities as partners complete steps and qualify for the next stage.
> A partner who lands in a portal full of everything on day one is overwhelmed and does nothing. Progressive onboarding starts them with the essentials and unlocks more, tabs, assets, and abilities, as they complete steps and qualify, so the portal grows with them.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| A full portal overwhelms them | Start with the essentials |
| Access is granted by hand | Segments unlock as they qualify |
| Partners plateau with no pull | Each unlock is a reward |
| There is no path to productive | A designed progression |
## Impact
A partner who lands in a portal full of everything does nothing. Revealing it as they earn it is the difference between an overwhelmed signup and an activated partner.
for your business
* **Live in days**
The path is designed once and every partner walks it, so nothing is staged per partner by hand
* **Cost to run**
It is built from the segments and experiences you already have, so there is nothing new to maintain
for your partners
* **Self-serve**
They unlock the program themselves by qualifying, with nothing to request from anyone
* **Enabled**
A focused first stage means they are never lost, and always have one clear next step
* **Efficient**
What they earned stays earned: the most permissive stage they match is the one that applies
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Managers** - productive without hand-holding
* **Partner Marketing** - the staged content and unlocks
* **Partners** - one next step, then the next
## See it work
* 
**Decide the unlocks**
What each stage earns the partner.
* 
**Pick the milestone**
A finished task, a certification, a tier, a CRM field.
* 
**Make it a segment**
A dynamic filter decides who has reached the stage.
* 
**Gate the portal**
Tabs and sections restricted to the stage that earned them.
## How it works
Partner Onboarding is a way of designing the partner experience so it reveals itself over time. You do not expose the full portal to a brand-new partner. You start them with a focused first stage - the few things they need to get going - and let the rest unlock as they earn it. Finish onboarding tasks, pass a certification, reach a tier, or hit a CRM milestone, and new tabs, content, and abilities appear.
This is built by combining what is already in Partners and the Portal. Dynamic segments decide who has reached each stage and update themselves as partner data changes. Portal experiences restrict tabs and sections to those segments, so a partner only sees what they have unlocked. Journeys give them the checklist that drives them forward, and tiers and certificates provide the milestones that flip the switch. The result is a partner who is never lost, always has a clear next step, and feels the program open up as they grow.
Because everything keys off live segment membership, the unlocking is automatic. You design the path once; partners move through it on their own, and you spend your time on the ones who stall, not on manually granting access. Set your baseline once on your organisation default, then give each stage segment only what that stage earns. When a partner matches several stages, the most permissive one wins. Nothing they unlocked is taken away because they still match an earlier stage.
Design the stages of your onboarding, define a dynamic segment for each, and gate the matching portal tabs, assets, and abilities to those segments. Partners start small, complete the steps in front of them, and watch the portal expand as they qualify, turning onboarding into a guided climb instead of a cliff.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
stages["Design stages"] --> segments["Segment per stage"]
segments --> gate["Gate portal tabs and assets"]
gate --> unlock["Portal unlocks as partner qualifies"]
```
## Run it from your AI assistant
* Which partners signed in the last 30 days but haven't finished onboarding?
* Create Acme's next onboarding task, assign it to them, and set it due Friday.
* Show partners who completed onboarding but haven't registered a deal yet.
* Mark Acme's onboarding tasks complete and move their lifecycle phase to active.
## Going deeper
Setup, configuration, and all how-to guides.
Endpoints and code.
**Works with**
Unlock stages with dynamic segments.
Give partners the onboarding checklist.
Reveal portal tabs as partners qualify.
# Partner Onboarding
Source: https://docs.introw.io/features/partners/onboarding/technical/index
Build progressive partner onboarding with journeys, dynamic segments, and segment-gated portal tabs so partners unlock content as they qualify.
## Where it lives
Partner Onboarding sits under **Portal**, at [Experiences](https://app.introw.io/templates).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| A published experience | Onboarding is what partners land in | [Publish an experience](/features/portal/experiences/guides/build-and-publish-a-portal-experience) |
| Permission for segments and experiences | Progressive access is built from both | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A connected CRM | Dynamic segments filter live data | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
| The milestones you gate on | A journey, certificate or tier | [Build a journey](/features/partners/journeys/guides/build-a-journey-from-scratch) |
## How it works
Progressive onboarding is not a single setting; it is a pattern you assemble from pieces that already
exist. Three of them do the work together:
* **Journeys** give a partner the ordered checklist that drives them forward, from first login to first
deal. See [Journeys](/features/partners/journeys).
* **Dynamic segments** decide which stage a partner has reached. A dynamic segment's membership updates
automatically from its filters, so as a partner completes a journey, earns a certificate, reaches a
tier, or a CRM property flips, they move into the next segment without anyone touching it. See
[Segments](/features/partners/segments).
* **Portal experiences** restrict tabs and sections to segments. A tab or section gated to a segment is
only visible to partners in it, so the portal reveals more as a partner qualifies. See
[Experiences](/features/portal/experiences).
Put together: define a segment per onboarding stage, gate the matching tabs, asset sections, and
ability-bearing blocks (forms, deal registration, courses) to those segments, and let journeys push
partners forward. A partner sees only their current stage, and the next one appears the moment they
qualify.
## Settings & configuration
You assemble onboarding across [Segments](https://app.introw.io/settings/segments) and the
[Experience builder](https://app.introw.io/templates).
### Define a segment per stage
Create a **dynamic** segment for each onboarding stage and set its audience filters to the condition
that defines that stage, for example onboarding journey complete, a certification earned, or a tier
reached. Membership recomputes as partner data changes, so partners enter the segment automatically when
they qualify. Use the audience preview to sanity-check who currently matches.
Every stage segment needs at least one condition, which it has by definition, and which an overriding
segment requires anyway. Stage filters do not need to exclude earlier stages. A partner in a later stage
usually still matches the earlier segments, and that overlap is safe: when overriding segments overlap,
the most permissive one wins, so each stage a partner earns only ever adds capabilities. See
[Layer segments to progressively unlock capabilities](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
### Gate tabs and sections
In the experience, **restrict a tab to specific segments** so only partners in a stage see it, and do the
same for sections within a stage. Gate the asset sections, forms, and other ability-bearing blocks that
should unlock at each stage. Partners not yet in the segment simply do not see the gated content.
### Drive partners forward
Apply an onboarding **journey** so partners have a concrete checklist. As they complete it (and the other
milestones your segments key on), they roll into the next stage's segment and the matching tabs unlock.
### Tune what each stage can do
Segment **permissions** control abilities like inviting colleagues or how much of their company's shared
data a contact sees, so a stage can unlock not just content but what a partner is allowed to do. Set your
baseline on the organisation-wide **All partners · Default**, then on each stage segment switch on
**Override the default for this segment** and set only what that stage grants. A stage that changes
nothing leaves its override off and inherits the baseline. When a partner matches several override
segments, the most permissive one wins.
**See all shared records** works exactly like invites: withhold it on the default and turn it on in the
stages that earn it. Because overrides merge most-permissive, a partner who still matches earlier stages
keeps everything a later one granted. The flip side is that a stage cannot hold a group back from
something another of their segments grants, so grant narrowly rather than broadly. See
[Layer segments to progressively unlock capabilities](/features/partners/segments/guides/layer-segments-to-progressively-unlock)
and [Create a dynamic segment](/features/partners/segments/guides/create-a-dynamic-segment).
## How-to guides
* 
[**Build a progressive onboarding path**](/features/partners/onboarding/guides/build-a-progressive-onboarding-path)
Plan onboarding stages, build a segment per stage, gate portal tabs and abilities by segment, and use journeys to unlock the portal as partners qualify.
* [**Get partner agreements signed**](/features/partners/onboarding/guides/get-partner-agreements-signed)
Take a partner from accepting your terms at intake to signing your NDA and partner agreement in DocuSign, and keep every signed document in their own portal.
## Troubleshooting
Unlocking is only as accurate as the segment filters, so a partner who does not match a stage's filters will not see its tabs, test the qualifying conditions before launch. Dynamic segment membership cannot be edited partner by partner; change the filters to change who qualifies. Publishing pushes experience changes to linked rooms, so preview each stage first. A partner with no experience assigned cannot be invited at all.
Confirm they match the stage segment's filters and the tab is restricted to that segment.
The tabs are not restricted to segments, or the segments are too broad.
The milestone the segment keys on is not being met or recorded; check the journey, certificate, or CRM property.
A gated section used a segment broader than intended.
Either the stage segment's override switch is off, so it inherits the default, or the contact matches another override segment that grants more and the most permissive one wins. For invites and notifications, put the baseline on the organisation default rather than on a stage.
Another segment the partner matches grants it, and overrides merge most-permissive. Withhold the capability on the default and grant it only on the stages that earn it.
# Bulk update partners
Source: https://docs.introw.io/features/partners/partner-management/guides/bulk-update-partners
Bulk edit tier, commission plan, currency, team roles, or the published portal experience for many partners at once, without updating them one by one.
## What you'll achieve
A whole cohort of partners updated in one pass: their tier, commission plan, currency, or a team role changed through the bulk edit dialog, or their published experience created or swapped through the bulk actions bar. What would have been dozens of identical edits becomes a single action.
## Before you start
You need write access to Partners. Tiers, commission plans, team roles, and experiences must already exist for the values you want to apply.
## Watch it
## Steps
On [Partners](https://app.introw.io/partners), use the row checkboxes to select every partner you want to change. The header shows how many are selected and opens the bulk actions bar. Filter the list first so you select exactly the cohort you mean.
Click **Edit** in the bulk actions bar to open the bulk edit dialog for your selection.
Under **Property to update**, pick what you are changing. One bulk edit changes one property across the whole selection:
* **Tier** - move every selected partner to the chosen tier. Use it after a tier review to promote or demote a cohort at once.
* **Commission Plan** - set the commission plan(s) for the selection, so their conversions calculate against the right plan.
* **Currency** - set the currency the selected partners transact in. Available when multi-currency is enabled.
* **A team role** (listed by its name, such as **Partner manager**) - assign a team member to that role across the selection. The dialog then asks for the **User** to assign.
Choose the tier, commission plan, currency, or team member that should apply to all selected partners. When assigning a team role to partners that already have someone in that role, Introw asks whether to replace the existing assignment.
Click **Update** to save. Introw updates every selected partner and clears the selection when it finishes.
To change which experience a cohort is published with, keep the partners selected and use the bulk actions bar instead of the Edit dialog:
* **Apply experience** - publish the selected partners with an experience, creating their partner portals in one pass. Use it to launch portals for a new cohort.
* **Update experience** - swap the experience the selected partners already use, updating their existing portals. Use it to move a cohort onto a refreshed or rebranded experience.
To remove a cohort, keep them selected and click **Delete** in the bulk actions bar. Because this is permanent, Introw asks you to type **delete** in the confirmation box before **Yes, Delete** turns on, so a bulk delete is always deliberate. Deleting a single partner from its row menu works the same way, except you confirm by typing that partner's name.
## Verify it worked
The partners you selected show the new value in the list, and the bulk actions bar is gone because the selection cleared. If you applied an experience, the selected partners now have portals on that experience.
## Related
Filter and view the list before you select a cohort.
Define team roles and assign owners on a single partner.
Full configuration options for the partners list.
# Create a partner manually
Source: https://docs.introw.io/features/partners/partner-management/guides/create-a-partner-manually
Add a single partner by hand and link it to its CRM company before automatic sync detects it, so you can start onboarding right away.
## What you'll achieve
A single partner added directly, linked to its CRM company where one exists, sitting on the partners list with a detail page ready for you to set their phase, tier, experience, and other fields. The new partner behaves exactly like a detected one, just created on demand.
## Before you start
You need write access to Partners. Connecting your CRM first lets Introw prefill company data and link the new partner back to its record, but you can also create one with no CRM connected.
## Watch it
## Steps
On [Partners](https://app.introw.io/partners), choose **Create partner** to open the dialog.
Identify the partner organization. The fields you see depend on whether a CRM is connected:
* **Company (CRM connected)** - search for and pick the partner's company so the new partner links back to that CRM record. If your CRM uses a custom partner object, you can also pick the **Partner** record directly. Linking is what makes the partner's deals and people attribute automatically.
* **Company domain and Company name (no CRM, or filling in by hand)** - enter the domain and name directly. Typing a domain prefills a suggested company name, which you can edit.
If your setup maps partner attribution properties, the dialog asks you to fill them in. Set them so the partner's deals and people attribute correctly from the moment they are created, rather than waiting for a later edit. Skip this step if no attribution properties are mapped.
Confirm to create the partner. Introw opens the new partner's detail page.
On the detail page, set the fields that decide how the partner is treated: **Phase**, **Tier**, **Champion**, **Language**, **Currency**, **Categories**, **Experience**, and **Commission Plan**. See [Work a partner record](./work-a-partner-record) for what each field controls. Setting them now means the partner is fully onboarded, not just created.
## Verify it worked
The new partner appears in [Partners](https://app.introw.io/partners) and on its detail page, linked to the CRM record when one was selected, with the fields you set ready to drive their experience.
## Related
Set every field, manage people, and add notes.
Let detection add partners automatically.
Full configuration options for partner records.
# Detect partners from your CRM
Source: https://docs.introw.io/features/partners/partner-management/guides/detect-partners-from-your-crm
Understand how Introw builds and syncs your partner list from CRM records, and where to run the connect-and-detect setup to keep it current.
## What you'll achieve
A clear picture of how partner detection works: which CRM object Introw treats as a partner, which records actually count, and how new matches keep flowing in without manual imports. With detection set up, your partners list stays current as a by-product of your CRM, not a chore.
## Before you start
You need access to integration settings, and a CRM (HubSpot or Salesforce) you can authorize.
## Watch it
## How detection works
Introw builds your partner list from three answers, given across the two setup steps, **Import partners** and **Attribute objects**:
* **How partners are stored** (**Import partners**, **Partner object**) - the CRM object that represents a partner, such as Company, Account, or a custom Partner object. This tells Introw where to look.
* **Which records count** (**Import partners**, **When...**) - the conditions (CRM properties plus manual selection) that narrow that object down to the records that are really partners. Only matching records become partners in Introw.
* **What attributes to them** (**Attribute objects**) - the linked objects (such as deals or contacts) that should appear on each partner record, so their pipeline and people show up automatically.
Once detection covers your full set of partners, you can turn on automatic sync so any new CRM record that matches your filters becomes a partner in Introw on its own. From then on the list stays current without anyone re-running an import.
Detection brings the people too, not just the account. Each partner's CRM account owner is suggested as a team member you accept with one click and set as the partner's manager (shown as **Requested** under **Settings, Team**), and the contacts associated with the partner's company are imported under the partner's **People**, ready to be given portal access. All of this runs from the CRM sync, with no SSO required. For the full picture of how people and access flow from the CRM, see [Provisioning](/features/access/provisioning).
## Run the setup
The connect-and-detect setup is the same setup page used to connect your CRM, so it lives with the CRM integration rather than being duplicated here. Open [Settings, then Integrations](https://app.introw.io/settings/integrations) and follow the connect guide for your CRM, then choose how partners are stored and which records sync.
## Verify it worked
Open [Partners](https://app.introw.io/partners). Your detected partners appear in the list, each linked to its CRM record, with linked deals visible on the partner detail page. A newly qualifying CRM record appears without you importing it once automatic sync is on.
## Related
The canonical setup: pick the CRM partner object.
Narrow detection and turn on automatic sync.
Add a partner before sync detects them.
How owners and contacts arrive with each partner, and how access is governed.
Full configuration options for the partners list.
# Organize the partners list
Source: https://docs.introw.io/features/partners/partner-management/guides/organize-the-partners-list
Build views, columns, filters, and lifecycle phases so each team reads the partners list the way they need to, then act on partners in bulk.
## What you'll achieve
A partners list that answers the right question for each team: saved views (shared or private) with the columns and filters they care about, lifecycle phases that show where every partner sits as a pipeline board, and bulk actions that update a whole cohort without opening each record. Partner managers see at a glance who needs a push, and leadership can read program health from the board.
## Before you start
You need write access to Partners to configure views, phases, and run bulk actions. A connected CRM is not required to organize the list, but CRM-backed properties only appear as columns when a CRM is connected.
Decide the stages a partner moves through (for example potential, onboarding, active, churned) so the phases you create match how your program actually works.
## Watch it
## Steps
### Build a view
Go to [Partners](https://app.introw.io/partners) and open the configure panel for the current view. This is where you choose the columns, filters, and sharing that define how this view of the list looks.
Decide which partner properties show as columns, then use **Add property** to add more.
* **Built-in properties** - fields Introw tracks directly, such as phase, tier, champion, and language. Add the ones the team scans on every partner. **People with access** is on by default and counts the partner's contacts who can sign in to the portal, including the ones who have not logged in yet; remove it and it stays removed. **Experience** names the experience the partner is on.
* **A HubSpot custom partner object's stage** - when your partners live on a HubSpot custom object with a pipeline, its stage shows as the stage name, and you can filter on it and edit it from the list and the partner's profile.
* **CRM-backed properties** - fields that live in your CRM. Add these when a team needs to filter or sort on data you maintain in HubSpot or Salesforce. They appear only when a CRM is connected. On a CRM property, **Is not known** also matches a partner that has no CRM record yet, so an unlinked partner shows up when you filter for a missing value.
Keep a view to the handful of columns that team actually reads; extra columns make the list harder to scan, not easier.
Narrow the view to the partners it is about - for example a single phase, a tier, or a segment. A filtered view stays focused on one question (such as "who is mid-onboarding") instead of showing every partner at once.
Choose who sees the view.
* **Private** - the view stays visible only to you. Use it for a personal working slice.
* **Shared with team** - colleagues see the same columns, filters, and layout. Use it for the views a whole team relies on, so everyone reads partners the same way.
Save the view to keep it. It appears as a tab on the partners list for quick switching, and teammates see it too when it is shared. Create as many views as you have distinct questions to answer.
### Organize partners into phases
In the configure panel for the list, find the phases section. A default set of phases already exists, running from a potential partner through to won and lost, so you can adapt rather than start from nothing.
Add a phase and give it a clear name that matches your program, such as a stage between first contact and signed. Each phase becomes a column in grid view, so name them the way you would describe the pipeline out loud. Repeat for every stage you track.
Drag phases into the sequence partners move through, so the board reads left to right like your real lifecycle. Order is what makes the grid tell a pipeline story.
Use **Grid view** to see one column per phase, then drag partners into the right column. You can also set the **Phase** field on a partner's detail page. Changes save immediately, and the choice between **List view** and **Grid view** is remembered for you.
To delete a phase, first choose another phase to move its partners into, then remove it. Introw requires the migration so no partner is ever left without a phase.
### Act on a cohort in bulk
Filter the list to the cohort you want (a view or a quick filter helps), then use the row checkboxes to select partners. The header shows how many are selected and reveals the bulk actions bar.
The bulk actions bar acts on every selected partner at once.
* **Update experience** - swap which experience the selected partners are published with, updating their existing portals.
* **Apply experience** - publish the selected partners with an experience, creating their partner portals in one pass.
* **Comment** - post an internal comment across the selected partners to flag follow-up for your team.
* **Edit** - open the bulk edit dialog to change a property (tier, commission plan, currency, or a team role) for the whole selection. See [Bulk update partners](./bulk-update-partners) for the full walkthrough.
Run the action. Introw applies it to every selected partner and clears the selection when it finishes, so the bulk actions bar disappears.
## Verify it worked
Your saved view appears as a tab on [Partners](https://app.introw.io/partners), and teammates see it too when it is shared. **Grid view** shows one column per phase with partners in the stages you assigned. After a bulk action, the selected partners show the new state in the list and the selection clears.
## Related
Change tier, commission plan, currency, or team roles for a whole cohort.
Set phase, tier, and the other fields on a single partner.
Turn a filter into a reusable audience.
Add any CRM field as a column here, on object overviews, and on partner-facing views - renamed for partners.
Full configuration options for the partners list.
# Work a partner record
Source: https://docs.introw.io/features/partners/partner-management/guides/work-a-partner-record
Open a partner, set every field that drives their experience, keep their contacts current, and capture the context your team needs.
## What you'll achieve
A partner record that is fully set up and current: the right tier, phase, champion, language, currency, and categories so their experience and commissions behave correctly; the CRM fields your team tracks, editable in place; an accurate set of contacts with the right portal access; and a running history of notes your whole team can see. Everything you set here drives what the partner experiences in their portal and how Introw attributes their deals.
## Before you start
Know which partner organization you are working. You need write access to Partners.
Tiers, commission plans, and experiences must already exist for the values you want to apply. Currency only appears when multi-currency is enabled for your organization, and language options come from the languages your organization has turned on.
## Watch it
## Steps
### Set the partner's core fields
Go to [Partners](https://app.introw.io/partners) and open the partner. The detail page opens on the **Partner Details** card, where the fields that drive their relationship live.
Introw shows a logo next to the partner name, found automatically from their domain. To replace it, hover the logo in the header and upload your own: it sits in a small square frame and is cropped to fill, so use a square image around **200×200**, PNG or JPG. The same logo shows up in the partner's own portal.
On the **Partner Details** card, set the fields that decide how this partner is treated:
* **Tier** - the partner's program tier. It governs the benefits, requirements, and badge they get, and other features read it. Pick the tier that matches their current standing.
* **Phase** - the lifecycle stage they sit in (the column they appear in on the grid view). Set it so the pipeline board reflects reality.
* **Champion** - the main contact at the partner organization. Choose from the people associated with the partner; this is who your team treats as the relationship owner on the partner side.
* **Currency** - the currency their commissions and revenue are shown in. It appears only when multi-currency is enabled. Leave it unset to use the organization default, or set it for partners who transact in another currency.
* **Language** - the language their portal and communications render in. Choose from your enabled languages; leave it on the default to inherit the organization language.
Open the **Partner Info** section and set **Categories** to tag the partner (for example by region, industry, or partner type). Categories help you slice the list and target segments, so apply the tags your program filters by.
The **Partner Info** section also carries the CRM fields you configured as columns on the partner list - account owner, region, health score, renewal date, any custom property. They are the live CRM values, and the editable ones can be changed right here: the write goes straight to your CRM, so you never open HubSpot or Salesforce to correct a field while working the partner.
Read-only properties, owner lookups, and picklists with no synced options show as values rather than inputs, and you need write access to Partners. Which fields appear is set on the partner list's configure panel, so the record shows exactly what your team decided to track. See [Show and rename CRM fields](/features/integrations/crm/guides/show-and-rename-crm-fields).
Open the **Portal Info** section to control what the partner gets:
* **Experience** - the experience the partner's portal is published with. Choosing one creates or updates their portal. Pick the branded experience that fits their partner type.
* **Commission Plan** - the commission plan(s) that apply to this partner. Set it so their conversions and payouts calculate against the right plan.
To change the linked company or CRM record, use the edit control on the **Partner Details** card to pick a different company or partner object, or to enter a company name and domain directly.
### Manage the partner's people
Open the partner's **People** tab to see everyone associated with the partner organization. This is the list of contacts who can be given portal access and notifications.
Use the add control to add a person to the partner. Enter their work email, and optionally their first and last name, so they appear on the partner and can be invited; left blank, the name comes from the matched CRM contact. Their role is read from your CRM contact mapping when one is configured, so the role shown reflects what the CRM holds.
For a contact who should use the partner portal, grant access (the invite action) so they receive an invitation. Once a contact has access, you can toggle whether they receive notifications. Contacts without access do not get portal notifications.
Removing a person from the partner works whether or not the partner has an experience yet, and a CRM contact you removed stays removed on the next sync.
Open a person to see their detail, where a ** fields** section carries the Contact properties you configured as columns on the **People** list - job title, seniority, country, or any custom field. The editable ones can be changed inline and write straight back to the contact in your CRM, and a link takes you to the contact record itself when you need the full picture. Correcting a job title or a phone number is a two-second edit on the partner, not a trip into HubSpot or Salesforce.
Their role is read from your CRM contact mapping when one is configured, so the role shown reflects what the CRM holds. Only CRM-backed contacts can be edited this way; a person who exists only in Introw has no CRM record to write to.
### Capture context with notes
Open the partner's **Notes** area (also reachable from the **Note** action on the **Partner Details** card). Notes capture what a structured field cannot: what was agreed, what to follow up on, and the history of the relationship.
Write the note. It is saved to the partner and visible to your team, so anyone can pick up the relationship with full context. Use the **Message** action on the same card when you want to post an internal comment instead of a lasting note.
## Verify it worked
The **Partner Details** card shows the tier, phase, champion, currency, and language you set, and the **Portal Info** section shows the chosen experience and commission plan. Any CRM field you edited on the **Partner Info** card or on a person's detail shows the new value, and the same value is on the record in your CRM. The **People** tab lists the contacts with their access state, invited contacts receive their invitation, and your notes appear on the partner for the whole team to see. The partner now experiences the portal, language, and commissions you configured.
## Related
Shape the list with views, columns, and phases.
Add a partner that sync has not detected yet.
Give a contact portal access.
Choose which CRM fields appear on the record, and edit them from Introw.
Full configuration options for partner records.
# Partner Management
Source: https://docs.introw.io/features/partners/partner-management/index
Auto-detect partners from your CRM, keep them in sync both ways, and organize them into lifecycle phases - one partner list, always the CRM's.
> Partner Management turns the partners you already track in your CRM into a live, organized program, with no second list to maintain and nothing that drifts out of sync.
## The problem it solves
Most programs run on a partner list that started in the CRM and quietly diverged into spreadsheets:
| Without Introw | With Introw |
| - | - |
| Recruiting is guesswork | Detect them from the CRM |
| The list drifts from the CRM | Two-way sync, one record |
| No view of where each stands | Lifecycle phases at a glance |
| Adding a partner is data entry | Matching records sync in |
## Impact
A partner can tell when a vendor has to look them up. Working from one live record, with their stage and their people on it, is what makes every conversation feel like a continuation.
for your business
* **In your CRM**
One partner list, owned by the CRM and synced both ways, so there is no second source of truth to keep
* **Live in days**
Detection builds the list the moment you connect, so the program starts populated instead of empty
* **Cost to run**
Partner ops configures detection, phases and views without involving engineering
for your partners
* **Self-serve**
Their people, deals, tasks, assets and goals are all on one record, so context is never rebuilt
* **Enabled**
Their stage is explicit, so a conversation starts from where they actually are
* **Efficient**
Nothing re-entered: their company data comes from the CRM record you already had
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Managers** - the relationship in one place
* **Partner Operations** - detection, phases and views
* **CRM Administrators** - no rogue partner objects
## See it work
* 
**Shape the list**
Show the built-in and CRM-backed properties your team works on.
* 
**Work the record**
Tier, phase, champion, currency and language, in one place.
* 
**See their people**
Every contact on the account, with portal access per person.
* 
**Change many at once**
Tier, plan, currency, a team role, or the partner manager.
## How it works
Partner Management detects your partners directly from the companies or records you keep in HubSpot or Salesforce. You tell Introw how partners are stored, which records count as partners, and what to link to them, and it builds your partner list from there. New partners that match your criteria can flow in automatically, and changes sync both ways so the CRM stays the source of truth.
Once partners are in, you organize them. A visual list shows the properties that matter to your team, and lifecycle phases (from first contact to signed and active) let you see at a glance where every partner sits. Each partner has a detail view with their people, deals, tasks, assets and goals in one place. A partner manager never has to leave Introw to understand a relationship, or jump into the CRM to keep it current.
Partner Management makes the CRM do the heavy lifting. Instead of maintaining a partner database, you point Introw at your existing records and it keeps a single, synced partner list organized into the phases your program runs on. Partner ops gets clean data without reconciliation, and partner managers get one place to see and move every relationship.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
crm["Point at CRM records"] --> list["Single synced partner list"]
list --> phases["Organized into phases"]
```
## Run it from your AI assistant
* Show partners in EMEA with no activity in the last 60 days.
* Change Acme's partner manager to me.
* Update Globex's lifecycle phase to active.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Partners are detected from your CRM.
Assign an owner to each partner.
Organize partners into tiers.
Trigger on a partner appearing or changing, and write fields back.
# Partner Management
Source: https://docs.introw.io/features/partners/partner-management/technical/index
Detect partners from your CRM, enable automatic sync, and organize the partners list into onboarding phases and lifecycle stages in Introw.
## Where it lives
Partner Management sits under **Partners**, at [Partners](https://app.introw.io/partners).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| A connected CRM | Partners are detected and synced from it | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
| Write access to Partners | To create and edit them | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Integration settings access | Detection and sync are configured there | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
## How it works
Introw builds your partner list from your CRM. During CRM setup you answer three
questions: how partners are stored in your CRM, which records actually count as
partners, and which objects (like deals) to link to them. From your answers,
Introw imports matching records as partners, links each one back to its CRM record,
and can keep importing new matches on its own.
Every partner lands in a **phase**, the lifecycle stage shown as a column in the
grid view of the partners list. You manage the list itself with **views**:
saved combinations of filters, columns, and sharing that let different teams look
at partners the way they need to. Open any partner to see their people, deals,
tasks, notes, assets, and goals, and to set per-partner fields like phase, tier,
champion, and language.
## Settings & configuration
Partner detection and sync are configured in the CRM setup flow, reached from
[Settings, then Integrations](https://app.introw.io/settings/integrations). The
list itself is configured directly on the Partners page.
### CRM detection and sync
**How partners are stored** is the first setup step. You pick the CRM object that
represents a partner, such as Company, Account, or a custom Partner object, and
confirm it. This tells Introw where to look.
**Partner filters** narrow that object down to the records that are really
partners, using CRM properties plus manual selection. Only records that match
become partners in Introw.
**Automatically sync new partners** is the toggle that keeps detection ongoing.
When it is on, any new CRM record that matches your filters becomes a partner in
Introw without manual work. It becomes available once your filter selection covers
all partners, so Introw knows the full set it should watch.
**Linked objects** decide what gets attributed to each partner, such as the deals
or contacts associated with them. You define one or more named links so partner
deals and people show up on the partner record.
### The partners list
**View** switches between **List view**, a table of partners, and **Grid view**,
a board with one column per phase. The choice is remembered for you.
**Phases** are the lifecycle stages partners move through. They are managed from
the list's configure panel, where you can add a phase, rename it, reorder phases,
and remove one (migrating its partners to another phase first). A fresh workspace
starts with a default set from potential partner through to won and lost.
**Views** are saved looks at the list. Each view has its own filters, visible
properties, and a sharing setting of **Private** or **Shared with team**. Use the
configure panel to choose which partner properties appear as columns and to add
new ones.
**Bulk edit** appears when you select one or more partners with the row
checkboxes. From the bulk actions bar you can update **Tier**, **Commission
Plan**, **Currency**, or a partner team role for every selected partner at once,
or run other actions such as applying an experience or adding a comment.
### Per-partner fields
On a partner's detail page you can set fields such as **Phase**, **Tier**,
**Champion**, **Language**, and (when enabled) **Currency**, and you can update the
partner's company or its link to the CRM record. Segment membership is shown here
too, but it is driven by your segments, not edited on the partner.
### CRM fields on the record
The **Partner Info** card also carries the CRM fields you configured as columns on the
partner list, showing live CRM values. Editable ones can be changed inline and write
straight back to your CRM; read-only properties, owner lookups, and picklists with no
synced options render as values instead. The same applies one level down: open a person
on the **People** tab and their ** fields** section shows the Contact properties
configured on the People list, editable in place, with a link through to the contact in
your CRM. Both views read their list's configuration, so you choose the fields once. See
[Show and rename CRM fields](/features/integrations/crm/guides/show-and-rename-crm-fields).
### Automate it with a workflow
The partner record is where most [workflows](/features/automation/workflows/technical) begin and end. **Partner created** runs when a new partner appears, whether someone added them or CRM detection brought them in, which is the hook for onboarding every partner identically. **Partner updated** runs when one of their fields changes, in Introw or in your CRM, narrowed by **Which changes count**: the Introw partner fields plus every partner-level CRM property on the company or your custom partner object.
The matching action is **Update partner properties**, which writes tier, phase, categories, owner, the partner's portal experience, and any writable CRM property, each row with its own **Write mode**. **Overwrite** always replaces what is there; **Fill in if not known** leaves a value a partner manager set by hand alone. Changes a workflow makes itself never re-trigger it, so writing a field the same workflow triggers on does not loop.
See [React to a CRM change on a partner](/features/automation/workflows/guides/react-to-a-crm-change-on-a-partner) and [Onboard a new partner automatically](/features/automation/workflows/guides/onboard-a-new-partner-automatically).
## How-to guides
* 
[**Bulk update partners**](/features/partners/partner-management/guides/bulk-update-partners)
Bulk edit tier, commission plan, currency, team roles, or the published portal experience for many partners at once, without updating them one by one.
* 
[**Create a partner manually**](/features/partners/partner-management/guides/create-a-partner-manually)
Add a single partner by hand and link it to its CRM company before automatic sync detects it, so you can start onboarding right away.
* [**Detect partners from your CRM**](/features/partners/partner-management/guides/detect-partners-from-your-crm)
Understand how Introw builds and syncs your partner list from CRM records, and where to run the connect-and-detect setup to keep it current.
* 
[**Organize the partners list**](/features/partners/partner-management/guides/organize-the-partners-list)
Build views, columns, filters, and lifecycle phases so each team reads the partners list the way they need to, then act on partners in bulk.
* 
[**Work a partner record**](/features/partners/partner-management/guides/work-a-partner-record)
Open a partner, set every field that drives their experience, keep their contacts current, and capture the context your team needs.
## Troubleshooting
Automatic sync only becomes available once your filter selection covers all partners, so Introw knows the full set to watch. Removing a phase requires moving its partners to another phase first. Partner detection depends on a connected CRM; without one you can still create partners manually, but there is nothing to sync against.
Check that the record matches your partner filters, or create it manually from its CRM company.
Automatic sync is likely off, or your filter selection does not yet cover all partners; revisit the find step.
The view is set to Private; switch it to Shared with team.
## FAQ
Many, one per entity you need to treat separately, because a partner is the unit that carries a portal, contacts, attribution, tiers, commissions and reporting. If the regions have different contacts, different owners, or their own numbers, they are separate partners. Group them back together with a [segment](/features/partners/segments) or a shared CRM property, and report on the group rather than the parent. There is no parent-and-child partner relationship, so a grouping property is the thing to keep clean.
No. Detection finds the ones already there, and you can [create a partner by hand](../guides/create-a-partner-manually) at any time, including with no CRM connected at all. A [partner application form](/features/forms/form-builder/guides/set-up-a-partner-application-form) creates them from a submission, and because a form's automation runs once per row, adding a [batch upload field](/features/forms/sharing-submitting/guides/bulk-upload-multiple-records) to that form turns a spreadsheet of partners into one pass. The [API](/features/developer/api) does the same from wherever your list lives today. A partner created in Introw can be linked to a CRM record later.
Tighten the filter on the partner object rather than deleting records: the filter is the boundary, and anything outside it never syncs. A dedicated CRM property that your filter tests on is the version of this that survives a program change, because it makes the decision explicit on the record instead of implicit in a list.
A deal can legitimately carry more than one partner: that is how [two-tier attribution](/features/deal-registration/multi-tier) credits a reseller and its distributor on one record, and each sees it in their own pipeline. What you do not want is an accidental double claim, which is what the conflict check on a [registration form](/features/deal-registration/registration) is for. If a duplicate has already landed, fix it on the CRM record, since attribution lives there.
# Create a dynamic segment
Source: https://docs.introw.io/features/partners/segments/guides/create-a-dynamic-segment
Build an audience that updates itself from filters, then set its permissions and notifications so the whole segment behaves the way you want.
## What you'll achieve
A dynamic segment whose membership follows your conditions automatically, with collaboration permissions and notification behavior set for that audience. Point any feature (a portal experience, a course, a campaign) at the segment and it stays targeted at the right partners, who collaborate and get notified exactly as you intend.
## Before you start
You need access to segment settings. A connected CRM lets a dynamic segment filter on live partner data.
Decide what makes a partner belong (for example tier, region, or lifecycle phase) so your conditions capture fit and behavior, not just one label.
## Watch it
## Steps
Go to [Segments](https://app.introw.io/settings/segments) and create a new segment. The segment editor opens on the **General** tab.
On the **General** tab, fill in the basics:
* **Segment name** - how the segment appears everywhere you use it (for example "Enterprise partners"). Required, and worth making self-explanatory since teammates pick it from lists.
* **Description** - an optional note for your team about who this segment is for. It does not affect membership.
On the **Audience** tab, set **Enrollment type** to **Dynamic**. Dynamic means membership auto-updates from conditions: partners entering or leaving the criteria are added or removed in real time as CRM properties change. (Choose **Static** instead only when you need a fixed, hand-picked list - see [Create a static segment](./create-a-static-segment).)
Still on the **Audience** tab, build the rules that decide who belongs:
* **Partner conditions** - rules on partner-level fields (such as tier, phase, country, or a CRM property). Use these to target by organization-level fit.
* **Contact conditions** - rules on the people at those partners, when you want to narrow to contacts who match (such as a role or activity signal).
Combine conditions to target by fit and behavior together, not just one label. Contact conditions cover Introw's own signals too, so a completed course or an earned certificate can define the audience. The live audience panel is open beside the builder as you work; the header control collapses it (**Hide audience**) and brings it back (**Show audience**).
Review the audience preview of who currently matches, with its partner and contact counts, to confirm the segment captures the right people before you rely on it.
On the **Permissions** tab, switch on **Override the default for this segment** first. Until you do, the segment follows your organisation default and the panel is read-only, showing you what its members currently get.
Both are phrased as grants, so more permission always reads as on.
* **Invite colleagues** - lets partners in this segment invite their own coworkers into the portal, and invited colleagues inherit the organisation default. The partner manager assigned to that partner is CC'd on every invite they send.
* **See all shared records** - when on, a contact sees everything shared with their company. Turn it off and they see only the records they are assigned as a collaborator on, with notifications following that access.
Each card shows a live preview of the partner-side result, and any setting that differs from your default is marked with an **Override** pill. For contacts in several override segments that disagree, the most permissive one wins. See [Layer segments to progressively unlock capabilities](./layer-segments-to-progressively-unlock).
Each card says which side of your default it is on, and moving it back is how the segment goes back to following the default. Across overlapping segments both resolve the same way, most-permissive: an invite grant in any of them wins, and **See all shared records** switched on in any of them wins.
On the **Notifications** tab, switch on **Override the default for this segment**, then set the recipients per event (announcements, comments, new records, task nudges, object updates, sleeping-deal nudges, submission outcomes, course and certificate events):
* **All partners** - everyone in the segment the event applies to.
* **Collaborating only** - just the contacts assigned as collaborators on the record. Offered only for events attached to a CRM record.
* **Disabled** - the event does not send to this segment.
Change only the events where this segment should differ from your default; the rest inherit it. Every event you change is marked with an **Override** pill, and the switch reports how many differ. For contacts in several override segments, the most allowing opinion wins: an event turned on in any of them reaches the contact, even if another turns it off.
This tab is **email only**. Which events reach a partner's Slack, Teams, or WhatsApp channel is set per platform on that chat integration, not per segment. See [Channels](/features/engagement/channels).
Save to create the segment. Membership now updates on its own as partner data changes, and the permissions and notification settings apply to everyone the conditions capture.
## Verify it worked
The segment shows its current members on [Segments](https://app.introw.io/settings/segments), and the count shifts as matching partner data changes. The segment also shows where it is used across the product, so before you later edit or delete it you can see its reach.
## Related
Hand-pick a fixed audience instead.
Use the segment to gate portal content.
How overlapping segments resolve, and how to design around it.
Full configuration options for segments.
# Create a static segment
Source: https://docs.introw.io/features/partners/segments/guides/create-a-static-segment
Hand-pick a fixed list of partners and contacts, then set its permissions and notifications so the exact group behaves the way you want.
## What you'll achieve
A static segment containing exactly the partners and contacts you chose, with collaboration permissions and notification behavior set for that group. The list stays fixed until you change it, and every feature pointed at the segment treats precisely that group the way you intend.
## Before you start
You need access to segment settings.
Have the partners (and the specific contacts) you want in mind, since a static segment is the exact list you pick.
## Watch it
## Steps
Go to [Segments](https://app.introw.io/settings/segments) and create a new segment. The segment editor opens on the **General** tab.
On the **General** tab, fill in the basics:
* **Segment name** - how the segment appears everywhere you use it. Required.
* **Description** - an optional note for your team about who this group is for.
On the **Audience** tab, set **Enrollment type** to **Static**. Static means you hand-pick the members and the list stays exactly as you set it until you edit it, rather than following conditions.
On the **Audience** tab, check the partner organizations you want in the segment. The audience panel shows the running count of who will be enrolled, so you can confirm the group as you build it.
Switch the audience view to contacts to refine who is included from those partners. By default the contacts at the partners you picked are enrolled; check or uncheck specific people when you need a tighter set than "everyone at these partners".
On the **Permissions** tab, switch on **Override the default for this segment** first. Until you do, the group follows your organisation default and the panel is read-only, showing you what its members currently get.
Both are phrased as grants, so more permission always reads as on.
* **Invite colleagues** - lets these partners invite their own coworkers into the portal, and invited colleagues inherit the organisation default. The partner manager assigned to that partner is CC'd on every invite they send.
* **See all shared records** - when on, a contact sees everything shared with their company. Turn it off and they see only the records they are assigned as a collaborator on, with notifications following that access.
Each card shows a live preview of the partner-side result, and any setting that differs from your default is marked with an **Override** pill. For contacts in several override segments that disagree, the most permissive one wins. See [Layer segments to progressively unlock capabilities](./layer-segments-to-progressively-unlock).
Each card says which side of your default it is on, and moving it back is how the segment goes back to following the default. Across overlapping segments both resolve the same way, most-permissive: an invite grant in any of them wins, and **See all shared records** switched on in any of them wins.
On the **Notifications** tab, switch on **Override the default for this segment**, then set the recipients per event (announcements, comments, new records, task nudges, object updates, sleeping-deal nudges, submission outcomes, course and certificate events): **All partners**, **Collaborating only** for events attached to a CRM record, or **Disabled**. Change only the events that should differ from your default; the rest inherit it. For contacts in several override segments, the most allowing opinion wins: an event turned on in any of them reaches the contact, even if another turns it off. This tab is email only, since chat is set per platform on the chat integration. See [Channels](/features/engagement/channels).
Save to create the segment. The list stays exactly as you set it, with the permissions and notification settings applied to that group.
Come back and add or remove members whenever the group changes; static segments do not update on their own.
## Verify it worked
The segment on [Segments](https://app.introw.io/settings/segments) contains exactly the partners and contacts you selected, and shows where it is used across the product so you can check its reach before editing or deleting it.
## Related
Let conditions define the audience instead.
Use the segment to gate portal content.
How overlapping segments resolve, and how to design around it.
Full configuration options for segments.
# Layer segments to progressively unlock capabilities
Source: https://docs.introw.io/features/partners/segments/guides/layer-segments-to-progressively-unlock
Set your organisation default, then let more specific segments override it to grant access as partners qualify, and know exactly how overlapping overrides resolve.
Partner contacts rarely sit in exactly one segment: a certified reseller in the Benelux can match your reseller segment and your certified segment at the same time. Introw resolves that in one cascade: your organisation-wide **All partners · Default** is the floor, segments that opted in to overriding it change it for their members, and the contact's own opt-outs come last. That makes segments safe to layer: set your baseline once on the default, and let each more specific segment change only what that stage earns. This is the mechanic underneath [progressive onboarding](/features/partners/onboarding), where journeys move partners toward milestones and each milestone unlocks the next layer. This guide sets up the layers, spells out exactly how overlapping settings resolve, and pairs the layers with a journey so partners keep moving up.
## What you'll achieve
A layered setup where every partner starts on your organisation default and unlocks more permissions, notifications, and portal content as they qualify for more specific segments, with a journey giving them the concrete path to the next layer, and no risk that an overlap accidentally locks a partner out of something they earned.
## How the default and overlapping segments resolve
Every permission and every partner email notification resolves the same way, per setting:
1. Start from **All partners · Default**, your organisation-wide baseline.
2. Apply the segments the contact matches **that opted in to overriding**. A segment with its override switch off contributes nothing, whatever its stored settings say.
3. Apply the contact's own opt-outs, which can only ever switch something off.
Two rules govern step 2:
* **An override replaces the default, in both directions.** Where an override segment states a setting, that value wins over the baseline, so a segment can hold a group back as well as open it up. A segment states a setting by moving it away from the default; anything it leaves alone falls through untouched, which is why a segment that only grants invites cannot accidentally change record visibility.
* **Overlapping overrides merge most-permissive.** When a contact matches several override segments that disagree on the same setting, whichever of them grants the most decides. Qualifying for more groups never takes a capability away:
* **Invite colleagues** - on if any of their override segments has it on.
* **See all shared records** - on if any of their override segments has it on. One is enough; the others do not have to agree.
* **Notification recipients** - the wider audience wins, so all partners beats collaborating only, and either beats disabled.
So if your default withholds full record visibility, a **Sales manager** segment grants it, and a **Gold partner** segment withholds it, a contact who matches both sees all shared records. They are a sales manager, and matching Gold as well does not cancel that.
Two things sit outside this cascade:
* **The contact's own opt-outs can only opt out.** A contact can turn off any event the layers above leave available, but cannot re-enable an event the default or a matched segment locked to off. Open their **Notifications** tab to read the full cascade, with each row badged by the layer that decided it and a link to change it at the right level.
* **Segment-gated surfaces are a union.** A tab, asset, form, course, or report restricted to segments is visible to a contact in any of those segments. Membership in another, more restricted segment never hides it, and this is unaffected by override switches.
The practical rule: your restrictions belong on the **default**, not spread across every segment. You no longer have to mirror a restriction into each segment to make it hold, a stage segment can lift one for the partners who earned it, and creating a segment for targeting no longer changes anyone's permissions or notifications.
## Before you start
You need access to segment settings, and write access to the experiences you plan to gate.
Decide the stages a partner moves through (for example: everyone, onboarded, certified, co-sell) and what each stage should unlock: which tabs, which permissions, which notifications.
## Watch it
## Steps
Go to [Segments](https://app.introw.io/settings/segments). **All partners** is pinned as the first row of the table, tagged **Default**; open it to reach **Default settings**. This applies to every partner and contact, including everyone who joins later, and it is the one place your most restricted settings belong.
* On the **Permissions** tab, set the tightest posture you want new partners to have: turn **Invite colleagues** off if new partners should not bring in coworkers yet, and turn **See all shared records** off if they should only see records they actively collaborate on.
* On the **Notifications** tab, keep only the essentials on (for example announcements), and set the events a brand-new partner should not receive yet, such as object updates, to **Disabled**.
You do not create a segment for this. The default is a layer of its own, and a dynamic segment with no conditions is not allowed to override anyway.
Create one dynamic segment per stage of your progression, each with the condition that marks the stage's milestone: an onboarding journey completed, a certificate earned, a tier reached, a lifecycle phase, or a CRM property value. Every stage segment needs at least one condition, which an override segment requires anyway.
On each, switch on **Override the default for this segment** on the tab you want to change, then configure only what the stage **earns**:
* **Permissions** - turn **Invite colleagues** on for stages trusted to grow their own team; turn **See all shared records** on so the stage sees everything shared with their company.
* **Notifications** - widen the recipients on the events the stage should now receive, for example object updates from **Disabled** to **Collaborating only** or **All partners**.
Stage filters do not need to exclude earlier stages: a partner who qualifies for a later stage usually still matches the earlier segments, and because overrides merge most-permissive, that overlap is exactly what you want. Leave a tab's override switch off wherever the stage changes nothing, and the segment simply inherits the default there.
The flip side is that a segment cannot hold a group back from something another of their segments grants. To keep a capability away from a group, withhold it on the default and grant it only on the segments that should have it, rather than granting it broadly and trying to claw it back.
See [Create a dynamic segment](./create-a-dynamic-segment) for the full walkthrough of the editor.
Point the surfaces each stage unlocks at its segment: restrict tabs and sections of an experience, target assets, courses, and forms. A partner in any of the chosen segments sees the surface, so gating to a stage segment shows it the moment a partner qualifies. See [Restrict a tab to segments](/features/portal/portal-access/guides/restrict-a-tab-to-segments).
Layers only unlock if partners hit the milestones your segments key on, so pair the setup with a **journey**: the ordered checklist that walks a partner toward the next stage, for example complete the onboarding tasks, finish the certification course, register a first deal. As they complete it, the milestone lands in their partner data, the next stage's dynamic segment picks them up, and the layer unlocks on its own. See [Build a journey from scratch](/features/partners/journeys/guides/build-a-journey-from-scratch) and [Assign a journey and track progress](/features/partners/journeys/guides/assign-a-journey-and-track-progress); for the full assembled pattern, tabs and sections included, see [Build a progressive onboarding path](/features/partners/onboarding/guides/build-a-progressive-onboarding-path).
Pick a partner contact who matches at least one granting segment and confirm they get the granted behavior, not the baseline: they see the unlocked tabs, they can invite, and they receive the events that stage earns. Open their **Notifications** tab and check the cascade names the stage segment rather than the default. Then check a partner who matches no stage segment still gets the restricted floor.
## Verify it worked
A partner who qualifies for a stage segment gains its capabilities, and a partner who matches none of them stays on your default. On [Segments](https://app.introw.io/settings/segments), the **Permissions** and **Notifications** columns show at a glance which stages change what and which follow the baseline. As partner data changes in your CRM, dynamic segment membership shifts and the portal opens up on its own, with no per-partner access management.
## Related
Build the segments each stage keys off.
The full assembled pattern: stages, gated tabs, and journeys.
Give partners the checklist that moves them to the next layer.
Full configuration options for segments.
# Spot and re-activate inactive partners
Source: https://docs.introw.io/features/partners/segments/guides/re-activate-inactive-partners
Build rolling segments of inactive and engaged partners, then route each into tailored follow-up to re-activate them the moment their activity drops.
Partner managers usually notice a partner has gone quiet only when a renewal wobbles or a number slips, and by then the momentum is already lost. A dynamic segment built on last activity turns that reactive scramble into a standing list: group the partners who have gone silent, group the ones still engaged, and point each at the right follow-up. Because a dynamic segment re-evaluates itself against live data, a partner who re-engages drops off the inactive list on their own, and whatever you wire to each segment keeps running without anyone maintaining a spreadsheet.
## What you'll achieve
Two rolling segments, one for partners who have gone quiet and one for partners who are actively engaged, that keep themselves current from live activity. Point re-engagement follow-up (an announcement, a task, a journey) at the inactive segment and deeper enablement at the engaged one, and each partner moves between the two automatically as their activity changes, with no list to maintain.
## How last activity is measured
Segments can filter on two separate activity signals, and they mean different things:
* **Partner last activity** - the last time anything happened on the partner, from either side. A portal or room visit, an asset view, a comment, a task update, a deal or object update, a form submission, or an announcement all refresh it. Because it counts your team's activity too, read it as "has this account gone dark", not "has the partner taken an action".
* **Contact last activity** - the last time that specific contact did something themselves. Only the contact's own actions refresh it; activity your team logs on their behalf does not. Use this when you want to catch a single champion going quiet rather than the whole account.
* **Contact last nudged** - the last time you successfully sent that contact an outbound email from Introw (announcements, journey steps, notifications, and other automated sends). It refreshes only when the send left without a delivery error, per recipient address within your organisation. It deliberately does not count opens, clicks, bounces, or failed sends, so it measures your own outbound reach, not the contact's engagement. Use it to find contacts you haven't touched recently, for example "everyone we haven't emailed in the last 60 days", so a re-engagement send doesn't pile on top of one you already sent.
Choose the level that matches what you're asking. Partner and contact last activity answer "who has gone quiet on us?"; contact last nudged answers "who have we gone quiet on?". They compose well - combine "Contact last nudged is before 60 days ago" with "Contact last activity is before 30 days ago" to catch contacts who are inactive *and* haven't heard from you in a while.
A partner or contact who has never been active has no last-activity date at all. A "before" comparison never matches an empty date, so an inactive segment that should also include partners who never engaged has to say so explicitly (see the third step below).
## Watch it
## Before you start
You need access to segment settings, and a connected CRM so a dynamic segment can filter on live partner activity.
Decide what "engaged" and "inactive" mean for your program, for example active within the last 7 days, and silent for 30 days or more. Pick the windows that match your sales motion.
## Steps
### Build the inactive segment
Go to [Segments](https://app.introw.io/settings/segments), create a new segment, and set **Enrollment type** to **Dynamic** on the **Audience** tab. Only a dynamic segment re-evaluates its members as activity changes; a static list would freeze the moment you saved it. Give it a name the whole team recognises, such as "Inactive partners (30+ days)". See [Create a dynamic segment](./create-a-dynamic-segment) for the full editor walkthrough.
Under **When a partner matches**, add a condition on **Partner last activity**. Set the operator to **`<`** (before) and the value to a **Relative** preset, picking **30 days ago** or typing your own window. This captures every partner whose last activity is older than your threshold. To key off a specific champion instead of the account, add the same condition under **When a contact matches** on **Contact last activity**.
A partner who has never done anything has no last-activity date, and the **`<`** comparison skips them. To pull them in, add a second condition on **Partner last activity** with the operator **is not known**; the builder joins it to the first with **Or**, so a partner counts as inactive when their last activity is old *or* absent. Leave this out only if you deliberately want to exclude partners who never engaged.
Use the audience preview to confirm the segment is catching the partners you expect, and not, say, everyone. Adjust the window until the list looks right, then save.
### Build the engaged segment
Create another dynamic segment the same way, for example "Engaged partners". This is the positive mirror of the inactive one.
Under **When a partner matches**, add a condition on **Partner last activity** with the operator **`≥`** (on or after) and a **Relative** value of **7 days ago**, so the segment holds the partners who have done something recently. Check the preview and save.
### Route each segment to follow-up
Point your win-back motion at the inactive segment: target a re-engagement [announcement](/features/engagement/announcements) at it, assign a [journey](/features/partners/journeys) that walks the partner back to a clear next step, or create a [task](/features/partners/tasks) so a partner manager reaches out. Because the segment is the audience, everyone currently quiet is included, and no one else.
Point deeper enablement at the engaged segment: advanced content, a co-sell announcement, or the next tier's requirements, so momentum compounds where it already exists.
## Verify it worked
Open each segment on [Segments](https://app.introw.io/settings/segments) and confirm the member counts and names match what you expect. Then watch the mechanic work: when a quiet partner logs back in, views an asset, or registers a deal, their **Partner last activity** refreshes, they fall outside the "before 30 days ago" window, and they drop off the inactive segment (and into the engaged one) on their own. Anything you wired to the segments follows automatically, with no list to prune.
## Related
Build the audience that updates itself from conditions.
Target a re-engagement message at the inactive segment.
Combine engagement segments with stage-based unlocking.
Full configuration options for segments.
# Segments
Source: https://docs.introw.io/features/partners/segments/index
Group partners into dynamic or static segments that target content, notifications, permissions, and more - audiences that keep themselves current.
> Segments are how you target the right partners: build an audience from live filters or a hand-picked list, then use it across the product so the right partners get the right experience.
## The problem it solves
Targeting partners usually means maintaining lists that are out of date the moment you
save them:
| Without Introw | With Introw |
| - | - |
| Targeting lists go stale at once | Dynamic filters stay current |
| One message misses everybody | Tailor it to who it fits |
| A tier is too blunt to target | Group on real attributes |
| Reusing an audience means rebuilding | Defined once, used widely |
## Impact
Partners disengage from programs that treat them like everybody else. Targeting on live CRM attributes rather than a single tier label is how the experience starts to fit them.
for your business
* **Cost to run**
One audience defined once and pointed at portal, notifications, courses and content, with no list upkeep
* **In your CRM**
Dynamic segments combine live CRM attributes and behaviour, so targeting stays accurate at any scale
for your partners
* **Self-serve**
The portal opens up as they qualify, because the most permissive overlapping segment wins
* **Enabled**
What reaches them fits them, rather than being everything sent to everyone
* **Efficient**
Nothing is taken away by still matching an earlier stage, so progress only goes forward
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Operations** - the audiences everything targets
* **Partner Marketing** - content aimed at who it fits
* **Partners** - an experience that fits them
## See it work
* 
**Dynamic or static**
A live filter, or a hand-picked list.
* 
**Define the audience**
Conditions on the partner, and on their contacts.
* 
**Check who matches**
A preview, before anything is targeted at them.
* 
**Override deliberately**
Permissions change only where you switch on an override.
## How it works
A segment is a named group of partners and contacts you can reuse everywhere. You can
build a **dynamic** segment from filters, so membership updates itself as partner data
changes in your CRM, or a **static** segment by hand-picking exactly who belongs. Either
way, the segment becomes a single audience you point other features at.
Segments do more than tag partners. One segment can drive everything a partner
experiences: which portal experiences appear, which notifications go out, what permissions
apply, and who gets targeted by courses, content, and campaigns. You define an audience
once and reuse it across the whole product, instead of setting up targeting feature by
feature. And because dynamic segments combine many live CRM attributes and behavior and
update themselves as that data changes, your targeting stays accurate at any scale without
anyone maintaining lists. That is what lets you move beyond static tiers toward audiences
defined by real fit and behavior.
Segments are also safe to layer. Permissions and notifications start from one
organisation-wide default, and a segment changes it only when you deliberately switch on
an override, so creating a segment to target an announcement never has side effects.
Where a segment does override, it can open something up or hold it back, and when several
overrides overlap the most permissive one wins, so nothing a partner earned is taken away
by still matching an earlier stage. That is what powers progressive unlocking: set your
baseline once, and let the portal open up as partners qualify for more.
Segments give your program a reusable targeting layer. Partner ops defines an audience
once, as a live filter or a fixed list, and every other feature can target it. Dynamic
segments keep themselves accurate from CRM data, so partner marketing reaches the right
partners with the right experience instead of curating lists by hand.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
define["Define an audience"] --> keep["Live filter or fixed list"]
keep --> target["Every feature targets it"]
```
## Run it from your AI assistant
* List partners in the healthcare vertical with over \$100k in sourced pipeline.
* Which partners match our top-performer profile?
* Show partners grouped by tier and country.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Gate portal tabs and sections.
Power progressive unlocking.
Control which assets and folders partners see.
Target an announcement at the right partners.
Auto-enroll a segment in a course.
Issue a certificate to a segment.
Show a form only to selected partners.
Restrict products to a segment.
Set goal targets for a segment.
Control who can see a report or dashboard.
Scope a deal coach to a segment.
Target tier benefits and assignments.
Trigger on a partner entering a segment, and enroll them in one.
# Set up dynamic and static partner segments in Introw
Source: https://docs.introw.io/features/partners/segments/technical/index
Create dynamic or static partner segments, define their audience criteria, and configure permissions and notifications for each segment in Introw.
## Where it lives
Segments sit under **Settings**, at [Segments](https://app.introw.io/settings/segments). The list groups them by type, and pins the org-wide default as its first row.
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Access to segment settings | To create and edit segments | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A connected CRM | Dynamic segments filter on live data | [Connect HubSpot](/features/integrations/crm/guides/connect-hubspot) |
Static segments need no CRM: their members are an explicit list.
## How it works
A segment is a reusable audience of partners and contacts. It is one of two types.
A **dynamic** segment selects its members automatically from the filters you define,
so membership updates as partner data changes. A **static** segment is a list you
hand-pick and update manually. You choose the type when you create the segment.
A segment is edited across a few tabs: its general settings, its **audience** (the
filters or hand-picked members), its **permissions**, and its **notifications**. Once
saved, a segment can be used across the product, from portal experiences to courses
and campaigns, and Introw shows where each segment is used so you can see its reach
before changing or deleting it.
Permissions and notifications resolve through one cascade: the organisation-wide
**All partners · Default**, then any segments that opted in to overriding it, then the
contact's own opt-outs. A segment changes nothing until you switch its override on, and
where it states a setting that value **replaces** the default for its members, in either
direction. Settings it leaves alone fall through untouched. When a contact matches several
override segments that disagree, each setting has its own tie-break: a grant resolves
most-permissive too: one segment that grants a capability decides it. See
[Layer segments to progressively unlock capabilities](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
## Settings & configuration
Segments are managed under
[Settings, then Segments](https://app.introw.io/settings/segments). The list groups
segments by type, and each segment opens a full editor.
### The default every partner starts from
**All partners** is pinned as the first row of the table, tagged **Default** and compared
in the same **Permissions** and **Notifications** columns as your segments. It appears on
the unfiltered **All** tab only, since it is not a segment and cannot match a filter.
Opening it takes you to **Default settings**, with three tabs: **General**, which
summarises the default and how many segments override each half of it, plus the same
**Permissions** and **Notifications** panels a segment has, without an audience. It
applies to everyone, so there is nothing to target. This is a layer of its own, not a
segment, so it has no membership, no usage links, and cannot be archived.
The **General** tab is where you read the override relationship before changing the
baseline: each half carries a count, either **No overrides** or **N segments override
this**, so you know how many groups will not follow a change you are about to make. The
segments list itself names them, one row per segment.
### Overriding the default for one segment
Each segment's **Permissions** and **Notifications** tabs open with one switch,
**Override the default for this segment**. While it is off the panel shows your
organisation defaults read-only, so you can see what the segment's members actually get.
Switch it on and the panel becomes editable, a count pill reports how many settings now
differ from the default, and every setting that diverges is marked with an **Override**
pill.
Creating a segment therefore has no permission or notification side effects, which is
what makes a segment safe to create purely for targeting an announcement.
An override segment has to target a subset. A dynamic segment with no conditions
matches every partner, so it cannot override the default: it would be a second
baseline competing with the first. Add at least one condition, or keep the segment for
targeting only. Static segments are never blocked, because their members are an
explicit list rather than a matched audience.
The segments list carries a **Permissions** column and a **Notifications** column, each a
live diff against your current default. A segment that changes nothing reads **Default**;
one that does shows what it resolves to, or **N overrides** with a tooltip listing each
difference. Because the columns compare against the live default, editing the default
updates every row.
### Choosing the type
**Dynamic** means the audience auto-updates from filters as CRM properties change.
**Static** means you hand-pick the members and the list stays fixed until you change
it. Pick dynamic when membership should follow the data, and static when you need an
exact, fixed group.
### Audience
The **audience** tab is where you define who is in the segment. For a dynamic segment,
set the filters and conditions on partners, contacts, and deals; for a static segment,
hand-pick the partners and contacts. A preview shows who currently matches so you can
sanity-check before saving.
#### Conditions and operators
Conditions are not limited to a flat list of ANDs. Group them with **and** / **or**, and nest the
groups, so "(EMEA and Gold) or strategic" is one segment rather than three.
Every property type offers **Is known** and **Is not known** - the operator to reach for when you want
partners with a value missing, or partners who have never done something. Text properties add contains
and does not contain; dropdowns add **Is any of** and **Is none of**; dates add rolling ranges as well as
fixed dates.
Alongside your CRM properties, Introw contributes its own filterable fields: partner name, phase, tier,
assigned experience, categories, created-in-Introw, partner team, **partner last activity**, and at
contact level **completed course**, **earned certificate**, **contact last activity**, and **contact last
nudged**. Combined with **Is not known**, those are what build "never opened the portal", "certified but
inactive for 90 days", or "nudged last week and still silent".
### Permissions
The **permissions** tab controls how the segment's partners can act. Each permission is a
card that states the rule, lists what it means in practice, and shows a live miniature of
the partner portal that reacts as you toggle it, so you can see the partner-side result
without publishing and impersonating a partner.
Both are phrased as grants, so more permission always reads as on.
**Invite colleagues** lets partner contacts invite coworkers into the portal, and invited
colleagues inherit the organisation default. It governs every route a partner has to add
someone, including their own team page at partners.introw\.io: with it off, the invite
action there is unavailable and points them back at their partner manager. With it on, every
invite a partner sends is CC'd to the partner manager assigned to that partner, so self-serve
never means out of sight. **See all shared records** lets a contact see
everything shared with their company; turn it off and they see only the records they are
assigned as a collaborator on. Notifications follow access either way, so a partner is
never notified about a record they cannot see.
Both replace the default in either direction. They differ only in how several segments
meeting on one contact combine:
| Setting | Overlapping segments merge to | Against the default |
| - | - | - |
| **Invite colleagues** | On if any of them has it on (most-permissive) | Replaces it, in either direction |
| **See all shared records** | On if any of them has it on (most-permissive) | Replaces it, in either direction |
Anything no override segment states falls through to the default. A segment states a
setting by moving it off the default value, so a segment that only grants invites leaves
record visibility alone rather than silently restating it.
**Restrictions are stickier than grants across overlapping segments.** A contact in one
segment that turns **See all shared records** off and another that leaves it on stays
restricted. So a restriction you intend to lift later belongs on the default, where a
stage segment can turn it back on, rather than in a segment the partner keeps matching.
**Invite** no longer behaves as an allowlist. Granting it to one segment used to
implicitly revoke it for everyone else. It now follows the cascade, so to limit invites
to one audience, switch **Invite colleagues** off on the default and on in that segment.
### Notifications
The **notifications** tab tunes which updates this segment's members receive. Switch on
**Override the default for this segment** and you set the recipients per event: **All
partners**, **Collaborating only** (offered only for events attached to a CRM record), or
**Disabled**. Every row that diverges from the organisation default is marked with an
**Override** pill, and the switch reports the live count of overridden events so you can
see the segment's impact without comparing to another screen.
For a contact in several override segments, the most allowing opinion wins per event: if
any of them turns a notification on, they receive it, even when another turns it off, and
the wider audience (all partners over only collaborating contacts) applies. When no
override segment states an event, the organisation default applies.
A segment's notification override is **email only**. Which partner events reach a
partner's Slack, Teams, or WhatsApp channel is set per platform on that chat integration,
on its **Partner channels** tab, because a channel belongs to a whole partner rather than
to a person. Chat cannot be targeted per segment. See
[Channels](/features/engagement/channels).
### How segment overrides show up on a contact
A partner contact's **Notifications** tab renders the full cascade so it is obvious
which layer owns each event:
1. **All partners · Default** - the organisation default, with a link to
[Default settings](https://app.introw.io/settings/segments/default) to edit it.
2. **Matched override segments** - each segment the contact belongs to that overrides
at least one event is listed by name, linked to its editor, with the number of
events it decides.
3. **This contact** - the events the contact has opted out of themselves.
Each event row on the tab is badged with the layer that decided it, so an admin can see
whether a value comes from the default, a specific segment override, or the contact's
own opt-out, and follow the link to change it.
Contact-level toggles are **opt-out only**. They can turn an available event off, but
they cannot re-enable an event that the organisation default or a matched segment has
locked to off. The rule is enforced when the change is saved rather than only hidden in
the interface, so an opt-out recorded against a locked event is stripped before it is
stored and no screen can claim an opinion a higher layer owns.
### Seeing where a segment is used
Each segment shows a count of where it is used across the product. Check it before you
edit or delete a segment so you understand the impact.
### Automate it with a workflow
Segments are how a [workflow](/features/automation/workflows/technical) answers "which partners", and a segment is the only trigger that can catch something no single event names. **Segment membership** runs when a partner enters or leaves a segment, so "quiet for 30 days", "crossed a revenue threshold" and "certified but not transacting" are the same trigger pointed at a different dynamic segment. See [Re-engage quiet partners](/features/automation/workflows/guides/re-engage-quiet-partners).
Every trigger and every condition fork also carries an **Only for partners in** block, so any segment you maintain here doubles as a workflow audience, checked before a run exists. A fork's segment block is re-read when that step runs, which is what lets a workflow ask "are they still quiet?" a week later.
In the other direction, the **Add to a segment** action enrolls a partner in a **static** segment, which is how a workflow unlocks everything else that keys off segments at once: portal tab visibility, content and asset visibility, course auto-enrollment, discounts, and notification recipients. Dynamic segments are not offered, because their membership is decided by their own audience and an enrollment there would be undone at the next evaluation. Segments a workflow adds partners to never re-trigger it.
## How-to guides
* 
[**Create a dynamic segment**](/features/partners/segments/guides/create-a-dynamic-segment)
Build an audience that updates itself from filters, then set its permissions and notifications so the whole segment behaves the way you want.
* 
[**Create a static segment**](/features/partners/segments/guides/create-a-static-segment)
Hand-pick a fixed list of partners and contacts, then set its permissions and notifications so the exact group behaves the way you want.
* 
[**Layer segments to progressively unlock capabilities**](/features/partners/segments/guides/layer-segments-to-progressively-unlock)
Set your organisation default, then let more specific segments override it to grant access as partners qualify, and know exactly how overlapping overrides resolve.
* 
[**Spot and re-activate inactive partners**](/features/partners/segments/guides/re-activate-inactive-partners)
Build rolling segments of inactive and engaged partners, then route each into tailored follow-up to re-activate them the moment their activity drops.
## Troubleshooting
A dynamic segment's membership is computed from its filters and cannot be edited partner by partner; change the filters to change who is in it. Before deleting a segment, check where it is used, since other features may depend on it. Set your baseline on the **All partners · Default** layer rather than spreading it across segments, and remember that a segment needs at least one condition before it can override anything. Overrides merge most-permissive, so a segment cannot hold a group back from something another of their segments grants: withhold a capability on the default and grant it only where it belongs. Archiving a segment stops it applying straight away, both its grants and its restrictions, so the **All partners · Default** layer decides for its members again; restoring it brings its policy and targeting back.
They do not match its filters; adjust the filters or use a static segment.
Its **Override the default for this segment** switch is off, so it inherits the default. The segments list shows **Default** in that column.
They match another override segment that grants more, and the most permissive one wins; tighten that segment or narrow its audience.
Another override segment they match grants it, and overrides merge most-permissive. Narrow that segment's audience, or withhold the capability on the default and grant it only where it belongs.
The segment is dynamic with no conditions, so it matches everyone and cannot override. Add a condition.
Confirm the segment is dynamic; static segments only change when you edit the list.
The segment was in use elsewhere; check the usage count before deleting.
# Create and show partner tasks
Source: https://docs.introw.io/features/partners/tasks/guides/create-and-show-partner-tasks
Create a one-off task on a partner with the right owner, due date, visibility, and auto-complete action, then surface it in the partner portal.
## What you'll achieve
A task assigned to the right person with a due date and visibility set, optionally completing itself when the partner takes an action, and showing up in the partner portal so the partner sees exactly what to do and can check it off without leaving the portal.
## Before you start
Know which partner the task is for. You need permission to manage partners and tasks.
To surface tasks in the portal, you need a published experience the partner can access.
## Watch it
## Steps
### Create the task
Go to [Partners](https://app.introw.io/partners), open the partner, and go to their **Tasks** tab. Add a task and give it a clear name that states the action.
Fill in the task so it lands on the right person with a clear deadline:
* **Due date** - the date the task is due. Set it so the partner knows the deadline; leave it empty for no due date.
* **Assignee** - who is responsible, picked from five groups: **Teams** (your company or the partner as a whole), **Partner segments**, **Internal partner teams** (a role on your side, such as the partner's assigned partner manager), **Your team** (a named colleague), or **Partner contacts** (a named person at the partner). Choose the level of accountability the step needs.
* **Visibility** - who can see the task: **Public** (your team and the partner), **Internal** (your team only), or **Assignee** (your team plus the assignee). A task assigned to the partner must stay visible to them, so it cannot be Internal.
* **Status** - **To do**, **In progress**, or **Done**. New tasks start in To do.
* **Description** - the instructions the partner reads. Be specific so they can act without asking.
* **Attachment** - an optional file to attach for reference.
### Automate completion (optional)
To let the task complete itself when the partner does something in the portal, use **Add action** and pick the **Action type**:
* **Watch asset** - completes when the partner views a chosen asset. Select the asset.
* **Upload** - completes when the partner uploads a file.
* **Submit form** - completes when the partner submits a chosen form. Select the form.
* **Go to link** - completes when the partner opens a link. Enter the URL.
* **Complete course** - completes when the partner finishes a chosen course. Select the course.
* **Obtain certificate** - completes when the partner earns a chosen certificate. Select the certificate.
Set the **Button label** the partner sees on the task, then save. The task moves to **Done** on its own once the partner completes the action, giving you a clean signal they did the step. **Complete course** and **Obtain certificate** finish automatically the moment the partner completes the course or is issued the certificate, so there is no button to click for those.
### Show the tasks in the portal
Go to [Portal](https://app.introw.io/templates) and edit the experience the partner receives. If tasks don't have an obvious home, add a dedicated **Tasks** tab so partners find them instantly.
Add the **Tasks** block to a section of the experience, then open its settings to reach the **Configure Tasks** panel.
In the panel, decide which tasks appear:
* **Layout** - show tasks as a **list** or a **grid**.
* **Standalone tasks** - turn this on to show the ad-hoc tasks you create directly on a partner (the ones from this guide), not just journey tasks.
* **Journey** - additionally include a journey's tasks in the same block by selecting it and turning on **Include tasks in this widget**.
* **Properties** - drag to control which task properties partners see, and in what order.
* **Collaboration** - optionally let partners add their own tasks, and hide completed tasks after a set number of days.
This lets one block show both one-off tasks and journey steps together.
Save the configuration and publish the experience to the partner so their live portal updates and they see their tasks.
## Verify it worked
The task appears on the partner's **Tasks** tab with the owner, due date, and visibility you set. A logged-in partner sees their assigned tasks in the experience and can complete them there, and an automated task moves to **Done** on its own once the partner takes the action.
## Related
Reuse a checklist across many partners instead of a one-off task.
Enroll partners in a journey from the portal automatically.
Full configuration options for tasks.
# Tasks
Source: https://docs.introw.io/features/partners/tasks/index
Assign, automate, and display the tasks that move partners through onboarding, activation, and ongoing engagement inside the partner portal.
> Onboarding and activation only happen when someone owns the next step. Tasks give every partner a clear checklist, assigned and tracked, so nothing stalls.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Partners stall with no next step | An assigned, visible list |
| Onboarding is rebuilt each time | A journey applies the playbook |
| Managers chase over email | Status is tracked in one place |
| Partners do not know what to do | Their tasks are in the portal |
## Impact
Nothing stalls a partner faster than not knowing what they are supposed to do next. A short list with their name on it is a smaller feature than it sounds and a larger effect.
for your business
* **Cost to run**
Partner managers create and assign tasks with no code, and automation puts the right ones there
* **Fits together**
A task can carry an action: watch an asset, submit a form, complete a course, obtain a certificate
for your partners
* **Self-serve**
They see and complete their own tasks in the portal, and check them off themselves
* **Enabled**
The task carries the thing it needs, so there is no hunt for the form or the course
* **Efficient**
One list of what is theirs, with due dates, instead of an email thread to reconstruct
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Managers** - tasks assigned and tracked
* **Partner Operations** - the onboarding playbook
* **Partners** - what is theirs to do next
## See it work
* 
**Set the details**
Due date, assignee, and whether the partner sees it.
* 
**Attach the action**
An asset to watch, a form to submit, a course to finish.
* 
**Put it in the portal**
A Tasks block on the experience they land on.
* 
**Choose what shows**
Standalone tasks, journey tasks, or both.
## How it works
Tasks are the concrete to-dos that drive a partner forward: complete onboarding steps, finish training, submit a document, book a kickoff. You assign tasks to partners or your own team, apply **journeys** so the same playbook reaches every new partner, and automate task creation so the right tasks appear at the right moment. Partners see their tasks in the portal and check them off, and you track completion across the program.
Where Journeys describe the phases a partner moves through, Tasks are the individual actions that get them there, and both work together.
Instead of an onboarding plan that lives in a spreadsheet and depends on manual chasing, tasks are assigned and automated through journeys. A new partner sees exactly what to do, the manager sees who is behind, and activation becomes a repeatable motion rather than a series of reminders.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
journey["Journey assigns tasks"] --> see["Partner sees next steps"]
see --> track["Manager tracks progress"]
track --> activate["Activation"]
```
## Run it from your AI assistant
* Create an onboarding checklist for Acme - NDA, kickoff call, portal setup - each due next week.
* Show every overdue partner task across the program, grouped by partner.
* Mark Acme's certification task done and post a comment congratulating them.
* Create a task on the Globex deal to send the security questionnaire, assigned to the partner.
* Which partners have open onboarding tasks with nothing completed in two weeks? Draft a nudge for each.
## Going deeper
Setup, configuration, and all how-to guides.
Endpoints and code.
**Works with**
Tasks make up a journey.
Same task model on shared deals.
Show partners their tasks in the portal.
Chase a task to its due date, and create one from any other event.
# Tasks
Source: https://docs.introw.io/features/partners/tasks/technical/index
Assign and automate the tasks that move partners through onboarding and activation, and show them to partners right in the portal.
## Where it lives
Tasks sits under **Partners**, at [Partners](https://app.introw.io/partners).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Partners synced into Introw | A task belongs to a partner | [Sync partners](/features/integrations/crm/guides/sync-partners-and-contacts) |
| Permission to manage tasks | To create and assign them | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A published experience | Only to show tasks in the portal | [Publish an experience](/features/portal/experiences/guides/build-and-publish-a-portal-experience) |
## How it works
A **task** is a single to-do assigned to a partner or to your own team, with an
owner, a due date, and a status. You create tasks directly on a partner, or they
appear when you **Apply** a [journey](/features/partners/journeys), a reusable
checklist built under **Journeys**. Partners see their tasks in the portal and
complete them there.
**Journeys** own the repeatable playbook (onboarding, activation, certification).
**Tasks** are the individual steps inside it. See
[Journeys](/features/partners/journeys) to build and apply a journey; use this
feature for one-off tasks, automation, and showing tasks in the portal.
## Settings & configuration
Tasks are managed from the partner area and the experience builder.
**Tasks** are created with an owner, due date, and description, and assigned to a
partner or a team member from the partner's **Tasks** tab.
**Portal display** shows a partner their tasks inside an experience by adding a
tasks block.
### Automate it with a workflow
A task is both something a [workflow](/features/automation/workflows/technical) can start from and something a workflow can create. **Task assigned** runs when a partner acquires a task, **Task completed** when it is marked done, so "when this task is finished, move the partner's phase and book the bonus" becomes a rule rather than a habit.
**Task assigned** is also the only trigger that offers a wait anchored to the task's own due date, which is what makes a reminder chain expressible at all: nudge three days before it is due, nudge again two days after it slips, then escalate to the partner manager on day five. Each fork can re-read **Task status right now**, the current status rather than the one the trigger recorded, so nobody is chased about work they have since done. See [Chase a task to its due date and escalate](/features/automation/workflows/guides/chase-a-task-to-its-due-date).
The other direction is the **Give a task** action: any other event can create a task, for the partner or for one of your own team, with **Visibility** set to **Internal** when the partner should not see it. That is how an escalation lands on a person's list instead of in an inbox.
## How-to guides
* 
[**Create and show partner tasks**](/features/partners/tasks/guides/create-and-show-partner-tasks)
Create a one-off task on a partner with the right owner, due date, visibility, and auto-complete action, then surface it in the partner portal.
## Troubleshooting
Applying a journey creates its full set of tasks for each partner, so review the journey before broad use. Tasks only appear to a partner in the portal if you add a tasks block to an experience they can see.
Confirm tasks are assigned and a tasks block is on a published experience they can access.
Check the automation trigger fired.
# Partner Team
Source: https://docs.introw.io/features/partners/team/index
Assign your team to each partner with clear roles, then let ownership drive portal contacts, communication senders, certificates, and approvals.
> A partner relationship needs an owner. Assigning your team to each partner makes ownership explicit, and that one decision drives the experience: who the partner sees as their contact, who signs their communications, who approves their requests, and who issues their certificates.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Partners do not know who to ask | Their contacts are shown |
| Mail comes from nobody | It comes from their manager |
| Approvals name someone who left | They route to the role |
| Ownership drifts from the CRM | Roles map to a CRM property |
## Impact
Partners judge a program by whether someone knows them. Making ownership explicit, and letting it drive who signs, approves and answers, is how a program stops feeling anonymous.
for your business
* **Cost to run**
Partner ops assigns teams and roles, and every downstream surface follows without more setup
* **In your CRM**
Partner team roles map to a CRM property, keeping ownership in sync with your source of truth
for your partners
* **Self-serve**
The portal shows their points of contact, kept current as assignments change
* **Enabled**
Announcements and emails come from the person who knows them, and replies reach that person
* **Efficient**
Their approval goes to the current manager, not a hard-coded name who has moved on
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Managers** - the partners that are theirs
* **Partner Operations** - ownership clean and CRM-synced
* **Partners** - a real person to reply to
## See it work
* 
**Open the Team card**
Ownership lives on the partner record.
* 
**Add someone**
Pick which of your people owns the partner.
* 
**Assign a role**
Lead manager, co-owner, technical contact.
* 
**Ownership resolves from it**
Notifications, tasks and senders follow the role.
## How it works
Partner Team is where you put the right people from your side on each partner. You assign team members to a partner and give them a role, such as the lead partner manager, a co-owner, or a technical contact. That assignment is not just a label: it cascades through the rest of the program so partner-facing surfaces reflect the real human relationship.
Once a partner has an assigned team, Introw uses it everywhere it matters. The portal can show the partner their points of contact, kept current automatically as assignments change. Partner-facing announcements and emails can be sent from and replied to the assigned manager instead of a generic address. When a partner contact invites a colleague into the portal, the assigned manager is CC'd on that invite. Certificates can carry the assigned manager as their issuer. Form approval workflows can route to the partnership manager rather than a hard-coded name. And because partner team roles can map to a CRM property, ownership stays reflected in your system of record.
The mechanics of building roles and scoping access live in [Team Management](/features/access/team-management). Partner Team is the partners-domain view of the same idea: who owns this partner, and what that ownership unlocks.
Assign each partner a team once, with roles that mean something. From that point the relationship is wired through the product. The partner sees a face, hears from a person, gets approvals from the right desk, and earns certificates with a real signatory. You never re-enter names on each surface.
## Run it from your AI assistant
* Who is the champion contact at Acme?
* Show the partner managers and owners across our partners.
## Going deeper
Setup, configuration, and all how-to guides.
Endpoints and code.
**Works with**
Roles are defined in team management.
Show points of contact in the portal.
Route approvals to the assigned manager.
Issue certificates as the assigned manager.
# Partner Team
Source: https://docs.introw.io/features/partners/team/technical/index
Assign team members and roles to a partner, then configure how ownership drives portal contacts, email senders, certificate issuers, and approvals.
## Where it lives
Partner Team sits under **Partners**, at [Partners](https://app.introw.io/partners).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Partner team roles defined | Ownership is assigned by role | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Permission to edit a partner | To manage its team | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A mapped CRM property | Only for CRM-synced ownership | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
## How it works
Every partner has a **Team** card on its detail view. That card lists the people from your side
who own the relationship, each holding a **partner team role**, the role someone holds on a
specific partner (for example lead partner manager, co-owner, or technical contact). You define
the available roles once under team settings, then assign members to them on each partner.
Assignment is the input; the rest of the program reads from it. When a partner has an assigned
team, that ownership becomes available to other surfaces: the portal experience can render the
partner's points of contact, partner-facing communications can use the assigned manager as their
sender and reply-to, invites a partner sends to their own colleagues CC the assigned manager,
certificates can name the assigned manager as the issuer, and form approval
gates can route to the partnership manager rather than a fixed user. Because partner team roles
can map to a CRM property, the owner you set here can stay reflected on the CRM record.
Defining and scoping the roles themselves (permission categories, single-member roles, limiting a
user to their assigned partners) is covered in
[Team Management](/features/access/team-management). This page focuses on assigning the team on a
partner and wiring the downstream impact.
## Settings & configuration
Assignment happens on a partner's **Team** card at [Partners](https://app.introw.io/partners); the
roles it draws from are defined under [Team](https://app.introw.io/settings/team).
### Assigning the team
On a partner's **Team** card, add a member and pick the partner team role they hold. Some roles
allow only a single member (for example a single lead manager); adding another prompts you to
replace the current one. Remove or change a member from the same card. The assigned team is what
every downstream surface reads.
### Points of contact in the portal
A portal experience can show the partner their assigned team as **points of contact**. Add a
partner profile or team section to the experience so the logged-in partner sees who owns their
relationship; the names update automatically as you change the assignment, with no per-partner
editing. See [Experiences](/features/portal/experiences).
### Communication sender and reply-to
Partner-facing communications such as announcements and emails can be sent from the partner's
assigned manager, so replies go to a real person rather than a generic inbox. Set the sender at the
communication level and it resolves to the assigned manager per partner. See
[Announcements](/features/engagement/announcements) and
[Partner notifications](/features/engagement/notifications).
### Certificate issuer
A certificate's **Issued by** field is the team member shown as the issuer on the credential. Set it
to the partner's assigned manager so certificates are signed by the right person. See
[Certificates](/features/courses/certificates).
### Approval routing
A form's approval gate can add the **partnership manager** as an approver step, which resolves to
the partner's assigned manager at submission time. This routes a partner's requests to whoever owns
them instead of a hard-coded name. See
[Submissions & Approvals](/features/forms/submissions-approvals).
## How-to guides
* 
[**Wire partner ownership**](/features/partners/team/guides/wire-partner-ownership)
Assign your team to a partner with the right roles, then wire ownership through portal contacts, senders, certificate issuers, and form approvals.
## Troubleshooting
Downstream surfaces resolve to the partner's assigned manager, so a partner with no team assigned falls back to defaults: the portal shows no contacts, communications use the org default sender, and the partnership-manager approver step has no one to route to. Single-member roles replace the existing member when you add another. Limiting a user to their assigned partners depends on those partners actually being assigned to them.
The partner has no team assigned, or the experience has no profile/team section.
The partner has no assigned manager, so it fell back to the org default sender.
The gate uses a fixed user instead of the partnership manager step, or no manager is assigned.
Update the certificate's Issued by field to the assigned manager.
# Activation
Source: https://docs.introw.io/headless/agentic-use-cases/activation
Lift partner activation rate from 30% to 50% with AI-driven early-warning detection. Catch silent failure 60-90 days before it surfaces in QBRs.
Activation rates baseline at 30–50% (under 20% unmanaged), and silent failure typically goes undetected until quarterly reporting. A continuous-monitoring agent detects engagement decay 60–90 days early, then routes the right intervention, CAM call, warm lead, micro-course, MDF offer. Lifting activation 30% → 50% on the same intake yields 67% more productive partners and \~€10M incremental sourced ARR per 100-partner cohort.
## How it works
## What is partner activation rate?
**Partner activation rate is the percentage of newly recruited channel partners who progress from a signed agreement to actively generating pipeline within a defined time window, typically measured by first deal registration or first closed-won opportunity within 90 days.** It sits between partner onboarding (where agreements are signed and portal access is granted) and sustained partner engagement (where the partner is producing revenue consistently). Activation rate is one of the most important leading indicators of channel program ROI because it determines how much of the recruitment budget actually produces pipeline.
## The activation gap nobody is watching
Onboarding completion is not activation. A partner can finish every training module, attend every kickoff call, get every certification, and then never register a deal. This is the silent failure mode of every channel program, and it's far more common than it should be.
The numbers are sobering. According to Unifyr's 2026 Channel Atlas, **typical activation rates for newly recruited partners range from 30–50%, and programs that don't actively manage activation see rates below 20%.** Half, sometimes more, of every recruitment dollar produces no pipeline. And because failure is silent (no event fires when a partner *doesn't* register a deal), nobody notices until quarterly reporting.
By then it's too late. Partners who drift through months of inactivity after onboarding are far more likely to disengage entirely. The first-deal window is short, and once it closes, the partner's enthusiasm for the relationship has typically evaporated. Reactivation campaigns help, re-engagement flows that add 2+ touchpoints can lift partner share activity from roughly 4% to 12% (ReferralCandy data): but reactivation is dramatically more expensive than preventing the drop-off in the first place.
## How does an AI agent catch silent partner failure early?
Introw's activation agent runs continuously in the background, watching for the absence of expected behavior. It detects partners who:
* Completed onboarding but haven't registered a deal in 30, 60, or 90 days
* Haven't logged into the portal or interacted with content
* Skipped the most recent training drop or campaign
* Are slipping below their cohort's median engagement
* Have open opportunities in your CRM that they haven't touched in 14 days
Crucially, the agent doesn't just produce a list, it **routes the right intervention**. Some partners need a CAM call. Some just need a relevant lead handed to them. Some need a one-page micro-course on a specific objection. Some need a fresh MDF opportunity. The agent's job is to surface the situation early enough, with enough context, that the right intervention is obvious.
A partner manager opens Slack and sees: *"Three of your partners completed onboarding 45+ days ago and have zero deal activity. Two have downloaded the security battle card but haven't followed up. One just logged in for the first time in three weeks and viewed two case studies. Suggested next actions: route a warm lead to Partner A, send the SI competency micro-course to Partner B, book a check-in with Partner C this week."*
That's not a dashboard. That's an action queue.
## Who wins, and how
**Partner Development Managers (PDMs)** stop discovering disengagement at the QBR. The agent surfaces silent failure 60–90 days earlier than it would otherwise be visible. Earlier detection means cheaper, more effective intervention, a 30-minute coaching call lands very differently when the partner is "stalled" than when they've decided you don't matter to their business.
**RevOps** gets a partner-health score that's actually predictive, not lagging. Industry benchmarks (Unifyr) show declining portal logins, reduced deal registrations, and lapsed certifications are leading indicators of churn, exactly the signals the activation agent is trained to catch and escalate.
**Channel Leadership** stops staring at the 80/20 dynamic and accepting it as inevitable. The honest math on most programs is that the bottom 60% of partners are quietly inactive. Recovering even a fraction of that population through early intervention has outsized economics, because the recruitment cost is already sunk.
**Partners themselves** get help before they decide you're not worth their time. Most disengaging partners aren't strategically choosing to walk away, they're getting busy with another vendor's program because that vendor's CAM noticed first and stayed in touch. The agentic model means your CAM notices first.
## Key statistics: activation impact
* **Activation rate baseline**: 30–50% for managed programs; below 20% for unmanaged (Unifyr Channel Atlas, 2026)
* **First-deal compounding**: partners reaching first deal within 90 days are **3–4× more likely** to stay active at one year (Unifyr)
* **Activation lift impact**: 30% → 50% activation = **67% more productive partners** per cohort
* **Per-cohort ARR uplift**: \~€10M of incremental sourced ARR per 100-partner cohort at €500K average sourced ARR per active partner
* **Reactivation lift potential**: 2+ touchpoint re-engagement flows can lift partner activity from 4% → 12% (ReferralCandy, 2025)
* **Detection lead time**: silent failure typically discovered at next QBR (90+ days late); agentic detection compresses to days
## Activation is goal-driven, not generic
Not every disengaging partner needs the same nudge. A partner pacing toward a tier-promotion threshold responds to a different message than one with bandwidth but no leads, and the difference between those two messages is the difference between an activation lift and a deletion in the inbox. The leverage move isn't “we miss you” copy; it's mapping each partner's diagnosed blocker (capability gap, lead drought, stuck pipeline, stakeholder turnover, channel-preference miss) to the specific intervention that unblocks it, framed against their actual goals from the program. Goal visibility plus next-best-action prescription beats generic re-engagement by a margin that compounds across the long tail.
## The deeper shift
Most partner programs treat activation as a metric to report, not a state to manage. Quarterly, someone calculates the activation rate, mentions it on a slide, and moves on. The day-to-day reality of disengagement plays out invisibly between reporting cycles.
The agentic model makes activation **operational**: a continuously monitored state with named owners, clear triggers, and routed interventions. It's the difference between checking the smoke alarm at the end of the year and having one that goes off the moment something starts smoking.
The compound effect is that programs stop running on the 80/20 default. When silent failure is caught early and intervened on consistently, the long tail of partners moves up the engagement distribution. The bottom 60% doesn't stay dormant, it produces. And that's where the next 10–20 points of partner-attached revenue actually live. For a complementary view on the inputs to activation, see [partner onboarding](/headless/agentic-use-cases/onboarding) and [partner segmentation](/headless/agentic-use-cases/partner-segmentation).
## Key takeaways
* **Definition**: Partner activation rate is the percentage of newly recruited partners who reach the first revenue-generating action (typically a deal registration or first closed deal). Industry baseline sits at **30–50%**, with unmanaged programs below 20%.
* **The cost of silent failure**: half or more of every recruitment dollar produces zero pipeline because partners drift through onboarding without registering deals, and nobody notices until quarterly reporting.
* **Introw's approach**: a continuous-monitoring agent detects partners who completed onboarding but show declining engagement, then routes the right intervention (CAM call, warm lead, micro-course, MDF offer).
* **Headline outcome**: lifting activation from 30% to 50% on the same intake yields **67% more productive partners** and roughly €10M of incremental sourced ARR per 100-partner cohort.
* **Stakeholders**: PDMs, RevOps, channel leadership, partners themselves.
## Frequently asked questions
Partner activation rate is the percentage of newly recruited partners who progress from a signed agreement to actively generating pipeline, typically measured by first deal registration or first closed deal within a defined window (often 90 days). It is calculated as (active partners) / (total recruited partners) × 100 and is one of the most important leading indicators of channel program health.
According to Unifyr's 2026 Channel Atlas, **typical activation rates for newly recruited partners range from 30–50%**, with poorly managed programs below 20% and best-in-class programs reaching 60% or higher. The realistic ceiling depends on partner mix (referral partners activate faster than enterprise SIs) and how aggressively the program manages the post-onboarding transition.
Partners go inactive primarily because the post-onboarding period lacks structure: no clear "what's next" guidance, no relevant leads, no proactive nudging from the vendor. PartnerStack research describes this as partners being "ghosted" by vendors after onboarding completion. The agentic model addresses it by catching the engagement decline within days instead of months.
Partner activation is a one-time transition: a partner moves from inactive to active by completing their first revenue-generating action. Partner engagement is ongoing and measures whether an already-active partner continues to invest effort. A partner can be activated (closed a deal six months ago) but disengaged (no activity since): the metrics answer different questions.
Introw's activation agent monitors leading indicators continuously: deal registration cadence vs. expected, portal login frequency, content interaction, training and campaign engagement, and stalled CRM opportunities. When signals deviate from cohort norms, the agent surfaces the partner with context (which signals slipped, what their history looks like) and a recommended intervention.
At an effective cost-per-acquired-partner of \~€15K (recruiting time, onboarding hours, portal provisioning, training development), every inactive partner is sunk recruitment investment. For a program with 100 new partners per year and 50% activation, that's **€750K of wasted spend annually**: a number that compounds across the lifetime of the program if activation isn't actively managed.
Yes, reactivation works, but is more expensive than prevention. Re-engagement flows with 2+ touchpoints can lift dormant partner activity from roughly 4% to 12% according to ReferralCandy data. Reactivation typically requires fresh incentives (extra commission, bonus tiers, new MDF allocations) that prevention doesn't, so catching disengagement at week 6 saves the cost of bribing the partner back at month 12.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Audits the entire partner network, leverages Introw goals to identify who needs activation, and generates per-partner personalized activation campaigns whose messaging maps to each partner's specific goals and diagnosed blocker.
Partner-side: unified renewal calendar + expansion plays across every vendor's installed customer base. Catches renewal slippage early; surfaces multi-vendor coordinated expansion conversations.
# Approval Workflows
Source: https://docs.introw.io/headless/agentic-use-cases/approval-workflows
AI-driven partner approval workflows auto-approve routine deal, MDF, and form submissions in seconds and route the rest, cutting SLA from days to seconds.
About 70% of distributors prefer vendors providing instant digital feedback, but most approvals queue for days because the 80% of routine submissions wait behind the 20% that need real judgment. Agentic approval workflows read every incoming submission, apply the vendor's custom rules, auto-approve straight-through cases in seconds, and route exceptions to the right human reviewer with full context. SLA on routine submissions collapses from days to seconds and channel ops capacity recovers 70–80%.
## How it works
## What are agentic partner approval workflows?
**Agentic partner approval workflows are AI-driven approval systems that automate decisions on incoming partner submissions, deal registrations, MDF project proposals, partner applications, co-marketing requests, and MAP milestones, by applying vendor-defined rules at machine speed and routing exceptions to the right human with full context.** The model handles the 80% of submissions that should be straight-through-processed in seconds, while elevating the 20% of edge cases that genuinely require human judgment with all relevant data already assembled.
## The approval queue that never empties
Every partner-facing form ends up in someone's queue. Usually a partner ops person. Often, in a tab that's been open for three days. The bottleneck is so pervasive that **partners experience "Portal Fatigue" while waiting for status, and \~70% of distributors prefer vendors who provide instant, digital feedback over those relying on manual correspondence** (Computer Market Research).
The math is straightforward: if 80% of submissions are routine and should be straight-through-processed, but every single one waits in a human queue, you're paying the cost of human review on every transaction whether it needs it or not. Channel ops teams burn hours each week on submissions that meet every approval criterion. Meanwhile the *non-routine* 20%, the cases that genuinely need judgment, sit in the same queue, often behind a stack of trivial approvals.
The result: SLA on routine cases is days when it should be seconds. SLA on complex cases is also days, when it should be hours. Everyone is unhappy.
## How does AI approval automation work?
Introw's approval agent reads every incoming submission and applies the vendor's custom rules. *"Auto-approve under €50K if all required fields present, partner tier ≥ Gold, no overlap with direct sales pipeline; otherwise route to Maria."* The same pattern applies to:
* **Deal registrations**: approved or routed in seconds
* **Partner applications**: auto-approve qualified applicants by ICP fit; route exceptions
* **MDF project proposals**: approve standard activities under threshold; route strategic spend
* **Co-marketing requests**: approve template-compliant requests; flag custom asks
* **MAP (mutual action plan) milestones**: auto-acknowledge complete milestones; surface stalled ones
The 80% that should be straight-through are processed in seconds. The 20% that need judgment land cleanly on the right person's desk with full context, the rule that matched, the exception that triggered, the partner's history, the relevant CRM data, so the human reviewer makes a decision in minutes instead of doing 15 minutes of context-assembly first.
Every decision is logged. Every override is auditable. The compliance team gets a complete trail for every routing and approval decision the agent made.
## Who wins, and how
**Partners** stop waiting. Routine deal registrations come back approved in seconds. Routine MDF requests come back approved the same day. The friction that drives partners to disengage from formal registration processes, "it takes too long to be worth doing", disappears for the cases where the program rules already say yes. (See [the deal registration deep-dive](/headless/agentic-use-cases/deal-registration) for the upstream submission experience.)
**RevOps and Channel Ops** stop being a queue-clearing function. The 80% disappears. The 20% remaining is the work that actually requires judgment, which is the work the team should have been doing all along. **One channel ops person can handle the exception load that previously required a team of three**: because the team's previous workload was mostly mechanical rule-application.
**Compliance and Governance** get an auditable trail that's actually complete. Every approval decision, automatic or manual, is logged with the rule that triggered it, the data that informed it, and the decision that was made. Override patterns become visible. Rule effectiveness becomes measurable.
**Channel Leadership** sees SLA metrics that are actually achievable. "Approve under 24 hours" used to be aspirational; now it's the floor, and most submissions clear in seconds. Industry benchmarks: programs that institute fast-approval workflows typically see partner-led revenue lift in the **15–35% range** because partners actually trust and use the registration process.
**The Direct Sales Team** stops getting blindsided. With auto-approval running rules that explicitly check for overlap with direct pipeline, channel conflict is prevented at the moment of approval, not discovered three weeks later when both teams are already six emails deep in negotiating. (See [the channel conflict deep-dive](/headless/agentic-use-cases/channel-conflict).)
## Key statistics: agentic approval workflow impact
* **Distributor preference for instant feedback**: \~70% prefer vendors providing instant digital response (Computer Market Research)
* **Straight-through processing potential**: \~80% of submissions should be auto-approved when rules are clear
* **SLA collapse**: routine approvals from days to seconds; complex cases from days to hours
* **Channel ops capacity recovery**: 70–80% of mechanical rule-application work eliminated
* **Partner-led revenue lift**: **15–35%** when approval workflows are streamlined and trusted (industry benchmarks)
* **Audit trail completeness**: 100%, every decision, every override, every rule version traceable
## The deeper shift
Approval workflows have historically been the place where partner program intentions go to die. Fast-approval is a written commitment in every partner agreement. The actual experience is queue limbo. The disconnect erodes trust over years.
The agentic model makes the SLA real. Auto-approval handles the 80%. Intelligent routing puts the 20% in front of the right human with full context. Compliance gets a complete trail. Channel ops gets their week back. Partners get the responsiveness they were promised.
Underneath that, the bigger shift is the role of human judgment in the channel ops function. When the agent handles mechanical rule-application, the humans who used to do that work are freed for the strategic work, exception design, rule evolution, partner-specific decisions, escalation handling, that channel programs have always needed and never had time for. That's the operating model upgrade. Not faster humans clicking approve. A function where humans only handle the cases that require humans, and where the system handles everything else, at machine speed, with machine consistency, and with full auditability.
## Key takeaways
* **Definition**: Agentic partner approval workflows are AI-driven systems that read every incoming partner submission (deal registration, MDF request, partner application, co-marketing proposal), apply the vendor's custom rules, auto-approve straight-through cases, and route exceptions to the right human reviewer with full context.
* **The cost of the queue**: \~70% of distributors prefer vendors providing instant digital feedback over manual correspondence; 80% of submissions are routine and should be straight-through-processed but typically wait days in human queues.
* **Introw's approach**: a rule-based agent applies vendor-defined criteria ("auto-approve under €50K if Gold tier, no direct overlap; else route to Maria"), with every decision logged and every override auditable.
* **Headline outcome**: SLA on routine submissions collapses from days to seconds; channel ops capacity recovers 70–80% as the routine workload disappears.
* **Stakeholders**: Partners, RevOps/Channel Ops, Compliance/Governance, Channel Leadership, Direct Sales.
## Frequently asked questions
Partner approval workflows are the structured processes vendors use to review and approve channel partner submissions, deal registrations, MDF project proposals, partner applications, co-marketing requests, and MAP milestones. Modern agentic approval workflows automate the 80% of routine cases with rule-based auto-approval and intelligently route the remaining 20% to human reviewers with full context.
Straight-through processing (STP) is the automated approval of submissions that meet all program criteria without human review. For partner programs, this typically applies to \~80% of incoming submissions: deal registrations under a value threshold, MDF requests for standard activity types, partner applications matching the ICP, and similar low-risk cases. STP collapses approval SLA from days to seconds.
The approval agent runs cross-checks at intake against the live CRM, looking for existing direct sales opportunities on the same account, prior partner registrations, and recent contact activity. Conflicts surface in seconds, not weeks, with a recommended resolution (split, override, partner-of-record reassignment) based on the vendor's rules of engagement.
Common auto-approval rules include: deal value below threshold, partner tier above threshold, all required fields present, partner certification status, no overlap with direct pipeline, account ownership rules, vertical eligibility, and territory assignment. Rules can be combined ("auto-approve under €50K if Gold tier and no direct overlap") to handle the majority of routine cases.
Exceptions, cases that don't match auto-approval criteria, are routed to the right human reviewer based on the vendor's routing logic (territory, partner tier, deal size, type of submission). The agent assembles full context for the reviewer (rule that matched/missed, partner history, CRM data, relevant rules of engagement) so the human decision takes minutes rather than the typical 15+ minutes of context-assembly.
Yes, every decision is logged, every override is auditable, and every rule is version-controlled. Introw operates under SOC 2 Type 2, ISO 27001, and GDPR compliance. The audit trail provides complete defensibility for compliance review, internal audit, and external scrutiny, typically more complete than legacy human-driven approval logging.
Yes. MDF project proposals, co-marketing requests, partner applications, and MAP milestones can all be processed through the same approval agent with form-specific rules. Straightforward MDF requests for template-compliant activities under a threshold can be auto-approved; strategic, custom, or high-value requests are routed to the right approver with full context.
# Campaigns & Announcements
Source: https://docs.introw.io/headless/agentic-use-cases/campaigns-and-announcements
AI partner marketing automation generates segmented campaigns from LinkedIn posts, blogs, and Loom recordings, scaling partner-facing output without hiring.
Most partner marketing managers ship one generic newsletter a month, and pay the cost in cadence, relevance, or both. AI-driven partner marketing automation converts any source content (LinkedIn posts, blogs, product launches, Loom recordings) into segmented partner-facing campaigns customized per tier, region, vertical, and partner type. Output multiplies 10–20× without hiring; segmentation lifts engagement 2–4× over generic blasts.
## How it works
## What is partner marketing automation?
**Partner marketing automation is the use of AI agents to generate, segment, and distribute partner-facing campaigns from any source content, including executive LinkedIn posts, product launches, press releases, blog posts, and Loom recordings, with each variant tailored per tier, region, vertical, partner type, and language.** It replaces the manual partner-newsletter model with a continuous, segmented stream of relevant communications that scales without expanding the partner marketing headcount.
## The partner marketing impossible triangle
Every partner marketing manager knows the constraint set:
* **Cadence**: partners need a continuous stream of relevant content to stay engaged
* **Relevance**: generic blasts get ignored
* **Headcount**: nobody has the budget to hire 10 partner marketing managers
You can have any two. You can never have all three. Most programs end up with low cadence (one newsletter a month), low relevance (the same content for every segment), or both, which is why partner email open rates and content download rates are widely treated as "engagement theater" by the people producing them.
The cost isn't just unread newsletters. **96% of B2B marketers expect to increase revenue attributable to channel partners** (Demand Gen Report / Channel Marketing Benchmark), but most can't, because their partners aren't sufficiently informed or motivated to sell. Communication is the carrier wave for everything else, campaigns, announcements, product launches, competitive responses. Get the carrier wave wrong and the rest doesn't matter.
## How does AI campaign generation work for channel marketing?
Introw's campaign system rebuilds the workflow around continuous, segmented, agent-assisted output.
A **background agent scans the vendor's LinkedIn weekly** and converts relevant posts into partner-segmented outreach the partner marketing manager can publish with one click. Every published post becomes the seed for a partner-relevant variation: an email to enterprise SIs, a Slack drop to high-velocity resellers, a portal announcement for the regional partners who serve healthcare. The marketing team doesn't have to lift the post into a campaign; the campaign is generated from the post.
The on-page **AI Assistant** lets the partner marketing manager edit announcements in natural language. *"Make this more technical for our SI segment."* *"Shorten this and add a CTA to the new MDF-eligible co-marketing program."* *"Translate this into German and adapt for our DACH resellers, who care more about compliance than the use case."* What used to require a copywriter and a half-day of revisions is now an inline agent prompt.
Campaigns can also be generated **from scratch** off any source material, a blog post, a product launch announcement, a press release, even a Loom recording the CEO sent on Slack. The agent extracts the core message, generates audience-segmented versions, and queues them for review.
Segmentation rules live in Introw, by tier, region, partner type, vertical, so every recipient gets a relevant version. No spray-and-pray. The agent does the audience-specific rewriting that human marketers don't have time to do. (For deeper detail on how segmentation works, see [the partner segmentation deep-dive](/headless/agentic-use-cases/partner-segmentation).)
## Who wins, and how
**Partner Marketing Managers** see their output multiply by **10–20×** without hiring. The same person who used to ship one newsletter a month is now shipping segmented updates after every product launch, every executive LinkedIn post, every competitive shift. The bottleneck stops being content production and starts being content strategy, which is the work the role should have been doing all along.
**Partner Sellers** start receiving communications that actually relate to their business. The healthcare-focused SI gets healthcare positioning. The high-velocity SMB reseller gets transactional offers. Industry research consistently shows that relevance is the single biggest driver of partner content engagement, a generic blast to a tier produces a fraction of the response of a tailored message to a specific segment.
**Vendor Marketing Teams** stop watching their best work die in the partner channel. The CEO's banger LinkedIn post used to be invisible to the partner ecosystem until someone got around to repackaging it. Now the agent ships partner-segmented versions of it within hours.
**Partners' end customers** see consistent, current messaging from every partner in the ecosystem. The competitive battle card that the vendor updated yesterday is in the field today, in every language, in every region.
## Key statistics: partner marketing automation impact
* **B2B marketer expectations**: 96% expect to increase channel partner revenue (Channel/Partner Marketing Benchmark Survey)
* **Output multiplier**: partner marketing managers move from \~4 partner-facing communications/month to **40–80** with agent assistance, a 10–20× lift
* **Engagement lift from segmentation**: comparable B2B benchmarks show segmented content drives **2–4× the open and click rates** of generic blasts
* **Time-to-market for announcements**: from days/weeks to hours; product launches reach every partner segment within 4 hours of public release
* **Localization economics**: agent-assisted translation collapses the cost of running region-specific campaigns to near zero
* **Partner-facing content velocity**: competitive responses (e.g., a new competitor entering the market) ship to all enabled partners within an hour, not weeks
## Release notes are the highest-leverage source
Partner-marketing radars usually focus on LinkedIn and blog posts. The source most often missed, and the highest-leverage, is the vendor's own release-notes feed. Every shipped feature is something partners need to position with prospects this week, but most release notes never reach partner-facing comms in time. The agent reads each release entry, filters out internal-only churn, and converts the rest into three derivatives per partner segment: a one-line “what's new” alert, talking points for partner sellers in active deals where the feature matters, and a customer-ready outreach template the partner can forward into their pipeline. There's also the partner-side mirror: a unified calendar of every vendor's upcoming launches, MDF cycles, webinars, and tier windows so the partner can plan customer outreach *around* vendor activity, not after it.
## The deeper shift
Partner marketing has been stuck in a 1995 newsletter model for far too long. Templates, blasts, lowest-common-denominator copy, manual segmentation when there's time. Most program-level data shows partners increasingly tune out vendor communications, not because they don't want to hear from the vendor, but because the cost of parsing irrelevant content has finally exceeded the value of finding the relevant bits.
The agentic model rebuilds the relationship around relevance. Every partner gets a feed that actually applies to them. The vendor's best content, the executive LinkedIn posts, the product launches, the competitive intelligence, the customer wins, flows continuously into the partner ecosystem in the right shape, in the right language, to the right segment.
Partner marketing stops being a content factory and starts being an editorial operation. The output goes up by an order of magnitude, the relevance goes up at the same time, and the headcount stays flat. That's the ratio that finally cracks the partner marketing impossible triangle. For complementary capabilities, see [AI partner training](/headless/agentic-use-cases/training) (which uses the same content sources for course generation) and [partner segmentation](/headless/agentic-use-cases/partner-segmentation) (which feeds the segmentation rules).
## Key takeaways
* **Definition**: AI-driven partner marketing automation uses background agents to convert any source content (LinkedIn posts, product launches, blogs, Loom recordings) into segmented partner-facing campaigns customized per tier, region, vertical, and partner type.
* **The cost of generic blasts**: 96% of B2B marketers expect channel revenue to grow, but most struggle to scale partner-facing communications because manual production caps cadence and relevance.
* **Introw's approach**: a background agent scans the vendor's LinkedIn weekly and converts posts into segmented outreach; an inline AI Assistant edits announcements in natural language; segmentation rules ensure every recipient gets a relevant version.
* **Headline outcome**: partner marketing managers ship **10–20× more partner-facing content** with the same headcount, and segmentation typically lifts engagement 2–4× over generic blasts.
* **Stakeholders**: Partner Marketing Managers, Partner Sellers, Vendor Marketing, partners' end customers.
## Frequently asked questions
Partner marketing automation is the use of AI agents to generate, segment, and distribute partner-facing campaigns at scale, from any source content (LinkedIn posts, blogs, product launches, Loom recordings) and customized per tier, region, vertical, partner type, and language. It replaces manual newsletter production with a continuous, segmented content stream.
An AI agent scans source content (executive LinkedIn posts, blog publications, product launches, internal Loom recordings) and converts each into multiple partner-segmented versions. Each version is tailored to a specific audience, enterprise SIs, high-velocity resellers, regional MSPs, vertical specialists, using segmentation rules defined in the PRM. The partner marketing manager reviews and publishes with one click.
Partner marketing managers using AI campaign generation typically ship **10–20× more partner-facing communications** with the same headcount. Where the manual model produces \~4 newsletters per month, the agentic model produces 40–80 segmented campaigns covering every product launch, executive post, and competitive shift.
Partner content segmentation is the practice of customizing communications per partner tier, region, vertical, partner type (reseller, SI, referral), and language. Effective segmentation typically drives **2–4× the engagement** of generic blasts, because partners invest attention in content that's relevant to their actual business motion.
Yes, Introw's campaign generation includes natural-language translation and localization, allowing a single source post to be adapted for partners in DACH, LATAM, APAC, and other regions. The agent doesn't just translate; it adapts tone and emphasis (e.g., compliance-forward for DACH, use-case-forward for the US) per regional preferences.
Introw connects to source content systems (LinkedIn, blog CMS, asset libraries, Notion, Slack, Loom) via MCP, and to delivery systems (email platforms, Slack workspaces, partner portals, Microsoft Teams). The agent orchestrates the workflow without requiring a rip-and-replace of the existing marketing stack.
**To-partner marketing** is the vendor's communications *to* their partners, newsletters, announcements, product updates, competitive intelligence. **Through-partner marketing** is the marketing assets the vendor provides for partners to use *with their end customers*, campaigns, social posts, email templates, landing pages. AI partner marketing automation accelerates both, generating segmented to-partner messaging and customizable through-partner assets from the same source content.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Continuously scans the vendor's LinkedIn, blogs, industry publications, and competitor news; filters to partner-relevant content; transforms into partner-ready language per segment; distributes and tracks via Introw.
Partner-side: unified calendar of every vendor's upcoming launches, webinars, MDF programs, and tier windows, ranked by relevance to the partner's actual customer base. Plan outreach around vendor activity, not after it.
# Channel Conflict
Source: https://docs.introw.io/headless/agentic-use-cases/channel-conflict
AI channel conflict detection cross-checks every partner deal submission against direct and indirect pipeline in real time to protect win rates and margin.
Organizations with poorly managed partner ecosystems have 23% lower win rates, and channel conflict drives 20–40% margin erosion in price-competitive categories. Agentic conflict detection cross-checks every partner submission against live CRM and partner pipeline data, partner-vs-partner, partner-vs-direct, marketplace-vs-reseller, at intake, applies rules of engagement consistently, and recommends resolutions auditably. Conflict surfaces before escalation, not after.
## How it works
## What is channel conflict?
**Channel conflict is the situation where two or more sales channels, including different partners, the vendor's direct sales team, or marketplaces, compete against each other for the same customer, deal, or territory.** It is one of the most damaging dynamics in any indirect sales motion because it erodes margins through pricing wars, damages partner trust, creates confusing customer experiences, and ultimately costs vendors revenue and partners. The three primary types are **horizontal conflict** (two partners at the same level competing), **vertical conflict** (vendor direct vs. partner, typically the most damaging to trust), and **multi-channel conflict** (different channel types clashing, e.g., marketplace pricing vs. reseller pricing).
## The most expensive trust problem in B2B
The numbers make the case impossible to ignore. **CompTIA research found 60% of IT industry respondents reported increased instances of channel conflict, with 36% assessing such conflict significantly eroded their business performance.** Organizations with well-managed partner ecosystems achieve **win rates 23% higher** (CSO Insights) than those with poorly managed ones, the conflict tax sits at the very top of the win-rate stack.
And industry analyses estimate moderate channel conflict at brand level can erode **20–40% of margin in categories with active price competition among partners** (i2o Retail) and cost a $50M brand $3–7M annually in compounded leakage.
The deeper problem isn't even the lost deals. It's the trust damage. **A single high-profile conflict, a vendor swooping in on a partner's deal, for example, can permanently damage a partnership that took years to build** (Unifyr Channel Atlas). News travels fast in partner communities. A vendor known for channel conflict struggles to recruit the next generation of partners, especially the experienced ones who've been burned before.
So channel conflict has compounding economics: it costs you the deal, then it costs you the partner, then it costs you the next partner you tried to recruit. There is no cheaper problem to solve.
## How does AI detect and resolve channel conflict?
Introw's channel conflict agent runs continuously against your CRM. After every form intake, every deal registration, every MDF request, every partner application, the agent cross-checks for:
* Existing direct sales opportunities on the same account or domain
* Existing partner registrations from other partners
* Recent contact activity from any source on the same prospect
* Territory and tier-based ownership rules
* Pre-defined exclusions (named accounts, strategic verticals)
Conflicts surface **at the moment of submission**, not three weeks later when escalation hits the channel chief's inbox. The agent doesn't just flag the problem, it **recommends a resolution**: split commission, override based on tier rules, partner-of-record reassignment, or first-to-register protection.
The system aligns with the vendor's documented rules of engagement: first-to-register policies, deal-protection windows, tier-based override rights. The agent is the rules-of-engagement enforcement engine. Same rules every time, every partner, every deal, which is exactly the consistency that makes partners trust the system.
A specific example: a Gold-tier partner registers a deal with Globex. The agent detects an open opportunity in Salesforce that the direct AE created two weeks ago. Instead of two days of email negotiation, the agent surfaces the conflict immediately, applies the rule (Gold-tier partners with documented prior engagement get priority on enterprise accounts under €500K), and routes a notification to both the direct AE and the partner with the resolution. Decision time: minutes. Trust impact: protected.
## Who wins, and how
**Partner Sellers** stop being blindsided. The single most damaging partner experience, discovering you've been competing against the vendor's direct team for three months, becomes structurally impossible because the conflict was caught at the moment of submission and resolved by clear, applied rules.
**Direct Sales Teams** also win. The "we worked this account for six months and now you're telling us a partner is on it" experience cuts both ways. Real-time pipeline visibility across direct and indirect motions means both sides know who has what, when. Competing against your own partner is unproductive at best and embarrassing at worst.
**Channel Leadership** finally has defensible enforcement. Rules of engagement are only as strong as their enforcement. Documents that aren't applied consistently aren't rules, they're suggestions. The agent applies them every time, with full audit trail, which is what gives the rules teeth.
**Compliance and Legal** get visibility into conflict patterns. If certain regions or product lines are producing disproportionate conflict events, the data is right there. Rule design becomes evidence-based instead of reactive.
**The customer**, downstream, stops getting two competing quotes from the same vendor. The customer experience problem of "we got three different prices from three different reps for the same product", which is one of the most credibility-destroying B2B experiences possible, is structurally prevented by upstream conflict detection.
## Key statistics: channel conflict economics
* **Win-rate uplift for managed ecosystems**: **+23%** vs. poorly managed (CSO Insights)
* **CompTIA channel conflict prevalence**: 60% of IT respondents report increased conflict; 36% say it significantly erodes business performance
* **Margin erosion from price competition between partners**: **20–40%** in active categories (i2o Retail)
* **Brand-level revenue leakage example**: a $50M brand experiencing moderate channel conflict typically loses **$3–7M annually\*\* through compounded margin compression
* **Partner attrition**: partners who repeatedly lose deals to direct or other partners stop investing effort, a measurable churn driver in industry surveys
* **Resolution velocity**: from days/weeks of email negotiation to **minutes** of rule-based resolution
## The deeper shift
Channel conflict has historically been managed reactively. A conflict happens, channel ops mediates, the loser walks away frustrated, and the program writes a slightly stricter rule that nobody enforces consistently. Repeat for years.
The agentic model flips it to proactive. Every submission is checked at intake. Every conflict surfaces in seconds. Every resolution applies the same rules with full transparency. The vendor's rules of engagement stop being a document and start being an active system.
Zero channel conflict isn't the goal, some overlap is inevitable in any healthy hybrid model. The goal is **predictable resolution**: partners who know exactly what happens when conflict arises and trust the process to be fair. That's what protects long-term trust, and that's what unlocks the 23% win-rate compounding benefit that ecosystem leaders have access to. For the upstream submission flow that feeds conflict detection, see [conversational deal registration](/headless/agentic-use-cases/deal-registration), and for the approval workflow that runs alongside, see [agentic approval workflows](/headless/agentic-use-cases/approval-workflows).
## Key takeaways
* **Definition**: Channel conflict occurs when two or more sales channels, partner-vs-partner, partner-vs-direct, or marketplace-vs-reseller, compete for the same customer or deal. AI-driven channel conflict detection cross-checks every submission against live CRM and partner pipeline data to surface conflicts at intake instead of after escalation.
* **The cost of unmanaged conflict**: organizations with poorly managed partner ecosystems have **23% lower win rates** (CSO Insights), and channel conflict causes **20–40% margin erosion** in categories with active price competition (i2o Retail).
* **The CompTIA finding**: 60% of IT industry respondents reported increased instances of channel conflict; 36% said it significantly eroded business performance.
* **Introw's approach**: a real-time conflict detection agent runs against the CRM at every intake, applies the vendor's rules of engagement, and recommends resolutions consistently and auditably.
* **Stakeholders**: Partner Sellers, Direct Sales, Channel Leadership, Compliance, Customers.
## Frequently asked questions
Channel conflict is the situation where two or more sales channels within the same vendor ecosystem compete for the same customer, deal, or territory. The three primary types are horizontal conflict (two partners at the same level competing), vertical conflict (vendor direct vs. partner), and multi-channel conflict (different channel types like marketplaces vs. resellers clashing). All three erode margin, damage partner trust, and confuse customers.
**Vertical conflict, where the vendor's own direct sales team competes against its channel partners, is the most damaging** because it strikes at the foundation of vendor-partner trust. A single high-profile vertical conflict (a vendor swooping in on a partner's deal) can permanently damage a partnership built over years and create a recruiting headwind that affects the entire program for the long term.
Industry analysis from i2o Retail estimates that moderate channel conflict erodes **20–40% of margin in categories with active price competition** between partners. A $50M brand typically loses **$3–7M annually\*\* through compounded margin leakage. CompTIA research adds that 36% of IT companies say channel conflict has significantly eroded their business performance.
An AI conflict detection agent cross-checks every incoming partner submission (deal registration, MDF request, partner application) against the vendor's live CRM data, looking for existing direct opportunities, prior partner registrations, recent contact activity, and territory assignments. Conflicts surface in seconds, with a recommended resolution based on the vendor's rules of engagement.
Rules of engagement are the documented policies that define which sales channel has priority in specific scenarios, named accounts reserved for direct sales, territory assignments for partners, deal protection windows for registered deals, tier-based override rights, and escalation procedures. Rules are only as strong as their enforcement; agentic enforcement applies them consistently across every transaction.
Deal protection windows typically range from **30 to 180 days** depending on sales cycle length, deal complexity, and partner tier. Higher-tier partners often receive longer windows. The right duration is one that gives the partner enough time to close the deal without locking opportunities indefinitely if the partner stalls.
No, some overlap is inevitable in any healthy hybrid (direct + indirect) model. The goal is not zero conflict but **predictable, consistent resolution**: partners who trust the process to be fair, applied the same way to every deal. Predictable resolution is what protects partner trust over the long term, and it requires the kind of rule-based, audit-logged enforcement that agentic systems make possible at scale.
# Commissions & Incentives
Source: https://docs.introw.io/headless/agentic-use-cases/commissions-and-incentives
Conversational AI for partner commission tracking - partners and CAMs query commission status, tier progress, and payout projections without a portal login.
Routine commission queries consume 20–40% of channel finance team time and erode partner trust faster than almost any other operational issue. Conversational commission tracking lets partners and CAMs query status, tier progress, payment timing, and projections in natural language, through Slack, Claude, or their own CRM, answered instantly from connected ERP, finance, and CRM systems with permission scoping. Query response collapses from hours/days to seconds; transparency stops being a quarterly favor.
## How it works
## What is conversational partner commission tracking?
**Conversational partner commission tracking is a model where channel partners and partner managers ask questions about commission status, tier progress, payment timing, and incentive goal projections in natural language, through Slack, Microsoft Teams, Claude, ChatGPT, or the partner's CRM, and receive instant, scoped answers from a partner-side AI agent connected to the vendor's finance and CRM systems.** It replaces the support-ticket-and-wait model that has historically slowed every commission inquiry to days.
## The transparency tax that compounds against you
Commission opacity is one of the most underrated trust killers in channel programs. Partners frequently don't know:
* Whether their last deal commission has been processed
* How close they are to the next tier's threshold
* Which specific deals contributed to their current quarter's MBO progress
* When the next payment will land
* What their projected commission is on a deal currently in stage 4
So they ask. And the question, which should take seconds to answer, instead enters a queue. They Slack their CAM, who pings finance, who checks the system, who replies the next day, who clarifies a follow-up question, who replies the day after.
The aggregate cost is significant on both sides. **Routine commission queries consume an estimated 20–40% of channel finance team capacity** in mid-to-large programs, with partner managers spending another large chunk of their time as middlemen. And every day a partner waits for a commission answer is a day they're slightly less inclined to invest pursuit effort in your deals, because opacity reads as disrespect, even when nobody intends it.
## How does conversational commission tracking work?
Introw's commission agent is a partner-side MCP server connected to the vendor's ERP, finance system, and CRM. Partners and partner managers ask questions in natural language and get scoped, instant answers:
* *"What's my current quarter commission progress?"*
* *"Which of my deals are still pending payment, and what's the expected timing?"*
* *"How far am I from the next tier?"*
* *"What's my projected commission on the Globex deal if it closes next week?"*
* *"Show me my commission trend over the last four quarters."*
The agent reads from the source-of-truth systems and answers from real data. **Permission scoping ensures partners only see their own commission data**: never another partner's, and partner managers see only the partners in their book.
For channel finance teams, the agent answers vendor-side queries too: *"How much have we paid out to APAC partners this quarter, and which partners are within 10% of tier promotion?"*
## Who wins, and how
**Partners** get same-second answers to the questions they used to wait days for. The trust impact compounds, a partner who can self-serve commission data trusts the program in a way that a partner who has to file a ticket cannot. And trust is the carrier wave for every other partner behavior: deal registration cadence, certification investment, joint marketing engagement, MBO commitment.
**Partner Managers** stop being commission-status middlemen. The hours per week historically spent fielding "where's my commission?" Slack messages get reclaimed for the strategic work that actually grows the partner book. (For complementary impact on QBR prep load, see [partner QBR automation](/headless/agentic-use-cases/qbrs-meeting-prep).)
**Channel Finance Teams** see their query queue collapse. The 20–40% of capacity that went to routine status inquiries gets redirected to what finance teams should actually be doing, modeling incentive structures, optimizing payment workflows, ensuring compliance, identifying anomalies. The agent doesn't replace the finance team; it offloads the mechanical reporting that wasn't a good use of finance talent in the first place.
**Channel Leadership** gets behavior change. When commission data is transparent and instant, partners self-monitor against tier thresholds, MBO progress, and incentive triggers. They invest pursuit effort precisely where they can see the math working in their favor, which is exactly the behavior the incentive structure was designed to motivate.
**Vendor Finance and Operations** get an audit trail and consistency that manual query handling can't provide. Every commission query, every answer, every escalation is logged. Discrepancy patterns become visible. Disputes resolve faster because both sides are looking at the same data, retrieved the same way, with the same scoping rules.
## Key statistics: conversational commission tracking impact
* **Channel finance time consumed by routine queries**: 20–40% in mid-to-large programs (industry estimate)
* **Query response time**: from hours/days to **seconds**
* **Partner manager middleman load**: significant percentage of weekly time recovered as queries self-serve
* **Trust impact**: transparency is consistently identified in channel surveys as a top driver of partner satisfaction
* **Behavior change**: visible tier-progress data drives focused pursuit effort on deals that move partners toward incentive triggers
* **Audit completeness**: every query, response, and escalation logged with full traceability
## Transparency × prescription
Commission visibility is necessary but not sufficient. A partner with live commission visibility doesn't just trust the vendor more, they make different decisions, but only when the data comes paired with prescription. *“Close deal X by Friday adds €18K and crosses you into Gold-tier eligibility next quarter”* is a fundamentally different message than *“your commission dashboard is here.”* The same agent that surfaces transparency can do the math the partner would do if they had time: where's the closest threshold, which deals already in pipeline move the needle most, which active SPIF or accelerator is leverageable in the time remaining. Vendors who pair visibility with action-prescription see partners optimize toward the outcomes the vendor *designed* the incentives to drive, which is the whole point of designing them in the first place.
## The deeper shift
Commission visibility has always been the operational concession partner programs make to finance system complexity. The data exists, but the access model is "file a ticket." Partners adapt by either pestering their CAM or, more often, disengaging from active monitoring of their own incentive math entirely. Both outcomes are bad.
The agentic model rebuilds the access pattern. Commission data becomes queryable on demand by the people who own it (the partner) and the people who manage it (the partner manager and finance teams): without anyone losing audit trail, scoping, or compliance. The information that was already in your systems is finally accessible at the speed it needs to be accessible.
That's not a finance system upgrade. It's a trust infrastructure upgrade. And trust, in channel programs, is the multiplier on every other investment, better activation, better win rates, better tier progression, better long-term partner retention. Make commissions transparent and the rest of the program runs at a different temperature. For complementary capabilities, see [ecosystem performance](/headless/agentic-use-cases/ecosystem-performance) for natural-language analytics across the broader program, and [partner QBR automation](/headless/agentic-use-cases/qbrs-meeting-prep) for QBR generation that includes commission status as a data layer.
## Key takeaways
* **Definition**: Conversational commission tracking lets channel partners and partner managers query commission status, tier progress, payment timing, and goal projections in natural language, through Slack, Claude, ChatGPT, or the partner's CRM, instead of opening tickets or chasing finance.
* **The cost of opacity**: routine commission queries consume **20–40% of channel finance team time** and erode partner trust faster than almost any other operational issue.
* **Introw's approach**: a partner-side MCP agent answers commission questions instantly from connected ERP, finance, and CRM systems, with permission scoping so partners only see their own data.
* **Headline outcome**: query response time collapses from hours/days to seconds; finance team capacity recovers significantly; partner trust compounds because transparency is no longer a quarterly favor.
* **Stakeholders**: Partners, partner finance teams, CAMs, channel leadership, vendor finance/ops.
## Frequently asked questions
Partner commission tracking is the process of recording, calculating, and reporting commission payments owed to channel partners for revenue they generate. Modern conversational tracking lets partners and managers query commission status, tier progress, and projections in natural language, replacing the ticket-and-wait support model that has historically slowed every commission inquiry to days.
An AI agent connected via MCP to the vendor's finance system and CRM can answer commission questions in natural language: current status, pending payments, tier progress, deal-level projections, historical trends. Partners get instant scoped answers; partner managers stop fielding "where's my commission?" Slack messages; finance teams reclaim the 20–40% of capacity that went to routine status inquiries.
Yes, the AI agent enforces strict permission scoping. Partners only see their own commission data. Partner managers see only the partners in their assigned book. Channel finance and leadership see what their roles permit. Permission boundaries are enforced at the data layer, not the UI layer, so the agent cannot return information the user wouldn't already be authorized to see.
Common queries include: current quarter commission progress, deals pending payment with expected timing, distance to the next tier threshold, projected commission on in-flight deals, historical trends, MBO progress, incentive trigger eligibility, and tax/payment-method status. The agent answers from the same source-of-truth data that finance reports run on.
Yes, Introw connects via MCP to standard finance and ERP systems (NetSuite, SAP, etc.) as well as to the CRM that drives commission calculation. The agent reads from the systems of record without requiring a finance system migration or a new commission engine.
When partners can see their commission math in real time, they self-monitor and self-direct. Tier progress visibility encourages them to invest pursuit effort in deals that move them toward thresholds. MBO transparency drives focused activity on the goals the incentive structure was designed to encourage. Transparency, in effect, makes the incentive structure actually do its job.
Channel finance teams typically spend **20–40% of their capacity** fielding routine commission status queries, work that's mechanical, repetitive, and not a good use of finance talent. Conversational tracking redirects that capacity to higher-value work: incentive structure design, payment workflow optimization, anomaly detection, and compliance.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Partner-side: pulls live goals, commissions, and pacing data, then prescribes the highest-leverage actions to maximize earnings before period end, with concrete impact estimates per move.
# Deal Coaching
Source: https://docs.introw.io/headless/agentic-use-cases/deal-coaching
AI deal coaching for channel partners delivers segment-specific guidance inside CRM, Slack, Teams, or email to lift partner-attached win rates without new PDMs.
Direct sales reps get coached weekly; partner sellers get a portal full of PDFs, and the win-rate gap shows it. AI deal coaching runs in every partner deal, embedded in the partner's own CRM, Slack, Teams, or email, with persona-specific guidance per partner type (SI, reseller, referral). Comparable AI coaching delivers 32–34% win-rate lift within six months while PDMs reclaim most of the \~13 hours/week they currently spend on routine in-deal advice.
## How it works
## What is AI deal coaching for channel partners?
**AI deal coaching for channel partners is an in-deal advisory model where an AI agent provides real-time, contextual sales coaching inside the partner's own workspace, pulling live deal context (stage, last activity, recent objections, competitive mentions) and delivering segment-specific guidance for SIs, resellers, referral partners, and other partner types.** It scales the coaching that direct sales teams have always received to the partner sales motion, where it has historically been impossible to deliver because of the math of human-driven coaching at scale.
## The historical weak spot of every channel motion
Every channel chief knows the pattern. Direct sales reps get coached intensively. Their pipeline is reviewed in 1:1s, their calls are listened to, their objections are role-played in weekly enablement. Partner sellers, who are often selling the same product to similar prospects, get a portal full of PDFs.
The economics are obvious. A vendor can afford to coach 200 internal reps. They can't afford to manually coach 5,000 partner sellers across 200 partner companies. So the partner motion has historically been the un-coached side of the revenue stack, and it shows up directly in the win-rate gap.
The data on coaching impact leaves no ambiguity. Sales teams using AI-powered coaching tools improve win rates by **34% within six months** (Whatfix research). Structured coaching delivers **32% higher win rates and 28% higher quota attainment** (Korn Ferry, 5th Annual Sales Enablement Study). **84% of sales reps reach quota when their organization deploys a best-in-class enablement strategy**: far above the industry average. None of this has been accessible to partner sellers at scale, because the coaching delivery model couldn't scale.
## How does AI deal coaching work in a partner program?
Introw's deal coaching agent runs in **every partner deal**. Not as a separate tool the partner has to log into, but as a coach embedded in the partner's actual workspace, their CRM (HubSpot/Salesforce), their Slack, their MS Teams, their email. Wherever the partner is working the deal, the coach is one prompt away.
The coaching is **dynamic**: it pulls live deal context: stage, last activity, sleeping flag, recent objections logged in comments, competitive mentions, stakeholder map. So advice is never generic. *"This deal has been at Stage 3 for 17 days. The last note says the prospect raised concerns about implementation timeline. Here's how we typically position our 6-week implementation against the prospect's stated risk concerns, plus three customer references in their vertical that closed similar timeline objections."*
Critically, **different coach personas are generated per partner segment**:
* **System Integrators (SIs)** get technical-fit coaching, integration architecture guidance, and stakeholder mapping for complex enterprise deals
* **Referral partners** get discovery-call talk-tracks and warm-introduction frameworks
* **Resellers** get pricing/objection guidance, competitive battle cards, and high-velocity closing tactics
The same product, different motions, different coaching, generated and maintained by the agent automatically.
## Who wins, and how
**Partner Sellers** stop selling solo. The biggest morale and retention factor in partner programs is whether the seller feels supported by the vendor. With a coach in every deal, every partner seller has access to the same quality of in-deal advice that an internal rep gets from their manager, without the partner having to flag a CAM or wait for a callback.
**Channel Account Managers and PDMs** stop being the bottleneck on coaching. The agent handles routine deal coaching at scale. PDMs reclaim time for the strategic deals where human judgment really matters, the complex enterprise pursuit, the strategic-account expansion, the executive-level relationship work. Highspot's 2025 State of Sales Enablement found **sales managers spend an average of 13 hours per week coaching reps**, of which a meaningful chunk is repetitive in-deal advice; agentic coaching takes most of that off the human's plate.
**Channel Enablement** sees their content actually used. The battle card that has historically gathered dust is surfaced by the coach at the moment of competitive objection. The case study sits dormant in a portal until the agent retrieves it for a deal that matches the customer profile. Content investment finally produces engagement, because the retrieval problem is solved.
**Channel Leadership** sees the win-rate gap close. Comparable structured coaching programs have produced **32–34% win-rate improvements within six months**, with some platforms reporting 50–200% lifts when AI coaching is operationalized into the daily workflow (SalesHood research). Applied to partner-attached deals, historically the lower-win-rate side of the revenue stack, that's transformative.
**End Customers** get partner sellers who actually know what they're talking about. Coached reps successfully navigate objections **61% more effectively** and adapt to buyer preferences **56% more effectively** (Careertrainer.ai). The customer's experience of the partner's competence is, downstream, the customer's experience of the vendor's competence.
## Key statistics: AI deal coaching for channel partners
* **Win-rate lift on partner-attached deals**: **34% within six months** with AI coaching (Whatfix)
* **Structured coaching impact**: **32% higher win rates, 28% higher quota attainment** (Korn Ferry)
* **Skill improvement**: **38% skill improvement, 40% faster time to readiness** (SalesHood, 34,000+ AI coaching session study)
* **Coaching frequency**: traditional models deliver \~4 touchpoints/year; agentic coaching delivers continuous in-deal touchpoints
* **PDM time recovery**: managers historically spending 13 hours/week on coaching reclaim most of the routine load
* **Pipeline conversion**: companies effectively using AI-driven coaching achieve **2× higher pipeline conversion rates** (Careertrainer.ai)
* **Objection handling**: coached reps navigate objections **61% more effectively** (Careertrainer.ai)
## Coaching that's grounded in your wins
The defining property of useful deal coaching isn't generic playbook quotes, it's evidence from *this vendor's actual past wins*. For every active partner deal, the agent finds the most analogous closed-won deals (same vertical, deal size, product mix, partner type), extracts what worked at each stage, and prescribes how the partner can replicate the pattern. Customer-specific objection handling, which assets and case studies were used, how long each stage took, who the champion was, all surfaced as evidence the partner can act on. There's a partner-side mirror, too: instead of waiting for the next QBR, the partner pulls up their own war room with vendor playbook plus similar past wins plus drafted next message in seconds, in the workspace they already work the deal in (CRM, Slack, Teams, email). The compound effect is partner-attached deals that no longer close at lower rates than direct.
## The deeper shift
Sales coaching has always been the differentiator between average sellers and great ones. Every revenue org knows this; every revenue org also knows that coaching at scale is impossible with humans alone, there aren't enough good coaches in the world to give every seller the touchpoints they actually need.
The agentic model breaks the constraint. A coach in every deal, deployed in the partner's actual workspace, with live deal context and segment-appropriate persona, is the operational unlock channel programs have been waiting for. It's the moment the partner sales motion stops being the under-coached side of the revenue stack.
The compound effect is that the historically weak win-rate of partner-attached deals starts to converge with, or exceed, direct. That's the architectural goal of every channel program: a partner motion that's not just additive in volume but competitive in quality. Agentic coaching is the mechanism that makes it possible without hiring an army of PDMs. For the underlying training that feeds coaching, see [AI partner training](/headless/agentic-use-cases/training), and for how 24/7 enablement complements deal coaching, see [enablement support](/headless/agentic-use-cases/enablement-support).
## Key takeaways
* **Definition**: AI deal coaching is an in-deal advisory model where an AI agent, segment-specific by partner type and pulling live deal context, provides stage guidance, objection handling, competitive positioning, and closing tactics inside the partner's own workspace (CRM, Slack, Teams, email).
* **The cost of un-coached partner sellers**: partner-attached deals historically close at lower rates than direct deals because partner sellers haven't had access to the structured coaching their direct counterparts get weekly.
* **The data**: AI coaching tools improve win rates by **34% within six months** (Whatfix), and structured coaching delivers **32% higher win rates and 28% higher quota attainment** (Korn Ferry).
* **Introw's approach**: a coach in every partner deal, with persona-specific guidance per partner type (SI, reseller, referral), embedded in the partner's actual workspace.
* **Stakeholders**: Partner Sellers, Channel Account Managers/PDMs, Channel Enablement, Channel Leadership, end customers.
## Frequently asked questions
AI deal coaching is a sales coaching model where an AI agent, pulling live deal context from the CRM (stage, activity history, recent objections, competitive mentions): provides contextual, real-time advice on stage progression, objection handling, competitive positioning, and closing tactics. For channel programs, the coach runs in every partner deal and is segment-specific by partner type (SI, reseller, referral).
Industry research (Whatfix, Korn Ferry, SalesHood) shows AI-driven coaching produces win-rate lifts of **32–34% within six months** when properly operationalized. For partner-attached deals, historically the lower-win-rate side of the revenue stack because partner sellers received minimal coaching, the impact is especially pronounced because the baseline was so low.
**Sales training** is the upfront learning of products, methodology, and competitive positioning, typically delivered via courses, certifications, and onboarding. **Deal coaching** is in-the-moment guidance applied to a specific deal in flight, what to say next, how to handle a particular objection, which case study to reference. Both matter; agentic models scale both, but deal coaching delivers the larger short-term win-rate impact.
Yes, Introw's deal coaching agent generates segment-specific personas. System integrators (SIs) receive technical-fit coaching and stakeholder mapping; resellers get pricing/objection guidance and high-velocity closing tactics; referral partners get discovery talk-tracks and warm-introduction frameworks. Each partner type sells the same product but with a different motion, and the coaching adapts.
The coach is embedded in the partner's actual workspace: their CRM (Salesforce, HubSpot), Slack, Microsoft Teams, email, or a conversational interface like Claude or ChatGPT. Partners don't have to log into a separate tool, the coach is one prompt away wherever they're already working the deal.
PDMs typically spend **\~13 hours per week on coaching** (Highspot State of Sales Enablement, 2025), much of which is repetitive in-deal advice. AI deal coaching offloads the routine load, freeing PDMs for strategic deals, complex enterprise pursuits, and exception handling, the work where human judgment delivers disproportionate value.
No, Introw's deal coaching draws context from CRM data (deal stage, activity history, notes, contacts, competitive mentions). Call recording integration enhances coaching where it's available, but the core coach functions on text-based deal context that exists in every modern CRM.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Profiles the active partner deal, finds the most analogous past won deals, extracts the success pattern at every stage, and prescribes replication coaching grounded in evidence, not a generic playbook.
Partner-side: in-deal coaching packet pulled live, vendor playbook, similar past wins, competitive battle cards, reference customers, drafted next message. The partner's seat at the coaching table.
# Headless Agentic Deal Registration
Source: https://docs.introw.io/headless/agentic-use-cases/deal-registration
Conversational deal registration lets channel partners register deals from Claude, Slack, email, or CRM in 90 seconds with clean CRM writeback.
Forms with 7+ fields drop completion 34%; portal adoption falls below 30% when submission takes more than 2 minutes. Conversational deal registration lets partners submit through natural language in Claude, ChatGPT, Slack, email, or their own CRM, with an AI agent asking follow-up questions for missing fields and writing back to Salesforce or HubSpot. Submission collapses from 8–15 minutes to under 90 seconds, and every captured registration carries 10–15 points of additional margin via deal protection.
## How it works
## What is conversational deal registration?
**Conversational deal registration is a deal registration model in which a channel partner submits a deal by typing a natural-language description of the opportunity into Claude, ChatGPT, Slack, email, or their own CRM, and an AI agent asks follow-up questions for missing required fields, validates types, runs duplicate detection, and writes the registration back to the vendor's CRM (Salesforce or HubSpot) with correct partner attribution.** It replaces the 14-field portal form that has historically been the primary friction point in channel programs.
## The deal registration friction tax
Deal registration is the single most important transaction in any channel program, and it's also the one with the worst user experience in B2B software. Every channel leader has watched the same scene play out: a partner has a real opportunity, opens the portal, hits a 14-field form, can't remember which dropdown maps to which Salesforce field, abandons the submission, and emails their AE friend instead. Half the time the registration just never happens.
The data is unforgiving. **Forms with more than 7 fields see a 34% drop in completion rates** (Computer Market Research). Most deal registration forms have 12–20 fields. Partners adopt portals when submission takes under 2 minutes; if the interface is clunky or approval exceeds 24 hours, **adoption rates plummet below 30%.** And every off-portal email-to-AE submission produces duplicate data, unclear ownership, and the exact channel conflict the registration process was supposed to prevent.
So you end up paying friction tax twice: once in lost registrations, and once again in cleanup costs when the registrations that did happen turn into Salesforce data hygiene projects.
## How does conversational deal registration work?
Introw lets partners register deals **conversationally**: via Claude, ChatGPT, Slack, email, their own CRM, or the portal. The form is no longer a wall the partner has to climb. It's a conversation the agent runs.
A reseller types into Claude: *"Register a new deal with Globex: €120K ARR, closing end of Q3, contact is [jane@globex.com](mailto:jane@globex.com)."* The agent **proactively asks follow-up questions** for missing required fields, in natural language. *"What's the partner contact at Globex? Is this a new logo or expansion? Which product line is this for?"* No one has to know which dropdown maps to which Salesforce field, because the agent does that translation.
Submission writes back to the vendor's HubSpot or Salesforce with **attribution to the right partner automatically**. Required fields are enforced before submission. Field types are validated. Duplicate detection runs against existing CRM accounts and partner registrations. The CRM ends up cleaner than it would with portal submissions, not messier.
The same flow works for "become a partner" applications, MDF project proposals, support tickets, co-marketing requests, *any* form Introw is configured to accept. One conversational interface, one set of validation rules, one clean writeback to the system of record.
## Who wins, and how
**Partner Sellers** register deals in the moment they have the conversation, not three days later when they finally find time to log into a portal. **The submission process takes under 2 minutes, and from anywhere.** A reseller leaving a customer meeting can register the deal from their phone before they even get back to the office, locking in the protection window before a competitor partner files first.
**Channel Operations** stop being the cleanup crew. Cleaner submissions = less back-and-forth = faster approval cycles. A 25% reduction in admin overhead just from clean submissions is realistic, since approximately a quarter of channel manager time historically goes to portal-status follow-up emails alone (Computer Market Research data).
**RevOps and Sales Ops** finally get partner-attached pipeline that's first-class data. Attribution is correct from the moment of submission, types are validated, and the CRM doesn't need a quarterly cleaning project to fix the registration garbage. Pipeline forecasting against partner-attached opportunities improves dramatically when the underlying data is structured properly.
**Channel Leadership** sees deal registration adoption climb past the 30% adoption ceiling that clunky portals impose. The data shows that **automated notifications and conversational interfaces lift partner-led revenue by \~35% on average** (Computer Market Research): largely because more deals get registered, more deals are protected, and more deals get the deal-protection benefits that motivate the partner to invest effort in closing.
**The partner program's reputation** improves. Friction is the leading cause of partners disengaging from a registration process, and disengagement is the leading cause of channel conflict, because partners who can't register deals revert to emailing AEs and creating exactly the duplicate-pursuit problems registration is supposed to prevent. (See [the channel conflict deep-dive](/headless/agentic-use-cases/channel-conflict) for that full picture.)
## Key statistics: conversational deal registration impact
* **Form abandonment threshold**: forms with 7+ fields see a **34% drop in completion** (Computer Market Research)
* **Portal adoption ceiling**: below 30% when submission takes >2 minutes or approval exceeds 24 hours
* **Submission time**: from 8–15 minutes (typical portal flow) to **under 90 seconds** for conversational submission
* **Margin uplift from registered deals**: **10–15 additional points of margin** through deal protection (Fullcast)
* **Partner-led revenue lift**: \~35% with automated notifications and conversational interfaces
* **Channel manager admin overhead**: \~25% of channel manager time goes to portal-status inquiries today; conversational interfaces eliminate most of that
## The partner's side: which vendor first?
A reseller with 5–20 vendors faces a question every deal-reg article ignores: when a new prospect surfaces, *which* vendor do I register with first, and how do I sequence the others? Splintering attribution by registering everywhere at once dilutes the partner's claim with each vendor and fragments the prospect conversation. The partner-side decision-support flow scores fit per vendor (vertical match, segment fit, partner's own track record with each), recommends sequencing (lead / attach / hold / skip), and pre-stages the registration payloads so the partner can act in seconds.
There's a second multi-vendor question that compounds with scale: across all my vendors, what registrations are pending approval, in conflict, or about to lose their protection window? A partner with 30+ live registrations across vendors needs a single status queue or those protection windows quietly expire on deals in flight, a margin loss the partner often discovers only after the deal closes.
## The deeper shift
Deal registration is the foundational transaction of every channel program. Get it wrong and everything downstream, channel conflict, attribution, margin protection, partner trust, degrades. Get it right and the partner program has the cleanest pipeline data in the entire revenue stack.
The agentic model gets it right by removing the portal as the gating interface. The portal stops being the place partners *have to go* to register deals. It becomes one of many places they *can*. The actual submission experience is conversational, validated, and attributed automatically, wherever the partner happens to be working at the moment they have the opportunity.
That's the architectural shift. Not "a better portal." A protocol-level integration of deal registration into the partner's actual workflow. The form isn't the product. The conversation is. And the result is a deal registration process that partners actually use, which is the only kind that protects margin, prevents channel conflict, and earns trust. For the approval workflow that runs after submission, see [agentic approval workflows](/headless/agentic-use-cases/approval-workflows).
## Key takeaways
* **Definition**: Conversational deal registration is a channel partner workflow where partners submit deals through natural language (in Claude, ChatGPT, Slack, email, or their own CRM) instead of completing a long portal form, with an AI agent asking follow-up questions for missing fields and writing back to Salesforce or HubSpot automatically.
* **The cost of portal friction**: forms with **7+ fields see a 34% drop in completion rates**, and partner portal adoption falls below 30% when submission takes more than 2 minutes or approval exceeds 24 hours.
* **Introw's approach**: deals can be registered from any conversational interface; the agent enforces required fields, validates types, runs duplicate detection against the CRM, and attributes correctly to the right partner, all in under 90 seconds.
* **Headline outcome**: registered deals carry **10–15 points of additional margin** through deal protection, plus access to MDF and pre-sales support, every additional registration captured represents real margin reclaimed.
* **Stakeholders**: Partner Sellers, Channel Operations, RevOps/Sales Ops, channel leadership, end customers.
## Frequently asked questions
Deal registration is a formal process where a channel partner notifies a vendor that they are actively pursuing a specific sales opportunity. Once approved, the partner receives a window of exclusivity (typically 30–90 days) during which other partners and the vendor's direct sales team cannot compete on that deal. Registered deals also typically carry 10–15 points of additional margin and access to MDF and pre-sales resources.
Conversational deal registration is a model where partners submit deal information through natural language (typed into Claude, ChatGPT, Slack, email, or their CRM) and an AI agent asks follow-up questions for missing fields, validates types, and writes back to the vendor's CRM. It replaces the traditional 14-field portal form with a 90-second conversation.
Industry research from Computer Market Research shows forms with **more than 7 fields see a 34% drop in completion rates**. Most deal registration forms have 12–20 fields, multi-step workflows, and unclear field-to-CRM mappings. Partners abandon submission and either email an AE (creating duplicate pipeline data) or skip registration entirely (losing deal protection).
Best-in-class channel programs target deal registration submission in **under 2 minutes** and approval within **24 hours**. Computer Market Research data shows partner adoption falls below 30% when submission exceeds 2 minutes or approval exceeds 24 hours. Conversational deal registration typically completes in **under 90 seconds**.
Introw writes registered deals back to Salesforce or HubSpot with correct partner attribution, required fields enforced, types validated, and duplicate detection complete. The CRM record is created cleaner than a portal submission would be, with no quarterly data hygiene cycle needed.
Deal protection is the period (typically 30–90 days) during which an approved registered deal is reserved for the partner who registered it, preventing competition from other partners or the vendor's direct sales team. Deal protection is what gives partners confidence to invest pursuit effort in opportunities, and is one of the primary economic incentives that drive partners to register deals.
Yes, the same conversational interface handles partner applications, MDF project proposals, co-marketing requests, support tickets, and any other Introw form. Each form has its own required fields, validation rules, and writeback destination, but partners interact with all of them through the same natural-language conversation.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Scans the vendor's Gmail or Outlook inbox for partner emails containing deal or lead registrations, extracts fields, deduplicates, conflict-checks, and processes through Introw, capturing off-portal submissions cleanly.
Scans the vendor's CRM or Excel pipeline to identify deals that would benefit most from partner influence, picks the right partner with evidence-grounded reasoning, handles registration and posts a context-rich comment on the deal.
Partner-side counterpart: surface accessible vendor accounts where the partner has unique influence (existing customer, vertical fit, prior similar wins) and act on them.
Partner-side: given a new prospect, scores each of the partner's vendors for fit and recommends sequencing, which vendor to lead with, which to attach, which to skip. Pre-stages the deal-reg payloads.
Partner-side: every registration across every vendor in one queue, pending, approved, in conflict, approaching protection-window expiry. Sorted by urgency with drafted actions per item.
# Ecosystem Performance
Source: https://docs.introw.io/headless/agentic-use-cases/ecosystem-performance
Conversational partner ecosystem analytics - ask questions like 'which Gold partners are at risk?' and get pipeline, tier, and revenue answers in seconds.
Ad-hoc analytics requests consume 30–50% of channel RevOps team capacity, with most strategic questions answered days after they were asked. Conversational ecosystem analytics let channel teams query partner data, pipeline coverage, activation, win rates, tier movement, engagement, ROI by segment, in plain language and get answers in seconds with full data lineage. Channel teams shift from reactive firefighting to proactive operations because every “what's happening with X” question is answerable in real time.
## How it works
## What are partner ecosystem analytics?
**Partner ecosystem analytics are the metrics, queries, and analytical workflows that measure the health and performance of a channel program, covering pipeline coverage by partner, activation and engagement rates, win rates and deal velocity by segment, tier movement and certification progress, and ROI by partner type and region.** Modern ecosystem analytics platforms add a conversational layer: channel teams ask questions in natural language and the system returns answers from live data, eliminating the historical dependency on RevOps for every ad-hoc analysis.
## The data exists. The access doesn't.
Every channel program already has the data, buried in Salesforce reports, HubSpot dashboards, partner portal logs, finance systems, training platforms, content engagement tools. The structural problem isn't capture. It's retrieval. When a channel chief asks "which Gold partners in EMEA have pipeline but low engagement scores?", the answer requires a RevOps analyst, half a day of spreadsheet work, and three rounds of clarification on what "low engagement" means.
Industry benchmarks suggest **ad-hoc analytics requests consume 30–50% of channel RevOps team time** in mid-to-large programs. The RevOps team becomes a query-answering function, and channel leadership operates on intuition between reports because the data is theoretically available but practically inaccessible.
The compounding cost: most strategic questions get answered days after they were asked, by which point the moment for action has passed. A channel chief who asks on Monday "are we tracking against quarterly targets?" and gets the answer on Thursday loses three days of intervention time. Multiply that latency across every strategic question a channel leader needs to ask, and the program runs in a permanent reactive mode.
## How does conversational ecosystem analytics work?
Introw's analytics agent runs queries against live partner data via MCP. Channel teams ask in natural language, through Slack, Claude, ChatGPT, or the Introw interface, and get answers from the source-of-truth systems in seconds:
* *"Which Gold partners haven't registered a deal in the last 60 days?"*
* *"What's our pipeline coverage by partner tier vs. quarterly target?"*
* *"Which partners crossed certification thresholds this month and might be ready for tier promotion?"*
* *"Show me partner-attached ARR by region with quarter-over-quarter trend."*
* *"Which partners have pipeline but low engagement scores, and what's the engagement signal that's missing?"*
* *"What's our average time-to-first-deal trend over the last four cohorts?"*
The agent assembles the answer from connected systems, CRM, PRM, engagement logs, finance, training, and returns it with **full data lineage** so the user can trace exactly which sources contributed to which numbers. (For the same data layer applied to QBR generation, see [partner QBR automation](/headless/agentic-use-cases/qbrs-meeting-prep).)
## Who wins, and how
**Channel Leadership** stops operating between reports. Strategic questions get answered in the meeting they were asked in, not by Friday. Decision velocity changes, interventions happen at the moment they would have the most impact, not three days late.
**Channel RevOps** stops being a query-answering function. The 30–50% of capacity that went to ad-hoc analytics requests gets redirected to the work RevOps should actually be doing, designing better incentive structures, building data models that improve forecasting, identifying systemic patterns that point to program-level changes. RevOps moves upstream from reactive to strategic.
**Partner Development Managers** get their book of business queryable. *"Which of my partners have a deal in stage 4 with no activity in 14 days?"*, answered in seconds. The PDM's day shifts from "where do I look first?" to "I already know where to look first." Combined with the QBR generation capabilities, the PDM role transforms from data-assembler to strategic advisor.
**Finance and the CFO** get partner-program ROI questions answered with the same depth as direct sales analytics. Cost-per-active-partner, partner-attached ARR per program dollar, payback period by partner type, all queryable in seconds, all backed by real data lineage. The case for partner program investment becomes defensible in CFO-grade terms.
**The Board** gets channel program reporting that's actually current. Quarterly board reviews stop being a frantic 10-day RevOps assembly project and start being a real-time data view that's always available.
## Key statistics: ecosystem analytics impact
* **Ad-hoc analytics requests**: 30–50% of channel RevOps team capacity historically (industry estimate)
* **Query response time**: from hours/days to **seconds** with conversational queries
* **Decision latency reduction**: strategic questions answered in the meeting they were asked in, not three days later
* **RevOps time recovered**: significant percentage redirected from query-answering to strategic data work
* **Data lineage transparency**: every answer traceable to source systems for full audit defensibility
* **Coverage of programmatic signals**: pipeline, engagement, tiering, certification, MBO progress, commission, and partner-attached ARR all queryable in one interface
## Continuous monitoring beats ad-hoc query
Conversational analytics is one mode of working with ecosystem data. The other, and the one most channel programs underuse, is continuous monitoring. Most material changes in a partner ecosystem are caught weeks late: partner X went dark in week 2, nobody noticed until the QBR in week 12. An ecosystem-wide anomaly scan running on cadence flags activity drops, dormant reactivations, register-and-stall sequences, deal-size outliers, and cohort-level shifts before they become quarterly surprises. Pair that with an automated weekly digest posted directly to the channel-team's Slack, wins, at-risk partners, pending approvals, KPI deltas, action items, and the program operates on a current heartbeat instead of a quarterly autopsy. The team stops asking *“what happened?”* and starts asking *“what did we do about it?”*
## The deeper shift
Channel programs have run on quarterly reporting for 30 years. RevOps assembles the deck, leadership reviews it, decisions get made, the cycle repeats. Between cycles, the program runs on intuition.
Conversational ecosystem analytics ends that cadence. Strategic questions are answerable continuously, in natural language, with full data lineage. The program operates in real time, with intervention happening at the moment of signal rather than at the next reporting cycle. Channel chiefs stop asking RevOps "can you pull this for me?" and start asking the data directly.
Underneath that, the bigger shift is the operating model of the channel function itself. When data access is no longer the rate-limiter, the channel team stops being structurally reactive. Problems are caught the day they emerge, not the quarter they emerge. Opportunities are recognized the day they materialize, not the QBR after. Channel programs stop being managed-on-paper and start being managed-in-real-time, which is the architectural change that turns the partner ecosystem from a reporting line into a competitive advantage.
For the complete picture of how this works alongside the rest of the agentic PRM stack, see [partner segmentation](/headless/agentic-use-cases/partner-segmentation), [partner activation](/headless/agentic-use-cases/activation), and [partner QBR automation](/headless/agentic-use-cases/qbrs-meeting-prep). The same data layer powers all of them.
## Key takeaways
* **Definition**: Partner ecosystem analytics are the metrics, dashboards, and analytical workflows used to measure channel program health, including pipeline coverage, partner activation, win rates, tier movement, deal velocity, engagement scores, and ROI by partner segment. Modern conversational analytics let channel teams query this data in natural language.
* **The cost of waiting on RevOps**: ad-hoc analytics requests consume **30–50% of channel RevOps team capacity**, with most strategic questions answered days after they were asked.
* **Introw's approach**: a natural-language analytics agent runs queries against live partner data, pipeline, engagement, tiering, performance, and returns answers in seconds, with full data lineage.
* **Headline outcome**: query response time collapses from hours/days to seconds; channel teams shift from reactive firefighting to proactive operations because every "what's happening with X" question is answerable in real time.
* **Stakeholders**: Channel leadership, RevOps, PDMs/CAMs, finance/CFO, board.
## Frequently asked questions
Partner ecosystem analytics are the metrics, dashboards, and analytical workflows that measure channel program health: pipeline coverage by partner, activation and engagement rates, win rates and deal velocity by segment, tier movement, certification progress, and ROI by partner type. Modern ecosystem analytics platforms add a conversational layer for natural-language queries against live data.
Core metrics include partner activation rate (% of recruited partners reaching first deal), partner-attached revenue contribution (% of total ARR from partner channel), pipeline coverage by tier vs. target, time-to-first-deal, partner engagement score, certification attainment rate, deal velocity by partner segment, and cost-per-active-partner. The right primary metric depends on program maturity and category, see [partner segmentation](/headless/agentic-use-cases/partner-segmentation) for benchmarks by category.
Traditional dashboards present pre-built views of the data, every novel question requires a new dashboard or a RevOps query. Natural-language analytics let users ask any question in plain English and get an answer assembled from live data in seconds. The dashboard model fits a stable analytical world; conversational analytics fits the reality that strategic questions are open-ended and continuously evolving.
Partner-attached revenue is the percentage of total ARR generated by deals sourced through channel partners. Crossbeam ELG benchmarks show wide variation by category: **24% in horizontal SaaS, 41% in hardware, 47% in cybersecurity, 58% in services-led businesses, and 19% in fintech**. The benchmark for a specific program depends on category, GTM model, and program maturity.
Introw's analytics agent runs scoped to the user's existing permissions in connected systems, the agent cannot return data the user is not already authorized to see. Every query, response, and underlying data access is logged for audit. SOC 2 Type 2, ISO 27001, and GDPR compliance are built into the architecture, not bolted on.
For channel program use cases, conversational analytics handle the majority of queries that previously required BI tools or RevOps assistance. Many programs use both, Introw's natural-language layer for ad-hoc strategic questions, traditional BI for highly stable, recurring reports, but the dependency on RevOps for ad-hoc analysis is what conversational analytics primarily replaces.
Adoption is typically rapid because the interface is natural language, there's no learning curve for SQL, dashboard configuration, or BI tool training. Channel leaders, PDMs, RevOps, and finance can all start asking questions on day one. The deeper benefits (decision velocity changes, RevOps capacity redirection, real-time strategic posture) compound over weeks as the team internalizes that strategic questions can be answered in the moment.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Combines Introw + Slack to auto-generate the weekly partner-team digest, wins, registrations, at-risk partners, pending approvals, KPI deltas, and post it directly to the channel-team Slack channel.
Continuous-monitoring scan across the partner ecosystem that surfaces unusual behaviors (sudden activity drops/spikes, register-and-stall, deal-size outliers, cohort-level shifts) before they become quarterly surprises.
# Enablement Support
Source: https://docs.introw.io/headless/agentic-use-cases/enablement-support
AI-powered partner support deflects 40-60% of routine tickets, cuts response time from 15 minutes to 23 seconds, and works 24/7 in every language.
Traditional partner support runs on 15-minute-to-multi-hour first-response times, often 36 hours from question to answer. AI partner support is a 24/7 multilingual agent on the vendor's content library, battle cards, and pricing rules, with a capability matrix governing what executes autonomously vs. requires human approval. Routine ticket deflection hits 40–60% (best-in-class 70–80%) and first response collapses from 15 minutes to 23 seconds, a 97% reduction.
## How it works
## What is AI partner support?
**AI partner support is a 24/7 multilingual AI agent embedded in a channel partner's flow of work, accessible from Slack, Microsoft Teams, the partner portal, the partner's CRM, Claude, or ChatGPT, that answers product, pricing, configuration, and competitive questions instantly and can execute scoped commands like provisioning sandboxes or pulling account status via MCP.** Unlike legacy partner chatbots, AI partner support is grounded in the vendor's actual knowledge base and runs under a configurable capability matrix that defines exactly which actions the agent can take without human approval.
## The hidden cost of every unanswered question
Every channel program runs on the same broken loop. A partner has a question, about pricing, configuration, a compliance requirement, a competitive objection. They Slack their CAM. The CAM is in another meeting. By the time the answer comes back, it's the next day. The deal is colder, the prospect has had time to talk to a competitor, and the partner has lost momentum.
The numbers underscore the cost. Industry research from Pylon shows AI-powered support implementations have driven first-response times from **15 minutes to 23 seconds, a 97% reduction**: and have collapsed resolution times from over 32 hours to 32 minutes. The traditional human-driven channel support motion can't compete with that, but it's still the dominant model in most partner programs.
It's not just speed. It's languages. It's time zones. It's the fact that 24/7 partner support staffed by humans is economically impossible for most vendors, but partner programs increasingly span time zones and languages where the question-and-answer cycle is the bottleneck.
## How does AI partner support work in practice?
Introw's enablement support is a 24/7 AI Agent in **every language**, trained on the vendor's content library, gated assets, deal playbooks, competitor battle cards, and pricing rules. It runs in the partner's flow of work, in the portal, in Slack, in MS Teams, in their CRM, in Claude, in ChatGPT, wherever the partner already works.
Critically, it's connected via MCP to internal knowledge bases and tooling. So it doesn't just answer questions; it can **execute scoped commands** the partner is permissioned for: request a sandbox, generate a quote, pull an account status, check certification eligibility for an MDF claim. The agent stops being a chatbot and starts being a teammate.
A reseller asks: *"My customer is asking about your data residency in EMEA, what's our official answer, and can you pull the latest regional compliance one-pager?"* The agent gives the answer in seconds, attaches the right asset, and logs the question against the deal in the CRM. No CAM ping. No 36-hour wait.
## How is partner data protected with AI agents?
This is where Introw's [capability matrix](/headless#governance-and-trust) matters. **Each MCP action is set to *Read-only*, *Write/Delete*, *Allowed*, *Approval Required*, or *Blocked*.** The vendor controls exactly which actions the agent can perform automatically and which require a human in the loop. Every agent action runs scoped to the partner's Introw permissions, the agent can never see anything the human partner couldn't already see. Every write is logged. Every action is auditable.
For enterprise partner programs, this is non-negotiable. SOC 2 Type 2, ISO 27001, GDPR compliance is built into the architecture. The "always-on AI agent" pitch has been around for a while; the difference here is that it's actually deployable in regulated environments because the governance is in the protocol, not bolted on after.
## Who wins, and how
**Partner Sellers** finally get the kind of immediate access to expertise their direct counterparts have. The 36-hour wait dies. They close the gap between "I have a question" and "I can keep selling", which is the moment most channel deals are won or lost.
**Channel Account Managers** stop being human help desks. Industry deflection benchmarks (Gartner, Pylon, Freshworks) suggest AI-driven enablement deflects **40–60% of routine partner support tickets**, with best-in-class implementations reaching 70–80%. That's the difference between a CAM spending half their week on FAQ duty and spending it on the strategic work that grows the partnership.
**Partner Enablement Teams** see their content actually used. Battle cards that have been gathering dust because nobody knew which one to pull are surfaced by the agent at the moment of question. The investment in content production starts producing measurable engagement, because the retrieval problem, historically the killer of partner content, is solved.
**Vendor IT and Security** get a deployment they can sign off on, because the capability matrix and permission scoping are first-class concerns, not afterthoughts.
**The customer**, downstream, gets faster, more accurate answers from the partner. The partner who can answer "yes, we're SOC 2, here's the report" in real time wins the deal that the partner who has to "circle back tomorrow" loses.
## Key statistics: AI partner support impact
* **First-response time**: from 15+ minutes (typical CAM Slack reply) to **23 seconds, 97% reduction** (Pylon / AssemblyAI case study)
* **Resolution time**: from 32+ hours to 32 minutes in documented implementations (Pylon)
* **Ticket deflection**: technology industry average **23%**; AI-enabled implementations **40–60%**, best-in-class **70–85%** (Gartner / Pylon)
* **Multilingual coverage**: a single agent serves every market the program operates in
* **CSAT impact**: AI-first support deployments have raised CSAT from 89% to 99% (Freshworks)
* **Compliance posture**: SOC 2 Type 2, ISO 27001, GDPR, agents scoped to the user's existing permissions, every action logged
## The deflection-rate ceiling is a content problem
AI deflects 40–60% of routine partner support tickets, but the gap between current and best-in-class (70–80%) is almost always the same shape: partners are asking specific questions the knowledge base doesn't have a clean answer to. The agent improvises (risky) or routes to humans (slow); either way, the deflection rate stalls. The unlock is inverting the analysis: instead of *“what content do we have?”*, ask **“what are partners actually asking that we don't answer well?”** Cluster the recurring questions, score the gaps, prescribe the next 3–5 content investments. The output is a content roadmap grounded in actual demand, not assumptions, and the deflection rate climbs because the support agent finally has the answers it needed.
## The deeper shift
Partner support has always been a function with two bad options: invest heavily in human coverage (expensive and slow to scale) or accept the latency cost (which silently bleeds win rate). Neither has been particularly attractive.
Agentic support breaks the trade-off. A 24/7 multilingual expert with command-execution capability and proper governance isn't theoretical anymore, it's deployable, auditable, and scoped. Partners get the speed and accuracy they need; vendors keep the control they require; CAMs get to stop being help desks and start being strategic partners.
The result is the closing of the 36-hour gap that has structurally drained channel win rates for as long as channel programs have existed. For the in-deal extension of this, where the same agent provides coaching during open opportunities, see [deal coaching](/headless/agentic-use-cases/deal-coaching). For how this connects to training delivery, see [AI partner training](/headless/agentic-use-cases/training).
## Key takeaways
* **Definition**: AI partner support is a 24/7 multilingual AI agent, trained on the vendor's content library, battle cards, and pricing rules, that answers partner questions and executes scoped commands (sandbox provisioning, quote generation, account lookup) via MCP-connected systems.
* **The cost of slow answers**: traditional partner support runs on 15-minute-to-multi-hour first-response times; AI-powered implementations cut this to **23 seconds (97% reduction)** according to Pylon case studies.
* **Introw's approach**: a 24/7 multilingual support agent in every language, with a capability matrix that scopes which actions the agent can execute automatically vs. require approval, SOC 2 Type 2, ISO 27001, GDPR compliant.
* **Headline outcome**: AI deflects **40–60% of routine partner support tickets** (Gartner / Pylon benchmarks), with best-in-class implementations reaching 70–80%.
* **Stakeholders**: Partner Sellers, CAMs, Partner Enablement Teams, Vendor IT/Security, end customers.
## Frequently asked questions
AI partner support is a 24/7 AI agent that answers channel partner questions about products, pricing, compliance, and competitive positioning, in any language, and can execute scoped commands like sandbox provisioning, quote generation, or account lookup via MCP-connected systems. It runs inside the partner's existing tools (Slack, Teams, CRM, portal, Claude, ChatGPT) rather than requiring a separate interface.
Industry research (Gartner, Pylon, Freshworks) shows AI-enabled partner support typically deflects **40–60% of routine tickets**, with best-in-class implementations reaching 70–85%. The technology-industry average for non-AI deflection sits at just 23%, meaning AI roughly doubles or triples deflection rates while improving response time.
Documented Pylon case studies show AI-powered support cuts first-response time from 15+ minutes to **23 seconds, a 97% reduction**. Resolution times have collapsed from 32+ hours to 32 minutes in similar implementations, fundamentally changing the partner experience around question-and-answer cycles.
Yes, Introw's AI partner support runs under a configurable capability matrix that defines exactly which actions the agent can perform (Read-only, Write/Delete, Allowed, Approval Required, Blocked). Every agent action is scoped to the user's existing Introw permissions, every action is logged, and the system holds **SOC 2 Type 2, ISO 27001, and GDPR compliance**.
The Model Context Protocol (MCP) is an open standard that lets AI agents securely connect to and act on external systems, CRMs, knowledge bases, ticketing tools, code repositories, and more. For partner support, MCP enables an agent to read from and write to Salesforce, HubSpot, Slack, Notion, and other tools without custom integrations or credential sharing.
Yes, a single AI partner support agent operates in every language a channel program needs. This replaces the historically uneconomic model of staffing native-language CAMs in every market and ensures partners in APAC, EMEA, LATAM, and other regions get the same response quality and speed as partners in headquarters' time zone.
No, it offloads the 40–80% of partner queries that are routine and FAQ-like, freeing CAMs for strategic relationship work, exception handling, and high-stakes deal coaching. The agentic model is best understood as a force multiplier for CAMs, not a replacement, because the work that requires human judgment is exactly the work CAMs are best at and historically didn't have time for.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Cluster recurring partner support questions, cross-check against the existing knowledge base, and produce a ranked content roadmap (battle cards, FAQs, micro-courses) to close the next deflection gap.
Write the missing one-pager, battlecard, or FAQ from your own knowledge sources and publish it straight into the asset library over MCP, filed and categorised, where the AI agent and the partner portal both read from.
Partner-side: ask any product / pricing / battle-card / configuration question to a specific vendor in natural language. Single-vendor scope per invocation, with cited answers and a clear handoff path for out-of-capability requests.
# HubSpot Agent Hub
Source: https://docs.introw.io/headless/agentic-use-cases/hubspot-agent-hub
Introw ships an MCP server for HubSpot Agent Hub, so custom agents and agentic workflows can run partner plays on direct-side CRM data.
HubSpot Agent Hub gives you custom agents and agentic workflows inside your own CRM. The Introw HubSpot app ships an MCP server for it, so a HubSpot agent can read the direct-side data no PRM ever sees - closed-won history, call transcripts, playbook logs, buyer intent, rep capacity, quote engagement - and write the result straight into the partner's world as a portal update, a task, a comment, or a form submission. Fifteen plays below, from partner recommendation on a direct deal to the full QBR lifecycle.
## How it works
## What is HubSpot Agent Hub?
**HubSpot Agent Hub is HubSpot's platform for AI agents: pre-built agents, custom agents you build yourself, and agentic workflows, managed in one place across the customer journey.** It sits inside the CRM your team already runs on, which is what makes it interesting for a partner program: the agent starts from live CRM data rather than from an export.
Three pieces matter for partner plays:
* **Pre-built agents** cover the direct motion out of the box: AEO, Data Agent, Prospecting Agent, Deal Progression, and Customer Agent.
* **Custom agents** are built in the agent builder from four ingredients: **instructions** (the agent's role, goal, and output), **actions** (what it is allowed to do), **knowledge** (brand, documents, knowledge vaults, CRM context), and **inputs** (the per-run data such as a deal name or close date).
* **Agentic workflows** put an agent inside HubSpot automation. You configure triggers and actions the way you already do, and add an agent as a step, so a play runs on a CRM event or a schedule instead of when someone remembers.
Agent Hub is in beta on Professional and Enterprise tiers, and agent runs consume HubSpot Credits. Check [HubSpot's Agent Hub documentation](https://knowledge.hubspot.com/ai/understand-agent-hub) for the current requirements.
## Where Introw fits: the MCP server inside the app
An agent's **actions** decide what it can actually do. HubSpot supports three sources: HubSpot's own actions, defaults like reading CRM records or browsing the web, and **MCP connectors**, which link an agent to an external system over the Model Context Protocol.
The Introw HubSpot app ships an MCP server as part of the app. Install or update the app, and **Introw MCP** appears in the **Connectors** tab when you add an action to an agent. **Introw makes its partner data and actions available to Agent Hub this way**, so partner plays stop being something you bolt on next to HubSpot and become something HubSpot agents run natively.
That single connection is what closes the loop:
* **HubSpot reads its own data natively.** The agent runs inside HubSpot, under the permissions of the person running it, so nothing about this widens Introw's OAuth scopes.
* **Introw is where the agent acts.** Through the MCP server the agent can search partners, tiers, goals, commissions and marketing funds, look up partner tasks and timeline activity, read and process form submissions such as deal registrations and shared leads, post partner-facing comments, create and update tasks, update partner fields and CRM object properties, submit any partner form, and pull the right enablement content.
* **The CRM stays the system of record.** Every write lands back where your reporting already looks.
See the [MCP overview](/features/developer/mcp) for the server itself, and [Connect HubSpot](/features/integrations/crm/guides/connect-hubspot) for the app install.
## The leverage: what only lives on the direct side
A partner platform can only act on what partners give it. The reason Agent Hub is worth building on is the data sitting on the other side of the business, which the agent reads natively:
| What the agent reads | Why a partner play needs it |
| - | - |
| Closed-won history | Which plays won, at which stage, against which competitor, on what line items and discount |
| Playbooks and playbook logs | The qualification and discovery scripts your reps run, and their filled-in answers |
| Call and meeting transcripts | What the customer actually said on the rep's demo, and the recap of it |
| Buyer intent signals | Funding, M\&A, exec moves, expansion, hiring, tech investment, visitor intent, job changes |
| Rep capacity and territory | Live owner load, win rate by segment, who can genuinely take a lead today |
| Quote engagement | Whether the buyer opened the quote, downloaded it, came back to it, or let it expire |
| Products, subscriptions, invoices | What was sold, at what price, renewing when, delivered how |
| Deal and lead scoring | Your own model of what a real opportunity looks like |
## The plays
Fifteen workflows worth building, grouped by where they sit in the partner motion. Each one names its HubSpot trigger, what it reads on the direct side, and what it writes back through Introw.
### Bringing partners into the motion
Three plays that get a partner and an opportunity onto each other, in both directions: a rep who needs a partner, a partner who needs a rep, and an account signal that should wake a partner up.
**Trigger:** a direct deal is created or reaches qualification, or the rep asks.
**Reads:** products and amount on the deal, account industry, size and geography, what the rep heard the customer needs, competitor in play.
The agent scores every partner against this specific deal: who holds a live certification on the products on it, who has closed deals like it in this segment and size band, who covers the geography, who works this vertical, who is trending up rather than coasting on old numbers, and who has room this quarter. It returns a ranked shortlist of two or three with the evidence behind each, writes it onto the deal record, and drafts the introduction.
Recency is weighted over volume, so a partner who won three deals like this in the last two quarters outranks one who won twelve of them three years ago. In a young program with thin attribution history, certification, geography and category carry the ranking until there are enough wins to read a pattern from.
**Why it matters:** this is the only play whose main user is the direct rep. Co-sell attach is a push metric today, with the partner team chasing sellers to involve partners, and this makes it a pull. It also spreads opportunity on evidence rather than on whichever partner the rep happens to remember, which is the quiet mechanism behind partner concentration.
**Trigger:** a partner shares a lead.
**Reads:** owner territory and current load, win rate by segment and rep, open pipeline per AE.
The agent qualifies the lead, then picks the AE who is genuinely right for it on territory, segment win rate, and who has room this week. It creates the task and tells the partner who owns it and by when they will hear back.
The commitment back to the partner is the point. A named owner and a stated response time turn a lead submission from a hopeful gesture into a transaction with terms, and the agent chases the rep if the terms slip.
**Why it matters:** a shared lead that sits unworked for a week teaches the partner not to share the next one. Rep capacity exists only in the CRM, which makes this the one routing decision a partner platform cannot make on its own.
**Trigger:** a buyer intent signal fires on an account a partner owns or overlaps.
**Reads:** funding, M\&A, exec change, expansion, hiring and tech investment, visitor intent on your site.
The partner's account just raised a round, moved a CRO, or started hiring against the problem you solve. The agent tells the partner what happened, why it matters for them specifically, which play to run, attaches the asset, and creates the task.
It only fires where the partner has standing: an existing customer, an open registration, or a mapped overlap. A partner who gets alerted about an account they have no relationship with learns to ignore the next one, so the bar for firing is deliberately high.
**Why it matters:** partners get the same intent-driven prompts the direct team gets. Nothing in the partner stack has this data, and it is the cheapest source of net-new partner pipeline you can put in their hands.
### On the live deal
Five plays for the window where the deal is in flight and both sides need to stay sharp: the partner coached off real wins, the rep fed the partner's questions, and neither of them guessing what the other just did.
**Trigger:** the stage sits unchanged, or the close date passes, on a partner deal.
**Reads:** closed-won deals in the same segment, competitor and loss reasons, winning line items and discount, the playbook that rep ran.
The agent finds the deals your direct team already won that look like this one, extracts what moved them at this exact stage, and hands the partner two or three specific next moves plus a drafted message to the buyer. Not generic stage advice: the move that worked on the last four deals like theirs.
The same pass reads the losses. If deals in this segment reliably die on a security review or a procurement step, the coach raises it before the partner walks into it, with the asset that cleared it last time.
**Why it matters:** direct reps get coached weekly off real win data. Partner sellers get a portal full of PDFs, and the win-rate gap shows it. This is the difference between advice and evidence, delivered on the deal rather than buried in a training module nobody opens. See [deal coaching](/headless/agentic-use-cases/deal-coaching) for the wider pattern.
**Trigger:** a direct rep's call or meeting ends on a partner-sourced deal.
**Reads:** call transcript and recap, deal stage and next step, the rep's notes.
The agent reads what the customer actually said on the demo, writes a partner-safe summary, and pushes it to the partner's portal timeline with a task for anything the partner needs to do. The rep writes nothing and changes none of their habits.
The filter matters as much as the summary. Internal pricing debate, forecast commentary and competitive positioning stay out. What the customer asked for, what worried them, and the one thing the partner is best placed to influence go in.
**Why it matters:** the partner learns within the hour that the demo happened, how it went, and what is needed from them. Silence after handoff is the single biggest reason referrers and co-sell partners stop bringing deals, and this ends it without adding a step to anyone's day.
**Trigger:** a partner comments on a live deal.
**Reads:** deal owner and stage, the rep's open tasks and load, recent activity on the account.
Introw's [partner support agent](/features/ai/partner-support) already answers the routine questions. This play handles what it should not: a live deal question the AE has to own. It classifies the comment, attaches the deal context, assigns it to the right rep with a drafted reply, and puts an SLA on it.
Where the rep does not respond it escalates on the timer, to the partner manager first and the sales manager second, so a partner is never left waiting on someone who is on holiday.
**Why it matters:** partner questions enter the direct team's actual work queue instead of dying in a portal thread nobody owns. Response time on deal-blocking questions is what partners judge a vendor on hardest, and it is usually invisible to the people being judged.
**Trigger:** the buyer opens, downloads, returns to, or lets a quote expire on a partner deal.
**Reads:** quote view and download events, quote status and expiry, line items and discount applied.
The buyer just opened the quote the partner sent. The agent nudges the partner within the hour with the right follow-up, while the interest is live. If the quote goes untouched, or the expiry approaches, it switches to a different message and pulls the rep in.
Reading the line items lets it be specific rather than generic. A buyer who keeps returning to a quote without signing is usually stuck on scope or price, so the partner gets their tier's discount authority alongside the nudge and knows what they can move without asking.
**Why it matters:** quote engagement is one of the strongest buying signals in the CRM, and partners currently have no way to see it. Acting on it in the hour rather than the week is straightforward pipeline velocity, on deals that are already late-stage.
**Trigger:** a stage change on a referral-sourced deal.
**Reads:** the rep's notes on why it moved, the next step on the deal.
Introw already notifies on stage change. The Agent Hub version adds the part that builds trust: why it moved, what happens next, and what, if anything, the referrer could help with. Written so it protects credit without dragging them into the sales cycle.
Tone is calibrated to the audience. A referrer is not a seller, so the update reads like a note from a colleague rather than a pipeline report, and it never asks them to do work they did not sign up for.
**Why it matters:** referrers do not want a status field, they want to know their introduction is being treated well. That feeling decides whether a second introduction ever arrives, and it is almost entirely a communication problem rather than a product one. See [deal updates](/features/referrals/deal-updates) for the built-in version.
### After the win
Four plays for the moment a partner is most willing to commit to the next thing, and most likely to be dropped instead.
**Trigger:** a partner-sourced deal closes won.
**Reads:** what the direct team expands into next, line items sold, segment expansion patterns.
The agent congratulates with the real commission figure and tier movement, then reads what your direct team typically sells into this segment next and hands the partner the specific follow-on account or product, with the evidence behind the suggestion.
It also names the pattern in the partner's own book. If their last four wins were all mid-market manufacturers, that is the shape to chase again, and the agent lists which of their existing accounts match it.
**Why it matters:** it turns the celebration into the next registration instead of a full stop. The window right after a win is when a partner is most willing to commit to the next one, and almost no program uses it for anything but a congratulations email.
**Trigger:** a referral closes won.
**Reads:** why the deal actually closed, call transcripts and decision moments, competitor displaced.
A short, genuinely celebratory note back to the referrer that does one useful thing: it explains why this one won. Not the amount, the reason. What the customer's trigger was, which objection nearly stopped it, and what finally clinched it.
Then it names the shape to look for next: the company profile, the buying trigger and the persona that made this work, described concretely enough that the referrer recognises it in their own network the same day they read it.
**Why it matters:** referrers guess at what a good introduction looks like, and mostly guess wrong. Telling them exactly why the last one worked is the highest-yield thing a referral program can do, and the moment right after a payout is when they are most receptive to hearing it.
**Trigger:** a deal closes won with an implementation partner attached.
**Reads:** line items actually sold, sales call transcripts and promises, the rep's notes and scope.
The agent builds the go-live plan on the deal record, scoped from what was genuinely sold and what the rep promised on the calls, checks the assigned consultants hold the right certifications, and creates the scoped tasks on both sides.
The promises are the valuable part. Commitments made verbally on a sales call are the usual cause of a delivery blow-up, and they sit in a transcript nobody reads once the deal is closed.
**Why it matters:** implementation partners inherit a forwarded email and a guess. Handing them the sale's actual content is the difference between a clean go-live and a rescue, and go-live rate is what drives renewal, expansion and the stickiness a deep implementation creates.
**Trigger:** a renewal date approaching on a partner-sourced customer.
**Reads:** subscription and invoice state, CSM notes and health, support ticket history.
The agent briefs the partner on where the account stands, what the CSM is worried about, and what the expansion case looks like, then creates the joint tasks on both sides ahead of the conversation.
Where the partner did the implementation it flags the delivery history too, because an unresolved go-live issue is usually the thing standing between a renewal and an expansion, and the partner is the only one who can clear it.
**Why it matters:** partners who sourced a customer usually hear about a renewal risk after it churns. Inverting that turns the partner into a retention asset instead of a party with no visibility and no role at exactly the moment they are most useful.
### The operating rhythm
Three plays for the partner manager, each one dependent on live amounts, live scoring or live owners to be worth running at all.
**Trigger:** three chained agentic workflows on meeting booked, meeting completed, and thirty days after.
**Reads:** live pipeline and amounts, the QBR recording and transcript, the direct team's view of those accounts.
Seven days out, the pack builds itself from pipeline, goals, commissions and what the direct team sees on the same accounts, with the risks surfaced at the top rather than buried on slide nine. Prep tasks land on the owner's list at the same time.
When the meeting is marked complete, the agent reads the recording and turns it into partner tasks, a portal comment and a follow-up email the same day. Thirty days later the third workflow checks what actually moved against what was agreed and reopens anything that slipped.
**Why it matters:** two to four hours of assembly per QBR becomes fifteen minutes of editing, which is what makes full partner coverage feasible instead of the usual twenty to thirty percent. The thirty-day check is the step nobody does manually, and it is the one that makes the next QBR a review rather than a reset. See [QBRs and meeting prep](/headless/agentic-use-cases/qbrs-meeting-prep).
**Trigger:** a deal closes won, or a monthly schedule.
**Reads:** deal score and health, comparable wins from the direct team, ICP fit on the partner's open accounts.
The agent computes the gap to the next tier, then does the part that makes it actionable: it ranks the partner's open deals by how likely they are to land in time, using your own deal scoring and how comparable deals actually went for the direct team.
Where the open pipeline does not cover the gap it looks the other way, and names accounts in the partner's book that fit the ICP but have no deal on them yet. The nudge arrives with a route rather than just a number.
**Why it matters:** a tier threshold only motivates when the partner can see which two deals get them there and believes they can win them. Live amounts, deal scoring and comparable outcomes all sit in the CRM, which is exactly why this play belongs on the direct side rather than in a portal widget.
**Trigger:** a HubSpot owner is deactivated.
**Reads:** live owner records and teams, book size and revenue per manager, territory coverage.
The moment a partner manager is deactivated, their book is redistributed by size, territory and current load rather than dumped on whoever sits nearest, and the new manager is introduced on each partner timeline.
It carries the context forward too. Open tasks, in-flight registrations and anything promised at the last QBR move with the partner, so the new manager starts informed instead of cold and the partner never has to explain their own history back.
**Why it matters:** partners going quiet after their manager leaves is one of the most predictable and least-managed causes of channel churn. Handling it on the trigger, within the hour, removes the gap entirely rather than shortening it.
## Build the first one
The MCP server ships with the app, so HubSpot only offers it once the app is installed and authorized with current scopes. See [Connect HubSpot](/features/integrations/crm/guides/connect-hubspot), and re-authorize through **Install update** if the connector does not appear.
In HubSpot, go to **Agents > Agent Hub > Agents** and create an agent, or clone a pre-built one. Write the instructions as the play: the trigger you expect, what to read, what to write back, and what to leave alone.
In the agent's **Actions** section, click **Add action**, open the **Connectors** tab, hover **Introw MCP** and choose **Connect and add**, then complete the authorization. Add only the tools the play needs; a narrow action list keeps the agent predictable.
Point the agent at the context it should not have to be told twice: rules of engagement, tier and discount authority, partner-safe language. Introw's [knowledge base](/features/ai/knowledge-base) holds the partner-facing version of the same material.
Move the play from on-demand to automatic with an agentic workflow: configure the HubSpot trigger, add the agent as a step, and let it run on deal stage, quote engagement, owner deactivation, or a schedule.
Agent runs consume HubSpot Credits. Run the play manually on a handful of records first, check what one run costs, and only then enroll the whole pipeline.
## Governance
The safeguards are the same ones every Introw agent runs under, and they hold when the caller is a HubSpot agent rather than a person in a chat window.
* **The agent inherits a person's access.** The HubSpot side runs under the permissions of the user running it, and the Introw side runs under the OAuth connection's partner scope. Neither widens.
* **Sensitive actions still wait for a human.** Introw's capability matrix marks each action Read-only, Allowed, Approval required, Write/Delete, or Blocked, so an agent that drafts freely can still be blocked from approving an MDF request. See [governance and trust](/headless#governance-and-trust).
* **Everything is auditable.** Writes land on the CRM timeline and the partner timeline, which is where your reporting already looks.
* **Partner-facing output is filtered on purpose.** Plays that read internal material, transcripts especially, publish a partner-safe summary rather than the source.
## Key takeaways
* **Agent Hub** is HubSpot's home for pre-built agents, custom agents, and agentic workflows, built from instructions, actions, knowledge, and inputs.
* **Introw ships an MCP server for Agent Hub**, so a HubSpot agent can act on your partner program through the app you already installed.
* **The leverage is direct-side data**: closed-won history, transcripts, playbook logs, buyer intent, rep capacity, quote engagement, subscriptions, and deal scoring, none of which a portal-first PRM can see.
* **Fifteen plays**, across bringing partners into the motion, the live deal, after the win, and the operating rhythm.
* **Cost and control**: runs consume HubSpot Credits, and every Introw action stays inside the capability matrix and the signed-in user's scope.
## Frequently asked questions
Agent Hub is HubSpot's platform for AI agents. It brings pre-built agents (AEO, Data Agent, Prospecting Agent, Deal Progression, Customer Agent), custom agents you build in the agent builder, and agentic workflows into one place, organized along the customer journey so you can see where AI is active and what it produced. It is in beta on Professional and Enterprise tiers and consumes HubSpot Credits.
Through MCP. The Introw HubSpot app ships an MCP server, so once the app is installed, **Introw MCP** shows up in the **Connectors** tab when you add an action to an agent. You connect it once, authorize it, and the agent can then use Introw's tools as actions.
Read partners, tiers, goals, commissions, marketing funds, partner tasks, and timeline activity; read and process form submissions such as deal registrations and shared leads; post partner-facing comments; create and update tasks; update partner fields and CRM object properties; submit any partner form; and retrieve enablement content. Every one of those runs through the capability matrix, so you decide which execute on their own and which route to a human.
No. Introw's own [AI agents](/features/ai) and the [MCP server](/features/developer/mcp) run these motions from Claude, ChatGPT, Slack, Teams, or the portal without Agent Hub. Agent Hub adds one thing the others cannot: native access to direct-side CRM data such as call transcripts, playbook logs, quote engagement, and rep capacity, without anyone widening an integration's scopes.
No. The Introw connection authenticates as a user over OAuth and inherits that user's partner scope, exactly like connecting Claude or ChatGPT. Actions that change data are governed by the same capability matrix, and sensitive ones can be set to require approval or be blocked outright.
Partners do not touch your Agent Hub. They get the mirror image through [Partner Connect](/features/partner-connect): their own assistant, their own chat tools, and their own CRM, scoped to their own data. Several plays here are designed to land in exactly that surface, which is why the partner sees a portal update or a task rather than a HubSpot notification.
Start with one that has a clean trigger and an obvious owner. Partner recommendation on a direct deal proves the value to the sales team, demo transcript to portal update proves it to partners, and shared-lead routing on live capacity fixes the response-time problem partners complain about most. Leave the scheduled plays until you have cost-modelled a run.
## Going deeper
Two-way sync, cards, workflow actions, and everything else Introw runs inside HubSpot.
The OAuth-protected server the connector talks to, and its full tool surface.
The classic-workflow counterpart: Introw actions you drop into a HubSpot workflow.
The same plays as named skills you can run from Claude Code today.
# Onboarding
Source: https://docs.introw.io/headless/agentic-use-cases/onboarding
Agentic partner onboarding cuts time-to-first-deal from 6-12 months to 60-90 days using AI chasing agents and conversational channel onboarding journeys.
Without structured onboarding, channel partners take 6–12 months to become productive, and partners who miss their first deal in 90 days are 3–4× less likely to ever activate. Agentic onboarding personalizes a journey per partner, runs a background agent that chases progress in the partner's preferred channel, and lets partners ask “what's next?” conversationally. Time-to-first-deal compresses to 60–90 days and CAMs reclaim \~300–400 hours per year from reminder-bot duty.
## How it works
## What is agentic partner onboarding?
**Agentic partner onboarding is a structured channel partner onboarding model in which an AI agent personalizes onboarding journeys per partner, monitors progress in real time, and proactively chases partners across their preferred communication channels, without requiring constant intervention from a Channel Account Manager.** The partner can also ask the agent conversationally ("what's next for me?") and receive contextual answers from a partner-side MCP server. The result is dramatically compressed time-to-first-deal compared with traditional portal-and-PDF onboarding.
## The economics of slow onboarding
Every day a new partner spends in onboarding is a day they're not generating pipeline, and a day closer to disengaging. The data is brutal: without structured onboarding, **the average channel partner takes 6–12 months to become fully productive** (Magentrix, 2026). With a well-designed program, that timeline compresses to **60–90 days**. Every month saved is a month of revenue brought forward.
And the activation cliff is steep. Partners who close their first deal within 90 days are **3–4× more likely to remain active at the one-year mark** than partners who don't, according to Unifyr's Channel Atlas. The first-deal moment is the single most important inflection point in the entire partner lifecycle, and bad onboarding is the leading cause of missing it.
So why is partner onboarding still mostly a PDF, a portal login, and a "good luck" email? Because at scale, anything more than that has historically required a Channel Account Manager (CAM) to chase the partner across email, Slack, and phone calls. CAMs don't scale. The math runs out by partner number 30.
## How does agentic onboarding work?
Introw's onboarding flips the model. Each new partner gets a personalized journey, tasks, due dates, owners, milestones, CRM-specific requirements, generated for their partner type, region, and competency focus. The journey isn't a static checklist. It's a live state, with a background agent monitoring progress and a partner-facing agent answering questions.
The agent **chases the partner in their channel of choice**: email, Slack, MS Teams, the portal. Reminders are written in the partner's tone, contextualized to where they are in the journey, not as templated nags. ("Hey Maya, you finished the product overview last week, the next 30 minutes that opens up, the security positioning module is what unlocks your first MDF eligibility. Here's the link.") Status writes back to Introw automatically; the CAM doesn't have to ask anyone for anything.
And the partner can ask back. *"What do I still need to do to be activated?"*, typed into Claude, ChatGPT, or Slack, gets a real, contextual answer from the partner-facing MCP: open tasks, due dates, the next milestone, what unlocks at completion. No portal login. No email tag. No 36-hour delay.
## Who wins, and how
**Channel Account Managers** stop being human reminder bots. CAMs spend a disproportionate amount of their week on chasing, checking who's done what, sending nudges, escalating to managers when partners stall. The agent absorbs that load entirely. CAMs reclaim that time for the high-value work, the strategic conversations and exception-handling that actually move partner-attached revenue.
**New partners** get a journey that respects their time. Industry guidance from HP and others consistently emphasizes the principle: "if you're trying to build this, onboard yourself to your own organization." Most partner managers who try this experiment find their own onboarding embarrassing. Agent-driven onboarding fixes it, the partner sees exactly what's expected, when, and why, with answers to "what's next" available 24/7 in their own language and tone.
**RevOps and Channel Ops** get a real-time onboarding completion dashboard that updates without manual data entry. Cohort analysis ("which onboarding cohort had the highest 90-day deal registration rate, and what differed in their journey?") becomes a one-question agent query, not a quarterly RevOps project. (See [the ecosystem performance deep-dive](/headless/agentic-use-cases/ecosystem-performance) for more on natural-language analytics.)
**Channel Leadership** finally gets predictability. Time-to-first-deal stops being an aspirational metric and starts being an SLA. Programs that institute structured journeys with proactive nudging consistently report compressing time-to-revenue from 6–12 months down to 60–90 days, sometimes faster for transactional partner types.
## Key statistics: agentic onboarding impact
* **Time-to-productivity baseline**: 6–12 months without structured onboarding (Magentrix, 2026)
* **Compressed timeline with structured programs**: 60–90 days target
* **First-deal retention compounding**: partners who reach first deal within 90 days are **3–4× more likely** to remain active at one year (Unifyr Channel Atlas)
* **CAM time recovered**: \~6–8 hours/week of onboarding chasing per CAM = **300–400 hours/year** redirected from reminders to relationship-building
* **AI support deflection**: comparable AI support implementations deflect **40–60% of routine queries** ("what's next?" questions), with best-in-class reaching 70–80% (Pylon / Freshworks data)
* **Onboarding completion lift**: structured journey programs typically lift completion rates by **15–30 percentage points** vs. portal-only programs
## The partner's view: many vendors at once
Most onboarding articles assume one vendor onboarding one partner. The honest reality on the partner side is messier: a typical reseller / SI / MSP is being onboarded by 3–10 vendors at any given moment, each with its own portal, its own checklist, and its own “what's next” framing. The natural result is that the most economically valuable onboarding stalls, not because the partner doesn't care, but because attention is finite and nobody told them which onboarding to advance today. A partner-side aggregator that shows every open onboarding across every vendor in one view, ranked by return-on-next-action, is becoming a basic expectation for partners who take their multi-vendor portfolio seriously. The vendors who recognize that, and surface their part of the journey in formats that aggregate cleanly with peers, get the partner's attention first.
## The deeper shift
Onboarding has always been treated as a one-time event with a finish line. Sign the agreement, deliver the welcome kit, hand off to the CAM. The agentic model treats it as the **first phase of a continuous, agent-supported relationship**: where the partner is being chased, supported, and unblocked the entire time, and where every status update is observable in real time without anyone having to ask for it.
The shift matters because the partner's perception of "what working with this vendor feels like" is set in those first 90 days. If the experience is friction, paperwork, and chase emails, the partner enters the relationship believing this is what working with you costs. If the experience is responsive, contextual, and respectful of their time, they enter believing the partnership is worth the investment.
That belief, set in the first 90 days, determines whether they're in the 80% who quietly disengage or the 20% who drive your channel. For what to do when partners *do* start to disengage, see [the activation deep-dive](/headless/agentic-use-cases/activation).
## Key takeaways
* **Definition**: Agentic partner onboarding is a structured, AI-driven onboarding model that personalizes journeys per partner, chases progress automatically across channels (email, Slack, Teams, portal), and answers partner questions conversationally, replacing static portal-and-PDF onboarding.
* **The cost of slow onboarding**: without structured onboarding, the average channel partner takes **6–12 months** to become fully productive. Industry research (Magentrix) shows structured programs compress this to **60–90 days**.
* **The activation cliff**: partners who close their first deal within 90 days are **3–4× more likely** to remain active at one year (Unifyr Channel Atlas).
* **Introw's approach**: a personalized journey per partner, a background chasing agent that nudges in the partner's preferred channel and tone, and conversational status checks via Claude, ChatGPT, or Slack.
* **Stakeholders**: CAMs, new partners, RevOps/Channel Ops, channel leadership.
## Frequently asked questions
Partner onboarding is the structured process of integrating new channel partners into a vendor's program and equipping them to sell, support, and represent the product effectively. It typically covers the first 30–90 days of the partnership and includes program orientation, product training, sales enablement, tool access, and first-deal support.
Industry research from Magentrix shows that without structured onboarding, the average channel partner takes **6–12 months** to become fully productive. With a well-designed onboarding program, that timeline compresses to **60–90 days**, with the first deal registration typically targeted within 30 days. The exact timeline depends on partner type and product complexity.
Time to first deal is the number of days between contract signature and a partner's first registered or closed opportunity, the single most important leading indicator of partner success. Unifyr Channel Atlas research shows partners who close their first deal within 90 days are **3–4× more likely** to remain active at the one-year mark, making onboarding velocity directly tied to long-term partner retention.
AI accelerates partner onboarding in three ways: (1) personalized journey generation per partner type, region, and competency, (2) proactive multi-channel chasing (email, Slack, Teams, portal) that replaces manual CAM reminders, and (3) conversational self-service so partners can ask "what's next?" and get contextual answers without waiting for a CAM response.
Conversational partner onboarding lets partners ask about their onboarding status, next tasks, and milestones in natural language, typically through Claude, ChatGPT, Slack, or Microsoft Teams, instead of logging into a portal. Behind the scenes, a partner-side MCP server returns the partner's open tasks, due dates, and next milestones with full personalization.
A CAM responsible for 30 partners typically spends 6–8 hours per week on routine onboarding chasing, sending reminders, checking status, escalating stalled partners. Agentic chasing recovers most of that load, freeing roughly **300–400 hours per CAM per year** for higher-leverage strategic work like top-tier partner relationship management.
Yes. Onboarding journeys can be personalized for resellers, system integrators (SIs), referral partners, MSPs, and ISVs, each with different milestones, content, and certification requirements. The agent applies the right journey based on the partner's profile, then adapts as the partner's competencies and engagement signals evolve.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Mines kickoff-call transcripts plus partner context, generates a personalized 90-day journey, assigns every task with owner and due date in Introw, and runs the project headlessly.
Partner-side: aggregated view of every open onboarding across every vendor portal, open tasks, milestones, time-to-first-deal, what's blocked. One screen for partners juggling 5+ vendors.
Partner-side decision support: across multiple in-flight onboardings, ranks each by ROI of next action so the partner knows which one to advance today.
# Partner Acquisition
Source: https://docs.introw.io/headless/agentic-use-cases/partner-acquisition
Agentic partner acquisition uses AI lookalike modeling on your top performers to replace recruitment guesswork. Lift activation from 30% to 50%, see how.
Partner recruitment has historically run on intuition and inbound applications, leaving up to half of every recruitment euro producing zero pipeline. Agentic acquisition flips the model: an AI agent reads CRM, engagement, and revenue data; extracts the patterns that correlate with top performers; and fires signal-based outbound through Clay and ABM platforms. Lifting activation from 30% to 50% on the same intake yields 67% more productive partners, roughly €10M of incremental sourced ARR per 100-partner cohort.
## How it works
## What is agentic partner acquisition?
**Agentic partner acquisition is a recruitment model in which an AI agent, connected to a vendor's CRM, partner engagement data, and revenue records, identifies the patterns that correlate with high-performing partners and uses those patterns to source, qualify, and engage lookalike candidates automatically.** Unlike traditional partner recruitment, which relies on inbound applications, competitor lists, and the intuition of a channel manager, agentic acquisition is grounded in live data and executes through MCP-connected tools the team already uses.
## The recruitment problem nobody talks about
Channel leaders have a dirty secret: most partner recruitment is theatre. A new logo gets signed, a slide deck gets updated, a celebratory Slack message goes out, and then nothing happens. Industry data confirms it. Across mature programs, **only 20% of authorized partners typically generate 80% of the revenue**, and activation rates for newly recruited partners sit between **30% and 50%** according to Unifyr's 2026 Channel Atlas, with poorly managed programs falling below 20%.
Translate that into spend. If your CAC for a new partner is €15K (recruiting time, onboarding hours, portal provisioning, training development) and half never close a deal, you're effectively burning half your recruitment budget. For a program signing 100 new partners a year, that's **€750K of effectively wasted spend**: money that funded relationships that will never produce pipeline.
The root cause isn't bad partners. It's bad targeting. Most programs recruit based on the loudest inbound applications, the partners a competitor used, or the ones a sales leader "has a feeling about." None of that is evidence.
## How does AI improve channel partner recruitment?
Introw's agentic acquisition flips the model. Instead of guessing, **an AI agent inspects your existing partner base, connected to live CRM, engagement, and revenue data, and identifies the patterns that actually correlate with high performance**. Geography. Vertical focus. Tech stack. Service mix. Headcount band. Sales cycle compatibility. Customer ICP overlap.
The agent then takes those patterns and fires signal-based outbound through MCP-connected tools your team already uses, Clay for enrichment and ABM platforms for execution. Outreach goes to partner prospects who match the profile of partners *who already work*, not partners who looked good on a list.
Concretely: a partner manager opens Claude or ChatGPT and types *"Show me the top 5 patterns across our top 10 performing partners by sourced ARR last year, then find me 100 lookalike partner candidates in DACH and trigger an outbound sequence."* The agent returns the patterns, suggests the lookalikes, and triggers the sequence. End-to-end, in minutes.
Use Introw's advanced reporting to compare your addressed market with your actual partner ecosystem before you recruit. If Germany already produces 3x the revenue but has only 50% of the partner bandwidth, or no partner in-region at all, the agent can turn that coverage gap into a prioritized acquisition brief instead of another generic prospecting list.
## Who wins, and how
**Channel Chiefs and VPs of Partnerships** stop defending their recruitment budget with anecdotes. They get an evidence-based partner ICP they can present to the CFO, with traceable lineage from "what worked" to "who we're recruiting next." According to CSO Insights research, organizations with the most effective enablement programs outperform peers on win rates by up to 17.9 percentage points, putting the right partners into that program is the leverage point.
**Partner Recruiters** stop spending 60–70% of their week on cold outreach. The agent handles sourcing, enrichment, and the first-touch sequence. Recruiters move upstream into qualifying high-intent replies and structuring partnership conversations, the highest-leverage work in the funnel.
**RevOps and Finance** finally see partner CAC stabilize. Cost-per-active-partner, the metric that actually matters, improves because activation rates climb when you start with better-fit partners. Moving from a 30% to 50% activation rate yields **67% more productive partners** from the same recruitment volume.
**The existing partner base** wins too. Better-fit new partners means less channel conflict downstream (see [the channel conflict deep-dive](/headless/agentic-use-cases/channel-conflict)), more credible joint-marketing partners, and a healthier ecosystem reputation that makes top partners want to stay.
## Key statistics: the economics of agentic partner acquisition
* **Activation rate baseline**: 30–50% for managed programs; below 20% for unmanaged (Unifyr Channel Atlas, 2026)
* **Pareto reality**: top 20% of partners drive 80% of revenue in most programs (industry consensus)
* **Activation lift impact**: moving from 30% → 50% = 67% more productive partners per cohort
* **Per-cohort revenue impact**: \~€10M incremental sourced ARR per 100-partner cohort at €500K average sourced ARR per active partner
* **Win-rate edge for managed programs**: +17.9 percentage points (CSO Insights, 5th Annual Sales Enablement Study)
* **Recruiter productivity**: agent-driven sourcing compresses prospecting time **70–80%**
* **Partner-attached revenue benchmarks**: 24% in horizontal SaaS, 47% in cybersecurity, 58% in services-led businesses (Crossbeam ELG / Partnership Leaders 2026)
## Top performers, redefined
Revenue alone misses the point. A partner with €100K of sourced ARR and 200 customers in your ICP is dramatically *under-leveraged*, not low-performing, and they're often the most informative lookalike template you have. When ecosystem data (Crossbeam) is in the loop, the agent reads partners along two dimensions: realized revenue, and **ecosystem reach**: total customer overlap, customers in your ICP, and customers sitting in your open pipeline today. That last one is the warmest signal channel programs can act on: a partner whose existing customer is your active opportunity converts a cold direct pursuit into a warm-introduction motion overnight. The natural by-product is a separate “high overlap, low realized revenue” bucket, partners who simultaneously serve as recruitment lookalike templates for net-new sourcing and as the highest-priority activation candidates inside the existing base.
## The deeper shift
Partner acquisition has historically been the least instrumented part of the channel motion. Onboarding has dashboards. Pipeline has forecasting. Even MDF has ROI scorecards. But recruitment has been a black box where someone scrolled LinkedIn and sent some emails.
Agentic acquisition changes the operating model. **Recruitment becomes a continuous background workflow**: agents are always scanning, always proposing lookalikes, always running outbound sequences against signal, instead of a quarterly campaign. The partner program stops being shaped by who happened to apply and starts being shaped by who the data says will succeed.
That's the difference between hoping your channel grows and engineering it. For what happens *after* you recruit the right partners, see the [agentic onboarding deep-dive](/headless/agentic-use-cases/onboarding) and the [partner segmentation playbook](/headless/agentic-use-cases/partner-segmentation).
## Key takeaways
* **Definition**: Agentic partner acquisition uses AI agents connected to live CRM, engagement, and revenue data to identify lookalike partner profiles and trigger signal-based outbound, replacing intuition-driven recruitment.
* **The cost of gut-feel recruitment**: typical channel partner activation rates sit at **30–50%**, and unmanaged programs fall **below 20%**: meaning up to half of every recruitment dollar produces zero pipeline.
* **Introw's approach**: an MCP-connected agent analyzes top performers, surfaces lookalike candidates, and fires outbound through Clay and ABM platforms from a single Claude or ChatGPT prompt.
* **Headline outcome**: lifting activation from 30% to 50% on the same intake yields **67% more productive partners**: roughly €10M of incremental sourced ARR per 100-partner cohort.
* **Stakeholders**: Channel Chiefs, Partner Recruiters, RevOps, Finance, and the existing high-performing partner base.
## Frequently asked questions
A lookalike partner profile is a data-derived pattern that describes the attributes shared by a vendor's highest-performing partners, including geography, vertical focus, technology stack, headcount band, sales cycle compatibility, and customer ICP overlap. Channel teams use lookalike profiles to recruit new partners who resemble existing top performers, replacing intuition-driven targeting with evidence-based selection.
Industry research from Unifyr's 2026 Channel Atlas shows that **typical activation rates for newly recruited partners range from 30% to 50%**, with programs that don't actively manage activation falling below 20%. This means up to half of a typical recruitment budget produces no pipeline, making activation rate one of the most underrated levers in channel ROI.
The Model Context Protocol (MCP) lets AI agents securely connect to tools like Clay, ABM platforms, HubSpot, and Salesforce, then orchestrate workflows across them from a single conversational interface. For partner recruitment, a channel manager can prompt an agent in Claude or ChatGPT to identify lookalike candidates, enrich them, and trigger outbound, without manually exporting lists between tools.
At an industry-typical effective cost-per-acquired-partner of €15K (recruiting time, onboarding, portal provisioning, training development), a program signing 100 new partners annually with a 50% activation rate effectively wastes **€750K per year** on partners who never produce pipeline. Improving targeting to lift activation by even 10–20 percentage points reclaims a significant fraction of that spend.
Partner activation is a one-time transition: the partner moves from inactive to active by completing their first revenue-generating action (typically a deal registration or first closed deal). Partner engagement is ongoing and measures whether an already-active partner continues to invest effort in the relationship over time. A partner can be activated but disengaged; both metrics matter, but they answer different questions.
Yes, agentic recruitment is designed to layer on top of existing CRM (Salesforce, HubSpot), enrichment (Clay), and outbound tools rather than replace them. The agent operates as an orchestration layer over the partner manager's existing stack, meaning the recruitment process improves without forcing a rip-and-replace migration of the underlying tooling.
Introw connects via the Model Context Protocol (MCP) to standard channel and revenue tools including Salesforce, HubSpot, Clay, Slack, Microsoft Teams, and major ABM platforms. The agent reads from and writes to these tools so partner managers can run the entire recruitment workflow from inside Claude, ChatGPT, Slack, or their CRM of choice.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
End-to-end agentic acquisition: top-performer pattern extraction, ecosystem-gap mapping against strategic goals, lookalike sourcing, stakeholder identification, joint-value ABM messaging, and Introw Partner Portal pre-configuration.
# Partner Segmentation
Source: https://docs.introw.io/headless/agentic-use-cases/partner-segmentation
Replace static Gold/Silver/Bronze tiers with AI-powered multi-axis partner segmentation to lift campaign relevance, PDM efficiency, and tier promotion fairness.
Static Gold/Silver/Bronze tiers produce generic programs that disengage 80% of the partner base. Live multi-axis segmentation, readiness, risk, region, competency, vertical, pulls from current CRM, engagement, and certification data and updates campaign and motion targeting in real time. Campaign relevance, PDM prioritization, and tier-promotion fairness all improve once segmentation stops being an annual exercise.
## How it works
## What is live partner segmentation?
**Live partner segmentation is a dynamic grouping system for channel partners that updates in real time based on live CRM, engagement, certification, and revenue data, replacing the static tier structures (typically Gold, Silver, Bronze) that have historically defined partner programs.** Instead of segmenting by a single revenue threshold reviewed annually, live segmentation lets channel teams group partners across many axes simultaneously: tier, region, vertical competency, certification status, deal-stage activity, training completion, and risk signal.
## Why "Gold, Silver, Bronze" doesn't tell you anything useful
Most partner programs still segment on one axis: revenue. Hit the threshold, get the tier badge. The problem is that revenue is a lagging indicator of everything that actually matters, readiness, vertical fit, technical capability, regional opportunity, motivation. Two "Gold" partners can have nothing in common except a number on a dashboard.
The cost of this is invisible but enormous. Generic tiers produce generic programs, generic programs produce generic engagement, and generic engagement is exactly what fuels the **80/20 dynamic** every channel leader complains about: the top 20% of partners drive 80% of the revenue, while the rest sit in tiered limbo as "partners-in-name-only," registering deals only when they accidentally trip over them.
If you can't tell a SOC 2-certified healthcare-focused MSP apart from a generic reseller in your tier structure, you can't run a relevant program for either of them.
## How does AI-driven partner segmentation work?
Introw's agent reads from the live data that already exists, CRM, engagement logs, certification records, deal history, regional revenue, content consumption, training completion, and groups partners across whatever axes the moment requires. Not just tier, but readiness, risk, region, competency, vertical, and stage of the partner lifecycle.
The shift is from *static tier* to *dynamic segment*. Static tiers update once a year. Dynamic segments update the moment something changes. A partner who completed a healthcare module last week is automatically in the "healthcare-ready" segment today, and the next campaign for healthcare prospects routes to them, without a partner manager rebuilding a list.
A channel manager can sit in Slack and ask: *"Which Gold partners in EMEA have completed our cybersecurity competency, have at least one open opportunity, but haven't engaged with the new threat-detection campaign?"* The agent answers in seconds. That answer would have taken a RevOps analyst half a day in spreadsheets, and by the time the spreadsheet was ready, half the data would already be stale.
## The competency-driven motion (and why "no-tier" is having a moment)
Modern channel programs are increasingly moving away from rigid tiers toward **competency-driven** or even **no-tier** motions. The logic is simple: a partner who's certified on your security suite and has three closed-won enterprise deals in financial services is the right partner to send a financial-services security lead to, regardless of their "tier."
That motion is impossible without live segmentation. You cannot route opportunities by competency if your competency data lives in a spreadsheet someone updates quarterly. You can if your competency data is queryable in natural language, in real time, by an agent that already has every signal connected.
## Who wins, and how
**Channel and Partner Marketing Managers** stop wasting campaign spend on partners who can't act on the offer. Generic blasts ("here's our new product launch, sell it!") get replaced with targeted plays ("here are the 23 partners certified on this product, in your priority verticals, with engaged contacts at five or more open accounts"). Industry research consistently shows that **partner-attached revenue contribution varies from 24% in horizontal SaaS to 47% in cybersecurity to 58% in services-led businesses**: meaning generic segmentation is leaving real money on the table by treating very different partner types the same way.
**Partner Development Managers (PDMs)** stop running quarterly business reviews on intuition. Their book of business is segmented for them, partners at-risk, partners trending up, partners with pipeline-but-low-engagement, partners ready for tier promotion, so every PDM conversation starts with the right priority list, not the loudest partner. (For more on QBR automation, see [the QBR deep-dive](/headless/agentic-use-cases/qbrs-meeting-prep).)
**RevOps** gets a segmentation layer that updates in real time and is queryable from natural language. They stop being the bottleneck for every "can you pull a list of partners who…" request, because the agent answers it directly.
**Partners themselves** get programs that actually fit them. The healthcare-focused SI gets healthcare campaigns, not generic enterprise content. The high-velocity SMB reseller gets transactional enablement, not 30-page enterprise battle cards. Relevance drives engagement, and engagement drives revenue.
## Key statistics: live segmentation impact
* **80/20 Pareto reality**: top 20% of partners drive 80% of revenue in typical programs (Successful Channels analysis)
* **Partner-attached revenue benchmarks by category**: 24% horizontal SaaS, 41% hardware, 47% cybersecurity, 58% services-led, 19% fintech (Crossbeam ELG / Partnership Leaders 2026)
* **First-deal retention compounding**: partners who close their first deal within 90 days are **3–4× more likely** to remain active at the one-year mark (Unifyr Channel Atlas)
* **Segmented vs. generic engagement**: B2B benchmarks consistently show segmented content drives **2–4× the engagement** of generic blasts
* **PDM capacity recovery**: a properly segmented book lets PDMs prioritize the 6–8 conversations per week that actually matter
## Ecosystem overlap as a segmentation axis
Tier and engagement aren't the only signals worth segmenting on. Once partner-overlap data (Crossbeam) is connected, the agent can slice the partner base by *which partners overlap with which target accounts*, a segment that doesn't exist in any portal but answers the most valuable operational question of the week: who do we bring into this deal, this account list, this expansion play? The static-tier view can't see it; the dynamic one can. Pair that with a rigorous quarterly tier-promotion review, sustained-quarter performance bars, configured demotion runways, drafted partner-facing comms, and the program shifts from arbitrary annual classifications into a live operational instrument.
## The deeper shift
Partner segmentation has always been treated as a static org-chart exercise. You write the tier definitions in a doc, you assign partners to tiers, you review it once a year. Everything in between happens off-segmentation, with partner managers running on memory and gut feel.
Agentic segmentation makes the dimension itself fluid. Today's segment is healthcare-ready partners with active EMEA pipeline. Tomorrow's segment is partners who've gone 30 days without a deal-stage update. Next week's segment is partners whose certifications are about to expire. The segmentation isn't a structure, it's a continuously evolving lens you can apply to your ecosystem to see exactly what you need to see, when you need to see it.
That's how a 200-partner program starts to feel like 200 individually managed relationships, instead of three tiers and a lot of guesswork. For how the same data layer enables real-time ecosystem queries, see [the ecosystem performance deep-dive](/headless/agentic-use-cases/ecosystem-performance).
## Key takeaways
* **Definition**: Live partner segmentation is the practice of grouping channel partners across multiple dynamic axes, readiness, risk, region, competency, vertical, using live CRM, engagement, and certification data, rather than a single revenue-based tier.
* **The cost of static tiers**: in most programs, the **top 20% of partners drive 80% of the revenue**, and "Gold/Silver/Bronze" segmentation produces generic programs that fail to engage the rest.
* **Introw's approach**: an AI agent reads live data, CRM, engagement logs, certification records, deal history, and generates dynamic segments on demand from natural-language queries.
* **Headline outcome**: campaign relevance, PDM prioritization, and tier-promotion fairness all improve once segmentation updates in real time instead of annually.
* **Stakeholders**: Partner Marketing Managers, PDMs, RevOps, partners themselves.
## Frequently asked questions
Partner segmentation is the practice of grouping channel partners into categories based on shared attributes, historically by revenue tier (Gold, Silver, Bronze), but increasingly by competency, vertical, region, readiness, or risk profile. Modern PRM platforms enable dynamic segmentation that updates in real time based on live CRM, engagement, and certification data.
Traditional partner tiering is static and revenue-based: partners hit a threshold, get assigned to a tier, and stay there until the next annual review. Dynamic segmentation is multi-axis and live: partners are simultaneously grouped by tier, region, certification status, vertical competency, deal activity, and engagement signals, all updating the moment underlying data changes.
A competency-driven partner motion routes opportunities, content, and incentives based on a partner's demonstrated capabilities (certifications, closed-won deals in a vertical, technical specializations) rather than their revenue tier. This approach is increasingly favored over rigid tier structures because it produces better customer outcomes and more accurate lead-to-partner matching.
"No-tier" partner program design eliminates rigid tier hierarchies (Gold/Silver/Bronze) in favor of dynamic, competency-based segmentation. Partners qualify for opportunities, MDF, and incentives based on their current capabilities and engagement, not on a once-a-year tier assignment. This model has become more practical with AI-driven PRM platforms that can manage segmentation complexity in real time.
Most programs see top 20% of partners generating 80% of revenue because static segmentation produces generic programs, generic programs produce uneven engagement, and uneven engagement produces a long tail of disengaged partners. Live segmentation breaks this pattern by enabling targeted interventions for the disengaged 80% before they become permanently dormant, see [the partner activation deep-dive](/headless/agentic-use-cases/activation).
Introw reads partner attributes, deal records, and engagement signals directly from Salesforce, HubSpot, and connected systems via MCP. Segments are computed on live data, no nightly batch jobs, no spreadsheet exports, and any segment can be referenced in campaigns, approval rules, and PDM workflows from inside the partner manager's existing CRM interface.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Quarterly tier review across the entire partner base, combines revenue, certifications, engagement, and goal attainment to recommend promote/hold/demote and drafts the partner-facing comms for each move.
Combines Introw + Crossbeam to find the best partner per target account, overlap-driven, fit-scored, and conflict-checked. Drafts the partner intro request.
# QBRs / Meeting Prep
Source: https://docs.introw.io/headless/agentic-use-cases/qbrs-meeting-prep
Partner QBR automation collapses 2-4 hours of prep into 10 seconds + 15 minutes editing. Make 100% QBR coverage feasible across your entire partner program.
PDMs spend 2–4 hours per QBR on data assembly, 240–500 hours/year for a 30-partner book, which is why most programs only achieve 20–30% real QBR coverage. Agentic generation pulls pipeline, goals, activity, engagement, commissions, MAP status, and a recommended agenda from connected systems in \~10 seconds. PDMs spend 15 minutes editing instead of 4 hours assembling, finally making 100% partner coverage feasible.
## How it works
## What is partner QBR automation?
**Partner QBR automation is the AI-driven generation of Quarterly Business Reviews, including pipeline analysis, goal progress, activity summaries, engagement scoring, commission status, mutual action plan tracking, and agenda recommendations, assembled instantly from connected CRM (Salesforce, HubSpot), PRM, and partner engagement systems.** It replaces the 2–4 hours of manual data assembly per QBR that has historically capped how many partners a PDM can actually review in depth.
## The QBR coverage gap nobody admits to
Channel teams say they review every partner quarterly. The honest reality is that most programs achieve **20–30% real QBR coverage** on the partner base, Gold-tier partners get full reviews, mid-tier get a half-baked version, and the long tail gets a check-in email and a "we'll catch up next quarter."
The cause is math. A PDM with 30 partners and 4 quarterly reviews per year would need to do 120 QBRs annually. At 2–4 hours of prep each, that's **240–480 hours just on prep**: before the actual meeting time, before the follow-up, before the expansion conversations the QBR is supposed to enable. The economics are impossible, so coverage gets cut.
The cost of incomplete coverage is a long tail of partners drifting without strategic check-in, and silent failure (see [the activation deep-dive](/headless/agentic-use-cases/activation)) often takes root precisely in the quarters where a partner gets a "we'll catch up next quarter" instead of a real review.
## How does AI generate a full partner QBR?
Introw's QBR agent pulls from every connected system in real time and assembles a complete review in roughly 10 seconds:
* **Pipeline status**: open opportunities, stage distribution, deal velocity vs. cohort
* **Goal tracking**: progress against MBOs, certification targets, quarterly commitments
* **Activity summary**: meetings, emails, training completion, content engagement
* **Partner engagement score**: composite signal vs. cohort benchmarks
* **Commission status**: paid, pending, projected
* **Mutual action plan progress**: milestones complete, blocked, due
* **Recommended agenda**: three to five priority topics surfaced from the data, with talking points
The PDM gets a fully drafted QBR. They spend **\~15 minutes editing**: adding strategic context the data doesn't capture, adjusting tone, sharpening recommendations, instead of 4 hours assembling.
## Who wins, and how
**Partner Development Managers** reclaim their week. A 30-partner book × 4 QBRs/year × 2-4 hours of prep saved per QBR equals **250–500 hours per year per PDM**. That's not a marginal improvement; that's a structurally different job. The work shifts from spreadsheet wrangling to strategic conversation, which is where PDMs add disproportionate value and what most PDMs joined the function to do.
**Partners** experience reviews that are actually data-driven instead of impressionistic. Most partners can tell when a QBR was assembled in the last hour and when it's the product of real analysis. Agent-generated reviews include the data depth that used to be reserved for top-tier partners, which means the mid-tier and long-tail get the same caliber of review every quarter, not a downgraded version.
**Channel Leadership** finally gets QBR coverage that matches the org chart. Coverage rates climb from the typical 20–30% of meaningfully reviewed partners to **near 100%** because the prep cost is no longer the binding constraint. That changes the strategic posture of the entire program, every partner gets visibility, every partner gets a feedback loop, every partner is being managed instead of managed-on-paper.
**RevOps** gets QBR-ready data on demand. The same data layer that powers QBR generation is queryable in natural language for ad-hoc analysis. (See [ecosystem performance](/headless/agentic-use-cases/ecosystem-performance) for that complementary capability.)
**Partner Teams** at the partner organization see a vendor that takes them seriously. The downstream effect on partner mindshare is significant, a partner that gets four genuine, data-rich quarterly reviews from a vendor invests differently than one that gets two real reviews and two perfunctory ones.
## Key statistics: agentic QBR impact
* **Manual prep time per QBR**: 2–4 hours of data assembly
* **PDM annual prep load**: 240–480 hours/year for a 30-partner book at quarterly cadence
* **Generation time with agent**: \~10 seconds for full draft
* **Editing time**: \~15 minutes per QBR for PDM strategic refinement
* **Time recovered per PDM**: **250–500 hours/year** redirected from prep to strategic conversation
* **QBR coverage uplift**: from 20–30% real coverage to **near 100%** feasible coverage
* **Quality consistency**: every partner, Gold to long-tail, receives the same data depth in their review
## Closing the loop after the meeting
The half of the QBR motion most articles ignore is what happens *after* the meeting. Decisions made in the room age into ambiguity unless someone captures them; commitments slip; the next QBR rehashes the same ground. The post-meeting agent, fed the recording or transcript, extracts decisions and action items, creates the tasks in the portal, drafts the follow-up email to attendees, and closes the loop the same day. Pair that with a partner-side prep skill (the partner walks in with their own data view plus a scorecard of how the vendor has been performing for them *as a partner*), and the QBR stops being a vendor-led report-out and becomes a real two-way operating ritual, with the data trail to prove it.
## The deeper shift
QBRs have historically been a binary in channel programs: either you do them well for your top 20% (and inadequately for the rest) or you cut corners across the board. The trade-off has been imposed by economics, not by intent. Every PDM wants to give every partner a real review. The hours don't exist.
Agentic generation removes the trade-off. The prep cost collapses. The coverage gap closes. The partner program becomes the first kind that can credibly say it's reviewing every partner with rigor every quarter, and produce the data trail to prove it.
The bigger architectural shift is that "doing the work of preparing for the meeting" stops being where PDM value is concentrated. The value moves to the conversation, the recommendation, the decision. The drudgery moves to the agent. That's the right division of labor, and it's the operating model that makes a 30-partner book actually feel like 30 individually managed relationships instead of 6 well-managed ones and 24 form-letter check-ins. For complementary insights, see [partner segmentation](/headless/agentic-use-cases/partner-segmentation) and [ecosystem performance](/headless/agentic-use-cases/ecosystem-performance).
## Key takeaways
* **Definition**: Partner QBR automation uses AI agents to instantly generate complete Quarterly Business Reviews, pulling pipeline, goals progress, activity, engagement, commissions, MAP status, and recommended agenda, directly from connected CRM, PRM, and engagement systems.
* **The cost of manual QBR prep**: PDMs spend **2–4 hours per QBR** on data assembly. For a 30-partner book with quarterly reviews, that's **240–500 hours per PDM per year**: most of which is mechanical work nobody enjoys.
* **The coverage gap**: most programs achieve only 20–30% real QBR coverage on their partner base because the prep cost makes 100% coverage economically impossible. Agentic generation makes 100% coverage feasible.
* **Introw's approach**: an AI agent generates the full QBR from connected systems in \~10 seconds. PDMs spend **15 minutes editing** the generated draft instead of 4 hours assembling one.
* **Stakeholders**: PDMs/CAMs, partners, channel leadership, RevOps, partner teams.
## Frequently asked questions
A partner QBR (Quarterly Business Review) is a structured quarterly meeting between a vendor's partner team (typically the PDM or CAM) and a channel partner to review pipeline, goals, performance against commitments, blockers, and strategic priorities for the next quarter. Effective QBRs anchor the partner relationship, surface risks early, and align both parties on the actions that drive partner-attached revenue.
Industry-typical manual QBR prep runs **2–4 hours per partner** for data assembly: pulling pipeline from the CRM, goal progress from spreadsheets, activity from email and meeting tools, commission status from finance systems. For a PDM with 30 partners and quarterly reviews, that's **240–480 hours of prep per year**: most of which is mechanical, repeatable work.
A complete agent-generated QBR includes pipeline analysis (open opportunities, stage distribution, velocity), goal tracking (progress against MBOs and certifications), activity summary (meetings, training, content engagement), partner engagement score, commission status, mutual action plan progress, and a recommended agenda with priority topics surfaced from the data.
Accuracy depends on the data quality of the connected systems, the agent reflects what's in the CRM, PRM, and engagement systems. With clean source data, generated QBRs are typically more comprehensive and consistent than manually assembled ones because the agent doesn't skip sections or miss data the way a time-pressed human does. PDMs review and edit before delivery, catching anything the data doesn't fully capture.
The economics of manual prep make full coverage impossible. A PDM with 30 partners doing 4 hours of prep per QBR, four times a year, would need 480 hours just for prep, more than 12 weeks of full-time work. Programs ration coverage by tier: Gold partners get real reviews, mid-tier get partial, and long-tail get a check-in email. Agentic generation removes the prep constraint and makes 100% coverage feasible.
Yes, Introw connects via MCP to standard CRM (Salesforce, HubSpot), PRM, finance, and engagement systems and pulls the data directly. No manual export, no spreadsheet copy-paste, no quarterly RevOps assembly project. The agent reads from systems of record and produces the QBR in their native data model.
No, automation replaces the *prep*, not the conversation. The PDM still runs the QBR, makes strategic recommendations, builds the partner relationship, and adjusts strategy. The agent handles the data assembly that nobody enjoys, freeing the PDM to spend the saved hours on the strategic and relational work that humans uniquely do well.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Single-partner QBR prep and book-wide coverage sweep, assembles pipeline, goals, activity, engagement, commissions, MAP status, and recommended agenda. Makes 100% partner coverage feasible.
Closes the post-meeting loop: turns the QBR recording or transcript into structured portal updates (tasks, comments, CRM updates) and a polished follow-up email to attendees, same day, no PDM tax.
Partner-side: before the QBR, the partner gets their own data view + drafted talking points + a partner-side scorecard of how the vendor has been performing as a partner. Walk in with their own narrative, not just the vendor's slides.
# Through-Channel Marketing
Source: https://docs.introw.io/headless/agentic-use-cases/through-channel-marketing
Agentic through-channel marketing (TCMA) delivers co-branded, AI-ready assets so partners run campaigns in their own tools with clean attribution back.
Partners that drive revenue already own marketing automation tooling, forcing them into a PRM to launch a campaign is friction that kills adoption. Through-channel marketing automation (TCMA) flips the model: the vendor distributes discoverable, AI-ready assets, email templates, messaging, narratives, positioning, and fully co-branded collateral, and partners (or their AI agents) turn them into campaigns in Mailchimp, HubSpot, or whatever they already run. Affiliate links and end-user forms attribute every click, lead, and conversion back to the partner, so partner marketing becomes measurable revenue you can reward with dedicated commission plans and announcements.
Stop building campaigns for partners. Arm them with AI-ready assets, then attribute every click and conversion back to the partner who drove it.
## How it works
## What is through-channel marketing automation?
**Through-channel marketing automation (TCMA) is the software and program layer through which a vendor equips indirect partners to run co-branded, locally-relevant demand-generation campaigns at scale, while the vendor keeps brand governance and gains attribution.** Unlike direct marketing automation (HubSpot, Marketo) built for a vendor's own database, TCMA operates through a two-tier model: the vendor creates and governs the assets, and partners personalize and deploy them to their own audiences under their own brand.
The distinction from co-op/MDF matters. Co-op and MDF address the *financial* barrier to partner marketing, they fund the spend. TCMA addresses the *capability* barrier, it makes the funded activity actually executable by partners whose teams lack marketing designers, copywriters, and media planners. The most effective channel programs solve both at once.
## Why forcing partners into a PRM fails
Most partner-marketing tooling assumes the partner will come into the vendor's portal to build and launch a campaign. Revenue-driving partners won't. They already have marketing automation tooling, a domain, a list, and a cadence, and asking them to rebuild all of that inside a PRM is friction that guarantees low adoption. Industry benchmarks bear this out: adoption of through-channel programs exceeds 60% only when the partner can launch in minutes, in the tools they already use.
So the job is not to be the partner's campaign tool. The job is to be the source of the assets, messaging, narrative, positioning, and co-branding, that make the partner's existing tool productive, and to instrument those assets so the vendor still sees the results.
## How does agentic TCMA work?
Introw treats every campaign asset as something both a human and an AI agent can consume.
A vendor **campaign kit** bundles the narrative, positioning points, email templates, and co-branded collateral for a campaign into one governed, discoverable package. Partners find it in the portal, or their **AI agent pulls it over Introw's MCP server** and assembles a ready-to-send drip campaign in the partner's own tool, scheduling included.
**Co-branding is first-class.** Not a logo stitched onto a deck, partners generate fully co-branded documents in any format (PDF, DOCX, JPEG) from templates the vendor controls, so the collateral is on-brand for both sides without a single design request.
**Attribution closes the loop.** The kit ships with affiliate links and end-user forms that carry the partner's identity. Every click, lead, and conversion the partner's campaign drives is attributed back to that partner automatically and lands in the vendor's CRM, feeding reporting on live revenue upside from partner marketing.
**Activation is built in.** A campaign can be tied to a dedicated commission plan and an announcement, so partners are incentivized and notified exactly when it pays off to act. And because the vendor owns the CRM source of truth, they can even share attributed lead lists back to partners to fuel the next campaign.
## Who wins, and how
**Partner Marketing Managers** stop producing one-off campaigns partner by partner. They publish a kit once, and the whole eligible partner base, and their AI agents, can launch from it. Output scales without headcount, and every launch is attributable.
**Partners' marketers and sellers** get exactly what they lack: on-message, co-branded, ready-to-run material they can push through their own tooling in minutes, and they get credited (and paid) for the demand they drive.
**Vendor RevOps and VP Partnerships** finally see partner marketing as a measured channel, not a black box. Clicks and conversions reconcile to the CRM, so partner-attached pipeline and revenue are as legible as direct.
**Partners' end customers** see consistent, on-brand messaging from a local partner they trust, delivered in the partner's own voice rather than a generic vendor blast.
## Key statistics: TCMA impact
* **Adoption**: through-channel programs exceed **60% partner adoption** when partners can launch in minutes in their own tools, and stall when forced into a separate portal.
* **Engagement**: co-branded, syndicated campaigns drive **2-4x the engagement** of manual PDF-and-email distribution.
* **Reach**: TCMA lets a vendor scale marketing through **hundreds or thousands of partners** simultaneously, versus a direct MAP that markets only to the vendor's own list.
* **The capability gap**: most channel partners have **zero dedicated marketing staff**, which is exactly why funded MDF so often goes unused without TCMA to make it executable.
* **Attribution**: closed-loop tracking replaces the **40% lead leakage** typical of manual channel handoffs.
## The deeper shift
Channel marketing has spent years trying to pull partners into vendor tools, and losing, because the partners who matter most already have their own. The agentic model inverts it: the vendor becomes the supplier of AI-ready assets and co-branding, the partner keeps their own tooling and audience, and attribution flows back so the vendor still measures and rewards the outcome. Partner marketing stops being a portal partners avoid and becomes a stream of ready-to-launch, attributable campaigns. For adjacent motions, see [Campaigns & Announcements](/headless/agentic-use-cases/campaigns-and-announcements) (the to-partner communication engine) and the [Through-Channel Marketing feature](/features/content/tcma) (the product mechanics).
## Key takeaways
* **Definition**: TCMA equips indirect partners to run co-branded, attributable demand-gen campaigns at scale, in their own tooling, while the vendor keeps brand governance and gains attribution.
* **The anti-pattern**: forcing revenue-driving partners into a PRM to build campaigns kills adoption; they already own marketing automation tooling.
* **Introw's approach**: distribute AI-ready assets and messaging, offer full co-branding in any format (PDF, DOCX, JPEG), and instrument every campaign with affiliate links and forms so clicks and conversions attribute back to the partner in the CRM.
* **Activation**: tie campaigns to dedicated commission plans and announcements, and share attributed lead lists to fuel the next campaign.
* **Headline outcome**: partner marketing becomes a measured, rewardable revenue channel, with 60%+ adoption and 2-4x engagement when friction is removed.
* **Stakeholders**: Partner Marketing Managers, partner marketers and sellers, Vendor RevOps, VP Partnerships, partners' end customers.
## Frequently asked questions
TCMA is the technology and program layer through which a vendor enables channel partners to execute co-branded, locally-relevant demand-generation campaigns at scale. The vendor creates and governs the assets; partners personalize and deploy them to their own audiences under their own brand, while the vendor retains brand control and gains attribution.
Traditional marketing automation (HubSpot, Marketo) is built for direct marketing to a vendor's own database. TCMA is built for indirect channels: it operates through a two-tier model where partners customize and run vendor campaigns under their own brand, to their own customers, with results attributed back to the vendor.
Revenue-driving partners already have their own marketing automation tooling, domain, list, and cadence. Rebuilding all of that inside a PRM is friction that suppresses adoption. TCMA instead supplies the assets and co-branding that make the partner's existing tool productive, and instruments them so the vendor still sees results.
Assets are published as structured, discoverable content the partner's AI assistant can pull over Introw's MCP server. The agent reads the campaign kit, narrative, positioning, and email templates, and assembles a ready-to-send drip campaign in the partner's own tool, including scheduling.
Fully co-branded documents in any format, PDF, DOCX, JPEG, generated from templates the vendor controls. It is not a logo stitched onto a deck; the partner's and vendor's branding merge into on-brand collateral the partner generates themselves.
Campaign kits ship with affiliate links and end-user forms that carry each partner's identity. Clicks, form submissions, and conversions map back to the partner automatically and land in the vendor's CRM, feeding reporting on partner-attached pipeline and revenue. Every interaction the partner drives is attributed to them.
Yes. Tie a campaign to a dedicated commission plan and send an announcement, so partners are both rewarded and notified exactly when it pays off to act. Vendors can also share attributed lead lists from the CRM to fuel the next campaign.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Vendor: build co-branded templates and generate per-partner versions in PDF, DOCX, or JPEG, then publish them to the portal and asset hub.
Partner: self-serve fully co-branded assets across every vendor portal, with your branding applied in the format you need.
Vendor: package positioning, narrative, and email templates into a ready-to-syndicate kit partner AI agents can consume, tied to a commission plan and announcement.
Partner: turn vendor enablement assets into a scheduled drip campaign in Mailchimp or HubSpot, with attribution links applied automatically.
# Training
Source: https://docs.introw.io/headless/agentic-use-cases/training
AI partner training auto-generates courses from your knowledge base, grades open-question assessments, and ships micro-courses in an hour without new hires.
Up to 70% of training content is forgotten within 24 hours, multiple-choice quizzes get gamed, and partner enablement teams ship courses too late to matter. AI partner training generates courses from your existing knowledge base over MCP, runs inline tutoring during the course, grades open-question assessments at scale, and pushes ad-hoc micro-courses to all enabled resellers in under an hour. Comparable AI coaching delivers up to 38% skill improvement, 40% faster readiness, and 32% win-rate lift within six months.
## How it works
## What is AI partner training?
**AI partner training is a channel enablement model in which AI agents generate courses, certifications, and skill assessments directly from a vendor's existing knowledge base, and provide inline tutoring, on-demand micro-courses, and rubric-based grading at scale.** Unlike traditional partner LMS platforms that depend on instructional designers manually building modules, AI partner training pulls content from Notion, Confluence, product docs, asset libraries, and recorded calls via MCP, then assembles, delivers, and assesses it automatically.
## The training paradox
Channel programs spend enormous resources on training. LMSs, video studios, instructional designers, certification programs, annual partner kickoffs. And then research shows up to **70% of training content is forgotten within 24 hours and 87% within a week** without reinforcement. Static PDFs don't reinforce. Multiple-choice quizzes don't measure understanding, they measure pattern recognition, which is what gets gamed.
Meanwhile, the demand for training is exploding. Every product launch, every competitive shift, every new vertical needs a course. Most enablement teams are staffed for a fraction of that work and end up either delivering courses too late to matter or skipping them entirely.
Industry data underscores the cost: only **84% of sales reps reach quota** even when their organization deploys a best-in-class enablement strategy, and most channel partners are working with substantially worse than best-in-class. Korn Ferry research shows consistent, well-reinforced training drives **32% higher win rates and 28% higher quota attainment**, but consistency is exactly what static training programs can't deliver.
## How does AI partner training work?
Introw's training stack rebuilds partner education around AI primitives.
**AI course creation** pulls from your existing knowledge base, Notion, Confluence, asset library, blog, product docs, over MCP and generates structured courses automatically. The same documentation your internal team already maintains becomes the source of truth for partner training, with no instructional designer in the middle. New product launches don't wait six weeks for course development; the course is ready the day the docs are.
**AI tutoring** runs inline during the course. The partner asks follow-ups in natural language ("What does our SOC 2 status actually mean for healthcare prospects who are asking about HIPAA?") and the agent answers from the same knowledge base, in context. This is the "sparring partner" pattern that current research identifies as the differentiator, practice and reinforcement embedded in the workflow, not a 90-minute event four times a year.
**AI skill assessments with open questions** replace multiple choice. Instead of testing whether a partner can pattern-match a definition, the assessment asks them to handle a real scenario in their own words, and an agent grades the response against a rubric. This is the only way to scale meaningful skill measurement to thousands of monthly learners without manual grading.
**Ad-hoc micro-courses** are generated on demand. A vendor losing deals to a new competitor doesn't wait for the next training cycle, they generate a 15-minute course on the competitor and push it to all enabled resellers within an hour. That's a fundamentally different speed of enablement than the industry has ever had.
## Build anywhere, deliver through Introw
The agentic model doesn't force you to author inside Introw either. Build the course wherever your team (or your agent) works best (Claude, Lovable, or any tool that can produce a SCORM package) and hand Introw the finished artifact over MCP: upload the zip straight into Introw's storage (`create_scorm_upload` returns a presigned upload URL) or point at a hosted URL. One `upsert_course` call takes the zip plus the settings that matter (name, description, a 3:1 thumbnail, due date, minimum passing score, a certificate to award, auto-enrollment on/off) and creates the course. With auto-enrollment on, the course appears in every partner's hub as soon as the package is live, and Introw holds it back until it's actually launchable, so partners never click into a half-imported course.
Iteration works the same way. Update the content in your AI tool, reorder modules, fix a chapter, re-export, and call `upsert_course` again with the `courseId`: Introw swaps the package **in place**. Same course, same link, same enrollments: completions (and issued certificates) stand, learners who were mid-course simply restart on the new version, and the old package keeps serving until the new one is fully live. Two read-only companions, `list_courses` and `list_certificates`, give the agent everything it needs to find the right course, link the right certificate, and confirm an import or replacement went live. Ask who completed a course or holds a certificate with `list_course_enrollments` and `list_issued_certificates`; the list tools also return partner and learner counts so you can answer "how many are certified, and for which courses?" without a roster.
The split of responsibilities is the point. Your AI tools own content generation: ultra flexible, fast, disposable. Introw owns everything that must stay centralized: partners access the training from the partner hub they already use (no re-auth, no separate LMS login), enrollment and scoring are tracked per learner, certificates are issued automatically on passing (including for SCORM courses), and completion syncs into your CRM so sales, channel, and ops all see who's trained. Content can live anywhere; the system of record stays in one place.
## Who wins, and how
**Partner Enablement Teams** stop being the bottleneck. The same team that was previously building 4–6 courses per quarter can now ship updates the day product changes ship. Their job shifts from content production to curriculum design, rubric authoring, and quality control, higher-leverage work.
**Partner Sellers** stop hating training. Open-question assessments reward genuine understanding. Inline tutoring means a confused moment in a course becomes a learning moment, not a dead end. Micro-courses on real, current situations (the new competitor, the new objection, the new compliance requirement) feel relevant, because they are. SalesHood research shows role-specific, reinforced AI coaching delivers up to **38% skill improvement and 40% faster time to readiness**.
**Channel Leadership** finally has a measurable, defensible link from training investment to commercial outcome. When certification attainment is connected to deal registration frequency, win rate, and average deal size, instead of just "completion rate", training stops being a cost line and starts being a measurable revenue lever.
**The customer**, downstream, gets a better experience. Untrained partners deliver bad implementations under your brand. Properly trained partners deliver good ones. The training problem is a customer-experience problem with a delay built in.
## Key statistics: AI partner training impact
* **Forgetting curve**: up to **70% of training content forgotten within 24 hours**, 87% within a week without reinforcement (Ebbinghaus / industry consensus)
* **Quota attainment with structured coaching**: **32% higher win rates, 28% higher quota attainment** (Korn Ferry)
* **AI coaching skill improvement**: **38% skill improvement, 40% faster readiness** (SalesHood, 34,000+ session study)
* **AI sales coaching win-rate lift**: **32% within six months** (Whatfix research); 50–200% in some operationalized implementations
* **Course production speed**: weeks-per-course (instructional design + video + LMS authoring) → same-day for AI-generated courses sourced from existing docs
* **Micro-course delivery time**: from "next training cycle" (weeks) to under one hour for ad-hoc competitor or compliance modules
## Certifications are economic gates, not learning rewards
The vendor-side framing of training is enablement; the partner-side framing is economics. A typical reseller carries 20–50 active certifications across their vendor portfolio, table-stakes ones, expiring ones, optional-but-margin-unlocking ones, and the ones that gate the next tier promotion with a specific vendor. Each vendor sends its own renewal nudges; nobody sends a unified view. Silent expirations strip the partner of deal-protection eligibility on the next big deal, discovered exactly when it matters most. Vendors who treat certifications as economic gates (and surface that framing transparently to the partner) get cleaner cert-completion behavior than vendors who treat them as completion-rate metrics.
## The deeper shift
Partner training has historically been a content-production problem. The agentic model makes it a curation problem instead. Your knowledge base, the docs, the blog posts, the recorded calls, the battle cards, is already most of what a course should contain. The agent's job is to assemble it into the right shape for the right partner at the right moment, then verify they understood it.
This is a fundamentally different operating model. Enablement teams stop being the assembly line for content and start being the editors of a continuously updating curriculum. Partners stop being students who sit through scheduled events and start being practitioners who get the right reinforcement when they need it.
That collapse is what makes channel education actually scalable, and it's what lets a channel program move from "we trained the partners" to "our partners are competent." For how this connects to in-deal coaching, see [the deal coaching deep-dive](/headless/agentic-use-cases/deal-coaching), and for how 24/7 enablement fits in, see [enablement support](/headless/agentic-use-cases/enablement-support).
## Key takeaways
* **Definition**: AI partner training generates structured courses, certifications, and assessments directly from the vendor's existing knowledge base, with inline AI tutoring during the course and open-question assessments graded against a rubric.
* **The cost of static training**: research shows up to **70% of training content is forgotten within 24 hours** and 87% within a week without reinforcement; multiple-choice quizzes that get gamed don't fix it.
* **Introw's approach**: courses generated from Notion/Confluence/docs over MCP, inline tutoring, open-question grading at scale, and ad-hoc micro-courses pushed to all enabled resellers in under an hour.
* **Headline outcome**: comparable structured AI coaching programs deliver up to **38% skill improvement, 40% faster time to readiness, and 32% win-rate lifts** within six months (SalesHood / Whatfix research).
* **Stakeholders**: Partner Enablement Teams, Partner Sellers, Channel Leadership, end customers.
## Frequently asked questions
AI partner training is a channel enablement model that uses AI agents to generate courses, certifications, and skill assessments from a vendor's existing knowledge base. Unlike traditional LMS-based training, which requires instructional designers to build each module, AI partner training pulls from documentation, product docs, recorded calls, and asset libraries via MCP and assembles enablement content automatically.
Introw's course generation agent connects to a vendor's documentation sources (Notion, Confluence, product docs, blog, asset library) over MCP, identifies the topics relevant to partner enablement, and produces structured courses with lessons, examples, and assessments. The agent maintains source-of-truth alignment so when documentation changes, the course can be regenerated automatically.
Open-question skill assessment is a partner certification method where the learner answers free-text questions about real scenarios (e.g., "How would you respond to a healthcare prospect concerned about HIPAA?") instead of selecting from multiple-choice answers. An AI grader scores the response against a rubric, allowing meaningful skill evaluation at the scale of thousands of learners, impossible with manual grading.
Introw can generate and push a 15-minute micro-course (e.g., on a new competitor or compliance requirement) to all enabled resellers in **under one hour**: versus the typical multi-week instructional design cycle. This is what allows channel programs to respond to competitive shifts at speed.
Industry research shows structured AI coaching programs improve win rates by **32% within six months** (Whatfix), with comparable platforms reporting 50–200% lifts when AI coaching is fully operationalized into the daily sales workflow (SalesHood research on 34,000+ AI coaching sessions).
Yes. Build and iterate on the course in any AI tool that can export a SCORM package, hand Introw the zip over MCP (upload it directly with `create_scorm_upload`, where agents PUT it and chat users get a drag-and-drop upload link, or host it anywhere and pass the URL), then create the course with a single `upsert_course` call, including its thumbnail, due date, passing score, certificate, and auto-enrollment. To update it later, re-export and call the same tool with the `courseId`: Introw replaces the package in place, keeping the course link, enrollments, completions, and issued certificates intact. Introw remains the delivery and tracking layer: partners take the course from their partner hub, and completion and certification sync to your CRM.
Yes, Introw's training stack can complement or replace existing LMS infrastructure. Many programs use Introw for ad-hoc micro-courses, AI tutoring, and open-question assessments while keeping their existing LMS for foundational certification programs. The MCP architecture allows interoperability across enablement systems.
Inline AI tutoring lets a partner ask follow-up questions during a course in natural language, getting contextual answers from the vendor's knowledge base without leaving the lesson. This addresses the "forgetting curve", research showing up to 70% of training content is forgotten within 24 hours without reinforcement, by embedding reinforcement directly in the moment of learning.
## Run it in Claude Code
Each workflow ships as a Claude Code skill, a `SKILL.md` file you drop into `.claude/skills//SKILL.md`. Claude triggers it on the prompts in the skill's description. See the [full skill library](/headless/skills) for the complete files.
Detects patterns in closed-lost deals, clusters by failure mode, and generates targeted micro-courses with open-question assessments and asset bundles, deployable in under an hour.
Builds a branded, visual course from your own knowledge sources, packages it as SCORM, and publishes it to Introw with `upsert_course` - certificate, passing score, and auto-enrollment included - then replaces the package in place as content evolves.
Partner-side: every required, optional, and expiring certification across every vendor. Ranked by economic stakes, what gates the next tier, what blocks an active deal, what unlocks higher margins.
# Headless
Source: https://docs.introw.io/headless/index
Introw is the AI-native, headless PRM on your CRM - run your whole partner program in plain language from Claude, ChatGPT, Slack, or your CRM.
> Introw is the AI-native PRM on top of your CRM. The next generation of partner programs is **headless**: your branded portal defines the partner experience and the rules, and the program also runs on the three surfaces where work already happens - the AI assistant, the chat tools, and the CRM - each enforcing those same rules. Agents do the mechanical work across the entire lifecycle, humans stay in the loop where judgment matters, and the portal is never the only way in, for your team or your partners. More adoption. More revenue. Zero friction.
## The headless motion
A portal is one surface among many. The [Introw vision](/introduction) is a world where agents do the mechanical work across the entire partner lifecycle and humans stay in the loop where judgment matters. A deal registers itself from a Slack message in under two minutes. Every strategic partner gets a QBR generated in seconds. Every deal gets a coach. Every partner question gets a 24/7 answer in their own language. RevOps stops being the bottleneck for "can you pull a list of...".
This works because of the bets that make Introw different from a legacy PRM:
Every agent reads and writes through your CRM. Nothing to migrate, nothing to reconcile - attribution and reporting stay real-time and trustworthy.
Partners and internal teams act in the tools they already use - CRM, Slack, Teams, email, and AI surfaces like Claude and ChatGPT. Nobody has to adopt a new tool, and the portal is never the only way in.
No consultants, no dev tickets. The partnerships team configures forms, portals, content, and automations - and now the agents - itself, so the program stays cheap to run.
API, embed, sync, and MCP are pieces you combine and embed into your own stack, not a monolith you accept whole.
## The three surfaces
"Where work already happens" is not an abstraction - it is three specific places, and Introw plugs into each one natively so nobody has to visit the portal to get something done:
1. **The AI assistant** - Claude, ChatGPT, Gemini, or any MCP client. Introw runs a secure [MCP server](/features/developer/mcp), so the whole program is conversational - search partners, register deals, prep QBRs, check commissions - in plain language.
2. **The communication tools** - Slack, Microsoft Teams, and email, plus WhatsApp on the partner side. The same agent sits in [shared channels and chat](/features/integrations/chat), built for the fast commercial moves: *"@Introw, share this \$20k deal for me."*
3. **The CRM** - your team runs the whole program inside HubSpot or Salesforce with [two-way sync](/features/integrations/crm), and partner reps get an Introw card on their own CRM record: live vendor status, one-click co-selling, one-click entry into the entire portal.
The same three surfaces run on both sides of the partnership: your team works them through Introw on top of your CRM, and [Partner Connect](/features/partner-connect) mirrors them for the partner. That is the whole point of headless: everybody stays where work already happens, and nobody - on either side - adds or logs into another tool. More adoption. More revenue. Zero friction.
## Built for both sides
The same headless motion serves everyone in the partnership - each person connects the AI assistant they already use and works with the data they're allowed to see.
Vendors run recruitment, segmentation, enablement, deal ops, coaching, QBRs, and ecosystem monitoring across the whole partner base - from Claude, Slack, or the CRM, without leaving their workflow.
Partner Connect brings the same three surfaces to the partner: their assistant, their chat tools, their own CRM. A cross-vendor cockpit for onboarding, certifications, pipeline, registrations, and incentives - no portal logins to juggle.
## The shift: from portal-era to agentic
Every traditional channel motion has the same shape - a portal at the center, partners forced to log in, CAMs as human help desks, RevOps as the bottleneck for every question. The agentic model rebuilds the stack around agents that work in your existing tools, with humans where the judgment lives.
**Portal-era PRM**
* Partners log into a separate portal to do anything.
* Deal registration is a 14-field form. Most are abandoned.
* CAMs spend their week chasing partners and answering FAQs.
* QBR prep eats 2-4 hours per partner. Most partners don't get one.
* Strategic questions wait days for a RevOps analytics cycle.
* Channel conflict is discovered three weeks after it happened.
**Agentic PRM with humans in the loop**
* Agents work inside Claude, Slack, and the CRM - wherever the partner already is.
* Conversational submission, under 90 seconds, from anywhere.
* CAMs stop being help desks and handle strategic conversations only.
* QBRs generate in seconds; a manager edits and ships - every partner, every quarter.
* Live, plain-language queries answered in seconds, not days.
* Real-time conflict detection at the moment of submission.
### The portal does not disappear, it changes job
Headless is not a portal-free program. Most partner activity still happens in the portal, and a branded portal on your own domain is still what a partner signs up to. What changes is its job. The portal is where the partner experience is **defined**: which deals and records a partner sees, which assets and courses they reach, which forms they may submit, what their tier and segment unlock. The agentic surfaces read from that same definition instead of holding rules of their own, so a partner asking Claude a question, a partner reading a Slack message, and a partner logged into the portal all meet exactly the same program. You govern once, in one place, and it holds everywhere.
## Run it from the AI you already use
The fastest interface to your partner program is the AI assistant you already work in. Introw runs a secure [MCP server](/features/developer/mcp) - the Model Context Protocol is how AI clients connect to tools - that exposes your partner program to Claude, ChatGPT, Cursor, and any other MCP client. Once connected, an assistant can search partners, look up commissions and goals, review submissions, prepare a business review, and take scoped actions like updating a partner or registering a deal, all in plain language. The same protocol powers the partner side through [Partner Connect](/features/partner-connect), so each partner connects their own assistant and works with their own data, scoped to exactly what they're allowed to see.
Every prompt across the product, grouped by area and ready to copy into your assistant.
How the OAuth-protected MCP server exposes your partner program to AI clients.
Point Claude at your Introw MCP server and start working conversationally.
Bring your partner program into ChatGPT through the same secure server.
Give every partner their own MCP-connected assistant, scoped to their data.
The assistants and agents Introw runs for partners and sellers.
The API, embed, sync, and MCP surfaces the agents build on.
Every agent runs on top of the systems your channel program already uses - Claude and ChatGPT, Salesforce and HubSpot, Slack, Teams and Gmail, Notion and Confluence, and many more via MCP - scoped to each user's permissions and writing back cleanly to the CRM as the system of record.
## Governance and trust
The "always-on AI agent" pitch has been around a while. The difference with Introw is that this one is genuinely deployable - because the safeguards are part of how the agent works, not bolted on afterward. An agent that can read your CRM and act on behalf of partners is only deployable if you can answer three questions with confidence: what can it see, what can it do on its own, and what happened after the fact. Introw answers all three.
* **Each person connects with their own login.** Every assistant connects over the same secure sign-in your team and partners already use - no shared keys, no back doors.
* **Agents are scoped by your roles and permissions.** Data access follows your existing RBAC: a partner's assistant reaches only that partner's data, and an agent's access follows the signed-in user's partner scope rather than widening it.
* **You decide what runs automatically and what waits for a human.** A vendor-owned capability matrix keeps sensitive actions behind approval, so routine work flows straight through while anything that needs judgment waits for a person.
* **Actions are recorded back to the CRM.** Agent actions and approvals are written to the CRM timeline, right where your reporting already looks.
Look up data the user can already see - partner tier, commission status, pipeline. Never writes.
Execute a write on its own - for example, submit a deal registration to the CRM.
Route to a human with full context first - for example, an MDF request above a threshold, or a channel-conflict override.
Never available to the agent - for example, touching another partner's records.
This is the same capability matrix referenced throughout the use cases - for example, the [approval-workflow split](/headless/agentic-use-cases/approval-workflows) that auto-approves the straightforward 80% and routes the 20% that needs judgment, and the [enablement-support agent](/headless/agentic-use-cases/enablement-support) that answers freely but requires approval to provision or spend.
For enterprise programs this is non-negotiable, so compliance is built into the architecture rather than promised on top of it: SOC 2 Type 2, ISO 27001, GDPR-ready, and MCP-native. Vendor IT and Security get a deployment they can sign off on. Go deeper in the [MCP overview](/features/developer/mcp) and [Access & Security](/features/access).
## Who wins
Agentic PRM doesn't replace people. It moves their work upstream - to the strategic, judgment-required part of every role - while agents absorb the mechanical work. The same headless motion lands differently for each role in the channel program.
**Proactive, not reactive.** Live ecosystem visibility - ask any question, get an answer in seconds. A defensible recruitment ICP grounded in data, and win-rate compounding from prevented conflict.
**Strategic time, not slideware.** QBR coverage hits 100% of strategic partners, coaching scales to every deal, and an action queue replaces dashboards - roughly 250-500 hours per year recovered.
**Relationships, not chasing.** Stop being a human help desk and reminder bot: the agent handles 40-60% of routine support and chases onboarding progress in the partner's channel.
**Editorial, not assembly line.** 10-20x content output without hiring, with every partner segment getting a relevant variant. The bottleneck moves from production to strategy.
**Infrastructure, not lookups.** No longer the bottleneck for every "can you pull a list of partners who..." request. Routine approvals auto-resolve, freeing capacity for real data work.
**Partnership that respects their time.** Register a deal in 90 seconds from anywhere, see commission in real time, get a coach in every deal, and get 24/7 answers in their own language.
## The partner lifecycle
Fifteen deep dives - from recruitment to QBRs - on what changes when an MCP-connected agent runs alongside the channel team. Each use case maps to a phase of the partner lifecycle, carries the evidence and economics behind it, and ships with [Claude Code skills](/headless/skills) you can drop into your own terminal.
Every use case is the native equivalent of the deep-dive article: the problem, how the agent solves it, who wins, the key statistics, an FAQ, and the matching skills. Open any card below to read the full rundown.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
acquire["Acquire and segment"] --> onboard["Onboard and activate"]
onboard --> enable["Enable and communicate"]
enable --> transact["Transact and govern"]
transact --> coach["Coach and review"]
coach --> measure["Measure and optimize"]
```
### Phase 01 - Acquire & segment
Replace recruitment guesswork with evidence. Replace static tiers with live, multi-axis segments.
AI lookalike modeling on your top performers replaces recruitment guesswork - lifting activation from 30% to 50%.
Replace static Gold/Silver/Bronze tiers with live, multi-axis segmentation for campaign relevance and fair promotion.
### Phase 02 - Onboard & activate
Compress time-to-first-deal. Catch silent failure 60-90 days before the next QBR would.
Cut time-to-first-deal from 6-12 months to 60-90 days with AI chasing agents and conversational journeys.
Lift activation rate from 30% to 50% with AI-driven early-warning detection of silent failure.
### Phase 03 - Enable & communicate
Stop being a content factory. Generate from your knowledge base; ship in hours, not weeks.
Auto-generate courses from your knowledge base, grade open-question assessments, and ship micro-courses in an hour.
Deflect 40-60% of routine tickets and cut response time from 15 minutes to 23 seconds, 24/7, in every language.
Generate segmented campaigns from any source - LinkedIn posts, blogs, Loom recordings - multiplying output 10-20x.
Arm partners with co-branded assets they launch in their own tooling, every click and conversion attributed back.
### Phase 04 - Transact & govern
Conversational deal reg, rule-based auto-approval, real-time conflict detection. SLA in seconds, not days.
Register deals conversationally in 90 seconds, from Claude, Slack, email, or CRM.
Auto-approve the 80% of routine submissions and route the rest, fully audit-logged.
Cross-check every submission against direct and indirect pipeline, in real time.
### Phase 05 - Coach & review
A coach in every deal. A QBR generated in seconds. Strategic time finally goes to strategic work.
Segment-specific guidance in every deal - lifting partner-attached win rates 32% within six months.
Collapse 2-4 hours of QBR prep into 10 seconds plus 15 minutes of editing - making 100% coverage feasible.
### Phase 06 - Measure & optimize
Conversational visibility into commissions and ecosystem health. End "let me get back to you on that."
Partners and CAMs query commission status, tier progress, and projections in seconds - no portal, no finance ticket.
Ask your data "which Gold partners are at risk?" in plain language and get answers in seconds.
## The Claude Code skill library
Every use case ships as one or more drop-in Claude Code skills - a `SKILL.md` file with structured trigger phrases, MCP tool calls, and PRM guardrails. Drop one into `.claude/skills//SKILL.md` and Claude triggers the right one when a prompt matches. There are skills for both sides: vendor skills for the channel team, and partner skills that give partners a cross-vendor view.
All 32 skills, grouped by use case, with full SKILL.md files ready to copy into your repo.
# Prompt library
Source: https://docs.introw.io/headless/prompts
Every prompt you can run against Introw - from Introw AI in the product, or from Claude, ChatGPT, Slack, Teams, or your CRM - grouped by product area and ready to copy.
> Every prompt below runs against your live partner data through one secure toolset.
> Run it in **Introw AI**, the assistant built into Introw, or from your own assistant over [Introw's MCP server](/features/developer/mcp) - Claude, ChatGPT, Gemini, Cursor.
> The surface changes, the prompt does not: the same tools, your own permissions, and every write landing in your CRM.
## Where to run them
* 
**Introw AI**
Built into Introw. Nothing to connect: open it and ask.
* 
**Claude**
A one-click connector, then an OAuth sign-in.
* 
**ChatGPT**
The same server, installed as a ChatGPT connector.
* 
**Any MCP client**
One server URL for Gemini, Cursor and the rest.
[Introw AI](/features/ai/copilot) runs the same toolset the [MCP server](/features/developer/mcp) exposes, so a prompt written for Claude works unchanged inside Introw, and the other way round.
Partners get the same choice: their own assistant through [Partner AI](/features/partner-connect/partner-ai), or the [support agent](/features/ai/partner-support) that answers them in the portal, Slack, Teams, email and WhatsApp.
## How to use this page
Introw AI is already there: open it from the top of Introw and ask. To use your own assistant, connect it once over MCP - see [Connect Claude](/features/developer/mcp/guides/connect-claude), [Connect ChatGPT](/features/developer/mcp/guides/connect-chatgpt), or [Connect an MCP client](/features/developer/mcp/guides/connect-an-mcp-client) for Gemini, Cursor and the rest.
Hover a prompt and use the copy button. Swap the partner names, tiers, and time ranges for your own; the phrasing does not have to be exact, the assistant matches on intent.
Reads run straight away. Actions that change data follow your capability matrix, so they either execute, wait for approval, or stay blocked. See [Governance and trust](/headless#governance-and-trust).
Prompts are grouped by the product area they act on, and each block links to the page that documents the capability behind it. If a prompt returns nothing, the usual cause is that the feature is not configured yet or your role cannot see the data, not that the assistant misunderstood.
## Partners
* Which Gold partners haven't registered a deal this quarter?
* Move Acme up to the Gold tier.
* Prepare a QBR for my top partner.
* For the three partners who signed this week, create their onboarding tasks and assign the first to each.
* Which partners are stalled midway through onboarding with no task completed in 14 days?
* Draft a nudge comment for every partner behind on their activation steps.
* Show each new partner's onboarding progress - to do, in progress, and done.
* Advance Acme's lifecycle phase to active now that their onboarding tasks are complete.
* Show partners in EMEA with no activity in the last 60 days.
* Change Acme's partner manager to me.
* Update Globex's lifecycle phase to active.
* Which partners signed in the last 30 days but haven't finished onboarding?
* Create Acme's next onboarding task, assign it to them, and set it due Friday.
* Show partners who completed onboarding but haven't registered a deal yet.
* Mark Acme's onboarding tasks complete and move their lifecycle phase to active.
* Who is the champion contact at Acme?
* Show the partner managers and owners across our partners.
* List partners in the healthcare vertical with over \$100k in sourced pipeline.
* Which partners match our top-performer profile?
* Show partners grouped by tier and country.
* Create an onboarding checklist for Acme - NDA, kickoff call, portal setup - each due next week.
* Show every overdue partner task across the program, grouped by partner.
* Mark Acme's certification task done and post a comment congratulating them.
* Create a task on the Globex deal to send the security questionnaire, assigned to the partner.
* Which partners have open onboarding tasks with nothing completed in two weeks? Draft a nudge for each.
* List every tier in order with its requirements and benefits.
* How close is Acme to the next tier based on their goal progress?
* Which Silver partners now meet the Gold requirements and should be promoted?
* Promote Acme to Gold and sync the new tier to our CRM.
* Show all partners grouped by tier and country.
## Visibility & collaboration
* Which shared deals are closing this quarter and what stage are they in?
* Add a comment on the Globex deal asking the rep for next steps.
* Create a task on the Acme deal to send the security questionnaire.
* Register a deal or share a lead for Acme without leaving your assistant.
* Show my pending deal and lead submissions and their status.
* Show all partner-attributed deals and their current stage.
* Which shared deals have stalled with no activity in two weeks?
* Update the amount on the Globex deal to \$95k.
* Create a task on the Acme deal to send pricing by Friday, assigned to me.
* Show open tasks across my shared deals, oldest first.
* Mark the 'send NDA' task on the Globex deal as done and comment that it's with legal.
* Reassign the follow-up task on the Globex deal to the partner and set it due Friday.
## Partner Connect
* What do I still need to close to reach the next tier with this vendor?
* @Introw, share this \$20k deal for me.
* Register the opportunities from my own CRM that mention the vendor's product.
* Check my pending commission and the vendor-side status of my deals.
* @Introw, share this \$20k deal for me.
* Register the deal we just discussed with the vendor.
* What's the vendor-side status of our shared deal?
* Ask the vendor's team to review my registration.
* What do I still need to close to reach the next tier with this vendor?
* Register the opportunities from my own CRM that mention the vendor's product.
* Check my pending commission and reconcile it against my own books.
* What training or certifications do I still need with this vendor?
* Show the vendor's live status on my open opportunity.
* Register this deal with the vendor without leaving my CRM.
* What next steps did the vendor's rep leave on our deal?
## Referrals
* Share a lead for Acme: contact [john@acme.com](mailto:john@acme.com), interested in the enterprise plan.
* Show all shared leads still pending review.
* What reward is owed on the referral that just closed?
* Does this referral overlap a deal our direct team already has?
* Has anyone else referred this account before?
* Which shared leads conflict with existing pipeline?
* What's the latest status on the deal I referred into Acme?
* Post a comment on my referred deal asking the rep for next steps.
* Show updates on all the deals I've referred.
* Share a new lead for Acme with contact [john@acme.com](mailto:john@acme.com).
* Show the leads I've shared this month and their status.
* Which of my shared leads have been accepted?
* What referral reward is owed on Acme's closed deal?
* How much have I earned in referral rewards this quarter?
* When is my next referral payout due?
## Deal Registration
* Register a deal for Acme: \$120k ARR, closing end of Q3, contact [jane@acme.com](mailto:jane@acme.com).
* Show every deal registration pending approval or in channel conflict.
* Approve the registration from Globex and link it to the existing CRM deal.
* Does this registration conflict with any direct or partner pipeline?
* Which registrations overlap an existing opportunity?
* Is Globex already being worked by our direct team?
* Register a new deal with Globex worth €80k, closing next month.
* Which registrations are pending, and which overlap our direct pipeline?
* Accept Acme's registration and link it to the existing HubSpot deal.
* Register a deal on behalf of our distributor's sub-reseller.
* Show registrations submitted through second-tier partners.
* Which multi-tier registrations are waiting on approval?
* Show the partner-attributed deals closing this quarter and their stage.
* Which registered deals haven't been updated in 30 days?
* Update the close date on the Globex deal to end of Q3.
## Engagement
* What have we announced to partners this quarter?
* Which partners engaged with our most recent announcement?
* Find what we have already told partners about our pricing change.
* Which announcements have partners seen recently?
* Show partner engagement with our latest announcement.
* Show recent partner portal activity - comments, visits, and task updates - this week.
* Which partners have been active in the last 7 days?
## Partner Portal & Branding
* Show recent partner portal activity - visits, comments, and asset views - this week.
* Which partners have been most active in the portal this month?
* List partners in the directory by category and country.
* List partners in the directory by category and country.
* Which partners are in the healthcare vertical?
## Content & Enablement
* Which assets are partners viewing most this month?
* Has Acme opened the latest pricing deck?
* What content has Acme viewed recently?
* Which assets are getting the most partner engagement?
* Which assets are partners viewing most?
* Has Acme downloaded the security whitepaper?
* Upload these partner one-pagers to the Sales folder.
* Generate a co-branded version of the launch one-pager with our branding
* Which co-branded assets can I personalize?
* What campaign assets can partners launch, and which folders are they in?
* Find our positioning and messaging material so I can build a partner campaign.
* Add this co-branded one-pager to the partner library under Campaigns.
## Courses & Training
* List our courses with their settings and whether the SCORM package imported cleanly.
* Create a course from this SCORM zip and link the partner certification certificate to it.
* Which certificates do we issue, and which course awards each one?
* Show course activity for Acme over the last quarter.
* Enroll Acme's technical contact in the onboarding course and create a task to finish it by Friday.
* Attach our reseller certificate to the sales onboarding course.
* Which of our courses do not award a certificate yet?
* Create a course from this SCORM zip and give it a 30-day due date.
* Replace the SCORM package on our reseller onboarding course.
* Set the passing score on our certification course to 80.
* Which courses auto-enroll partners, and which are marked required?
* What is the due date on each of our required courses?
## Forms
* Submit a co-marketing request form for Acme.
* Show all pending form submissions across every form.
* Approve Globex's submission and notify them.
* When Acme submits a lead, does it update the existing company or create a new one?
* Which fields does the deal-registration form write back to the CRM?
* Which forms can I submit for Acme?
* Start a project submission form for Acme and tell me which fields are required.
* Which forms can I submit for Acme, and what are the ways to submit them?
* Share the deal registration form with Globex as a partner-specific link.
* Submit a batch of leads for Acme from a CSV.
* Show all pending submissions across every form.
* Approve Acme's submission and notify them.
* Return Globex's registration for missing fields.
## Commissions & SPIFFs
* What's our total earned-but-unpaid commission, and what's due to be paid next month?
* How much commission has Acme earned this quarter, and on which deals?
* Explain how Acme's commission plan pays out - rates, tiers, and installments.
* Show the most recent payouts across all partners and their stage.
* Which partners have the most pipeline commission at stake this quarter?
* Show the commission lines generated for Acme this quarter and the deals behind them.
* What's earned-but-unpaid for Acme right now?
* Which deals drove the most commission this month across all partners?
* Break down this quarter's commission by partner.
* Explain how Acme's commission plan pays out, including rate tiers and installments.
* Which commission plans are active, and what source object does each read from?
* What rate applies to a new-business resale deal versus a renewal?
* Which partners are on the referral plan versus the reseller plan?
* What was paid out to partners last quarter, and to whom?
* How much commission is on upcoming payouts right now?
* Show Acme's most recent payouts and where each one stands.
* Which payouts are still waiting on payment?
* Show my most recent payouts and their stage.
* What commission is due to be paid out next month, and to whom?
* How much has been paid to Acme year to date?
* Which payouts are still in review?
* How is commission calculated for referrals versus resale?
* What currency are our commissions reported in?
* What rate tiers and installments does each active plan use?
## Market Development Funds
* 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?
* What's our total MDF budget, approved spend, and available balance across all funds?
* Which partners still have unspent MDF allocation this quarter?
* When does the Q3 marketing fund expire?
* Generate the reimbursement statement for Acme's approved claims.
* Which MDF invoices are approved but not yet paid?
* Mark Acme's Q2 project paid and notify them.
* Submit an MDF proposal for Acme: \$5k for a co-hosted webinar next quarter.
* Which MDF proposals are still waiting on approval?
* What did Acme propose to spend their Q3 allocation on?
* Submit an MDF claim for Acme's webinar: \$3.2k with the invoice attached.
* Show all MDF claims pending approval this month.
* How much of Acme's approved budget is left after claims?
* What ROI have partners reported against the Q2 fund?
* Which MDF projects sourced the most pipeline this quarter?
* Show the return on Acme's field-event project.
## Affiliate
* Which affiliate partners drove conversions this quarter, and how much did each bring in?
* Show the deals attributed to our affiliate partners and their current stage.
* What commission is earned but unpaid across our affiliate partners?
* Which affiliate partners have had no attributed activity in the last 60 days?
* Show the affiliate conversions still waiting on review.
* Which conversions were accepted last month, and which partner submitted each one?
* What commission plan applies to our affiliate partners, and at what rate?
* List the affiliate conversions recorded this month.
* Which partner submitted each of last week's conversions?
* Have any conversions come in from Acme since we installed tracking?
* Show the affiliate conversions that were declined, and who submitted them.
* Are any pending conversions flagged as a potential channel conflict?
* Decline this conversion and leave the partner a comment explaining why.
## Reporting & Dashboards
* Which Gold partners are at risk?
* How is Acme tracking against its goals this quarter?
* Prepare a QBR for Acme with pipeline, goals, activity, and commissions.
* Which partners drove the most sourced pipeline this quarter?
* Show partner-attached revenue broken down by tier.
* How many deals did partners register this month?
* How is Acme tracking against its KPIs this quarter?
* Which partners are behind on their goals?
* Show goal progress for my top five partners.
* Which partners have the highest engagement this month?
* Show partners whose activity has dropped off recently.
* What's Acme's recent portal and deal activity?
* Which Gold partners are at risk?
* Show partner-attached pipeline broken down by tier this quarter.
* Which partners' activity has dropped off this month?
* List partners active in the last 30 days with open deals.
* Build a view of registrations by partner and status.
* Total the ARR on our partner accounts, broken down by region and tier.
## AI Agents
* Answer a partner's question about our MDF claim process.
* Prep a QBR for Acme from live CRM data.
* Review this MDF claim against our proof-of-spend rules.
* Draft a partner announcement from this release-notes URL.
* Write a webinar invite for next month's partner enablement session.
* What should I announce to partners based on our recent updates?
* Review this MDF claim against our proof-of-spend rules.
* Is this deal registration complete enough to approve?
* Return the submissions that are missing required documents.
* Prep a QBR for Acme - pipeline, commissions, and open tasks.
* Which partners have had no activity in the last 30 days?
* Who's closest to hitting the next tier, and what do they still need?
* Create a partner onboarding course from our product one-pager.
* Add a short quiz to the end of module 2.
* Draft a certificate for the sales-fundamentals course.
* Does this new registration conflict with any direct or partner pipeline?
* Flag registrations that overlap existing opportunities.
* Is Globex already being worked by our direct team?
* Coach me on the Acme deal: what are the risks and next steps?
* Which of my deals need attention this week?
* What should I do to move the Globex deal forward?
* What does our partner agreement say about renewals?
* Summarize the latest product release notes for partners.
* Which onboarding docs cover certification?
* What's our deal registration process?
* How do partners request MDF?
* Where do I find the latest sales deck?
## Integrations
* Show Acme's open deals synced from HubSpot.
* Update a deal property and sync it back to Salesforce.
* Register a deal for Acme from Slack or your CRM.
* Show Acme's open deals from HubSpot with their stage and amount.
* Update the close date on the Globex deal and sync it to Salesforce.
* Which CRM deals are linked to partners but have no recent activity?
* Register a deal for Acme from Slack.
* Ask from Teams which partners haven't registered a deal this quarter.
* Share a lead with the vendor straight from Slack.
## Localization
* Set Acme's language to French and currency to EUR.
* Answer this partner's question in Spanish.
* Set Acme's currency to EUR.
* Show Acme's commissions in their local currency.
* Answer this partner's question in Spanish.
* Set Acme's portal language to German.
## Access & Security
* Reassign Acme's partner manager to another team member.
* Who owns each of our partners?
* Who owns each of our partners?
* Reassign Acme's partner manager to another team member.
* Reassign Acme's partner manager to another team member.
## Developer Platform
* Connect an assistant over MCP and ask which partners are at risk.
* Register a deal or prepare a QBR from Claude.
* Give partners their own scoped AI assistant.
* Which Gold partners haven't registered a deal this quarter?
* Show partners in EMEA with no activity in the last 60 days.
* Prepare a QBR for Acme with pipeline, goals, and commission status.
* What commission is pending for Acme, and when is the next payout?
* Register a deal for Acme: contact [john@acme.com](mailto:john@acme.com), \$40k, closing next quarter.
* Approve the deal registration Globex submitted yesterday.
* Create a task for Acme to complete their security review, due Friday.
* Move Acme up to the Gold tier and sync it to our CRM.
## Beyond single prompts
A prompt is one question or one action. When a motion repeats every week, turn it into a skill: a named play with its own trigger phrases and tool calls that your assistant runs end to end. See the [skill library](/headless/skills) for vendor and partner skills, and the [agentic use cases](/headless/agentic-use-cases/partner-acquisition) for how these motions play out across the partner lifecycle.
# Skill library
Source: https://docs.introw.io/headless/skills/index
What agentic skills are, why they matter for partner teams, and how to run them across the partner lifecycle, from acquisition to ecosystem performance.
> Skills turn the repetitive, cross-system work of running a partner program into a single prompt. Each one is a reusable play your AI assistant already knows how to run against your live CRM and partner data, so a partner manager, an ops lead, or a partner can go from question to executed action without touching five tools.
## What a skill is
A skill is a `SKILL.md` file: a named play with trigger phrases, the exact Introw (and Crossbeam, CRM, email, or Slack) tool calls it should make, and partner-program guardrails baked in. When your prompt matches a skill's description, the assistant runs that play end to end and writes the result back to your CRM.
You don't have to be technical to use one. Drop it into Claude Code, or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp).
## Why skills matter for your team
Most channel work is mechanical: pulling the same reports, chasing the same updates, prepping the same reviews. Skills move that work off your plate and keep it grounded in real data.
Recruiting lookalike partners, prepping a QBR, coaching a live deal, catching a partner going quiet, each becomes one prompt instead of an afternoon across dashboards.
Batch motions, tier reviews, deal registration from the inbox, the weekly channel digest, anomaly detection, run on demand, with every write logged back to the CRM.
A cross-vendor cockpit for onboarding, certifications, pipeline, registrations, and incentives, without logging into each vendor portal separately.
Every recommendation traces back to a real tool call, and sensitive writes stay human-in-the-loop, so you get speed without losing control of your CRM.
## How to use a skill
Browse the library below, grouped by the partner-lifecycle use case it serves.
Drop the `SKILL.md` into `.claude/skills//SKILL.md`, or simply run the play in plain language through [Introw's MCP server](/features/developer/mcp) from the tool you already work in.
Describe what you want, "prep my QBR for BrightPath", "find partners we should recruit in DACH", and the matching skill fires and calls live data.
The skill assembles the analysis and drafts the writes; you approve anything that touches the CRM.
## Vendor and partner skills
Run by the channel team, recruitment, segmentation, enablement, deal ops, coaching, QBRs, and ecosystem monitoring across the whole partner base.
Run by partners themselves, a cross-vendor view of onboarding, certifications, pipeline, registrations, QBR prep, and incentive maximization.
Skills call live data through the Model Context Protocol, Introw plus Crossbeam, CRM, email, and Slack, so every recommendation traces back to a real tool call.
Each skill ships with PRM best-practice guardrails: human-in-the-loop on writes, territory checks, data-sharing scope, and clean cross-skill handoffs.
## The library
Read the matching use-case deep dive for the economics and playbook behind each group, then open any skill for its full `SKILL.md`.
### Partner Acquisition
Deep dive: [Partner Acquisition](/headless/agentic-use-cases/partner-acquisition)
**Vendor skill** · End-to-end agentic partner acquisition. Use when a Channel Chief, VP Partnerships, Partner Recruiter, or RevOps user wants to (a) identify top-performing partners (combining revenue with…
**Built for:** Partner Program Manager · VP Partnerships · Partner Recruiter
### Partner Segmentation
Deep dive: [Partner Segmentation](/headless/agentic-use-cases/partner-segmentation)
**Vendor skill** · Use quarterly (or on demand) when a Channel Chief, RevOps, or PDM wants to audit the entire partner base for tier promotion or demotion eligibility, combining revenue, certifications,…
**Built for:** Partner Program Manager · Channel RevOps · Partner Development Manager
**Vendor skill** · Use when a Channel Chief, RevOps, AE-aligned Channel Manager, or PDM wants to find the best partner(s) to bring into a target account list, by combining Crossbeam overlap data with…
**Built for:** Alliance Manager · Channel RevOps · Partner Development Manager
### Onboarding
Deep dive: [Onboarding](/headless/agentic-use-cases/onboarding)
**Vendor skill** · Use when a CAM, PDM, or Channel Ops user wants to spin up a personalized onboarding plan for a new partner, using meeting transcripts (kickoff calls, intro meetings, partnership-fit…
**Built for:** Channel Account Manager · Partner Development Manager · Channel Ops Manager
**Partner skill** · Use when a partner user is being onboarded by multiple vendors and wants a single aggregated view of progress, open tasks, milestones, and time-to-first-deal across every vendor portal…
**Built for:** Partnerships Lead · Partner Operations · Partner Seller
**Partner skill** · Use when a partner is being onboarded by multiple vendors and wants a focused decision on *which onboarding to advance today / this week*, based on commitment dates, economic upside,…
**Built for:** Partnerships Lead · Partner Operations
### Activation
Deep dive: [Activation](/headless/agentic-use-cases/activation)
**Vendor skill** · Use when a Channel Chief, PDM, RevOps, or Channel Ops user wants to run a full activation sweep across the entire partner network, auditing every partner against their goals,…
**Built for:** Partner Program Manager · Partner Development Manager · Channel RevOps
**Partner skill** · Use when a partner who resells / co-sells ongoing services wants a unified view of customer renewal dates, expansion windows, and at-risk accounts across every vendor they work with, so…
**Built for:** Partnerships Lead · Partner Seller · Customer Success Manager
### Training
Deep dive: [Training](/headless/agentic-use-cases/training)
**Vendor skill** · Use when a Partner Enablement lead, Channel Chief, or RevOps user wants to detect patterns in closed-lost partner deals, clustering by lost-reason and customer context, and generate /…
**Built for:** Partner Enablement Manager · Partner Program Manager · Channel RevOps
**Vendor skill** · Use when a Partner Enablement lead, Partner Manager, or Channel Ops user wants to build a partner training course end to end with AI: author from the vendor's own knowledge sources, apply the vendor's branding, package as SCORM, and publish to Introw over MCP /…
**Built for:** Partner Enablement Manager · Partner Program Manager · Channel Ops
**Partner skill** · Use when a partner user wants to see all required, optional, and expiring certifications across every vendor they work with, flagging what's table-stakes, what gates higher-margin SKUs,…
**Built for:** Partner Enablement · Partner Operations · Partner Seller
### Enablement Support
Deep dive: [Enablement Support](/headless/agentic-use-cases/enablement-support)
**Vendor skill** · Use when a Partner Enablement lead, Channel Ops, or Vendor IT user wants to analyze recurring partner support questions over a window, clustering by intent and cross-checking against…
**Built for:** Partner Enablement Manager · Channel Ops Manager · Vendor IT
**Vendor skill** · Use when a Partner Enablement lead, Partner Marketing Manager, or Channel Ops user wants to produce a partner-facing document (one-pager, battlecard, FAQ) from the vendor's own knowledge sources and publish it into the Introw asset library over MCP /…
**Built for:** Partner Enablement Manager · Partner Marketing Manager · Channel Ops
**Partner skill** · Use when a partner user needs to ask a product, pricing, configuration, enablement, or compliance question to a specific vendor, or wants to execute a scoped self-service action…
**Built for:** Partner Seller · Partner Operations
### Campaigns & Announcements
Deep dive: [Campaigns & Announcements](/headless/agentic-use-cases/campaigns-and-announcements)
**Vendor skill** · Use when a Partner Marketing Manager wants a continuous-running content radar, scanning the vendor's release notes, LinkedIn, blogs, industry publications, and competitor news for…
**Built for:** Partner Marketing Manager · Vendor Marketing
**Partner skill** · Use when a partner wants a unified calendar of upcoming product launches, webinars, MDF programs, campaigns, and tier-promotion windows across all the vendors they work with, so they…
**Built for:** Partner Marketing · Partnerships Lead
### Through-Channel Marketing (TCMA)
Deep dive: [Through-Channel Marketing](/headless/agentic-use-cases/through-channel-marketing)
**Vendor skill** · Use when a Partner Marketing Manager wants to turn a vendor template into fully co-branded collateral for every partner, generating per-partner PDF, DOCX, or JPEG versions and publishing them to the portal…
**Built for:** Partner Marketing Manager · Vendor Marketing
**Partner skill** · Use when a partner wants to self-serve fully co-branded collateral from any vendor they work with, applying their own branding to vendor templates and downloading it in the format they need…
**Built for:** Partner - Sales & Marketing · Partner Operations
**Vendor skill** · Use when a Partner Marketing Manager wants to package positioning, narrative, messaging, and email templates into a ready-to-syndicate campaign kit that partners and their AI agents can launch, tied to a…
**Built for:** Partner Marketing Manager · Vendor Marketing
**Partner skill** · Use when a partner wants to turn a vendor's campaign kit into a scheduled drip campaign in their own email tool (Mailchimp, HubSpot, etc.), with co-branding and partner-attribution links applied…
**Built for:** Partner - Sales & Marketing · Partner Operations
### Deal Registration
Deep dive: [Deal Registration](/headless/agentic-use-cases/deal-registration)
**Vendor skill** · Use when a Channel Ops, RevOps, or PDM user wants to scan the vendor's Gmail or Outlook inbox for partner emails containing deal or lead registrations, auto-extract fields, validate,…
**Built for:** Channel Ops Manager · Channel RevOps · Partner Development Manager
**Vendor skill** · Use when a Channel Chief, RevOps, PDM, or AE wants to scan the vendor's CRM (or Excel pipeline) to identify open deals or direct-sales accounts that would benefit most from partner…
**Built for:** Partner Program Manager · Channel RevOps · Account Executive
**Partner skill** · Use when a partner user wants to scan accessible vendor pipeline / shared accounts to identify deals where they have unique influence (existing customer relationship, vertical fit,…
**Built for:** Partner Seller · Partnerships Lead
**Partner skill** · Use when a partner has a new prospect and wants to know which of their vendors fit best, in what order, and how to position each, based on the prospect's stack, segment, vertical, and…
**Built for:** Partner Seller · Partnerships Lead
**Partner skill** · Use when a partner wants a single view of every deal/lead registration they have outstanding across all vendors, pending approval, approved, in conflict, approaching protection-window…
**Built for:** Partner Operations · Partnerships Lead
### Deal Coaching
Deep dive: [Deal Coaching](/headless/agentic-use-cases/deal-coaching)
**Vendor skill** · Use when a CAM, PDM, or Channel Account Manager wants to coach a specific partner deal by first finding similar past won deals (same vertical, deal size, product mix, partner type),…
**Built for:** Channel Account Manager · Partner Development Manager
**Partner skill** · Use when a partner seller is working a specific deal and wants a comprehensive coaching packet, vendor playbook for the stage, similar past wins, competitive battle cards, reference…
**Built for:** Partner Seller
### QBRs / Meeting Prep
Deep dive: [QBRs / Meeting Prep](/headless/agentic-use-cases/qbrs-meeting-prep)
**Vendor skill** · Use when a PDM, CAM, or Channel Chief wants to prepare a Quarterly Business Review (or MBR / WBR): instantly assembling pipeline, goals, activity, engagement, commissions, MAP status,…
**Built for:** Partner Development Manager · Channel Account Manager · Partner Program Manager
**Vendor skill** · Use after a QBR / MBR / partner business review meeting when a PDM, CAM, or Channel Chief wants to turn the meeting recording or transcript into structured portal updates (tasks created,…
**Built for:** Partner Development Manager · Channel Account Manager · Channel Ops Manager
**Partner skill** · Use before a partner heads into a QBR / MBR with a vendor, generates the partner's *own* data view (deals sourced, engagement, training, goals progress, asks to bring up, the partner's…
**Built for:** Partnerships Lead · Partner Operations
### Commissions & Incentives
Deep dive: [Commissions & Incentives](/headless/agentic-use-cases/commissions-and-incentives)
**Partner skill** · Use when a partner user wants to know exactly which actions to take this quarter to maximize commission earnings, hit the next bonus tier, or unlock the next accelerator. Pulls live…
**Built for:** Partner Seller · Partner Finance
### Ecosystem Performance
Deep dive: [Ecosystem Performance](/headless/agentic-use-cases/ecosystem-performance)
**Vendor skill** · Use when a Channel Chief, Channel Ops, or RevOps user wants to generate the weekly partner-team Slack digest, wins, registrations, at-risk partners, pending approvals, KPI deltas,…
**Built for:** Partner Program Manager · Channel Ops Manager · Channel RevOps
**Vendor skill** · Use when a Channel Chief, RevOps, or PDM wants a continuous-monitoring scan across the partner ecosystem to surface unusual behaviors, sudden activity drops or spikes, atypical deal…
**Built for:** Partner Program Manager · Channel RevOps · Partner Development Manager
# Co-brand My Collateral
Source: https://docs.introw.io/headless/skills/partner/cobrand-my-collateral
Partner skill to self-serve co-branded collateral from any vendor by applying their own branding to templates and downloading as PDF, DOCX, or JPEG.
*Partner skill for [Through-Channel Marketing](/headless/agentic-use-cases/through-channel-marketing).*
**Skill ID:** `partner-cobrand-my-collateral`
Use when a partner wants to self-serve fully co-branded collateral from any vendor they work with, applying their own branding to vendor templates and downloading it in the format they need (PDF, DOCX, JPEG). Trigger phrases include "co-brand this vendor asset", "put my branding on this", "get a branded version of the deck", "co-brand across my vendors", "download a branded one-pager", "make this my own".
**Built for:** Partner - Sales & Marketing · Partner Operations
**Workflow:** Enumerate vendor portals → Find co-brandable templates → Apply my branding → Download in the right format
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-cobrand-my-collateral
description: Use when a partner wants to self-serve fully co-branded collateral from any vendor they work with, applying their own branding to vendor templates and downloading it in the format they need (PDF, DOCX, JPEG). Trigger phrases include "co-brand this vendor asset", "put my branding on this", "get a branded version of the deck", "co-brand across my vendors", "download a branded one-pager", "make this my own".
---
# Co-brand My Collateral (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** the partner has access to.
**Use case**: Through-Channel Marketing (TCMA), partner-side, multi-vendor.
## When to use this skill
Use when a partner wants ready-to-use, fully co-branded collateral from their vendors, carrying both the vendor's and the partner's branding, without waiting on the vendor's design team or logging into each portal separately.
**Sample prompts that fire this skill:**
- "co-brand this vendor asset"
- "put my branding on this"
- "get a branded version of the deck"
- "co-brand across my vendors"
- "download a branded one-pager for the campaign"
- "make this my own"
## Why this matters
Partners rarely have design staff, so vendor collateral that needs branding work usually never gets used. Self-serving fully co-branded assets, in the format the partner needs, means the partner can put on-brand, dual-branded material in front of their customers in minutes, across every vendor they represent, from one assistant.
## Process
### Step 1: Enumerate vendor portals
- `Introw_Connect_Staging:partners`: get all portals the partner has access to.
### Step 2: Find co-brandable templates
For each `roomId`:
- Search the vendor's content / asset hub for templates marked co-brandable (those with partner-branding placeholders).
- Filter to what the partner actually needs (a specific campaign, product, or vertical).
### Step 3: Confirm the partner's branding
- Confirm the partner's own logo and details are on file with each vendor so the merge produces a fully branded result. Flag any vendor where branding is missing.
### Step 4: Generate and download
- Generate the co-branded copy per requested format (PDF, DOCX, JPEG).
- Confirm the vendor's locked branding is intact and the partner's branding merged correctly, then provide the download.
## Output format
- **Available co-brandable assets** across vendors: vendor, asset, formats offered.
- **Generated copies**: vendor, asset, format, download reference.
- **Fix list**: vendors where the partner's branding is missing and needs to be captured first.
## Guardrails & PRM best practice
- **Strictly scoped per portal.** Each vendor's assets are only fetched with its own `roomId`. No cross-portal leakage.
- **Respect locked areas.** Only the partner-branding fields change; never alter the vendor's locked branding or claims.
- **No fabricated branding.** If the partner's branding isn't captured with a vendor, capture it first; don't invent it.
- **Use current versions.** Always co-brand the latest template version the vendor published; don't reuse a stale local copy.
- **Cross-skill handoff.** Turn co-branded collateral into a live campaign via `partner-drip-campaign-from-assets`; plan which campaigns to run via `partner-cross-vendor-content-calendar`.
```
Drop this file into `.claude/skills/partner-cobrand-my-collateral/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Cross-Vendor Certification Tracker
Source: https://docs.introw.io/headless/skills/partner/cross-vendor-cert-tracker
Partner skill to track required, optional, and expiring certifications across every vendor, flagging what gates higher-margin SKUs and next-tier promotions.
*Partner skill for [Use case 05: Training](/headless/agentic-use-cases/training).*
**Skill ID:** `partner-cross-vendor-cert-tracker`
Use when a partner user wants to see all required, optional, and expiring certifications across every vendor they work with, flagging what's table-stakes, what gates higher-margin SKUs, and what unlocks the next tier per vendor. Trigger phrases include "all my certifications", "what's expiring", "certs across vendors", "unified cert calendar", "what training is overdue", "cert obligations", "what unlocks higher margins".
**Built for:** Partner Enablement · Partner Operations · Partner Seller
**Workflow:** Enumerate vendor portals → Held · expiring · gating SKUs · tier-promo → Cost of expiry × tier leverage × renewal effort → Action queue · skip list · tier bridges
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-cross-vendor-cert-tracker
description: Use when a partner user wants to see all required, optional, and expiring certifications across every vendor they work with, flagging what's table-stakes, what gates higher-margin SKUs, and what unlocks the next tier per vendor. Trigger phrases include "all my certifications", "what's expiring", "certs across vendors", "unified cert calendar", "what training is overdue", "cert obligations", "what unlocks higher margins".
---
# Cross-Vendor Certification Tracker (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** the partner has access to.
**Use case**: 05, Training (partner-side, multi-vendor).
## When to use this skill
Use when a partner user wants to see all required, optional, and expiring certifications across every vendor they work with, flagging what's table-stakes, what gates higher-margin SKUs, and what unlocks the next tier per vendor.
**Sample prompts that fire this skill:**
- "all my certifications"
- "what's expiring"
- "certs across vendors"
- "unified cert calendar"
- "what training is overdue"
- "cert obligations"
- "what unlocks higher margins"
## Why this matters
Partners working with 5–10 vendors are juggling 20–50 active certifications: table-stakes ones, expiring ones, optional-but-margin-unlocking ones, and the ones that gate the next tier promotion. Each vendor sends its own renewal nudges; nobody sends a unified view. The result is silent expirations that strip the partner of deal-protection eligibility on the next big deal, discovered exactly when it matters most.
This skill closes the gap: one calendar across every vendor, ranked by economic stakes (margin lost on expiry > tier promotion blocker > nice-to-have), with renewal effort estimates so the partner can plan.
## Process
### Step 1: Enumerate vendor portals
- `Introw_Connect_Staging:partners`: get all portals the partner has access to.
### Step 2: Pull cert state per portal
For each `roomId`:
- `Introw_Connect_Staging:get_tier_information`: what certifications each tier requires (held / required / optional).
- `Introw_Connect_Staging:search_partner_engagement`: completed training events, cert achievement records.
- `Introw_Connect_Staging:search_tasks`: any open cert-related tasks.
- `Introw_Connect_Staging:get_goals`: cert-related goals.
### Step 3: Classify per certification
For each cert across all vendors, capture:
- **Status**: held (current), held (expiring soon), expired, in progress, not yet started.
- **Required vs. optional** at the partner's current tier.
- **What it unlocks**: tier-promotion gate, higher-margin SKU access, deal-protection eligibility on specific products, MDF eligibility.
- **Expiration date** if applicable.
- **Renewal effort** (typical hours / re-test / refresher course).
- **Vendor** + portal + relative tier.
### Step 4: Score economic stakes per cert
Rank what's at stake for each cert by:
- **Cost of expiry**: revenue loss if it expires (deal protection lost on in-flight deals, SKU access removed, tier demotion risk).
- **Tier-promotion leverage**: does completing this cert close the gap to the next tier with a vendor where promotion is otherwise close?
- **Renewal urgency**: days to expiry × renewal effort, prioritize close-to-expiry-and-cheap-to-renew over far-off-and-effortful.
- **Strategic vendor weight**: certs with vendors who represent a larger share of partner revenue rank higher.
### Step 5: Generate the calendar
- **This week / month**: certs to act on now (expiring, blocking active deals, near tier promotion).
- **Next 90 days**: scheduled renewals + new certs to start.
- **Strategic (no urgency, high upside)**: certs that would unlock notably higher margins.
- **Optional (skip-eligible)**: certs the vendor surfaces but with low ROI for this partner's motion.
### Step 6: Recommend a study plan
For top-priority certs:
- Estimated time investment.
- Suggested order (renew expiring before starting new).
- Whether the cert can be earned async (course + assessment) or requires a scheduled event.
- Link to start in the relevant vendor portal.
## Output format
- **Cross-vendor cert calendar**: table with vendor, cert name, status, expiration, what-it-unlocks, urgency.
- **Action queue**: top 3–5 certs to tackle this month.
- **Tier-promotion bridges**: certs that would close a tier gap with a specific vendor.
- **Expiring-and-at-risk**: certs expiring in < 30 days with their economic exposure.
- **Skip list**: certs flagged as low-ROI for this partner's actual motion.
## Guardrails & PRM best practice
- **Strictly scoped per portal.** Each vendor's cert data only fetched with that vendor's `roomId`. No cross-portal data leakage.
- **Time-bound everything.** "Expiring soon" without a window is meaningless, always state the date.
- **Don't compare vendors competitively.** It's the partner's view; rank for the partner's attention. But don't frame as "Vendor X has worse training than Vendor Y" in any output that could leak vendor-side.
- **Renewal effort honesty.** If a vendor's renewal is a 3-hour deep cert vs. a 15-min refresher, surface the difference. Partners optimize on time-per-margin-unlocked.
- **Strategic priority over completeness.** Don't push the partner to chase every optional cert; surface the ones with real economic stakes for *their* motion. Cert completion isn't the goal, margin and deal eligibility are.
- **Pair with deal context.** A cert that's "optional" abstractly may be critical if the partner has an in-flight deal that needs it. Cross-check `search_crm_objects` to flag this.
- **Don't auto-enroll.** Recommend, don't enroll. The partner schedules learning around their own bandwidth.
- **Capture intent.** When the partner commits to a cert path, use `add_task` on the relevant vendor portal, feeds the vendor's tier-promotion-batch-review next cycle.
- **Cross-skill handoff.** Cert that gates a tier promotion → flag for `partner-onboarding-prioritizer` (if onboarding) or watch for vendor-side tier review. Cert blocking an in-flight deal → urgent intervention via `partner-helpdesk` or CAM ping.
```
Drop this file into `.claude/skills/partner-cross-vendor-cert-tracker/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Cross-Vendor Content & Activity Calendar
Source: https://docs.introw.io/headless/skills/partner/cross-vendor-content-calendar
Partner skill for a unified calendar of vendor product launches, webinars, MDF programs, campaigns, and tier-promotion windows across every vendor.
*Partner skill for [Use case 07: Campaigns & Announcements](/headless/agentic-use-cases/campaigns-and-announcements).*
**Skill ID:** `partner-cross-vendor-content-calendar`
Use when a partner wants a unified calendar of upcoming product launches, webinars, MDF programs, campaigns, and tier-promotion windows across all the vendors they work with, so they can plan their own outreach, sales motions, and customer communications around vendor activity. Trigger phrases include "what's coming up", "vendor calendar across all my vendors", "upcoming launches", "MDF windows", "what should I plan around", "vendor activity calendar".
**Built for:** Partner Marketing · Partnerships Lead
**Workflow:** Enumerate vendor portals → Launches · MDF windows · webinars · tier reviews → Customer-base fit × motion fit × leverage → Weekly action queue + drafted outreach
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-cross-vendor-content-calendar
description: Use when a partner wants a unified calendar of upcoming product launches, webinars, MDF programs, campaigns, and tier-promotion windows across all the vendors they work with, so they can plan their own outreach, sales motions, and customer communications around vendor activity. Trigger phrases include "what's coming up", "vendor calendar across all my vendors", "upcoming launches", "MDF windows", "what should I plan around", "vendor activity calendar".
---
# Cross-Vendor Content & Activity Calendar (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** the partner has access to.
**Use case**: 07, Campaigns & Announcements (partner-side, multi-vendor).
## When to use this skill
Use when a partner wants a unified calendar of upcoming product launches, webinars, MDF programs, campaigns, and tier-promotion windows across all the vendors they work with, so they can plan their own outreach, sales motions, and customer communications around vendor activity.
**Sample prompts that fire this skill:**
- "what's coming up"
- "vendor calendar across all my vendors"
- "upcoming launches"
- "MDF windows"
- "what should I plan around"
- "vendor activity calendar"
## Why this matters
Every vendor runs its own roadmap of launches, campaigns, MDF cycles, webinars, and incentive programs, and announces them in its own portal, on its own cadence. The partner who could capitalize on a Vendor X launch with their installed base often misses it because they didn't see the announcement until two weeks later. Multiplied across 5–10 vendors, the partner is constantly playing catch-up on vendor activity.
This skill aggregates: every vendor's announced upcoming activity, in one calendar, ranked by what's most leverageable for the partner's actual customer base. Plan outreach around launches; pre-stage campaigns; book SE time before the wave hits.
## Process
### Step 1: Enumerate vendor portals
- `Introw_Connect_Staging:partners`: get all portals.
### Step 2: Pull upcoming activity per portal
For each `roomId`:
- `Introw_Connect_Staging:search_partner_engagement`: recent and upcoming campaign / announcement events the partner has been invited to.
- `Introw_Connect_Staging:search_form_submissions`: open MDF program windows, co-marketing proposals, partner application deadlines.
- `Introw_Connect_Staging:search_tasks`: vendor-assigned tasks with due dates that hint at upcoming activity.
- Knowledge-base content where launch / event metadata is published.
### Step 3: Classify each event
For each upcoming activity across vendors, capture:
- **Type**: product launch, feature release, webinar, certification cohort, MDF window, campaign template release, tier-review window, executive event, training drop.
- **Date / window**.
- **Audience** (which segments / verticals / regions does this apply to).
- **Partner action required** (read-only, register to attend, opt-in, MDF apply, campaign deploy).
- **Economic stake** (related to a SKU the partner sells, a vertical the partner serves, a tier the partner is approaching).
- **Vendor + portal**.
### Step 4: Score relevance to this partner
Rank each event by:
- **Customer-base fit**: does the partner have prospects/customers in segments where this matters?
- **Partner motion fit**: does it apply to what the partner actually sells (avoid noise from products outside the partner's portfolio)?
- **Effort vs. impact**: a MDF window with 1-week deadline + low fit ranks lower than a launch in the partner's strongest vertical.
- **Vendor-relationship leverage**: high-value when it's a vendor where the partner is pacing for a tier promotion or activation.
### Step 5: Build the unified calendar
- **This week**: items that need action now (deadlines, registrations, opt-ins).
- **Next 30 days**: items to plan around, pre-stage outreach, book SE time, queue campaigns.
- **Strategic 30–90 days**: bigger windows worth shaping the partner's quarter around.
- **FYI**: vendor activity not directly leverageable but worth knowing.
### Step 6: Recommend partner moves per high-relevance item
For top-scored events:
- **Outreach plan**: which customers / prospects to contact when, framed around the launch.
- **Campaign queueing**: which assets to use, what segment to send to.
- **MDF application**: drafted proposal aligned to the program.
- **Pre-event prep**: certifications to complete before a launch hits, demos to schedule with vendor SE.
## Output format
- **Calendar across vendors**: table by date with vendor, event, type, action required, fit score.
- **This-week action queue**: anything time-sensitive.
- **30-day plan**: moves the partner should pre-stage now.
- **Strategic windows**: bigger opportunities worth shaping the quarter around.
- **Drafted outreach / MDF apps**: copy-pasteable per top-relevance item.
## Guardrails & PRM best practice
- **Strictly scoped per portal.** Each vendor's calendar data is only fetched with its own `roomId`. No cross-portal leakage in any partner-facing or vendor-facing output.
- **Vendor-confidential roadmap data stays internal.** Some vendor announcements are partner-confidential (e.g., advance notice on a launch). Don't surface those to customer-facing outreach or campaigns until embargo lifts.
- **Don't pre-announce.** If a vendor has shared advance launch info under embargo, the calendar can show it to the partner, but the partner's drafted customer outreach must respect the embargo date.
- **Relevance discipline.** Surface 5–10 high-fit events per cycle, not 50 generic vendor events. Generic feeds train the partner to ignore the calendar.
- **Honor capacity.** A partner can't action 12 launches in 2 weeks. Recommend a focused 3–5 priority moves; the rest is FYI.
- **Match to actual customer base.** If the partner's customer base skews mid-market services, an enterprise launch is FYI not action. Use deal/customer signals (`search_crm_objects`) to ground relevance.
- **Don't auto-deploy campaigns.** Campaign queueing means drafted + ready-for-review, not pushed to customers automatically.
- **Capture commitments.** When the partner commits to apply for MDF or attend an event, log via `add_task` on the relevant vendor portal.
- **Run on cadence.** Weekly default. Daily during heavy launch periods.
- **Cross-skill handoff.** Outreach plan → individual customer-level coaching via `partner-deal-war-room`. Cert pre-reqs for upcoming launches → `partner-cross-vendor-cert-tracker`. MDF program windows → drafted apps stay with this skill until applied.
```
Drop this file into `.claude/skills/partner-cross-vendor-content-calendar/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Cross-Vendor Onboarding Tracker
Source: https://docs.introw.io/headless/skills/partner/cross-vendor-onboarding-tracker
Partner skill giving a single aggregated view of onboarding progress, open tasks, milestones, and time-to-first-deal across every vendor portal at once.
*Partner skill for [Use case 03: Onboarding](/headless/agentic-use-cases/onboarding).*
**Skill ID:** `partner-cross-vendor-onboarding-tracker`
Use when a partner user is being onboarded by multiple vendors and wants a single aggregated view of progress, open tasks, milestones, and time-to-first-deal across every vendor portal they have access to. Trigger phrases include "onboarding status across vendors", "where am I with each vendor", "all my onboardings", "cross-vendor onboarding progress", "what do I owe each vendor", "vendor onboarding scoreboard".
**Built for:** Partnerships Lead · Partner Operations · Partner Seller
**Workflow:** Enumerate vendor portals → Tasks · goals · engagement · first-deal status → % complete · 90-day cliff · risk · unlocks → Cross-vendor view + next-move recos
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-cross-vendor-onboarding-tracker
description: Use when a partner user is being onboarded by multiple vendors and wants a single aggregated view of progress, open tasks, milestones, and time-to-first-deal across every vendor portal they have access to. Trigger phrases include "onboarding status across vendors", "where am I with each vendor", "all my onboardings", "cross-vendor onboarding progress", "what do I owe each vendor", "vendor onboarding scoreboard".
---
# Cross-Vendor Onboarding Tracker (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** the user has access to.
**Use case**: 03, Onboarding (partner-side, multi-vendor aggregation).
## When to use this skill
Use when a partner user is being onboarded by multiple vendors and wants a single aggregated view of progress, open tasks, milestones, and time-to-first-deal across every vendor portal they have access to.
**Sample prompts that fire this skill:**
- "onboarding status across vendors"
- "where am I with each vendor"
- "all my onboardings"
- "cross-vendor onboarding progress"
- "what do I owe each vendor"
- "vendor onboarding scoreboard"
## Why this matters
A typical reseller / SI / MSP is being onboarded by 3–10 vendors at any given time. Each vendor has its own portal, its own checklist, its own CAM, its own "what's next" framing. The partner has zero unified view, and the natural result is that *some* of those onboardings stall (often the most economically valuable one), because the partner just runs out of attention. This skill solves that by aggregating across portals: one screen, all open onboardings, ranked by what to do next.
Partners who close their first deal within 90 days are **3–4× more likely** to remain active (Unifyr Channel Atlas): applying that benchmark across multiple vendors compounds the cost of attention drift.
## Process
### Step 1: Enumerate portals
- Call `Introw_Connect_Staging:partners` to get the full list of portals this user has access to. Capture `roomId`, vendor name, partner record ID per portal.
- If the user is in just one portal, this skill still works, but the value is highest with 2+.
### Step 2: Pull onboarding state per portal
For each `roomId`, in parallel where possible:
- `Introw_Connect_Staging:search_tasks` (with that `roomId`): open and recently completed onboarding tasks.
- `Introw_Connect_Staging:get_goals`: onboarding-stage goals and progress.
- `Introw_Connect_Staging:search_partner_engagement`: recent activity + the cadence vs. the partner's baseline with that vendor.
- `Introw_Connect_Staging:search_form_submissions`: first-deal registration if any.
- `Introw_Connect_Staging:search_crm_objects`: first deal in pipeline if any.
- `Introw_Connect_Staging:get_tier_information`: what onboarding completion unlocks for this vendor.
### Step 3: Compute per-vendor onboarding state
For each vendor:
- **% complete** (tasks done / tasks total).
- **Days since onboarding start.**
- **Days to 90-day cliff** (the activation window).
- **First deal status**: not yet, in pipeline, registered, closed.
- **Top blockers**: tasks overdue, missing certifications, missing assets/contacts.
- **What unlocks next**: deal protection, MDF eligibility, tier benefits, dedicated PDM access.
- **Risk flag**: stalled (engagement decay + missed milestones), at-risk (slipping), on track, near activation.
### Step 4: Rank for partner attention
Surface vendors in priority order based on:
- **Urgency**: closeness to the 90-day cliff (first-deal window).
- **Economic upside**: tier benefits at completion (margin uplift, MDF access).
- **Sunk effort**: how far in already (don't waste 60% complete onboardings).
- **Effort to next unlock**: a vendor 1 task from a tier promotion is high-ROI vs. one with 8 tasks remaining.
The partner sees a clear "do this next, then this, then this" recommendation across the whole onboarding portfolio.
## Output format
- **Cross-vendor onboarding scoreboard**: table with vendor, % complete, days-in, first-deal status, top blocker, next unlock, risk flag.
- **Today's recommended actions**: top 3 highest-ROI moves, each tagged with which vendor and which `roomId`.
- **At-risk callouts**: any vendor onboarding where the 90-day cliff is approaching without first-deal traction.
- **Stalled escalation suggestions**: where to ping the CAM (with drafted message) to unstick.
## Guardrails & PRM best practice
- **Strictly scoped per portal.** Each portal's data is fetched only with that portal's `roomId`: no cross-portal data leakage.
- **Don't compare vendors competitively to each other in the output.** It's the partner's view; it's fine to rank for attention. But framing like "Vendor X is treating you better than Vendor Y" is messy and risks leaking into vendor-facing comms.
- **Time-bound every signal.** "Stalled" without a window is meaningless; always state the days since last activity.
- **Honor stated constraints.** If the partner has already told a specific vendor they're slow this quarter, don't re-flag the same delay as "at risk", capture context once via `add_comment` to that portal.
- **Action over commentary.** Every flag carries a next-best move. Don't list problems without prescriptions.
- **First-deal gravity.** Across all vendors, prioritize first-deal motion in vendors past day 60, that's where the economics flip.
- **Capture the loop.** When the partner takes a recommended action, log via `Introw_Connect_Staging:add_comment` on the relevant portal so the next run sees the progression.
- **Cross-skill handoff.** Decision-style "where do I focus today?" → `partner-onboarding-prioritizer`. Stuck onboarding → `partner-helpdesk` to find the answer or escalate. First-deal motion → `partner-register-deal` (if installed) or `partner-deal-war-room`.
```
Drop this file into `.claude/skills/partner-cross-vendor-onboarding-tracker/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Deal War Room
Source: https://docs.introw.io/headless/skills/partner/deal-war-room
Partner skill delivering a deal-specific coaching packet with vendor playbooks, past wins, competitive battle cards, and next moves pulled live from the CRM.
*Partner skill for [Use case 11: Deal Coaching](/headless/agentic-use-cases/deal-coaching).*
**Skill ID:** `partner-deal-war-room`
Use when a partner seller is working a specific deal and wants a comprehensive coaching packet, vendor playbook for the stage, similar past wins, competitive battle cards, reference customers, objection handling, suggested next moves, pulled live from the relevant vendor portal(s). The partner-side counterpart to the vendor's deal-coaching skills. Trigger phrases include "war room for this deal", "coach me on \[deal]", "what do I do next on \[account]", "how have we won deals like this", "objection handling for \[deal]", "competitive position on \[deal]", "draft the next message".
**Built for:** Partner Seller
**Workflow:** The partner's deal in flight → Vendor playbook · battle cards · similar wins · calls → Top 3 moves · objection lines · drafted message → Captured to deal + tracked
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-deal-war-room
description: Use when a partner seller is working a specific deal and wants a comprehensive coaching packet, vendor playbook for the stage, similar past wins, competitive battle cards, reference customers, objection handling, suggested next moves, pulled live from the relevant vendor portal(s). The partner-side counterpart to the vendor's deal-coaching skills. Trigger phrases include "war room for this deal", "coach me on [deal]", "what do I do next on [account]", "how have we won deals like this", "objection handling for [deal]", "competitive position on [deal]", "draft the next message".
---
# Deal War Room (Partner)
**Audience**: Partner seller, uses **claude.ai Introw Connect Staging** MCP. Operates per-portal (one vendor at a time, or across both vendors in a multi-vendor deal).
**Use case**: 11, Deal Coaching (partner-side; companion to vendor `vendor-deal-coach-from-similar-wins`).
## When to use this skill
Use when a partner seller is working a specific deal and wants a comprehensive coaching packet, vendor playbook for the stage, similar past wins, competitive battle cards, reference customers, objection handling, suggested next moves, pulled live from the relevant vendor portal(s). The partner-side counterpart to the vendor's deal-coaching skills.
**Sample prompts that fire this skill:**
- "war room for this deal"
- "coach me on [deal]"
- "what do I do next on [account]"
- "how have we won deals like this"
- "objection handling for [deal]"
- "competitive position on [deal]"
- "draft the next message"
## Why this matters
Direct sales reps get coaching weekly; partner sellers usually get a portal full of PDFs and a quarterly QBR. AI deal coaching closes that gap, but only if the coaching is **immediate, specific, and grounded in the partner's own deal context**, not generic playbook quotes.
This skill is the partner's in-deal war room: the seller pulls up the deal, asks "what's the move?", and gets stage-aware guidance, similar wins to model on, the right battle card, the right reference customer, and a drafted next-message, all in seconds. Industry research: AI coaching produces **34% win-rate lift within six months** (Whatfix); coached reps navigate objections **61% more effectively** (Careertrainer.ai). Extending that to partner sellers is the unlock the channel motion has been missing.
## Process
### Step 1: Resolve the portal(s)
- `Introw_Connect_Staging:partners`: confirm which vendor portal(s) the deal involves. Most deals are single-vendor; some (multi-product / SI motions) span 2+.
- If multi-vendor, run the war room independently per portal and synthesize.
### Step 2: Pull the active deal context
- `Introw_Connect_Staging:search_crm_objects`: full deal record: stage, value, products, contacts, last activity, close date, competitor mentions, recent comments, stalled flag.
- `Introw_Connect_Staging:search_partner_engagement`: partner's own activity on this deal.
- `Introw_Connect_Staging:search_tasks`: open tasks tied to the deal.
### Step 3: Use the dedicated coaching tool first
`Introw_Connect_Staging:deal_coaching` is purpose-built, pass the deal context. It returns persona-aware guidance grounded in the vendor's playbook. Treat its output as the foundation; the rest of this skill enriches it.
### Step 4: Find similar past wins (partner's own)
- `Introw_Connect_Staging:search_crm_objects`: partner's own closed-won deals in the trailing 12 months, filter to similar vertical / deal size / product / customer segment.
- Aim for 3–7 high-similarity wins. If thin, surface the caveat, fabricated patterns are worse than honest absence.
- For each: how long in stage, what worked, what objections came up, which assets / case studies / reference customers were used.
### Step 5: Pull the right vendor assets
For the deal's product / vertical / competitive context, identify (from the vendor's connected knowledge base):
- **Battle cards** for any competitor named.
- **Case studies** in the prospect's vertical / segment.
- **Reference customers** the partner can name-drop or arrange a call with.
- **Pricing / packaging guidance**: including deal-protection eligibility (10–15 pts margin reminder).
- **Compliance attestations** (SOC 2, HIPAA, GDPR) if vertical-relevant.
### Step 6: Surface stage-aware next moves
Based on stage, deal age, and similar-win patterns, prescribe:
- **Top 3 next actions**: concrete moves with rationale, ranked by impact.
- **Champion / power assessment**: is there an executive sponsor? If not, the gap.
- **Drafted message** for the most important next outreach (email / Slack / LinkedIn): copy-pasteable.
- **Risk flags**: patterns from comparable lost-or-stalled deals to actively avoid.
- **Realistic close timeline**: based on comparables, not stated.
### Step 7: Capture and queue
- `Introw_Connect_Staging:add_comment` on the deal, log the war-room session so the vendor's PDM can see the coaching trail at next QBR.
- `Introw_Connect_Staging:add_task`: convert top 3 next actions into trackable tasks with due dates.
- For stuck deals where the partner needs vendor help (technical Q, exec sponsorship, pricing exception): draft the CAM/PDM ask.
## Output format
- **Deal snapshot** (2 lines).
- **Vendor's coaching baseline** (from `deal_coaching` tool).
- **Similar past wins**: 3–7 with similarity rationale + what worked.
- **Vendor assets to use**: battle cards, case studies, reference customers (named + linked).
- **Top 3 next actions** with ETA + rationale.
- **Drafted next message**: copy-pasteable, persona-tuned.
- **Risk flags**: what to avoid based on comparable losses.
- **Logged artifacts**: comment ID + task IDs created.
## Guardrails & PRM best practice
- **Partner-side scope.** Only the partner's own deals + vendor-shared content. Never reference other partners' deals.
- **Don't push off-strategy.** Stay aligned to the vendor's playbook (pricing, ICP, positioning). Coaching that contradicts the vendor's strategy damages the co-sell motion.
- **Persona match is non-negotiable.** Coaching an SI motion like a transactional reseller motion breaks both the deal and the relationship. The `deal_coaching` tool handles this, reinforce it, don't override it.
- **Honest signal density.** If similar wins are thin (< 3), say so. Don't extrapolate from 1 comparable as if it were a pattern.
- **Don't draft customer-facing content the seller hasn't seen.** Drafts are starting points; the seller tailors before sending.
- **Reference customers require permission.** Don't recommend name-dropping a reference customer without checking the vendor has cleared them for partner use in this segment.
- **Capture the coaching.** Every war-room session logs to the deal via `add_comment` so the trail survives.
- **Margin discipline.** When suggesting concession paths, surface the deal-protection margin (10–15 pts) the partner already earns by registering, concessions come out of *that* envelope, not on top of it.
- **Multi-vendor deals.** If two vendors are involved, run the war room per portal and surface both views. Don't blend; let the seller see each vendor's playbook.
- **Cross-skill handoff.** Net-new prospect not yet registered → `partner-register-deal` (if installed). Stuck on champion / power gap and need vendor exec engagement → draft the CAM ask. Multi-vendor opportunity → check `partner-prospect-to-vendor-fit-finder` for sequencing.
```
Drop this file into `.claude/skills/partner-deal-war-room/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Drip Campaign from Assets
Source: https://docs.introw.io/headless/skills/partner/drip-campaign-from-assets
Partner skill turning a vendor campaign kit into a scheduled drip in Mailchimp or HubSpot, with co-branding and partner-attribution links applied automatically.
*Partner skill for [Through-Channel Marketing](/headless/agentic-use-cases/through-channel-marketing).*
**Skill ID:** `partner-drip-campaign-from-assets`
Use when a partner wants to turn a vendor's campaign kit into a scheduled drip campaign in their own email tool (Mailchimp, HubSpot, etc.), with co-branding and partner-attribution links applied automatically. Trigger phrases include "build a drip campaign", "schedule this in Mailchimp", "turn this kit into emails", "set up a nurture sequence", "launch this campaign in HubSpot", "automate this campaign".
**Built for:** Partner - Sales & Marketing · Partner Operations
**Workflow:** Pull vendor kit → Co-brand + insert attribution links → Build sequence → Schedule in the partner's own tool
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-drip-campaign-from-assets
description: Use when a partner wants to turn a vendor's campaign kit into a scheduled drip campaign in their own email tool (Mailchimp, HubSpot, etc.), with co-branding and partner-attribution links applied automatically. Trigger phrases include "build a drip campaign", "schedule this in Mailchimp", "turn this kit into emails", "set up a nurture sequence", "launch this campaign in HubSpot", "automate this campaign".
---
# Drip Campaign from Assets (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP (+ the partner's own email-tool MCP: Mailchimp, HubSpot, etc.).
**Use case**: Through-Channel Marketing (TCMA), partner-side.
## When to use this skill
Use when a partner wants to launch a vendor campaign in the marketing tool they already run, turning a vendor campaign kit into a scheduled, co-branded, attributed drip sequence, without rebuilding anything in a vendor portal.
**Sample prompts that fire this skill:**
- "build a drip campaign from this kit"
- "schedule this in Mailchimp"
- "turn this kit into emails"
- "set up a nurture sequence for this vendor's campaign"
- "launch this campaign in HubSpot"
- "automate this campaign to my list"
## Why this matters
The partner already has the audience, the domain, and the sending tool. What they lack is the on-message content and the time to assemble it. Pulling a vendor's ready-made kit and assembling it into a scheduled drip in the partner's own tool means the partner launches in minutes, in their own voice, while the vendor still gets full attribution on every click and conversion. This is exactly the friction removal that lifts through-channel adoption past **60%**.
## Prerequisites
- The partner has an email / marketing tool with an MCP or API the assistant can reach (Mailchimp, HubSpot, etc.).
- The partner's audience / list exists in that tool.
- The partner's branding is captured with the vendor (for co-branded assets).
## Process
### Step 1: Pull the vendor campaign kit
- `Introw_Connect_Staging:partners`: identify the vendor portal.
- Fetch the campaign kit for that `roomId`: email templates, narrative, positioning, co-branded collateral, and the campaign's attribution links / form.
### Step 2: Co-brand and insert attribution
- Ensure the co-branded collateral carries the partner's branding (hand off to `partner-cobrand-my-collateral` if needed).
- Insert the **partner-attributed affiliate links and form** into every email so all resulting clicks and conversions attribute back to the partner. Never strip or replace the attribution links; that breaks the vendor's tracking and the partner's credit.
### Step 3: Build the sequence
- Map the kit's email templates into a drip sequence: order, send delays, and audience segment.
- Adapt tone to the partner's voice while preserving the vendor's approved claims and positioning.
### Step 4: Schedule in the partner's own tool
- Create the campaign / sequence in the partner's email tool via its MCP (Mailchimp, HubSpot, etc.): create the emails, set the schedule, and assign the target list/segment.
- Leave the campaign in **draft / scheduled-pending-review** state, and do not auto-send.
### Step 5: Confirm and log
- Summarize the scheduled sequence for the partner to review and activate.
- `Introw_Connect_Staging:add_task` on the vendor portal to log that the campaign was launched, so the activity is visible to the vendor.
## Output format
- **Sequence plan**: each email, send delay, and target segment.
- **Attribution check**: confirmation that partner-attributed links / form are in every email.
- **Tool setup**: what was created in the partner's email tool and its current state (draft / scheduled).
- **Review checklist**: what the partner should confirm before activating.
## Guardrails & PRM best practice
- **Never send automatically.** The skill ends at a scheduled/draft campaign the partner reviews and activates.
- **Preserve attribution.** Attribution links and forms must be present in every email; this is how the partner gets credited and paid.
- **Respect the vendor's claims.** Adapt voice, not substance; don't alter approved product claims, pricing, or compliance language.
- **Strictly scoped per portal.** Kit data is fetched only with the owning vendor's `roomId`. No cross-portal leakage.
- **Consent and compliance.** Only send to lists the partner is permitted to email; honor opt-out and regional consent (GDPR/CAN-SPAM) rules.
- **Use current assets.** Pull the latest kit version; don't reuse stale local copies.
- **Cross-skill handoff.** Co-brand collateral via `partner-cobrand-my-collateral`; plan which campaigns to run and when via `partner-cross-vendor-content-calendar`.
```
Drop this file into `.claude/skills/partner-drip-campaign-from-assets/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Partner Helpdesk
Source: https://docs.introw.io/headless/skills/partner/helpdesk
Partner helpdesk skill for asking a vendor product, pricing, configuration, or compliance question, or running scoped self-service actions without the portal.
*Partner skill for [Use case 06: Enablement Support](/headless/agentic-use-cases/enablement-support).*
**Skill ID:** `partner-helpdesk`
Use when a partner user needs to ask a product, pricing, configuration, enablement, or compliance question to a specific vendor, or wants to execute a scoped self-service action (sandbox provisioning, account lookup, quote draft): without opening the vendor's portal. Single-vendor scope per invocation. Trigger phrases include "ask vendor X about Y", "what's the price for…", "where's the battle card for…", "spin up a sandbox", "look up account…", general partner-side product Q\&A.
**Built for:** Partner Seller · Partner Operations
**Workflow:** Partner asks in their flow → Knowledge · lookup · scoped action → KB · CRM · capability matrix → Cited answer · scoped action · audit log
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-helpdesk
description: Use when a partner user needs to ask a product, pricing, configuration, enablement, or compliance question to a specific vendor, or wants to execute a scoped self-service action (sandbox provisioning, account lookup, quote draft): without opening the vendor's portal. Single-vendor scope per invocation. Trigger phrases include "ask vendor X about Y", "what's the price for…", "where's the battle card for…", "spin up a sandbox", "look up account…", general partner-side product Q&A.
---
# Partner Helpdesk (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP. Operates on a **single vendor portal at a time** (the partner picks or the agent confirms).
**Use case**: 06, Enablement Support.
## When to use this skill
Use when a partner user needs to ask a product, pricing, configuration, enablement, or compliance question to a specific vendor, or wants to execute a scoped self-service action (sandbox provisioning, account lookup, quote draft): without opening the vendor's portal. Single-vendor scope per invocation.
**Sample prompts that fire this skill:**
- "ask vendor X about Y"
- "what's the price for…"
- "where's the battle card for…"
- "spin up a sandbox"
- "look up account…"
## Why this matters
Traditional partner-vendor support runs on 15-minute-to-multi-hour first-response times, often **36 hours from question to answer** when escalations are involved. AI partner helpdesks deflect **40–60% of routine queries** (Gartner / Pylon benchmarks), with first response collapsing to **23 seconds, a 97% reduction**. For partner sellers who are mid-deal and need an answer right now, this is the difference between closing the deal and losing momentum.
This skill is the partner's in-flow helpdesk: ask anything in natural language, get the answer from the vendor's connected content base, with proper citation and a clear handoff path when the question is out of scope.
## Process
### Step 1: Resolve the vendor portal
- If the partner has access to multiple vendor portals, call `Introw_Connect_Staging:partners` and confirm which vendor this question is about. **One vendor per invocation**: don't blend answers across vendors.
- If only one portal, proceed.
### Step 2: Triage the query type
Classify the question:
- **Knowledge** (product, pricing, how-to, battle card, enablement, compliance) → answer from connected knowledge sources, with citation.
- **Account / deal lookup** → use `Introw_Connect_Staging:search_crm_objects` (scoped to partner's data).
- **Task / commitment** → use `Introw_Connect_Staging:search_tasks`.
- **Commission / payment status** → out of scope for this skill; suggest `partner-my-commissions` (if installed) or escalate to CAM.
- **Action request** (sandbox, quote, registration) → use the appropriate write tool **only if scoped under the vendor's capability matrix**; otherwise route for human approval.
### Step 3: Answer or act
- For **knowledge questions**: pull from the vendor's connected knowledge base (Notion, Confluence, asset library, product docs). Cite which doc / battle card / pricing rule the answer came from. If the answer is partial or stale, say so honestly.
- For **lookups**: query Introw Connect (CRM objects, tasks, form submissions). Return the data scoped to the partner's permissions.
- For **scoped actions**:
- In-scope auto-actions (per the vendor's capability matrix): account lookup, quote draft, sandbox request submission, deal registration via `share_lead_or_register_deal`. Echo the captured fields back for confirmation before executing any write.
- Approval-gated actions (pricing exception, MDF release, contract change, partner-tier change): do NOT execute. Draft the request and route via `add_task` to the right CAM / approver.
- For **out-of-capability requests**: say so plainly. Don't improvise outside the matrix.
### Step 4: Always offer a follow-up path
- "If this doesn't fully answer, I can route this to your CAM", and if accepted, use `Introw_Connect_Staging:add_task` or `add_comment` to log the request with the vendor.
- If the answer was knowledge-based, surface where the partner can find it next time (the actual portal location).
## Output format
- **Direct answer** in the partner's preferred language, with source citation when knowledge-backed.
- **Action confirmation** (with reference ID) when an action was executed.
- **Clear handoff message** when the query is approval-gated and routed to a human.
- **Follow-up suggestion**: "want me to set a task for your CAM to follow up?"
## Guardrails & PRM best practice
- **Single-vendor scope per invocation.** This skill never aggregates answers across vendors. Each session targets one portal, confirmed at the start. Multi-vendor questions go to a different skill (or a CAM).
- **Strict data scoping.** Show only the data the partner is entitled to see in their portal. Never expose other partners' deals, vendor-internal pricing rules, or cross-customer data.
- **Capability matrix is the contract.** Anything outside the matrix is routed, not improvised. "Outside the matrix" answers should always include the alternate path (CAM, approval form, etc.).
- **Compliance.** Customer PII, pricing exceptions, and contract terms stay human-approved unless explicitly scoped under SOC 2 / ISO 27001 / GDPR controls.
- **Multilingual.** Answer in the partner's language even if source content is in English. If translation introduces ambiguity, link to the source.
- **Cite sources.** Knowledge answers always reference which battle card / doc / pricing page they came from. Opacity erodes trust faster than not knowing.
- **Honest about gaps.** If the answer isn't in the connected knowledge base, say so, don't fabricate. Surface as a content gap (feeds `vendor-support-content-gap-detector` next cycle).
- **Don't write without confirmation.** Any write action (registration, sandbox request, etc.) echoes the captured fields back for confirmation before calling the write tool.
- **Log for the loop.** Use `add_comment` on the relevant record to capture the question and resolution. Feeds the vendor's deflection audit and improves the knowledge base over time.
- **Cross-skill handoff.** Deal-related coaching question → `partner-deal-war-room`. Cert / training question → `partner-cross-vendor-cert-tracker`. Commission-status → out-of-scope, refer to commission-specific skill or finance contact.
```
Drop this file into `.claude/skills/partner-helpdesk/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Incentive Maximizer
Source: https://docs.introw.io/headless/skills/partner/incentive-maximizer
Partner skill showing exactly which actions to take this quarter to maximize commission earnings, hit the next bonus tier, and unlock accelerators.
*Partner skill for [Use case 13: Commissions & Incentives](/headless/agentic-use-cases/commissions-and-incentives).*
**Skill ID:** `partner-incentive-maximizer`
Use when a partner user wants to know exactly which actions to take this quarter to maximize commission earnings, hit the next bonus tier, or unlock the next accelerator. Pulls live goals, commissions, and pacing data, then prescribes specific high-leverage moves. Trigger phrases include "how do I maximize my earnings", "what should I focus on this quarter", "how close to the bonus", "next tier unlock", "incentive plan for me", "where's the easiest commission left".
**Built for:** Partner Seller · Partner Finance
**Workflow:** Goals · commissions · pacing · open deals → Per plausible action · in € or % → Impact × probability ÷ effort → Concrete actions · drafted asks · unblocks
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-incentive-maximizer
description: Use when a partner user wants to know exactly which actions to take this quarter to maximize commission earnings, hit the next bonus tier, or unlock the next accelerator. Pulls live goals, commissions, and pacing data, then prescribes specific high-leverage moves. Trigger phrases include "how do I maximize my earnings", "what should I focus on this quarter", "how close to the bonus", "next tier unlock", "incentive plan for me", "where's the easiest commission left".
---
# Incentive Maximizer (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP.
**Use case**: 13, Commissions & Incentives.
## When to use this skill
Use when a partner user wants to know exactly which actions to take this quarter to maximize commission earnings, hit the next bonus tier, or unlock the next accelerator. Pulls live goals, commissions, and pacing data, then prescribes specific high-leverage moves.
**Sample prompts that fire this skill:**
- "how do I maximize my earnings"
- "what should I focus on this quarter"
- "how close to the bonus"
- "next tier unlock"
- "incentive plan for me"
- "where's the easiest commission left"
## Why this matters
Most partner programs publish their commission and tier rules and assume partners optimize behavior accordingly. They don't, partners are running their own businesses, juggling multiple vendors, and often don't have time to model "what would maximize my earnings with Vendor X this quarter." The result: partners leave money on the table, and the vendor's incentive design under-performs.
This skill closes the gap by doing the math the partner would do if they had time: where's the closest threshold, what activity moves the needle, and what specific deals or plays would unlock the next chunk of earnings. **Transparency multiplied by prescription**: the partner-side companion to the vendor's commission analytics.
## Process
### Step 1: Resolve the portal
If the partner has access to multiple vendor portals, call `Introw_Connect_Staging:partners` first to get available portals. Confirm which `roomId` to use.
### Step 2: Pull the partner's full incentive context
- `Introw_Connect_Staging:get_tier_information`: current tier, all tier definitions, what each unlocks (margin %, MDF, deal protection, accelerator multipliers).
- `Introw_Connect_Staging:get_goals`: committed goals, targets, progress, time remaining in the period.
- `Introw_Connect_Staging:search_commissions`: paid, accrued, pending; commission rate currently in effect.
- `Introw_Connect_Staging:search_crm_objects`: open deals (stage, value, close date, products): these are the candidates for moving the needle.
- `Introw_Connect_Staging:search_form_submissions`: recent registration cadence.
### Step 3: Compute earnings-impact per next-step action
For each plausible action the partner could take, estimate the marginal earnings impact:
- **Close deal X already in pipeline**: value × commission rate × tier multiplier. Sort open deals by EV (probability × value × marginal commission impact).
- **Register N more deals before period end**: for partners with a registration-volume bonus.
- **Hit the next tier threshold**: gap to next tier × what the next tier unlocks (if Gold gives 5 pts more margin on all subsequent business, that's a multi-quarter unlock, not just this quarter).
- **Hit a goal threshold**: for partners pacing close to a goal that triggers a bonus.
- **Activate a SPIF / accelerator**: currently active SPIFs and what they require (e.g., "+10% on healthcare deals over €50K closed before quarter-end").
- **Complete a certification that gates a higher-margin product**: for partners blocked from a higher-margin SKU by a missing cert.
### Step 4: Identify the highest-leverage moves
Rank the actions by:
- **Earnings impact**: actual € or % uplift.
- **Probability**: how achievable in the time remaining? (A deal at Stage 4 with 30 days left is high; a deal at Stage 1 is wishful.)
- **Effort**: relative effort vs. the partner's normal motion. (Closing a deal already in late stages is low-effort; recruiting a new logo from scratch is high.)
Score each action: impact × probability ÷ effort. Top 3–5 surface as the recommendation.
### Step 5: Frame for action
Each recommendation includes:
- **The action** in concrete terms ("Close deal Globex by 30 March, currently at Stage 4, est. €120K").
- **The earnings impact** ("Adds €18K to your Q3 commission at your current rate; pushes you across the €500K threshold for Gold-tier eligibility next review").
- **Why it's leverageable** ("This deal is in the segment where your historical win rate is 65%; same partner closed a similar one last quarter").
- **What you need to unblock it** (link to deal-coaching skill if stuck, link to register-deal skill if not yet registered, link to CAM if executive engagement needed).
### Step 6: Surface the dashboard view
Provide a single-glance summary:
- **Current period earnings**: paid / accrued / projected.
- **Distance to next tier**: revenue gap, certs gap, time remaining.
- **Distance to next bonus / accelerator threshold**.
- **Active SPIFs you're eligible for**: list with requirements.
- **Top 3 next moves** ranked.
## Output format
- **Earnings dashboard** (current + projected + thresholds).
- **Top 3 recommendations** with concrete actions, impact, and unblock paths.
- **Active SPIFs / accelerators** the partner is eligible for, with requirements.
- **Certification gaps** that gate higher-margin products.
- **Direct links** to the relevant follow-up actions (deal coaching, registration, CAM call).
## Guardrails & PRM best practice
- **Strict scope.** Only this partner's data, never reference other partners' commissions, deals, or rates.
- **Don't promise outcomes.** Projections are estimates based on current pacing and stated probabilities. Always frame as "if you close deal X by date Y, this is the impact", not "you will earn €Z."
- **Vendor rules are vendor rules.** Don't speculate about commission rate changes or tier eligibility being lowered. Refer rate questions to the partner's CAM.
- **Surface, don't pressure.** The skill prescribes; the partner decides their priorities. Vendor-side incentives shouldn't override the partner's strategic considerations.
- **Be honest about probability.** Suggesting a partner can close 5 stage-1 deals in 14 days to hit a threshold isn't realistic, flag low-probability paths as low-probability.
- **Multi-vendor reality.** The partner has other vendors competing for their attention. Recommendations should be honest about effort, high-effort recommendations need real impact to be worth it.
- **No self-dealing.** Don't recommend actions that benefit only the vendor (e.g., "register deals you're not really pursuing to hit volume thresholds"). Recommendations should be in the partner's actual interest.
- **Capture the conversation.** If the partner takes one of the recommended actions (close X, register Y), use `Introw_Connect_Staging:add_comment` on the relevant record to log the connection, gives the vendor's team context for the next QBR.
- **Refresh frequency.** Quarterly is too slow, monthly check-ins are more useful in the back half of a quarter when small moves still matter. Weekly in the final 30 days of a quarter for partners close to a threshold.
- **Cross-skill handoff.** Stuck deals → `partner-coach-my-deal`. Net-new registrations → `partner-register-deal`. Tier/goal status check-in → `partner-my-tier-and-goals` (if installed). Commission status → `partner-my-commissions` (if installed).
```
Drop this file into `.claude/skills/partner-incentive-maximizer/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Onboarding Prioritizer
Source: https://docs.introw.io/headless/skills/partner/onboarding-prioritizer
Partner skill deciding which vendor onboarding to advance today or this week based on commitment dates, economic upside, sunk effort, and current bottlenecks.
*Partner skill for [Use case 03: Onboarding](/headless/agentic-use-cases/onboarding).*
**Skill ID:** `partner-onboarding-prioritizer`
Use when a partner is being onboarded by multiple vendors and wants a focused decision on *which onboarding to advance today / this week*, based on commitment dates, economic upside, sunk effort, and current bottleneck. Companion to the cross-vendor onboarding tracker, this one is decision-mode, not status-mode. Trigger phrases include "which onboarding should I focus on", "where should I spend my time", "prioritize my onboardings", "what's highest ROI today", "next move across all my onboardings".
**Built for:** Partnerships Lead · Partner Operations
**Workflow:** Filter to in-flight only → Urgency × upside × sunk effort × momentum → Marginal value per hour spent → Top 1–3 moves with effort + payoff
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-onboarding-prioritizer
description: Use when a partner is being onboarded by multiple vendors and wants a focused decision on *which onboarding to advance today / this week*, based on commitment dates, economic upside, sunk effort, and current bottleneck. Companion to the cross-vendor onboarding tracker, this one is decision-mode, not status-mode. Trigger phrases include "which onboarding should I focus on", "where should I spend my time", "prioritize my onboardings", "what's highest ROI today", "next move across all my onboardings".
---
# Onboarding Prioritizer (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** with active onboardings.
**Use case**: 03, Onboarding (partner-side, multi-vendor decision support).
## When to use this skill
Use when a partner is being onboarded by multiple vendors and wants a focused decision on *which onboarding to advance today / this week*, based on commitment dates, economic upside, sunk effort, and current bottleneck. Companion to the cross-vendor onboarding tracker, this one is decision-mode, not status-mode.
**Sample prompts that fire this skill:**
- "which onboarding should I focus on"
- "where should I spend my time"
- "prioritize my onboardings"
- "what's highest ROI today"
- "next move across all my onboardings"
## Why this matters
The cross-vendor onboarding tracker (`partner-cross-vendor-onboarding-tracker`) gives the *status*, what's where with each vendor. This skill answers the harder question: **given that I have 90 minutes today and three open onboardings, which one do I touch first?** Most partners answer by gut. The wrong choice silently kills the most valuable onboarding.
The cost of attention drift on the highest-economic-upside onboarding is non-recoverable: the 90-day first-deal window closes, the partner-side enthusiasm wears off, the relationship drifts into the dormant 80%. This skill prevents that by ranking onboardings by **return-on-next-action**, not by completion percentage.
## Process
### Step 1: Enumerate active onboardings
- `Introw_Connect_Staging:partners`: get all portals.
- For each portal, determine if onboarding is active (lifecycle stage = onboarding, or first-deal not yet registered, or onboarding tasks still open).
- Filter to onboardings actively in flight; skip ones already activated or aged out.
### Step 2: Pull decision inputs per portal
Per active onboarding:
- `Introw_Connect_Staging:search_tasks`: open tasks + their due dates + the next milestone.
- `Introw_Connect_Staging:get_goals`: any onboarding-stage goals + pacing.
- `Introw_Connect_Staging:search_partner_engagement`: recent activity (signal of momentum vs. drift).
- `Introw_Connect_Staging:get_tier_information`: what completing onboarding unlocks (margin, MDF, deal protection, dedicated PDM).
- `Introw_Connect_Staging:search_crm_objects`: first deal status (in pipeline / not yet).
### Step 3: Score each onboarding on the prioritization axes
- **Urgency**: days remaining to the 90-day cliff. Closer = higher priority.
- **Economic upside at activation**: tier benefits unlock value (margin uplift × expected pipeline volume in this vendor's segment for the partner).
- **Sunk effort**: how far in already (don't waste 60% complete onboardings, but don't keep pushing dead ones).
- **Effort to next unlock**: an onboarding 1 task from a tier benefit is high-ROI vs. 8 tasks from anything.
- **Momentum**: recent engagement vs. drift. Onboardings that have stalled need a momentum-restart move (a CAM ping, a first registration), not more tasks.
- **Relationship strategic weight**: vendors more central to the partner's portfolio (more pipeline / more existing customers) earn higher weighting.
### Step 4: Compute Return-on-Next-Action
For each onboarding, the question is: *if I spend 1 hour on this today, what's the marginal value?* That's:
- **(Economic upside at activation × probability the action moves activation forward) ÷ (effort of the action)**
Rank by ROI of next action. Top 1–3 are the focus list.
### Step 5: Recommend the specific next action per top-ranked onboarding
For each:
- **The action** in concrete terms ("Register your first deal, Account X is closest in your pipeline. Vendor Y's first-deal protection unlocks ~€8K margin").
- **The unblock**: if the action is gated by a missing task / cert / asset, surface that.
- **Effort estimate** (10 min / 1 hr / 1 day).
- **What it unlocks immediately**.
### Step 6: Surface stall-recovery moves
Some onboardings are stalled, engagement decay, no recent activity. For those:
- Recommend a momentum-restart move (CAM ping with drafted message; small first deal to unlock first-deal status).
- Or recommend honest abandonment if the math doesn't justify continuing (some vendor relationships aren't going to be productive, surface that conclusion).
## Output format
- **Today's focus list**: top 1–3 onboardings, each with the specific next action + effort + payoff.
- **Stall-recovery moves**: onboardings that need a momentum reset.
- **Honest skip list**: onboardings where ROI doesn't justify continuing (with rationale).
- **Aggregate context**: total onboardings active, total ARR potential at full activation, weeks of attention "owed" given current pacing.
## Guardrails & PRM best practice
- **Strictly scoped per portal.** Each onboarding's data is fetched with its own `roomId`. No cross-portal data leakage.
- **Don't shame.** If the partner has 5 stalled onboardings, the framing isn't "you've been failing at this." It's "here's the highest-ROI single move you could make today." Action-bias, not judgment.
- **Honest about diminishing returns.** Some onboardings should be deprioritized, and saying that explicitly is more useful than implying it. If the math says "skip Vendor Z this quarter," surface it cleanly.
- **Effort honesty.** A 10-minute action ranks higher than a 4-hour action with similar payoff. Surface effort estimates honestly.
- **Don't ignore strategic weight.** A vendor with smaller per-deal margin but huge customer-base overlap may rank higher than a high-margin vendor with no customer fit.
- **Capture the decision.** When the partner picks a focus, log via `add_comment` so future runs see the trail.
- **Update on cadence.** This skill is meant to run weekly (or daily during high-onboarding load). Once-a-quarter usage misses the point.
- **Cross-skill handoff.** Once the partner commits to a focus and starts the action: status-mode → `partner-cross-vendor-onboarding-tracker`. Stuck-in-cert-gating → `partner-cross-vendor-cert-tracker`. First-deal motion → `partner-deal-war-room` to coach the deal forward.
```
Drop this file into `.claude/skills/partner-onboarding-prioritizer/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Pipeline Partner-Influence Companion
Source: https://docs.introw.io/headless/skills/partner/pipeline-influence-companion
Partner skill scanning shared vendor pipeline and accounts to surface deals where the partner has unique influence via existing relationships or vertical fit.
*Partner skill for [Use case 08: Deal Registration](/headless/agentic-use-cases/deal-registration).*
**Skill ID:** `partner-pipeline-influence-companion`
Use when a partner user wants to scan accessible vendor pipeline / shared accounts to identify deals where they have unique influence (existing customer relationship, vertical fit, geographic proximity, prior similar wins): then surface those deals as candidates to register, share context on, or request to be placed on. Trigger phrases include "where can I add value", "which vendor deals fit me", "find deals I should be on", "my partner-influence opportunities", "register the deals I can influence".
**Built for:** Partner Seller · Partnerships Lead
**Workflow:** Vendor accounts visible to partner → Existing customer · vertical · geo · prior wins → Why-you-fit + what registration unlocks → Register · place-me-on · context comment
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-pipeline-influence-companion
description: Use when a partner user wants to scan accessible vendor pipeline / shared accounts to identify deals where they have unique influence (existing customer relationship, vertical fit, geographic proximity, prior similar wins): then surface those deals as candidates to register, share context on, or request to be placed on. Trigger phrases include "where can I add value", "which vendor deals fit me", "find deals I should be on", "my partner-influence opportunities", "register the deals I can influence".
---
# Pipeline Partner-Influence Companion (Partner)
**Audience**: Partner user, **claude.ai Introw Connect Staging** MCP.
**Use case**: 08, Deal Registration (partner-side companion to `vendor-pipeline-partner-influence-scout`).
## When to use this skill
Use when a partner user wants to scan accessible vendor pipeline / shared accounts to identify deals where they have unique influence (existing customer relationship, vertical fit, geographic proximity, prior similar wins): then surface those deals as candidates to register, share context on, or request to be placed on.
**Sample prompts that fire this skill:**
- "where can I add value"
- "which vendor deals fit me"
- "find deals I should be on"
- "my partner-influence opportunities"
- "register the deals I can influence"
## Why this matters
Partners typically only register deals they sourced themselves, but a meaningful chunk of vendor-direct or co-sell-eligible pipeline is on accounts where the partner already has earned influence: existing customer relationships, vertical specialization, geographic proximity, prior similar wins. Surfacing those opportunities to the partner self-service multiplies the partner-led-revenue lift (~35%, Computer Market Research) without requiring a vendor-side PDM to spot every opportunity manually.
## Process
### Step 1: Resolve the portal
If the user has access to multiple partner portals, call `Introw_Connect_Staging:partners` first and confirm which `roomId` to use.
### Step 2: Pull what the partner can see
Strictly scoped to the partner's accessible data:
- `Introw_Connect_Staging:search_crm_objects`: vendor accounts/deals visible to this partner (per their portal permissions).
- `Introw_Connect_Staging:search_partner_engagement`: their own engagement / asset views.
- `Introw_Connect_Staging:search_form_submissions`: their existing registrations.
- `Introw_Connect_Staging:get_goals`: partner's own goals (pacing context).
- `Introw_Connect_Staging:get_tier_information`: tier eligibility for any product/segment.
### Step 3: Identify partner-influence candidates
For each accessible vendor account/deal, score the partner's natural fit:
- **Existing customer**: partner already serves this customer in another capacity.
- **Vertical specialization**: partner's vertical focus matches the customer's industry.
- **Geographic proximity**: partner's region matches the customer's region.
- **Prior similar wins**: partner has closed similar deals (vertical × deal size × product).
- **Tech-stack match**: partner builds integrations the deal would benefit from.
- **Service attach**: deal would benefit from implementation services the partner offers.
Score each candidate. Surface the top N with the strongest case.
### Step 4: Frame the value to the partner
For each candidate, articulate:
- **Why you fit** (the strongest one or two signals).
- **What registering / placing yourself on this would unlock** (deal-protection 10–15 pts margin, MDF eligibility, pre-sales support, tier progression).
- **What the partner would need to do** (intro call, share customer reference, attend joint pitch).
### Step 5: Take the action the partner chooses
- **Register the deal**: hand off to the `partner-register-deal` flow, pre-filled with the captured fields.
- **Submit a "place me on this" request**: use `Introw_Connect_Staging:share_lead_or_register_deal` with the appropriate form type and a comment explaining the influence rationale.
- **Add context to the deal**: `Introw_Connect_Staging:add_comment` to share what the partner knows about the customer (existing relationships, prior conversations, vertical-specific risks).
- **Add a follow-up task**: `Introw_Connect_Staging:add_task` for the partner to track outreach.
## Output format
- **Top-N candidate list** with: account, deal-context-as-visible, why-you-fit, suggested action.
- **Action confirmations** for any submission / comment / task created.
- **Suggested follow-ups**: e.g., when to check back on response.
## Guardrails & PRM best practice
- **Strictly scoped to partner's permissions.** This skill never surfaces vendor-direct or other-partner data the portal doesn't expose to this partner. If the data isn't visible in the partner's portal scope, it doesn't appear here.
- **Influence claim must be evidenced.** Every "why you fit" needs a concrete signal (existing relationship, prior win, vertical match): speculative claims undermine the partner's standing with the vendor.
- **Don't over-register.** If a partner registers everything they "could" influence, the vendor's review queue clogs and trust degrades. Prioritize aggressively, top 3–5 candidates, not 50.
- **Conflict awareness.** If the account is already covered by another partner per visible portal data, don't surface it as a registration candidate, surface as a co-sell or referral opportunity instead, or skip.
- **Echo before submit.** For any registration/share, echo the captured fields back for confirmation before calling the write tool.
- **Capture context in the comment.** When the partner has unique knowledge about the customer (decision-maker dynamics, prior product use, regional considerations), capture via `add_comment`: that context is the partner's strongest contribution.
- **Goal-aware suggestions.** Prefer candidates that move the partner toward their `get_goals` targets, pacing matters.
- **Don't promise vendor outcomes.** This skill submits requests; vendor review and conflict logic determine acceptance. Frame next steps as "submitted, in review per SLA," not approval.
- **Cross-skill handoff.** Confirmed registrations → `partner-register-deal` flow. Coaching needs after placement → `partner-coach-my-deal`.
```
Drop this file into `.claude/skills/partner-pipeline-influence-companion/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Pre-QBR Self-Prep
Source: https://docs.introw.io/headless/skills/partner/pre-qbr-self-prep
Partner skill for pre-QBR prep - generates the partner's own view of deals sourced, engagement, training, goal progress, and asks to bring into a vendor QBR.
*Partner skill for [Use case 12: QBRs / Meeting Prep](/headless/agentic-use-cases/qbrs-meeting-prep).*
**Skill ID:** `partner-pre-qbr-self-prep`
Use before a partner heads into a QBR / MBR with a vendor, generates the partner's *own* data view (deals sourced, engagement, training, goals progress, asks to bring up, the partner's own scorecard of how the vendor has been performing as a partner) so the partner walks in with their own narrative, not just the vendor's slides. Trigger phrases include "prep my QBR", "I have a QBR with \[vendor]", "what should I bring up in the QBR", "my QBR data", "pre-meeting prep with vendor", "partner-side QBR prep".
**Built for:** Partnerships Lead · Partner Operations
**Workflow:** Sourced · closed · engagement · commissions → Performance + vendor-as-partner scorecard → Tier · MDF · deal protection · field support → Narrative + agenda + watch-outs
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-pre-qbr-self-prep
description: Use before a partner heads into a QBR / MBR with a vendor, generates the partner's *own* data view (deals sourced, engagement, training, goals progress, asks to bring up, the partner's own scorecard of how the vendor has been performing as a partner) so the partner walks in with their own narrative, not just the vendor's slides. Trigger phrases include "prep my QBR", "I have a QBR with [vendor]", "what should I bring up in the QBR", "my QBR data", "pre-meeting prep with vendor", "partner-side QBR prep".
---
# Pre-QBR Self-Prep (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP. Single-vendor scope per invocation (the QBR is with one vendor).
**Use case**: 12, QBRs / Meeting Prep.
## When to use this skill
Use before a partner heads into a QBR / MBR with a vendor, generates the partner's *own* data view (deals sourced, engagement, training, goals progress, asks to bring up, the partner's own scorecard of how the vendor has been performing as a partner) so the partner walks in with their own narrative, not just the vendor's slides.
**Sample prompts that fire this skill:**
- "prep my QBR"
- "I have a QBR with [vendor]"
- "what should I bring up in the QBR"
- "my QBR data"
- "pre-meeting prep with vendor"
- "partner-side QBR prep"
## Why this matters
QBRs are usually run *to* the partner, not *with* them. The vendor's PDM walks in with prepared slides, owns the agenda, and frames the conversation. The partner shows up reactively, answering questions about pipeline, hearing concerns, taking notes. The result is QBRs that miss the partner's perspective entirely: their constraints, their wins with this vendor's product they want to celebrate, their asks (more MDF, deal-protection extension, tier promotion, lead share, regional support), and their honest read on how the vendor is treating them as a partner.
This skill flips that. Before the QBR, the partner gets their own data view + drafted talking points. They walk in with their own narrative and asks. The QBR becomes a real two-way review instead of a vendor-led report-out.
## Process
### Step 1: Resolve the portal
- If the partner has access to multiple vendor portals, call `Introw_Connect_Staging:partners` and confirm which vendor's QBR this is for. **Single vendor per invocation.**
### Step 2: Pull the partner's own performance with this vendor
- `Introw_Connect_Staging:search_crm_objects`: partner-attached deals (closed-won, in-flight, slipped, stalled) over the review period.
- `Introw_Connect_Staging:search_form_submissions`: registrations submitted, with status (approved, pending, rejected, conflict).
- `Introw_Connect_Staging:search_partner_engagement`: engagement intensity over the period.
- `Introw_Connect_Staging:search_tasks`: open + completed tasks (training, MAP commitments).
- `Introw_Connect_Staging:get_goals`: committed goals + progress.
- `Introw_Connect_Staging:search_commissions`: commissions earned, paid, accrued, pending, and any disputes.
- `Introw_Connect_Staging:get_tier_information`: current tier + distance to next tier.
### Step 3: Compute partner's-eye-view metrics
Build the partner's narrative:
- **What we sourced this quarter**: count, ARR, breakdown by product / vertical / region.
- **What we closed**: wins, with the case studies behind them (so the partner can name-drop in the QBR).
- **What stalled / lost**: and a partner-side read on why (vendor's pricing? competitor? lack of vendor support?).
- **Our pipeline trajectory**: what's coming, when, deal-protection coverage, support needs.
- **Our investment in the vendor**: training completed, certs earned, events attended.
- **Goal pacing**: on track / behind / ahead of committed goals.
- **Our financial picture with this vendor**: commissions earned, payment timeliness, disputes.
### Step 4: Compute the partner's "vendor scorecard"
The honest part, how is this vendor performing as a *partner* to me? Score:
- **Approval responsiveness**: avg days to deal-reg approval, MDF approval, conflict resolution.
- **Lead share generosity**: leads passed to me + their conversion rate.
- **Pricing flexibility**: deal exceptions granted vs. requested.
- **Field support quality**: SE / pre-sales availability when I asked.
- **Payment timeliness**: on-time vs. aged payable.
- **Communication quality**: PDM responsiveness, info flow on launches.
This isn't to attack the vendor, it's to give the partner data to bring up specific friction with concrete asks ("approvals took avg 5 days this quarter, would help to get under 2 days").
### Step 5: Surface the asks
Based on the data, identify what the partner should bring up:
- **Tier promotion ask**: if pacing strong but tier not yet moved.
- **Deal protection extensions**: for slipping deals where the protection window is closing.
- **MDF asks**: campaigns the partner wants to fund.
- **Lead share asks**: segments where the partner has capacity.
- **Pricing flexibility**: for specific in-flight deals where pricing is the blocker.
- **Field support**: vendor SE engagement on strategic deals.
- **Process improvements**: based on the scorecard's pain points.
- **New product / vertical interest**: if the partner sees an opportunity to expand the partnership.
### Step 6: Draft the partner's narrative
Generate a 3–5 minute opening the partner can use in the QBR (or just structure their notes):
- **What worked** (1–2 wins to celebrate, named).
- **Our investment** (concrete numbers, registrations, certs, events).
- **What stalled and why** (honest, blame-shared where appropriate).
- **What we're asking for** (the specific list, in priority order).
- **What's coming** (pipeline framing, with numbers).
Tone: collaborative, data-grounded, asks specific things. Not a complaint list, not a victory lap.
## Output format
- **Partner performance dashboard**: sourced/closed/in-flight, cert/training, engagement, goal pacing.
- **Partner's vendor scorecard**: how the vendor performed for this partner this quarter.
- **Asks list**: prioritized, with data backing each.
- **Drafted QBR opening**: copy-pasteable, 3–5 minutes spoken.
- **Talking points for the agenda**: bullet-pointed, in case the vendor leads with their slides.
- **Watch-outs**: anything the partner should be ready to be asked about that the vendor will likely raise.
## Guardrails & PRM best practice
- **Single-vendor scope.** The QBR is with one vendor; the data view is scoped to that portal. Don't blend in other vendors' data.
- **Honest, not adversarial.** The vendor scorecard is for the partner's planning. Bring up specific friction with specific data, but frame asks as *partnership investments*, not complaints.
- **Don't surface other partners' data.** Even when the partner can see vendor-aggregate stats, don't quote other partners' numbers in the QBR, destroys the vendor's trust.
- **Strategic > comprehensive.** Pick 2–3 asks, not 12. A QBR isn't a wishlist; it's a focused conversation.
- **Pre-empt vendor concerns honestly.** If you have stalled deals the vendor will flag, address them in your own opening, don't make the vendor raise it first.
- **Tier-trajectory transparency.** If the partner is far from a tier promotion, don't manufacture a request that won't land. Use the data.
- **Capture commitments made.** After the QBR, the vendor may run `vendor-qbr-recording-to-portal-followup` (if installed). The partner should also log their own takeaways via `Introw_Connect_Staging:add_comment`: gives the partner-side audit trail.
- **Don't draft the vendor's responses.** The partner's prep is the partner's prep. Speculating on what the vendor will say is unhelpful.
- **Cross-skill handoff.** Stalled deals identified during prep → `partner-deal-war-room`. Cert-ask asks → cross-check via `partner-cross-vendor-cert-tracker`. Renewal/expansion deals to surface → `partner-renewal-and-expansion-coordinator` (if installed).
```
Drop this file into `.claude/skills/partner-pre-qbr-self-prep/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Prospect-to-Vendor Fit Finder
Source: https://docs.introw.io/headless/skills/partner/prospect-to-vendor-fit-finder
Rank which of a partner's vendors best fit a new prospect and how to position each, based on the prospect's stack, segment, vertical, and pain points.
*Partner skill for [Use case 08: Deal Registration](/headless/agentic-use-cases/deal-registration).*
**Skill ID:** `partner-prospect-to-vendor-fit-finder`
Use when a partner has a new prospect and wants to know which of their vendors fit best, in what order, and how to position each, based on the prospect's stack, segment, vertical, and pain points. Pre-stages the deal-registration payloads. Trigger phrases include "which vendor for this prospect", "best vendor fit for \[account]", "what should I lead with", "vendor sequencing for this deal", "match prospect to my vendors", "where do I register this".
**Built for:** Partner Seller · Partnerships Lead
**Workflow:** Stack · segment · vertical · pain → Vertical · segment · stack · track record · tier → Lead · Attach · Hold · Skip → Registration payloads ready to file
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-prospect-to-vendor-fit-finder
description: Use when a partner has a new prospect and wants to know which of their vendors fit best, in what order, and how to position each, based on the prospect's stack, segment, vertical, and pain points. Pre-stages the deal-registration payloads. Trigger phrases include "which vendor for this prospect", "best vendor fit for [account]", "what should I lead with", "vendor sequencing for this deal", "match prospect to my vendors", "where do I register this".
---
# Prospect-to-Vendor Fit Finder (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** the partner has access to.
**Use case**: 08, Deal Registration (partner-side, multi-vendor).
## When to use this skill
Use when a partner has a new prospect and wants to know which of their vendors fit best, in what order, and how to position each, based on the prospect's stack, segment, vertical, and pain points. Pre-stages the deal-registration payloads.
**Sample prompts that fire this skill:**
- "which vendor for this prospect"
- "best vendor fit for [account]"
- "what should I lead with"
- "vendor sequencing for this deal"
- "match prospect to my vendors"
- "where do I register this"
## Why this matters
A good reseller / SI often has 5–20 vendors in their portfolio, and every new prospect surfaces the same questions: *which vendor fits best? what's the right opening move? in what order do I bring each vendor in? where do I register first?* Most partners answer these on instinct, and lose deals by leading with the wrong product, registering with the wrong vendor first, or splintering attribution by registering everywhere at once.
This skill turns those decisions into structured analysis grounded in the partner's actual vendor portfolio + each vendor's actual sweet spot. Then it pre-stages the registration payloads so the partner can act in seconds.
## Inputs to gather first
- **Prospect context**: company name, domain, segment / size, vertical, current tech stack (if known), stated pain points or initiative.
- **Sales motion intent**: solo deal, multi-vendor co-sell, services-led implementation, transactional resell.
- **Time horizon**: imminent (closing this quarter), exploratory (educating the buyer).
## Process
### Step 1: Enumerate vendor portals
- `Introw_Connect_Staging:partners`: get all portals the partner has access to. Capture vendor name, partner record, tier per vendor.
### Step 2: Pull each vendor's sweet spot signals
For each `roomId`, in parallel:
- `Introw_Connect_Staging:get_tier_information`: what the partner's tier unlocks (margin, MDF, deal protection, certifications held).
- `Introw_Connect_Staging:search_crm_objects`: partner's own closed-won deals with this vendor (vertical, deal size, products): the partner's *track record* with each vendor.
- `Introw_Connect_Staging:search_partner_engagement`: engagement intensity (signal of relationship health).
- Whatever vendor case-studies / battle cards are accessible in each portal (the vendor's official sweet spot).
### Step 3: Score vendor-prospect fit per vendor
For each vendor, score along:
- **Vertical fit**: does the vendor have customer wins / case studies in the prospect's vertical?
- **Segment fit**: vendor's typical deal size matches the prospect's profile? (Don't pitch enterprise tooling to a 50-person company.)
- **Stack fit**: does the vendor integrate with the prospect's current tech stack? Are there displacement plays or extension plays?
- **Partner's track record with this vendor**: has the partner closed similar deals before? Win rate, sales cycle.
- **Tier/cert eligibility**: is the partner certified to sell the relevant SKU?
- **Deal-protection eligibility**: can the partner register this with deal protection?
- **Relationship health**: is this vendor relationship active, dormant, strained?
### Step 4: Recommend sequencing
For multi-vendor opportunities (most common in SI motions), recommend the order:
- **Lead with**: the vendor whose product solves the prospect's *primary* pain, with strongest fit + partner's best track record.
- **Attach**: vendors whose products extend the lead solution naturally (e.g., security ↔ observability, CRM ↔ data tools).
- **Hold for later**: vendors whose products are speculative for this prospect, bring in only after the lead motion is closing.
- **Skip**: vendors with poor fit (don't dilute the conversation).
For each recommended vendor, articulate:
- **Why it fits** (one sentence).
- **Opening positioning**: the framing to use ("Vendor X for healthcare-grade security on top of your existing stack").
- **Asset to send first**: case study or battle card from that vendor.
- **Estimated deal size and cycle** based on partner's track record with that vendor.
### Step 5: Pre-stage registration payloads
For each vendor in the recommended sequence:
- Pre-fill the deal-registration form with what's known (account, vertical, est. size, products).
- Surface for the partner to confirm and submit via `Introw_Connect_Staging:share_lead_or_register_deal`.
- Mark which registration to file first (sequence matters for deal-protection windows).
- Pre-flight check: any conflict with partner's existing registrations on this account?
### Step 6: Capture the analysis
- `Introw_Connect_Staging:add_comment` on each relevant vendor portal, log that this prospect was evaluated, the framing decision, and the registration plan.
## Output format
- **Vendor fit matrix**: vendors × fit dimensions × scores.
- **Recommended sequence**: Lead / Attach / Hold / Skip, each with one-line rationale.
- **Per-vendor opening framing + asset**: copy-pasteable.
- **Registration sequence + payloads**: ready for confirmation/submission.
- **Conflict pre-flight**: flags if anything risks channel conflict.
## Guardrails & PRM best practice
- **Don't register with everyone "just in case".** Splintering attribution dilutes the partner's claim with each vendor and fragments the prospect conversation. Pick a sequence and execute it.
- **Lead with fit, not commission.** Recommending the highest-margin vendor regardless of prospect fit erodes the partner's reputation. Fit first, commission optimization second (and only as a tiebreaker between equally-good fits).
- **Honest about gaps.** If no vendor in the partner's portfolio is a strong fit for this prospect, say so, don't force-fit. The partner's reputation depends on bringing the right tool, not the available one.
- **Track-record honesty.** If the partner has zero closed-won deals with a vendor, the "track record" score is empty, flag it. Don't pretend an untested vendor relationship is a strength.
- **Tier eligibility hard-gates.** If the partner's tier or certifications don't authorize selling a vendor's relevant SKU, that vendor drops out, even with otherwise great fit.
- **Pre-flight conflict checks.** Before recommending a registration, scan partner's existing registrations on the same account. Re-registering an already-claimed account creates conflict, not value.
- **Sequencing matters for deal protection.** Most vendors offer deal protection on first-mover registrations within their window. Recommend the registration order that maximizes protection coverage.
- **Don't leak vendor-confidential data.** Each vendor's data stays scoped to its portal. The cross-vendor analysis happens locally; vendor-confidential framings (specific pricing, internal sales motion details) never get echoed into another vendor's portal or the partner's prospect outreach.
- **Capture the rationale.** When the partner picks a sequence, log it via `add_comment` so future analyses (and CAM conversations) have the trail.
- **Cross-skill handoff.** Once registered → `partner-deal-war-room` for stage-aware coaching. Multi-vendor co-sell coordination needed → flag for human handoff (CAMs from both vendors, not the agent).
```
Drop this file into `.claude/skills/partner-prospect-to-vendor-fit-finder/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Cross-Vendor Registration Status Tracker
Source: https://docs.introw.io/headless/skills/partner/registration-status-tracker
One view of every deal and lead registration a partner has across all vendors: pending, approved, in conflict, or nearing protection-window expiry.
*Partner skill for [Use case 08: Deal Registration](/headless/agentic-use-cases/deal-registration).*
**Skill ID:** `partner-registration-status-tracker`
Use when a partner wants a single view of every deal/lead registration they have outstanding across all vendors, pending approval, approved, in conflict, approaching protection-window expiry, sorted by urgency and recommended action. Trigger phrases include "all my registrations", "what's pending approval", "deal regs across vendors", "protection windows expiring", "registrations in conflict", "registration status".
**Built for:** Partner Operations · Partnerships Lead
**Workflow:** Enumerate vendor portals → Pending · approved · conflict · expiring → Red · yellow · green → Drafted CAM pings · conflict responses
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-registration-status-tracker
description: Use when a partner wants a single view of every deal/lead registration they have outstanding across all vendors, pending approval, approved, in conflict, approaching protection-window expiry, sorted by urgency and recommended action. Trigger phrases include "all my registrations", "what's pending approval", "deal regs across vendors", "protection windows expiring", "registrations in conflict", "registration status".
---
# Cross-Vendor Registration Status Tracker (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** the partner has access to.
**Use case**: 08, Deal Registration (partner-side, multi-vendor).
## When to use this skill
Use when a partner wants a single view of every deal/lead registration they have outstanding across all vendors, pending approval, approved, in conflict, approaching protection-window expiry, sorted by urgency and recommended action.
**Sample prompts that fire this skill:**
- "all my registrations"
- "what's pending approval"
- "deal regs across vendors"
- "protection windows expiring"
- "registrations in conflict"
- "registration status"
## Why this matters
Partners with active pipelines across 5+ vendors often have 20–50 registrations in flight at any given moment, pending approvals, approved-but-aging, in-conflict, sitting on the edge of protection-window expiry. Each vendor's portal shows you *its* slice. Nobody shows you the unified view.
The cost of missing one is significant: a protection window expiring on a deal-in-flight strips 10–15 points of margin off the eventual close. A conflict left unresolved for two weeks degrades vendor trust on every future registration. This skill makes the whole queue visible in one place, sorted by urgency, with recommended action per item.
## Process
### Step 1: Enumerate vendor portals
- `Introw_Connect_Staging:partners`: get all portals.
### Step 2: Pull registration state per portal
For each `roomId`:
- `Introw_Connect_Staging:search_form_submissions`: all registrations in trailing 6–12 months, with status.
- `Introw_Connect_Staging:search_crm_objects`: corresponding deal records (stage, value, last-activity, close-date).
- `Introw_Connect_Staging:get_tier_information`: protection-window length per tier (typically 30/60/90 days).
### Step 3: Classify each registration
Bucket each registration:
- **Pending approval** (and aging): submitted, vendor SLA running. Flag if past stated SLA.
- **Approved & in protection window**: clean, on track. Show days remaining in window.
- **Approved & nearing window expiry**: < 30 days left in protection. The most urgent class.
- **Approved & expired**: protection window closed; deal still open. Flag for re-registration request or extension ask.
- **In conflict**: vendor flagged as conflicting with another partner or direct sales. Action: respond to vendor with evidence, or accept resolution.
- **Rejected**: partner needs to either appeal, register correctly, or move on.
- **Closed-won**: confirm commission attribution is correct (cross-check `search_commissions`).
- **Closed-lost**: opportunity to log lessons; close cleanly.
### Step 4: Surface urgency
Sort across all portals by urgency:
- **Red**: protection expiring < 7 days on an active deal; in-conflict registrations sitting > 48 hours; pending approvals past SLA.
- **Yellow**: protection expiring 7–30 days; approvals approaching SLA; aging post-approval with no deal activity.
- **Green**: clean, on track.
### Step 5: Recommend action per item
For each non-green item:
- **Pending past SLA** → CAM ping, drafted message included.
- **Protection expiring soon, deal still open** → choose: (a) register protection extension, (b) accelerate close, (c) accept loss of protection. Surface the trade-off.
- **In conflict** → review the conflict, gather evidence (existing customer relationship, prior similar wins), draft response.
- **Rejected, recoverable** → draft the corrected resubmission.
- **Closed-won with attribution issues** → flag for finance/CAM follow-up.
### Step 6: Surface aggregate insight
- **Approval velocity by vendor**: which vendors are slow vs. fast (informs future routing).
- **Conflict frequency by vendor**: which vendors have RoE issues.
- **Win rate by vendor**: which registrations actually close.
These are partner-internal insights, not for the QBR adversarially, just for the partner's own routing decisions.
## Output format
- **Status dashboard across vendors**: table with vendor, account, value, status, urgency, action.
- **Action queue**: sorted red → yellow, with recommended next move per item.
- **Drafted CAM pings** for SLA-breached approvals, copy-pasteable per vendor.
- **Drafted conflict responses** with evidence outline.
- **Aggregate insight**: vendor-by-vendor approval velocity, conflict rate, win rate.
## Guardrails & PRM best practice
- **Strictly scoped per portal.** Each registration's data is fetched only with that vendor's `roomId`. No cross-portal data leakage in the responses sent back to vendors.
- **Don't submit vendor-confidential data into another vendor's portal.** Cross-vendor analysis happens locally; the partner's CAM pings to Vendor X never reference Vendor Y's data.
- **Conflict responses must be evidence-grounded.** Don't draft a conflict appeal that overclaims partner equity in an account. Surface the evidence honestly; let the partner decide what to argue.
- **Protection-window honesty.** Some vendors don't extend protection windows beyond the original term. Surface the policy if known; don't promise an extension that isn't policy.
- **Re-registration is rare.** If a deal already had protection that expired, re-registering is generally not allowed. Surface the right ask, extension, exception, or accept loss of protection.
- **Closed-won attribution.** When attribution looks off, draft the inquiry to vendor finance/CAM with the specifics (deal ID, expected commission, actual commission). Don't escalate before checking the data.
- **Don't auto-act.** Surface action; partner submits.
- **Capture every CAM ping** via `Introw_Connect_Staging:add_comment` on the relevant registration record so the trail exists for future audits.
- **Run on cadence.** Weekly default; daily during heavy-pipeline quarters. Daily-discovered issues are 10× cheaper to resolve than QBR-discovered ones.
- **Cross-skill handoff.** Stalled approved registrations → `partner-deal-war-room` to coach the deal forward. Conflicts that can't be resolved → escalate to vendor channel ops via `partner-helpdesk` or direct CAM.
```
Drop this file into `.claude/skills/partner-registration-status-tracker/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Renewal & Expansion Coordinator
Source: https://docs.introw.io/headless/skills/partner/renewal-and-expansion-coordinator
Unified view of customer renewal dates, expansion windows, and at-risk accounts across every vendor a reseller or co-sell partner works with.
*Partner skill for [Use case 04: Activation](/headless/agentic-use-cases/activation).*
**Skill ID:** `partner-renewal-and-expansion-coordinator`
Use when a partner who resells / co-sells ongoing services wants a unified view of customer renewal dates, expansion windows, and at-risk accounts across every vendor they work with, so they can coordinate proactive outreach before renewals lapse and surface expansion plays at the right moment. Trigger phrases include "upcoming renewals", "expansion windows across vendors", "customer renewal calendar", "what's renewing in 90 days", "at-risk customer accounts", "expansion opportunities", "customer base review across vendors".
**Built for:** Partnerships Lead · Partner Seller · Customer Success Manager
**Workflow:** Enumerate vendor portals → Renewal dates + expansion signals → Health × adjacent fit × multi-vendor coordination → Drafted customer + CAM pings
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: partner-renewal-and-expansion-coordinator
description: Use when a partner who resells / co-sells ongoing services wants a unified view of customer renewal dates, expansion windows, and at-risk accounts across every vendor they work with, so they can coordinate proactive outreach before renewals lapse and surface expansion plays at the right moment. Trigger phrases include "upcoming renewals", "expansion windows across vendors", "customer renewal calendar", "what's renewing in 90 days", "at-risk customer accounts", "expansion opportunities", "customer base review across vendors".
---
# Renewal & Expansion Coordinator (Partner)
**Audience**: Partner user, uses **claude.ai Introw Connect Staging** MCP across **all portals** the partner has access to.
**Use case**: 04, Activation (partner-side, multi-vendor, applies to ongoing customer-relationship motions: SaaS resell, MSP, services-led).
## When to use this skill
Use when a partner who resells / co-sells ongoing services wants a unified view of customer renewal dates, expansion windows, and at-risk accounts across every vendor they work with, so they can coordinate proactive outreach before renewals lapse and surface expansion plays at the right moment.
**Sample prompts that fire this skill:**
- "upcoming renewals"
- "expansion windows across vendors"
- "customer renewal calendar"
- "what's renewing in 90 days"
- "at-risk customer accounts"
- "expansion opportunities"
- "customer base review across vendors"
## Why this matters
Renewal and expansion revenue is where partner P&L compounds, a partner who actively manages renewals + expansions across their installed base earns 2–3× more lifetime customer value than one who sells, ships, and forgets. But for partners with customers across 5+ vendors, the calendar is impossible: each vendor's contract renewals are tracked in that vendor's portal (or worse, in the partner's spreadsheet), and the expansion windows aren't always known until the vendor announces a feature push.
This skill aggregates: every customer × every vendor × every renewal/expansion window in one view, sorted by what to act on now. Renewal slippage is the silent killer of partner P&L; this skill makes it visible early.
## Process
### Step 1: Enumerate vendor portals
- `Introw_Connect_Staging:partners`: get all portals.
### Step 2: Pull customer + contract state per portal
For each `roomId`:
- `Introw_Connect_Staging:search_crm_objects`: closed-won deals (the partner's installed base with this vendor); contract end dates if encoded; renewal-stage records.
- `Introw_Connect_Staging:search_partner_engagement`: recent activity on those accounts.
- `Introw_Connect_Staging:search_form_submissions`: any expansion/upsell registrations already in flight.
- `Introw_Connect_Staging:search_tasks`: vendor-assigned tasks tied to renewal/expansion motions.
- `Introw_Connect_Staging:search_commissions`: commission history per account (renewal-cycle commissions vs. one-time).
### Step 3: Classify each customer × vendor relationship
For each customer-vendor pair:
- **Status**: active subscription / approaching renewal / in renewal / lapsed / expansion-eligible.
- **Renewal date** (if known) and **days remaining**.
- **Annual contract value** (if visible) and **expected renewal value** at current usage.
- **Expansion signals**: has the vendor launched a relevant new SKU? Has the customer's usage grown? Is there an adjacent product the partner could attach?
- **Health signals**: usage trending up vs. down (where vendor data exposes this); recent customer service tickets; CSM red-flags.
- **Partner action history**: when did the partner last touch the customer about this vendor's product?
### Step 4: Build the unified calendar
- **In renewal now / past due**: drop everything. Highest urgency.
- **Renewing in 30 days**: action queue this week.
- **Renewing 30–90 days**: pre-renewal motion, confirmation outreach, expansion conversations.
- **Renewing 90–180 days**: strategic, early expansion plays, multi-product attach.
- **Expansion-eligible (off-cycle)**: customers where a vendor has launched something attachable.
### Step 5: Score expansion-play priority
For expansion-eligible customers, rank by:
- **Customer health** (don't push expansion to an at-risk account).
- **Adjacent-product fit** (vendor's new SKU matches customer's stated needs).
- **Multi-product attach motion** (expansion across vendors, e.g., customer renews Vendor X security, partner pitches Vendor Y observability layered on top).
- **Effort vs. revenue impact**.
### Step 6: Recommend per-customer next move
For top-priority renewals + expansion plays:
- **Outreach plan**: who at the customer to contact, when, what to lead with.
- **Coordinated multi-vendor pitch** if the customer is renewing one vendor and expansion-eligible on another, frame as a strategic conversation rather than disjoint pitches.
- **Drafted message** to the customer, copy-pasteable.
- **Drafted CAM ping** to the relevant vendor if the partner needs vendor SE / pricing engagement to close.
- **Pre-stage registration**: if expansion is likely to land, pre-fill the deal-reg payload via `share_lead_or_register_deal`.
## Output format
- **Renewal calendar across vendors**: table with customer, vendor, contract end, current ACV, days remaining, status, urgency.
- **Action queue this week**: top 5–10 by urgency.
- **Expansion plays**: customers with expansion-eligible signals, ranked.
- **Coordinated multi-vendor pitches**: accounts where 2+ vendors line up for a single conversation.
- **Drafted outreach + CAM pings** per priority item.
- **At-risk callouts**: customers showing churn signals, surfaced for vendor partnership.
## Guardrails & PRM best practice
- **Strictly scoped per portal.** Each customer-vendor relationship is fetched with that vendor's `roomId`. The aggregated view is the partner's local synthesis.
- **Customer-confidential data stays scoped.** If the partner can see the customer's usage / renewal numbers in a vendor's portal, that data doesn't get echoed into another vendor's portal or any third-party communication.
- **Don't push expansion to at-risk customers.** A churn-flagged customer needs retention motion, not an upsell pitch. Surface health signals clearly; the partner picks the play.
- **Renewals are not assumptions.** Just because a contract is approaching renewal doesn't mean the customer renews. Don't pre-stage commissions; surface as opportunity.
- **Multi-vendor coordination respects the customer's reality.** A customer doesn't want 6 separate sales pitches in a quarter, the partner's value is in coordinating into one strategic conversation. Recommend that, not splintered outreach.
- **Don't surface vendor-confidential roadmap to customers.** Some vendors share advance feature info with partners under embargo. Expansion plays grounded in those features must respect the embargo date.
- **Capture customer-side commitments separately.** When the customer commits to a renewal or expansion, log the partner's-eye-view via `add_comment` on the relevant vendor portal. Don't auto-create the registration, let the partner confirm the deal first.
- **Don't auto-pitch at customer.** Drafts are starting points; the partner edits + sends with relationship voice.
- **Run on cadence.** Monthly default; weekly during heavy renewal quarters.
- **Cross-skill handoff.** Pre-staged registrations → `partner-register-deal` flow. In-flight expansion deals → `partner-deal-war-room` for coaching. Customer at risk → escalate to vendor CSM via `partner-helpdesk` or direct CAM.
```
Drop this file into `.claude/skills/partner-renewal-and-expansion-coordinator/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Strategic Partner Acquisition: ABM Orchestrator
Source: https://docs.introw.io/headless/skills/vendor/acquisition-abm-orchestrator
End-to-end agentic partner acquisition: identify top-performing partner targets using revenue plus Crossbeam ecosystem overlap, then orchestrate ABM outreach.
*Vendor skill for [Use case 01: Partner Acquisition](/headless/agentic-use-cases/partner-acquisition).*
**Skill ID:** `vendor-acquisition-abm-orchestrator`
End-to-end agentic partner acquisition. Use when a Channel Chief, VP Partnerships, Partner Recruiter, or RevOps user wants to (a) identify top-performing partners (combining revenue with Crossbeam-based ecosystem-reach signals, overlapping customers, customers in the vendor's ICP, customers in the vendor's pipeline), (b) surface ecosystem coverage gaps against strategic goals, (c) build a lookalike profile, (d) find key stakeholders at target partner accounts, and (e) launch a relevance-tight ABM campaign with joint-value messaging, while pre-configuring the Introw Partner Portal experience for incoming targets. Trigger phrases include "agentic partner acquisition", "build a partner ABM campaign", "find me partners we should recruit", "ecosystem coverage gap", "joint-value outreach", "lookalike + outbound", "ICP-overlap-driven partner recruitment", "find under-leveraged partners by Crossbeam overlap", "ecosystem-reach lookalikes", "high-overlap low-revenue partners".
**Built for:** Partner Program Manager · VP Partnerships · Partner Recruiter
**Workflow:** Top performers + strategic goals + ICP playbook → Pattern + ecosystem reach → Net-new lookalike targets → ABM outreach + portal pre-config
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-acquisition-abm-orchestrator
description: End-to-end agentic partner acquisition. Use when a Channel Chief, VP Partnerships, Partner Recruiter, or RevOps user wants to (a) identify top-performing partners (combining revenue with Crossbeam-based ecosystem-reach signals, overlapping customers, customers in the vendor's ICP, customers in the vendor's pipeline), (b) surface ecosystem coverage gaps against strategic goals, (c) build a lookalike profile, (d) find key stakeholders at target partner accounts, and (e) launch a relevance-tight ABM campaign with joint-value messaging, while pre-configuring the Introw Partner Portal experience for incoming targets. Trigger phrases include "agentic partner acquisition", "build a partner ABM campaign", "find me partners we should recruit", "ecosystem coverage gap", "joint-value outreach", "lookalike + outbound", "ICP-overlap-driven partner recruitment", "find under-leveraged partners by Crossbeam overlap", "ecosystem-reach lookalikes", "high-overlap low-revenue partners".
---
# Strategic Partner Acquisition: ABM Orchestrator (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP + **optional claude.ai Crossbeam** MCP (+ optional Clay / ABM-platform MCPs if installed).
**Use case**: 01, Partner Acquisition.
## When to use this skill
End-to-end agentic partner acquisition. Use when a Channel Chief, VP Partnerships, Partner Recruiter, or RevOps user wants to (a) identify top-performing partners, combining revenue with Crossbeam-based ecosystem reach (overlapping customers, customers at the partner that match the vendor's ICP, customers at the partner that are in the vendor's open pipeline), (b) surface ecosystem coverage gaps against strategic goals, (c) build a lookalike profile, (d) find key stakeholders at target partner accounts, and (e) launch a relevance-tight ABM campaign with joint-value messaging, while pre-configuring the Introw Partner Portal experience for incoming targets.
**Sample prompts that fire this skill:**
- "agentic partner acquisition"
- "build a partner ABM campaign"
- "find me partners we should recruit"
- "ecosystem coverage gap"
- "joint-value outreach"
- "lookalike + outbound"
- "ICP-overlap-driven partner recruitment"
- "find under-leveraged partners by Crossbeam overlap"
- "ecosystem-reach lookalikes"
- "high-overlap low-revenue partners"
## Why this matters
Channel partner activation baseline sits at **30–50%**, with unmanaged programs **below 20%** (Unifyr Channel Atlas). At ~€15K effective cost-per-acquired-partner, a 100-partner-per-year intake at 50% activation **wastes €750K/year** on partners who never produce pipeline. Lifting activation 30% → 50% on the same intake = **67% more productive partners** ≈ **€10M incremental sourced ARR per 100-partner cohort**. Partner recruitment has been the least-instrumented part of the channel motion; this skill instruments it end-to-end.
**Ecosystem reach is a top-performer signal that revenue alone misses.** A partner with €100K in sourced revenue but 200 customers overlapping the vendor's ICP (per Crossbeam) is *not* a low performer, they're a massively *under-leveraged* one. The lookalike profile built from such a partner unlocks net-new recruitment that revenue-only ranking would never surface. When Crossbeam is connected, this skill weighs **revenue × ecosystem reach** rather than revenue alone, and explicitly surfaces high-overlap-low-revenue partners as both (a) lookalike templates for net-new recruitment and (b) activation candidates inside the existing base.
## What this skill orchestrates
1. **Top-performer pattern extraction**: what makes our best partners actually best, combining revenue and (when Crossbeam is connected) ecosystem reach into our ICP and pipeline.
2. **Under-leveraged-partner detection**: partners with high Crossbeam overlap but low realized revenue, who are both (a) the strongest lookalike templates and (b) activation candidates inside the existing base.
3. **Strategic-goal-aligned gap analysis**: where the ecosystem is short relative to revenue ambition.
4. **Lookalike candidate sourcing**: net-new targets matching the pattern.
5. **Stakeholder identification**: *which humans* inside those targets to engage.
6. **Joint-value ABM campaign generation**: relevance-tight messaging per target.
7. **Portal experience pre-configuration**: so when a prospect engages, they land in a fine-tuned Introw experience, not a generic application form.
## Inputs to gather first
- **Reference cohort scope**: top performers by what (sourced ARR, win rate, expansion ARR, certification depth)? Default: top 10–20 by trailing-4-quarter sourced ARR.
- **Strategic goals**: Net-new region coverage? Vertical penetration? Product-line attach? Pull from `Introw:get_goals` if encoded; else ask.
- **Geo / vertical / segment / partner-type constraints.**
- **Volume + cadence**: how many targets, what outbound cadence.
- **CTA**: deal-reg-eligible co-sell, joint webinar, pilot offer, lead share?
## Process
### Step 1: Build the reference cohort
**Revenue dimension** (always available):
- `Introw:search_crm_objects`: closed-won deals (trailing 4 quarters), grouped by sourcing partner.
- `Introw:search_partners`: enrich with tier, lifecycle, categories, contact info.
- `Introw:search_partner_engagement`: engagement intensity (comments, deal updates, asset views, form submits).
- `Introw:search_commissions`: commissions earned as a sustained-performance proxy.
- `Introw:get_tier_information`: tier rules if scoping to a specific tier.
**Ecosystem-reach dimension** (when Crossbeam MCP is connected, heavily recommended for this skill):
- `Crossbeam:*`: for each existing partner, pull customer overlap counts:
- **Total overlap**: how many customers they have that exist in the vendor's CRM in any form.
- **ICP overlap**: how many of their customers match the vendor's defined ICP (segment / vertical / size).
- **Pipeline overlap**: how many of their customers are currently *open opportunities* in the vendor's pipeline (these are the highest-value overlap, they're warm-introduction opportunities sitting on the table).
- **Closed-won overlap**: customers the vendor has already won where the partner is also present (validates partner-vendor compatibility).
- **Lapsed-customer overlap**: vendor's churned customers the partner still serves (reactivation opportunity).
- Weight overlap *type* (pipeline > ICP > total > lapsed) and *recency* (last 90 days > older).
Build a unified score per existing partner: `(realized revenue) × (sustained-quarter weight) + (ecosystem-reach weight × overlap_score)`. Partners with strong ecosystem reach but weak revenue surface as a separate "under-leveraged" bucket, they're the highest-value lookalike templates.
### Step 2: Extract the lookalike signature
Across the reference cohort (now including the under-leveraged-but-high-overlap bucket), summarize:
- Vertical / segment / geography
- Partner type (SI, reseller, referral, MSP, marketplace)
- Tech-stack signals from CRM custom fields
- Headcount band
- Avg deal size, sales cycle, win rate
- Onboarding → first-deal lag
- Engagement intensity (activities per active week)
- **Customer-base composition** (Crossbeam): what segments / verticals dominate the partner's customer book? What % of their customers fall in our ICP? What's the typical *overlap-to-revenue ratio* (a partner with high ratio is converting overlap to revenue efficiently; low ratio is the activation gap).
- **Pipeline overlap density** (Crossbeam): partners whose existing customer base correlates with our open-pipeline accounts are the strongest co-sell-fit profile.
### Step 3: Map ecosystem coverage gaps to strategic goals
Cross-check the lookalike signature and current footprint against goals:
- `Introw:get_goals`: strategic goals (regions, verticals, products to grow).
- Compute coverage: do we have enough lookalike-pattern partners in each goal area?
- Surface gaps: e.g., "Germany generates 3× the revenue but has 50% of the partner bandwidth, or no partner at all in healthcare."
- **Crossbeam-driven gap**: cross-check the vendor's open pipeline + ICP target accounts against the existing partner base, are there segments / verticals where the vendor has heavy pipeline but no partner with overlap into it? Those are the highest-priority recruitment targets.
- The output of this step is a **ranked acquisition brief**, not a generic prospecting list.
### Step 4: Source net-new targets
- If a Clay / ABM-platform MCP is installed, use it to source firmographically-matched candidates against the lookalike signature + gap brief.
- If not, output a **directly-pasteable acquisition brief** (firmographic filters + intent signals) for the recruiter to feed into their tool of choice.
### Step 5: Identify key stakeholders at target accounts
For each target partner account:
- Look for the channel/alliances/business-development decision-maker.
- Look for sales leaders who'd benefit from the joint motion.
- Look for technical leads if the relationship requires integration.
- Use Clay/LinkedIn enrichment if available; otherwise output a stakeholder-role checklist for human enrichment.
### Step 6: Generate joint-value ABM messaging per target
The defining quality of this skill: messaging is **relevance-tight, not template-tight**. For each target:
- Open with a specific reason this partnership creates joint value (not "we'd love to partner").
- Reference the target's actual customer ICP overlap with our top performers.
- Quantify the joint outcome (typical sourced ARR per top performer of this profile).
- Tier-aware CTA, pilot, co-sell, lead share, joint webinar.
- Localize tone (DACH = compliance-forward, US = use-case-forward).
- Drafts should pass the "would I respond?" test before being sent.
### Step 7: Pre-configure the Introw Partner Portal experience
A target who engages should not land in a generic "fill out this 14-field form" experience. For each target, prepare:
- A **personalized landing brief**: why we reached out, the specific joint-value framing, the relevant case studies for their vertical/geo.
- Pre-filled application fields where data is already known.
- Recommended first-90-days journey aligned to their partner type (this hands off cleanly to `vendor-personalized-onboarding-orchestrator`).
- Use `Introw:add_comment` on the prospect record to capture the personalized framing so the CAM has full context when the target engages.
- If using `Introw:share_lead_or_register_deal` to nominate the target for outreach, attach the personalization payload in the comment.
### Step 8: Hand off to outbound execution
- If outbound execution MCPs are available, fire the sequences with the per-target messaging.
- Otherwise, package into an outbound brief the recruiter can run.
- Set follow-up tasks via `Introw:add_task` so engagement signals get captured back.
## Output format
- **Reference cohort summary**: top performers + revenue + engagement metrics + (Crossbeam) total / ICP / pipeline overlap counts.
- **Under-leveraged-partner list**: high-overlap, low-revenue partners surfaced separately as both lookalike templates AND activation candidates.
- **Lookalike signature**: 5–8 firmographic + behavioral + ecosystem-reach bullets.
- **Ecosystem coverage gap map**: gaps ranked by strategic-goal alignment + revenue impact + pipeline-overlap absence.
- **Target list**: accounts × stakeholders × match score × joint-value framing.
- **ABM message variants per target**: drafted, not sent.
- **Portal experience brief per target**: personalization payload ready for activation.
- **Suggested next actions** with owners + ETA.
## Guardrails & PRM best practice
- **Evidence-based, not vibes-based.** Every recommendation traces back to a tool call. CSO Insights: top-quartile programs outperform peers on win rate by **+17.9 pts**: this only holds if you recruit the right partners, not the loudest applicants.
- **Revenue ≠ performance when ecosystem reach exists.** A partner with €100K revenue and 200 ICP-matched customers is under-leveraged, not low-performing. Don't filter them out of top-performer ranking based on revenue alone, they're often the most informative lookalike template AND a high-priority activation candidate.
- **Crossbeam data has lag.** Overlap data refreshes typically run nightly or weekly; flag stale data and avoid acting on overlaps > 30 days old without confirmation.
- **Crossbeam respects data-sharing scope.** Only surface overlaps within authorized population groups / partner-data-sharing agreements. Never surface partner customer names outside the vendor-internal scope.
- **Territory check before outbound.** `Introw:search_partners` for existing coverage in the geo/vertical to avoid flooding territory and seeding channel conflict.
- **Don't auto-create partner records.** End at the brief + outbound. Partner record creation is a deliberate human action.
- **Joint value, not vendor benefit.** Messaging must articulate what the *partner* gets, framed in their economics, not what we get.
- **No spray-and-pray.** If the target list exceeds the lookalike pattern's natural population, segment harder; don't dilute relevance to hit volume.
- **Lookalike ≠ filter.** The signature frames the search; let the recruiter override on judgment.
- **Frame outcomes in expected ARR uplift.** A 1pt activation lift on a 100-partner cohort beats hiring 30 mediocre partners, keep the user honest about the math.
- **Capture decisions** via `Introw:add_comment` on the partner/prospect record so the audit trail survives reorgs.
- **Hand off cleanly**: when a target converts, the personalization payload feeds the onboarding orchestrator. No "what was that conversation about" gaps.
- **Cross-skill handoff.**
- Under-leveraged partners (high overlap, low revenue) found in Step 1 → feed `vendor-activate-network-with-personalized-campaigns` to wake them up before recruiting their lookalikes.
- Pipeline-overlap signals on existing partners → `vendor-pipeline-partner-influence-scout` to convert overlap into deal-registration opportunities now (don't wait for the recruitment cycle).
- Target-account list with overlap signals on prospective partners → `vendor-crossbeam-cosell-finder` (proactive co-sell variant).
- Once a target converts → `vendor-personalized-onboarding-from-transcripts` to pick up cleanly.
```
Drop this file into `.claude/skills/vendor-acquisition-abm-orchestrator/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Activate the Network with Personalized Campaigns
Source: https://docs.introw.io/headless/skills/vendor/activate-network-with-personalized-campaigns
Run a full activation sweep across the partner network: audit every partner against goals and generate personalized per-partner activation campaigns.
*Vendor skill for [Use case 04: Activation](/headless/agentic-use-cases/activation).*
**Skill ID:** `vendor-activate-network-with-personalized-campaigns`
Use when a Channel Chief, PDM, RevOps, or Channel Ops user wants to run a full activation sweep across the entire partner network, auditing every partner against their goals, identifying who needs activation, and generating per-partner personalized activation campaigns whose messaging maps to each partner's specific goals and gap. Trigger phrases include "activate the network", "who needs activation", "personalized activation campaigns", "audit and activate", "partner activation sweep", "fix the long tail".
**Built for:** Partner Program Manager · Partner Development Manager · Channel RevOps
**Workflow:** Goals · engagement · pipeline · tasks → Per-partner blocker → Mapped to goal + blocker (templates from playbook) → Right channel · re-audit at 14 days
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-activate-network-with-personalized-campaigns
description: Use when a Channel Chief, PDM, RevOps, or Channel Ops user wants to run a full activation sweep across the entire partner network, auditing every partner against their goals, identifying who needs activation, and generating per-partner personalized activation campaigns whose messaging maps to each partner's specific goals and gap. Trigger phrases include "activate the network", "who needs activation", "personalized activation campaigns", "audit and activate", "partner activation sweep", "fix the long tail".
---
# Activate the Network with Personalized Campaigns (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP.
**Use case**: 04, Activation.
## When to use this skill
Use when a Channel Chief, PDM, RevOps, or Channel Ops user wants to run a full activation sweep across the entire partner network, auditing every partner against their goals, identifying who needs activation, and generating per-partner personalized activation campaigns whose messaging maps to each partner's specific goals and gap.
**Sample prompts that fire this skill:**
- "activate the network"
- "who needs activation"
- "personalized activation campaigns"
- "audit and activate"
- "partner activation sweep"
- "fix the long tail"
## Why this matters
Industry baseline activation: **30–50%** for managed programs, **below 20%** unmanaged. Half or more of every recruitment dollar produces zero pipeline because partners drift through onboarding without registering deals, and nobody notices until quarterly reporting. Lifting activation 30% → 50% on the same intake = **67% more productive partners** ≈ **€10M incremental sourced ARR per 100-partner cohort**. Reactivation after disengagement is dramatically more expensive than catching the drop-off early, re-engagement flows can lift dormant activity from ~4% to 12% (ReferralCandy), but prevention beats reactivation by an order of magnitude.
This skill is a **workflow**, not a query. It audits the entire network, scores activation state per partner, and generates campaigns where each partner gets messaging tied to their *specific goals*, not a generic "we miss you" blast.
## Process
### Step 1: Define the audit scope
Default: every active partner, including freshly onboarded. Confirm with the user. Optional scoping: tier, region, partner type, time-since-onboarding.
### Step 2: Pull network-wide signals
- `Introw:search_partners`: full partner list with tier, region, lifecycle stage.
- `Introw:get_goals`: committed goals per partner (KEY: this skill's personalization hinges on goal data).
- `Introw:search_crm_objects`: pipeline state and recent registrations per partner.
- `Introw:search_form_submissions`: last registration / lead share timestamp.
- `Introw:search_partner_engagement`: engagement intensity over 30/60/90-day windows.
- `Introw:search_tasks`: overdue / aging tasks per partner.
- `Introw:get_tier_information`: what each partner's current tier expects of them.
- `Introw:search_commissions`: earned vs. expected as a performance proxy.
### Step 3: Score every partner
Apply a multi-signal score per partner:
- **Activated**: first deal registered or closed within 90 days of onboarding.
- **Pacing**: on track for committed goals (`get_goals` progress vs. target run-rate).
- **Stalled**: completed onboarding, zero deal activity in 30/60/90 days.
- **Dormant**: was active, dropped off (declining engagement, no recent registrations).
- **At risk**: engagement decay + missed milestone but recoverable.
### Step 4: Diagnose *why* per partner
Don't just bucket, identify the specific blocker for each non-activated partner:
- **Capability gap**: never completed key training/cert.
- **Lead drought**: no inbound or warm leads to act on.
- **Stuck pipeline**: has open opportunities not advancing in 14+ days.
- **Goal mismatch**: partner's stated goals don't match what the program is enabling them on.
- **Stakeholder gap**: primary contact left; relationship orphaned.
- **Channel preference miss**: vendor pushed via email; partner lives in Slack.
- **Margin / incentive friction**: recent commission dispute or rate-perception issue.
### Step 5: Generate per-partner personalized activation campaigns
For each non-activated partner, build a campaign whose messaging maps to **their specific goals** and **their specific blocker**:
- **Subject / hook**: references the partner's stated goal (from `get_goals`) and their tier or vertical.
- **Joint-value framing**: concretely articulates what activating produces for *them*: deal-protection margin (10–15 pts), MDF access, pre-sales support, tier-progression unlocks.
- **Asset / next step**: directly tied to the diagnosed blocker:
- Capability gap → micro-course nudge.
- Lead drought → warm lead share via `Introw:share_lead_or_register_deal`.
- Stuck pipeline → deal coaching invite (hand off to `vendor-deal-coach-from-similar-wins` or `vendor-coach-partner-deal`).
- Stakeholder gap → CAM intro to a new contact.
- Channel preference miss → re-deliver via the partner's preferred channel.
- Margin friction → CAM call to address.
- **CTA**: one specific action, with the next-step link or task.
- **Tone**: partner-type-aware (transactional for SMB resellers, strategic for enterprise SIs, educational for new partners).
### Step 6: Distribute and track
- Push messages via the partner's preferred channel (email / Slack / Teams / portal).
- Use `Introw:add_task` to create CAM follow-ups for high-touch partners (top tier, strategic).
- Use `Introw:add_comment` on the partner record to capture the activation attempt for the audit trail.
- Schedule a re-audit window (default 14 days) to measure campaign-driven activation lift via `Introw:search_partner_engagement` and `search_form_submissions`.
## Output format
- **Network audit summary**: counts by bucket (Activated / Pacing / Stalled / Dormant / At risk).
- **Stalled & dormant table**: partner, tier, days since last engagement, diagnosed blocker, recommended intervention.
- **Per-partner campaign drafts**: hook, body, CTA, channel, copy-pasteable.
- **Distribution plan**: who gets what, when, via which channel, with which CAM owner.
- **Re-audit schedule**: when to measure activation lift.
## Guardrails & PRM best practice
- **Goal-driven, not generic.** If you can't tie a campaign's framing to a partner's specific goal from `get_goals`, the campaign isn't personalized, it's a blast in disguise. Push back rather than ship a generic version.
- **Diagnose before prescribing.** A campaign that nudges a "training-completed-no-leads" partner to do more training will accelerate disengagement, not fix it. Match the intervention to the diagnosed blocker.
- **Don't blast the whole network at once.** Partners talk; if the activation cadence reads as automated, trust collapses. Stagger campaigns and respect engagement saturation.
- **Tier-fairness with effort-tiering.** Top-tier strategic partners get a CAM call recommendation, not a templated email, even when the message would otherwise be the same.
- **Action over commentary.** Every flag carries a next-best action. A list without prescriptions creates fatalism.
- **Capture the loop.** Every campaign send + every response routes through `Introw:add_comment` on the partner record so the next quarter's QBR has the trail.
- **Channel preference is sacred.** Pushing in the wrong channel reads as "doesn't know me", exactly the message activation should *not* send.
- **Don't down-tier or deactivate from this skill.** Activation surfaces and prescribes; tier moves and program decisions go through governance.
- **Pair with other skills.** Hand off cleanly: blocked-on-coaching → `vendor-deal-coach-from-similar-wins`; blocked-on-training → `vendor-microcourse-from-closed-lost` or `vendor-training-gap-analysis`; blocked-on-onboarding → `vendor-onboarding-progress-audit`.
```
Drop this file into `.claude/skills/vendor-activate-network-with-personalized-campaigns/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Ecosystem Anomaly Detector
Source: https://docs.introw.io/headless/skills/vendor/anomaly-detector
Continuous scan of the partner ecosystem to surface unusual behavior: activity spikes or drops, atypical deal patterns, and dormant partner reactivations.
*Vendor skill for [Use case 14: Ecosystem Performance](/headless/agentic-use-cases/ecosystem-performance).*
**Skill ID:** `vendor-anomaly-detector`
Use when a Channel Chief, RevOps, or PDM wants a continuous-monitoring scan across the partner ecosystem to surface unusual behaviors, sudden activity drops or spikes, atypical deal patterns, dormant-partner reactivations, register-then-stall sequences, abnormal goal pacing, before they show up as quarterly surprises. Trigger phrases include "anomaly check", "what's unusual this week", "weird partner behavior", "spot the outliers", "ecosystem anomalies", "what changed materially".
**Built for:** Partner Program Manager · Channel RevOps · Partner Development Manager
**Workflow:** Engagement · deals · goals · commissions → vs. trailing-90-day baseline · per partner → Suppress noise · multi-signal first → Recommended next skill per item
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-anomaly-detector
description: Use when a Channel Chief, RevOps, or PDM wants a continuous-monitoring scan across the partner ecosystem to surface unusual behaviors, sudden activity drops or spikes, atypical deal patterns, dormant-partner reactivations, register-then-stall sequences, abnormal goal pacing, before they show up as quarterly surprises. Trigger phrases include "anomaly check", "what's unusual this week", "weird partner behavior", "spot the outliers", "ecosystem anomalies", "what changed materially".
---
# Ecosystem Anomaly Detector (Vendor)
**Audience**: Vendor, uses **claude.ai Introw** MCP.
**Use case**: 14, Ecosystem Performance.
## When to use this skill
Use when a Channel Chief, RevOps, or PDM wants a continuous-monitoring scan across the partner ecosystem to surface unusual behaviors, sudden activity drops or spikes, atypical deal patterns, dormant-partner reactivations, register-then-stall sequences, abnormal goal pacing, before they show up as quarterly surprises.
**Sample prompts that fire this skill:**
- "anomaly check"
- "what's unusual this week"
- "weird partner behavior"
- "spot the outliers"
- "ecosystem anomalies"
- "what changed materially"
## Why this matters
Ad-hoc analytics requests consume **30–50% of channel RevOps team capacity**. Most channel programs catch material changes weeks late, partner X went dark in week 2, nobody noticed until the QBR in week 12. Continuous anomaly detection makes the program **operationally responsive** instead of retrospective: when something unusual happens, somebody knows within days, not quarters.
The companion to `vendor-detect-at-risk-partners` (which scores per-partner risk): anomaly detection works **ecosystem-wide**, finding patterns the per-partner view misses (cohort-level shifts, segment-wide engagement drops, unusual deal-size spikes).
## Anomaly classes to detect
1. **Activity drop**: partner whose 30-day engagement is below their trailing 90-day baseline by > 50%.
2. **Activity spike**: partner whose engagement is suddenly > 2× their baseline (worth understanding, opportunity or noise).
3. **Dormant reactivation**: partner who was inactive 60+ days and just registered a deal or logged in.
4. **Register-and-stall**: partner who registered a deal but no follow-up activity in 14+ days.
5. **Deal-size outlier**: registration with deal value > 3× the partner's historical average (legitimate big deal or data error).
6. **Stage-velocity anomaly**: deals stuck in stage > 2× the cohort median for that stage.
7. **Tier-pace divergence**: partner pacing materially above or below their tier's median run-rate.
8. **Goal-pace cliff**: partner who was on track for a goal and suddenly fell off-pace this week.
9. **Cohort-level shifts**: a whole segment (region, tier, partner type) showing aggregate unusual movement (e.g., DACH SI registrations halved this week).
10. **Concentration risk**: an unusual fraction of new pipeline coming from a single partner, celebrate but flag.
## Process
### Step 1: Define the scope
- Default: full active partner base, trailing 7-day window vs. trailing 90-day baseline.
- Optional: scope to tier, region, partner type, or a specific cohort.
- Sensitivity setting: aggressive (flag > 1σ deviations) vs. conservative (> 2σ). Default conservative, false-positive fatigue is the enemy.
### Step 2: Pull baseline + current state
- `Introw:search_partners`: base set with tier, lifecycle stage, region.
- `Introw:search_partner_engagement`: engagement over current window AND baseline window.
- `Introw:search_crm_objects`: deal stage / value / velocity over both windows.
- `Introw:search_form_submissions`: registration cadence.
- `Introw:get_goals`: goal pacing vs. expected run-rate.
- `Introw:search_commissions`: commission events as a performance proxy.
### Step 3: Compute deviations per partner per signal
For each partner × signal:
- Compute current-window value.
- Compute trailing baseline (90-day median).
- Flag deviations beyond the configured sensitivity threshold.
- Annotate each flag with: signal name, current value, baseline, % deviation, plausible explanations.
### Step 4: Cluster and classify
- **Per-partner**: how many signals are flagged for the same partner? Multi-signal flags (engagement drop + goal-pace cliff + register-and-stall) score higher than single-signal flags.
- **Per-cohort**: aggregate flags by tier / region / partner type to spot ecosystem-level shifts.
- **Per-class**: which anomaly classes are firing most this week?
### Step 5: Filter for signal quality
- Suppress known-explainable: holidays, vendor-side outages, expected seasonality.
- Suppress noisy: very small partners where 1–2 events shift percentages dramatically.
- Suppress already-flagged: don't re-surface anomalies escalated last week unless they got worse.
### Step 6: Surface for action
- **High-priority anomalies**: top 5–10, ranked by severity × revenue exposure.
- **Watch list**: 10–20 secondary flags worth knowing.
- **Cohort-level findings**: anything ecosystem-wide.
- **Recommended action** per high-priority item: who should look at it, what skill to run next (`vendor-detect-at-risk-partners`, `vendor-coach-partner-deal`, `vendor-activate-network-with-personalized-campaigns`, etc.).
## Output format
- **Top anomalies** table: partner, anomaly class, severity, revenue exposure, recommended next action, owner.
- **Watch list** (less urgent).
- **Cohort findings** (ecosystem-wide patterns).
- **Suppression log**: what was filtered out and why (transparency for trust calibration).
- **Comparison to last run**: what's new vs. what's been on the list.
## Guardrails & PRM best practice
- **Anomaly ≠ problem.** Some anomalies are good news (a dormant partner just registered a $500K deal). The skill flags unusual; the human decides if it's celebrate, intervene, or ignore.
- **Conservative defaults.** False positives erode trust faster than false negatives. Better 5 high-quality flags than 50 noisy ones.
- **Always state the window.** Anomalies are window-relative; without explicit windows, comparisons are meaningless.
- **Suppress small-N noise.** A partner with 3 lifetime registrations doesn't have a stable baseline; flag thresholds need minimum-sample-size guards.
- **Pair with explanation.** Don't surface a flag without context. "Engagement dropped 60%" is not actionable; "Engagement dropped 60%, last activity was 12 days ago, prior cadence was every 3 days, no recent CRM updates either" is.
- **Don't auto-act.** Surface, don't act. Anomaly-driven auto-actions risk over-correcting on noise.
- **Run on cadence.** Daily for active programs, weekly for smaller. Anomalies discovered three weeks late aren't anomalies anymore, they're confirmed problems.
- **Feed the digest.** This skill's output is the natural input for `vendor-slack-weekly-channel-digest`'s "Anomalies" section.
- **Capture decisions.** When an anomaly is investigated and resolved (or dismissed), log via `Introw:add_comment` on the relevant partner so the next run has context for suppression.
- **Cross-skill handoff.** Per-partner anomalies → `vendor-detect-at-risk-partners` for full risk-scoring; segment-wide drops → `vendor-activate-network-with-personalized-campaigns` for cohort intervention; deal-velocity issues → `vendor-coach-partner-deal` or `vendor-deal-coach-from-similar-wins`.
```
Drop this file into `.claude/skills/vendor-anomaly-detector/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Agentic Asset Publisher
Source: https://docs.introw.io/headless/skills/vendor/asset-publisher
Draft partner one-pagers, battlecards, and FAQs from your own sources, then publish them and manage asset library folders in Introw over MCP.
*Vendor skill for [Enablement Support](/headless/agentic-use-cases/enablement-support).*
**Skill ID:** `vendor-asset-publisher`
Use when a Partner Enablement lead, Partner Marketing Manager, or Channel Ops user wants to produce a partner-facing document (one-pager, battlecard, FAQ, pricing summary, integration guide) from the vendor's own knowledge sources and publish it into the Introw asset library over MCP, link an existing page or video as a URL asset, refresh an asset that already exists, or organise the library itself (create, rename, move, or archive folders). Trigger phrases include "write a one-pager for our partners", "create a battlecard on \", "publish this PDF to the asset library", "add this deck to the partner portal", "add this YouTube video as an asset", "update the pricing one-pager", "replace that file with the new version", "create a folder for X", "reorganise the asset library", "archive that folder".
**Built for:** Partner Enablement Manager · Partner Marketing Manager · Channel Ops
**Workflow:** Brief + the vendor's own knowledge sources → check what exists with `list_assets` + `list_asset_folders` → author the document → export as PDF → open one upload slot for the whole batch via `create_asset_upload` → `upsert_asset` over MCP with folder, categories, and audience → keep the tree tidy with `upsert_asset_folder` → iterate by replacing the file in place
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-asset-publisher
description: Use when a Partner Enablement lead, Partner Marketing Manager, or Channel Ops user wants to produce a partner-facing document (one-pager, battlecard, FAQ, pricing summary, integration guide) from the vendor's own knowledge sources and publish it into the Introw asset library over MCP, link an existing page or video as a URL asset, refresh an asset that already exists, or organise the library itself (create, rename, move, or archive folders). Trigger phrases include "write a one-pager for our partners", "create a battlecard on ", "publish this PDF to the asset library", "add this deck to the partner portal", "add this YouTube video as an asset", "update the pricing one-pager", "replace that file with the new version", "create a folder for X", "reorganise the asset library", "archive that folder".
---
# Agentic Asset Publisher (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP.
**Use case**: Enablement Support.
## When to use this skill
Use when the user wants partner-facing content to exist in Introw without authoring it inside Introw: write the document here (from their knowledge sources, in their voice), then create or update the asset over MCP so it lives in the asset library, is searchable by the partner-facing AI agent, and can be surfaced in partner experiences.
**Sample prompts that fire this skill:**
- "write a one-pager our resellers can send to prospects"
- "create a battlecard against Competitor X for our partners"
- "turn our pricing page into a partner FAQ and publish it"
- "publish this PDF to the asset library under Sales"
- "add this Loom walkthrough as an asset for Acme only"
- "the pricing changed, update the one-pager"
## Why this matters
Partner content dies in two places: never written, or written and never filed. Partners then ask a CAM for a battlecard that exists in someone's Drive. Authoring here and publishing over MCP closes both gaps in one motion: the document is grounded in the vendor's real docs and data, and it lands in the library the partner portal and the AI partner-support agent both read from, with a category, a folder, and an owner. Iteration is cheap: replace the file in place and the asset keeps its id, link, view history, and version history.
## The five MCP tools
| Tool | Kind | What it does |
| --- | --- | --- |
| `Introw:list_assets` | read-only | Lists assets (assetId, name, description, fileName, mimetype, `type: FILE` or `URL`, folder, categories, isPublic, viewCount, timestamps) and the library's folders. Source of `assetId` for updates and `folderId` for filing. Filter with `query`, `folder`, `partnerId`. |
| `Introw:list_asset_folders` | read-only | The folder tree: folderId, `name`, `path` (readable location such as "Sales/Battlecards"), parentFolderId, partnerId, categories, `assetCount` (assets directly inside), `subfolderCount`, and `archived` + `archiveReason` with `includeArchived`. Filter with `query`, `parentFolder` (that folder's subtree), `partnerId`. |
| `Introw:create_asset_upload` | mutation | Pass `fileNames`, **every file of the job in one call** (up to 15), each **including its extension** (the extension decides the content type). Returns `uploadPageUrl` (one drag-and-drop page covering the whole batch, 30-minute expiry) and `files[]`, each entry carrying that file's `uploadKey`, its own presigned `uploadUrl`, and the `contentType` a PUT must send. Neither delivery path needs any network, firewall, or allowlist change. Nothing appears in the library until `upsert_asset` is called with the key. |
| `Introw:upsert_asset` | mutation | Omit `assetId` = create (requires `name` + exactly one source). Provide `assetId` = update; only the fields you pass change. Sources: `uploadKey` (from `create_asset_upload`), `fileUrl` (public https file, copied into Introw's storage), or `url` (a URL asset: page, video, or hosted doc that stays where it is). Settings: `description`, `folder`, `categories`, `partnerId`, `isPublic`. On update, passing any source REPLACES the file. |
| `Introw:upsert_asset_folder` | mutation | Omit `folderId` = create (requires `name`; `parentFolder` nests it, `partnerId` puts it in a partner's library). Provide `folderId` = update: `name` renames, `parentFolder` MOVES the folder with everything inside it, `categories` replaces its tags, `archived: true`/`false` archives or restores the folder **and its entire contents**. |
Two neighbouring tools are worth knowing: `Introw:find_relevant_content` searches what is already in the knowledge base (use it before writing something that exists), and `Introw:search_partners` resolves a `partnerId` when the asset is for one partner only.
## Process
### Step 1: Scope the asset
Confirm before writing:
- **Audience**: which partner type and role (a reseller's seller and an SI's consultant need different documents). One partner only, or the whole network?
- **Format and length**: one-pager, battlecard, FAQ, guide. Default to one page unless the user asks for more.
- **Sources**: which connected knowledge to draw from, such as docs sites, Notion, Confluence, Drive, the product docs, the website. Never fabricate; every claim traces to a source.
- **Filing**: which folder and categories, and whether it should be publicly shareable.
### Step 2: Check what already exists
Run `Introw:list_assets` with a `query` on the topic, and `Introw:find_relevant_content` for the same question. If a close match exists, propose updating it (Step 8) instead of adding a near-duplicate.
Then run `Introw:list_asset_folders` to see how the library is organised and where this belongs. Reuse the folder and category names already in use; a library with "Battlecards", "battle cards", and "Competitive" is a library nobody browses. `assetCount` and `subfolderCount` show you which folders are actually used and which are empty shells.
### Step 3: Write the document
- **Partner-facing voice**: written for someone selling or delivering the vendor's product to their own customer, not for internal staff.
- **Grounded**: real product names, real pricing, real integration steps, from the sources. Cite where each section came from in your summary to the user.
- **Skimmable**: short sections, a clear headline, tables over paragraphs for comparisons, an explicit "what to do next".
- **On-brand**: pull logo, colors, and typography from the vendor's site or brand assets if the format supports it.
- **No internal-only content**: partners download this. No unreleased roadmap, no internal margins, no customer names without permission.
### Step 4: Export as a PDF (or the format the user asked for)
PDF is the default: it previews inline in the portal and its text is indexed for the AI agent. Office files (DOCX, PPTX, XLSX) also work and get a converted PDF preview. Images and video are fine too. Keep it under 2 GB.
### Step 5: Hand Introw the files
Call `Introw:create_asset_upload` **once for the whole job**, passing every file in `fileNames` (up to 15), each including its extension, for example `['acme-partner-one-pager.pdf', 'acme-q3-deck.pptx']`. One call means one upload page, so the user uploads once instead of once per file. If a batch comes back asking you to split it, split it and call again.
Then pick a delivery path on **your own** capability. **Never ask anyone to change network, firewall, or allowlist settings: neither path needs one.**
1. **You cannot run shell commands or send an HTTP request with a file body** (every chat assistant, and any case where the files are on the user's machine and not yours): give the user `uploadPageUrl`, and only that. It is one drag-and-drop page taking the whole batch in a single visit, and it requires them to be signed in to Introw in this organisation (they are redirected to log in if needed). The page skips a file it already received and any file that is not part of this upload, and says so, and if some files fail it asks for just those again, so a second drop never duplicates what landed. Ask them to tell you when it is done.
2. **You can**: for each entry of `files[]`, HTTP PUT that file's raw bytes to its own `uploadUrl` with its `contentType` as the `Content-Type` header, for example `curl --fail -T one-pager.pdf -H "Content-Type: application/pdf" ""`. The header must match exactly or the signature is rejected.
Either way, finish with one `upsert_asset` call per file, passing that file's `uploadKey`. Links expire after 30 minutes; if they lapse, request a new slot. If `upsert_asset` reports that no file has landed yet, wait and retry.
Two shortcuts skip the upload entirely:
- **`fileUrl`**: a publicly downloadable https file. Introw copies it into its own storage, so the source only needs to live until the call.
- **`url`**: a page, video, or hosted doc that should stay at its own location (YouTube, Loom, Vimeo, Vidyard, Google Docs / Slides / Sheets, Calendly, or any https page). Introw stores the link and embeds it, and nothing is copied, so that URL must stay live and publicly reachable.
Never pass local file paths or base64 to `upsert_asset`.
### Step 6: Publish it
1. Recap every setting (name, description, folder, categories, partner scope, public link) and get explicit approval. This is a write.
2. `Introw:upsert_asset` with no `assetId`, passing the source and settings:
- **`folder`**: a `folderId` from `list_assets`, or a path such as `Sales/Battlecards` (missing folders are created, existing ones reused). `/` means the library root. The response lists any folders it created, so you can report them.
- **`partnerId`**: only when the asset is for one partner's private library. Omit it for the shared library every partner can see.
- **`categories`**: reuse the org's existing category names.
- **`isPublic`**: only when the user explicitly wants a link that works without signing in. Default off.
3. Report the `assetId` and the `assetUrl` from the response so the user can open it in Introw. `status: "created"` means it is live in the library; previews and AI-search indexing finish in the background, so a preview can take a moment.
If the response comes back `status: "already_exists"`, that exact file or link is already an asset. Do not retry with a new upload; use the returned `assetId` to update it instead. For a URL asset this is checked per folder, so filing the same link in a second folder on purpose still works: pass the other `folder`.
### Step 7: Keep the library organised
Folder work is a first-class part of publishing, not an afterthought. `Introw:upsert_asset_folder` covers it:
- **New section**: create a folder, optionally nested (`parentFolder` takes a folderId or a path such as `Sales/Battlecards`, creating missing levels). A folder that already exists in that place is reused, not duplicated.
- **Rename or re-tag**: `folderId` + `name` or `categories`.
- **Reorganise**: `folderId` + `parentFolder` moves the folder **with every subfolder and asset inside it**. Pass `/` to move it to the top level. A folder adopts its new parent's library, so moving between the shared library and a partner's changes who can see the content. Say that out loud before doing it.
- **Retire a section**: `archived: true` archives the folder and everything inside (with an optional `archiveReason`). Partners lose access immediately and the AI agent stops answering from those documents. `archived: false` restores it; if the name was taken again in the meantime, Introw suffixes the restored folder and tells you.
Confirm any move or archive with the user first and report the counts the tool returns (`archivedAssetCount`, `archivedFolderCount`), so they know how much content it touched. Prefer archiving over asking someone to delete: it is reversible.
### Step 8: Iterate, update settings or replace the file
- **Settings-only change** (rename, description, categories, folder, public link): `upsert_asset` with `assetId` and just those fields. The response lists what actually changed, and returns `status: "unchanged"` when nothing differed.
- **Content change**: upload the new file (`create_asset_upload` → deliver it by the path Step 5 picks → new `uploadKey`), then `upsert_asset` with `assetId` + that `uploadKey`. This replaces the file **in place**: same asset, same link, view history kept, and the previous version stays in the asset's version history so it can be restored in Introw. In-portal previews and AI-search content regenerate in the background. **Always confirm with the user before replacing**, since every partner sees the new file immediately.
- **Swapping types is allowed**: passing `url` to an asset that was a file turns it into a URL asset, and vice versa.
- Omitting `folder` or `partnerId` on an update leaves the asset where it is. Moving an asset out of a partner's library back into the shared one is done in Introw.
## Output format
- **Brief recap** (pre-write, for sign-off): audience, format, sources, filing plan.
- **The document itself** plus a short content summary and where each section came from.
- **Publish receipt**: `assetId`, `assetUrl`, folder (and any folders created), categories, audience (shared library or which partner), public link on or off.
- **Reorganisation receipt** (when folders changed): what moved or was archived, and how many assets and subfolders it affected.
- **Distribution note**: what still has to happen for partners to see it in the portal (see the guardrail below), and the phrasing to use to update it later.
## Guardrails & PRM best practice
- **Knowledge-sourced, never fabricated.** Every claim traces to the vendor's real docs or data; cite the source. Partner-facing collateral is one forward away from being customer-facing.
- **Confirm before every write.** Settings recap before creating; explicit confirmation before replacing a file, because partners see the new version immediately.
- **The library is not the portal.** Publishing puts the asset in the asset library and makes it searchable for the AI partner-support agent, but it does not add it to a specific portal tab or partner experience. Placing it in an asset hub component, or linking a partner-specific asset into a partner experience, is done in Introw. Say so in the receipt rather than implying partners will see it in their portal navigation right away.
- **Check for duplicates first.** `list_assets` plus `find_relevant_content` before writing. Updating the asset partners already bookmarked beats publishing a second one.
- **Reuse the existing taxonomy.** Existing folder names and categories over new ones, checked with `list_asset_folders`. Do not invent a parallel structure, and do not create a folder per asset.
- **Moving and archiving folders is bulk work.** Both act on everything inside the folder: a move relocates every asset in it (and can switch which library, so which partners, they belong to), and archiving hides them all and removes them from the AI agent's knowledge base. Confirm first, then report the counts the tool returns.
- **Archive, never ask for deletion.** Archiving is reversible (`archived: false`) and keeps the audit trail; there is no delete in this skill by design.
- **`isPublic` is a real decision.** It creates a link that works without signing in. Default off; only enable when the user asks, and never for pricing or anything partner-confidential.
- **Partner-specific means partner-specific.** With `partnerId` set, only that partner sees it. Use it for negotiated pricing or one partner's plan, not as a filing shortcut.
- **URL assets depend on the source staying up.** A link that dies is a broken asset. Prefer uploading a file for anything the vendor controls and wants to keep.
- **Permissions.** Anything that touches the shared library requires the connected Introw user's `assets_write` permission: publishing there, and also editing or moving an asset or folder that lives there, even when the call names a partner. If the tool reports it is missing, surface that plainly (an admin grants it) instead of retrying, or scope the work to a partner's own library if that is what the user actually wanted.
- **Cross-skill handoff.** What to write should come from real gaps: `vendor-support-content-gap-detector` (recurring partner questions) or `vendor-content-radar` (market and release signals). Per-partner branded variants of a published asset: `vendor-cobranded-collateral-generator`. If the content is training rather than reference, build a course instead with `vendor-scorm-course-builder`. To nudge partners toward the new asset, use `Introw:create_partner_task` or an announcement.
```
Drop this file into `.claude/skills/vendor-asset-publisher/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Campaign Kit Builder
Source: https://docs.introw.io/headless/skills/vendor/campaign-kit-builder
Package positioning, messaging, and email templates into a syndicated campaign kit that partners and their AI agents can launch through-channel.
*Vendor skill for [Through-Channel Marketing](/headless/agentic-use-cases/through-channel-marketing).*
**Skill ID:** `vendor-campaign-kit-builder`
Use when a Partner Marketing Manager wants to package positioning, narrative, messaging, and email templates into a ready-to-syndicate campaign kit that partners and their AI agents can launch in their own tooling, tied to a dedicated commission plan and an announcement. Trigger phrases include "build a campaign kit", "package this campaign for partners", "make a syndicatable campaign", "assemble the launch kit", "create a partner campaign bundle", "ship this campaign to partners".
**Built for:** Partner Marketing Manager · Vendor Marketing
**Workflow:** Gather assets + attribution → Assemble discoverable kit → Tie to commission plan → Announce + track
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-campaign-kit-builder
description: Use when a Partner Marketing Manager wants to package positioning, narrative, messaging, and email templates into a ready-to-syndicate campaign kit that partners and their AI agents can launch in their own tooling, tied to a dedicated commission plan and an announcement. Trigger phrases include "build a campaign kit", "package this campaign for partners", "make a syndicatable campaign", "assemble the launch kit", "create a partner campaign bundle", "ship this campaign to partners".
---
# Campaign Kit Builder (Vendor)
**Audience**: Vendor (**claude.ai Introw** MCP).
**Use case**: Through-Channel Marketing (TCMA).
## When to use this skill
Use when a Partner Marketing Manager wants to turn a campaign into a self-contained, discoverable kit that packages narrative, positioning, messaging, email templates, co-branded collateral, and attribution links, so partners (or their AI agents) can pull it and launch in their own marketing tooling, with incentives and an announcement wired in.
**Sample prompts that fire this skill:**
- "build a campaign kit"
- "package this campaign for partners"
- "make a syndicatable campaign"
- "assemble the launch kit for the Q3 promo"
- "create a partner campaign bundle"
- "ship this campaign to partners"
## Why this matters
Revenue-driving partners already have their own marketing tooling, and forcing them into a PRM to build a campaign kills adoption, which clears **60%** only when partners can launch in minutes in the tools they already use. The vendor's job isn't to be the partner's campaign tool; it's to supply an AI-ready, attributable kit that makes the partner's own tool productive. A well-formed kit is also machine-readable, so a partner's AI agent can assemble a ready-to-send campaign from it directly.
## Inputs to gather
- **Campaign brief**: the offer, target audience, key message, and CTA.
- **Source material**: narrative, positioning points, existing email copy, blog / launch content to derive from.
- **Co-branded collateral**: templates partners will personalize (see `vendor-cobranded-collateral-generator`).
- **Attribution**: the affiliate link scheme and end-user form for this campaign.
- **Incentive**: the commission plan to tie the campaign to, if any.
## Process
### Step 1: Assemble the kit contents
- Draft or collect the kit components: campaign narrative, positioning, 2–4 email templates (sequence-ready for a drip), social copy, and links to the co-branded collateral. Write everything partner-ready and format it so an AI agent can parse each component (clear headings, one asset per purpose).
### Step 2: Wire attribution into the kit
- Include the campaign's affiliate link and end-user form so every partner launch is attributable back to the partner. The kit should never ship without attribution; that's what closes the loop.
### Step 3: Resolve the audience and publish
- `Introw:search_partners`: determine the eligible segment (tier / region / vertical).
- `Introw:get_tier_information`: confirm tier entitlements that affect eligibility or messaging.
- Publish the kit as a governed, discoverable bundle in the content library / asset hub, visible to the target segment, so both partners and their AI agents can find it.
### Step 4: Tie to an incentive
- Enroll participating partners in the dedicated commission plan for the campaign, so they earn on the demand it drives. Confirm the plan is live before announcing.
### Step 5: Announce and track
- Draft the launch announcement (do not auto-broadcast; human approval before send) so partners know the kit is live and incentivized.
- `Introw:search_partner_engagement` at 7 / 14 / 30 days to measure kit adoption and campaign engagement.
- `Introw:add_comment` on the campaign record to log the kit contents, audience, and incentive tie-in.
## Output format
- **Kit manifest**: every component (narrative, positioning, email sequence, social copy, co-branded collateral, attribution assets) with its purpose.
- **Audience**: segment definition and recipient count.
- **Attribution plan**: affiliate link scheme + form wired into the kit.
- **Incentive**: commission plan tied to the campaign.
- **Announcement draft**: ready for review.
- **Tracking plan**: when and how adoption / engagement is measured.
## Guardrails & PRM best practice
- **Attribution is non-negotiable.** Never publish a kit without affiliate links / forms; an unattributable campaign defeats the purpose.
- **Don't auto-broadcast.** The skill ends at a drafted announcement + eligible list; a human approves the send.
- **Segment, don't blast.** If the eligible segment is > 50% of all partners, push back and segment harder.
- **AI-readable structure.** Keep each component discrete and clearly labeled so a partner's agent can consume the kit reliably.
- **Confirm the incentive is live** before announcing. Announcing an incentive that isn't active erodes trust.
- **Localization is not translation.** If the kit targets multiple regions, adapt tone and emphasis, don't just translate.
- **Cross-skill handoff.**
- Generate the co-branded collateral via `vendor-cobranded-collateral-generator`.
- Partners launch the kit via `partner-drip-campaign-from-assets`.
- For continuous to-partner communication off source content, see `vendor-content-radar`.
```
Drop this file into `.claude/skills/vendor-campaign-kit-builder/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Co-branded Collateral Generator
Source: https://docs.introw.io/headless/skills/vendor/cobranded-collateral-generator
Turn a vendor template into fully co-branded PDF, DOCX, or JPEG collateral for every partner and publish it to the portal and asset hub.
*Vendor skill for [Through-Channel Marketing](/headless/agentic-use-cases/through-channel-marketing).*
**Skill ID:** `vendor-cobranded-collateral-generator`
Use when a Partner Marketing Manager wants to turn a vendor template into fully co-branded collateral for every partner, generating per-partner PDF, DOCX, or JPEG versions and publishing them to the portal and asset hub. Trigger phrases include "co-brand this for our partners", "generate co-branded collateral", "make a partner-branded version", "co-brand the campaign one-pager", "roll out co-branded assets", "generate branded PDFs for all partners".
**Built for:** Partner Marketing Manager · Vendor Marketing
**Workflow:** Pick template + audience → Merge partner branding per format → Generate PDF/DOCX/JPEG per partner → Publish to portal + log
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-cobranded-collateral-generator
description: Use when a Partner Marketing Manager wants to turn a vendor template into fully co-branded collateral for every partner, generating per-partner PDF, DOCX, or JPEG versions and publishing them to the portal and asset hub. Trigger phrases include "co-brand this for our partners", "generate co-branded collateral", "make a partner-branded version", "co-brand the campaign one-pager", "roll out co-branded assets", "generate branded PDFs for all partners".
---
# Co-branded Collateral Generator (Vendor)
**Audience**: Vendor (**claude.ai Introw** MCP).
**Use case**: Through-Channel Marketing (TCMA).
## When to use this skill
Use when a Partner Marketing Manager wants to produce fully co-branded collateral (not a logo stitched onto a deck, but on-brand documents carrying both the vendor's and the partner's branding) for one partner, a segment, or the whole partner base, and publish them where partners can self-serve.
**Sample prompts that fire this skill:**
- "co-brand this for our partners"
- "generate co-branded collateral"
- "make a partner-branded version of the campaign one-pager"
- "roll out co-branded assets to Gold partners"
- "generate branded PDFs for all partners"
## Why this matters
Co-marketing stalls when every co-branded asset is a one-off design request. Most channel partners have **zero dedicated marketing or design staff**, so collateral that isn't ready-to-use simply never ships. Generating fully co-branded assets from a governed template, in whatever format the partner needs (PDF, DOCX, JPEG), removes the design bottleneck and lets co-marketing scale to hundreds of partners while staying on-brand for both sides.
## Inputs to gather
- **Source template**: the base asset with vendor branding and placeholders for partner name / logo / details (a PDF with named form fields, or an equivalent template).
- **Target audience**: all partners, a segment (tier / region / vertical), or a named list.
- **Output format(s)**: PDF, DOCX, JPEG, or several.
- **Distribution target**: which portal experience / asset hub the copies should surface in.
## Process
### Step 1: Confirm the template and its editable areas
- Confirm which parts of the template are locked (stay as vendor branding) and which are co-branding fields (partner name, logo, contact details). Locked areas protect brand consistency; only the co-branding fields change per partner.
### Step 2: Resolve the audience
- `Introw:search_partners`: pull the target roster with tier / region / vertical.
- Confirm each partner has branding captured (logo + details). Flag partners missing a logo: they will get a copy generated **without** their brand unless fixed first.
### Step 3: Generate per-partner, per-format
- For each partner, merge their branding into the template and generate the requested format(s). Produce one co-branded copy per partner, saved as a partner-specific asset that belongs to that partner only.
- Report any partner whose copy could not be produced (missing branding, template error) so the source can be fixed and re-run.
### Step 4: Publish and surface
- Surface each partner's copy through a partner-specific asset hub in a portal experience, so each partner finds only their own co-branded version.
### Step 5: Log
- `Introw:add_comment` on the relevant partner or campaign record to log which collateral was generated and distributed, for audit trail.
## Output format
- **Generation summary**: template used, audience size, formats produced.
- **Per-partner result**: partner, formats generated, distribution target, status (done / skipped-missing-branding / error).
- **Fix list**: partners missing branding that need attention before a re-run.
- **Distribution note**: where each partner will find their copy.
## Guardrails & PRM best practice
- **Lock the brand.** Anything that must stay on-brand is locked in the template, not left editable.
- **No brand, no fake brand.** A partner missing a logo gets a vendor-only copy or is skipped; never fabricate partner branding.
- **Partner-scoped assets.** Each generated copy belongs to one partner; never expose one partner's co-branded asset to another.
- **Format fidelity.** Confirm the output format renders correctly (fonts, image resolution for JPEG) before broad rollout: generate one sample and review.
- **Human review on new templates.** For a template's first run, review one generated copy before generating for the whole base.
- **Cross-skill handoff.**
- Bundle the generated collateral into a campaign via `vendor-campaign-kit-builder`.
- Partners can self-generate their own versions via `partner-cobrand-my-collateral`.
```
Drop this file into `.claude/skills/vendor-cobranded-collateral-generator/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Content Radar & Distribution
Source: https://docs.introw.io/headless/skills/vendor/content-radar
Continuous content radar scanning release notes, LinkedIn, blogs, and competitor news, then distributing partner-ready messaging per segment through Introw.
*Vendor skill for [Use case 07: Campaigns & Announcements](/headless/agentic-use-cases/campaigns-and-announcements).*
**Skill ID:** `vendor-content-radar`
Use when a Partner Marketing Manager wants a continuous-running content radar, scanning the vendor's release notes, LinkedIn, blogs, industry publications, and competitor news for partner-relevant content, transforming relevant items into partner-ready messaging per segment, and distributing + tracking through Introw. Auto-updates partners on new product releases. Trigger phrases include "scan release notes", "update partners on new releases", "convert release notes to partner outreach", "scan LinkedIn for partner content", "content radar", "what's new for partners this week", "convert blog posts to partner outreach", "weekly partner content sweep", "competitive content distribution".
**Built for:** Partner Marketing Manager · Vendor Marketing
**Workflow:** Release notes · LinkedIn · blog · Loom → Relevance · 3 derivatives per item → Tier · region · vertical · type → Right channel · engagement-tracked
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-content-radar
description: Use when a Partner Marketing Manager wants a continuous-running content radar, scanning the vendor's release notes, LinkedIn, blogs, industry publications, and competitor news for partner-relevant content, transforming relevant items into partner-ready messaging per segment, and distributing + tracking through Introw. Auto-updates partners on new product releases. Trigger phrases include "scan release notes", "update partners on new releases", "convert release notes to partner outreach", "scan LinkedIn for partner content", "content radar", "what's new for partners this week", "convert blog posts to partner outreach", "weekly partner content sweep", "competitive content distribution".
---
# Content Radar & Distribution (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP (+ WebFetch / WebSearch, and any installed LinkedIn / RSS / blog MCPs).
**Use case**: 07, Campaigns & Announcements.
## When to use this skill
Use when a Partner Marketing Manager wants a continuous-running content radar, scanning the vendor's release notes, LinkedIn, blogs, industry publications, and competitor news for partner-relevant content, transforming relevant items into partner-ready messaging per segment, and distributing + tracking through Introw. Auto-updates partners on new product releases.
**Sample prompts that fire this skill:**
- "scan release notes"
- "update partners on new releases"
- "convert release notes to partner outreach"
- "scan LinkedIn for partner content"
- "content radar"
- "what's new for partners this week"
- "convert blog posts to partner outreach"
- "weekly partner content sweep"
- "competitive content distribution"
## Why this matters
**96% of B2B marketers expect to grow channel revenue** (Demand Gen Report): but most can't, because their partners aren't sufficiently informed. Communication is the carrier wave for everything else: campaigns, launches, competitive responses, customer wins. Manual production caps the partner marketing manager at ~4 partner-facing communications/month; agentic radar+segment+distribute lifts that to **40–80 (10–20×)** without hiring, with **2–4× engagement** vs. generic blasts. Competitive responses ship in **under one hour** instead of weeks.
This skill is a **continuously-running radar**, not a one-shot generator. It scans, filters, transforms, distributes, and tracks, and is meant to run on a cadence (weekly default) so partner-facing content velocity is sustained.
## Sources to monitor
1. **Release notes / changelog feeds / product update pages**: the **highest-leverage source** for partners. Every shipped feature is something partners need to position with prospects, but most release notes never reach partner-facing comms in time. Sources include Notion / Confluence release pages, public changelog URLs, and vendor docs sites.
2. **Vendor's own LinkedIn**: exec posts, brand posts, employee thought leadership. (Vendor's best content historically dies in the partner channel.)
3. **Vendor blog / press / launch feeds.**
4. **Industry publications**: partner-relevant analyst notes, trend pieces, customer-vertical news.
5. **Competitor moves**: public announcements, pricing changes, leadership changes that change the partner's competitive context.
6. **Customer wins / case studies** as they're published.
7. **Loom / video drops** the executive team shares, extract transcript, treat as a content source.
The user should configure source URLs / handles up front; the skill scans them.
## Process
### Step 1: Scan
- **Release notes**: use installed knowledge-base MCPs (Notion, Confluence, Box, Google Drive) when the changelog lives there; otherwise WebFetch on the public changelog URL or RSS feed. Capture each release entry with version, date, title, body, and any tagging the vendor applies (feature / fix / breaking change / pricing / packaging).
- **LinkedIn**: use installed LinkedIn MCP if available; otherwise WebFetch on profile/company pages or rely on a saved RSS-style feed.
- **Blogs / publications**: WebFetch on the source, or RSS MCP if installed.
- **Competitor news**: WebSearch with site filters.
- Tag each item with source + publish-date + raw text.
### Step 2: Filter to partner-relevant content
For each candidate item, score relevance:
- **Product / feature update** that partners need to know to sell.
- **Competitive response** material, how to position vs. a competitor's move.
- **Customer win**: case study a partner can use in their own outreach.
- **Industry / vertical signal**: context for partners selling into that vertical.
- **Executive thought leadership** that the partner can reshare or quote.
- **Compliance / regulatory** signal that affects partner motion.
Drop low-relevance items (internal HR posts, generic "we're hiring" content, anniversary celebrations): relevance discipline is the whole point.
**Release-notes-specific filtering** (release notes need their own classifier, most release entries are ignorable to partners):
- **Customer-facing feature** (visible to end users / changes the demo / unlocks new use cases) → **push** (high priority).
- **Competitive implications** (closes a gap vs. a named competitor / answers a recurring objection) → **push + flag for battle-card update**.
- **Pricing / packaging change** (new SKU, price move, billing change, tier-eligibility change) → **push urgent** + escalate to channel leadership before broadcast.
- **Integration / API change** that affects partners building on the platform → **push to SI / ISV partners specifically**.
- **Compliance / security attestation update** (new SOC 2, ISO, FedRAMP, regional certs) → **push to vertical-specialist partners** (healthcare, financial services, public sector).
- **Bug fix / internal-only change** → **skip** (no partner value; clutters the channel).
- **Breaking change / deprecation** → **push urgent** with migration guidance, partners with affected customers need lead time.
### Step 3: Segment + transform per audience
For each high-relevance item, generate partner-ready variants segmented by:
- **Tier** (Gold gets co-sell language; Bronze gets enablement-led).
- **Region / language** (DACH = compliance-forward; LATAM = use-case-forward).
- **Partner type** (SI = technical depth; reseller = transactional CTA; referral = warm-intro framing).
- **Vertical specialty** (healthcare partners get HIPAA-flavored framing).
Each variant should:
- Open with relevance to the partner ("As a healthcare-focused SI, here's what changed this week…").
- State the takeaway in 1–2 sentences (partners don't read filler).
- Provide the asset / next step (link, asset ID, deal-reg deep link).
- Carry a clear CTA (use the new battle card, register a deal, attend the webinar, share with prospects).
**Release-notes-specific transforms**: for each pushed release item, generate three derivatives, not just one:
- (a) **One-line "what's new" alert** per partner segment, a Slack-or-email-friendly headline that says what shipped, who it benefits, and the link to learn more.
- (b) **Talking points for partner sellers in active deals where the feature matters**: cross-check open deals via `Introw:search_crm_objects` and surface the partners with relevant pipeline; their version of the alert includes named deals and the specific positioning angle.
- (c) **Customer-ready outreach template**: a forward-able message the partner can lightly edit and send to prospects/customers in their pipeline. Frames the new capability as a reason to (re-)engage.
### Step 4: Build segmentation context from Introw
- `Introw:search_partners`: current partner roster with tier/region/categories.
- `Introw:get_tier_information`: tier-specific entitlements that affect message framing.
- `Introw:search_partner_engagement`: last-touch saturation: skip recipients who got 2+ touches in the last 14 days.
### Step 5: Distribute
For each variant × segment:
- Push via the partner's preferred channel (email, Slack, Teams, portal announcement).
- For high-priority items (product launch, competitive response), include a `share_lead_or_register_deal` deep link to convert reading into action.
- Use `Introw:add_comment` on the relevant partner records or campaign record for audit trail.
### Step 6: Track engagement
- Use `Introw:search_partner_engagement` 7 / 14 / 30 days post-send to measure response (asset views, comments, registrations attributable to the campaign).
- Surface engagement asymmetry, if Variant A landed in DACH but Variant B died in NA, feed that back into the next radar cycle.
- Use `Introw:add_comment` to log the campaign performance summary on each campaign event.
## Output format
- **Radar digest**: scanned items with relevance score and disposition (publish / skip / route).
- **Release notes this cycle**: dedicated section listing every release item scanned + its disposition (push / skip / route) + variant set if pushed (alert, seller talking points, customer-ready template). Embargo flags called out.
- **Per-published-item**: segment list × variants drafted, with channel and send window.
- **Recipient counts** per variant.
- **Suppression list** for engagement-saturated partners.
- **Tracking plan**: when and how engagement gets measured.
- **Next-cycle improvements**: what worked, what to drop.
## Guardrails & PRM best practice
- **Relevance discipline.** A radar that publishes generic content trains partners to ignore the channel. Be aggressive about filtering, better 3 high-relevance items per week than 30 mediocre ones.
- **Segment, don't blast.** If a variant's recipient count is > 50% of total partners, the segment is too broad, push back and segment harder.
- **Source attribution.** When sharing competitor or industry content, link the source, partners trust attribution.
- **Localization is not translation.** Adapt tone and emphasis per region, don't just google-translate.
- **Don't auto-send launches or pricing comms.** Skill ends at draft + recipient list for those, human approval before broadcast.
- **Tier-fairness.** Don't strip the long tail; give them a tier-appropriate variant. Exclusion erodes trust.
- **Compliance scope.** Region-specific disclaimers, opt-out language, GDPR consent checks before sends to EU partners.
- **Track to revenue, not opens.** Tie campaigns to deal-registration uplift in targeted segments via `Introw:search_form_submissions` over the trailing 30 days.
- **Run on cadence.** Radar value compounds with frequency. Weekly default; daily for active competitive periods or product launches.
- **Don't pre-announce embargoed releases.** Some release entries are partner-NDA-only until GA, respect embargo and disclosure dates strictly. If the source includes embargo metadata, treat it as authoritative; if not, default to "internal partner-team only" until you confirm GA status.
- **Don't auto-push breaking changes / deprecations** without a coordinated migration plan, partners with affected customers need vendor-side support engagement, not just a notification.
- **Cross-skill handoff.**
- Recurring objection-related features (a release that addresses a known closed-lost reason) → `vendor-microcourse-from-closed-lost` to author a targeted micro-course.
- Release alerts feed the partner-side `partner-cross-vendor-content-calendar` view so partners see vendor activity on their own calendar.
- Strategic content (major launches, exec posts) → `vendor-generate-segmented-campaign` for higher-effort treatment.
```
Drop this file into `.claude/skills/vendor-content-radar/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Crossbeam Co-Sell Partner Finder
Source: https://docs.introw.io/headless/skills/vendor/crossbeam-cosell-finder
Find the best co-sell partners for a target account list by combining Crossbeam overlap data with Introw partner performance signals.
*Vendor skill for [Use case 02: Partner Segmentation](/headless/agentic-use-cases/partner-segmentation).*
**Skill ID:** `vendor-crossbeam-cosell-finder`
Use when a Channel Chief, RevOps, AE-aligned Channel Manager, or PDM wants to find the best partner(s) to bring into a target account list, by combining Crossbeam overlap data with Introw partner performance signals. Trigger phrases include "find partners that overlap with these accounts", "Crossbeam co-sell", "ELG partner match", "who already has the customer", "ecosystem-led match", "best partner for this target list", "warmest overlap on Account X".
**Built for:** Alliance Manager · Channel RevOps · Partner Development Manager
**Workflow:** Open opps · ABM · expansion candidates → Customer · opp · champion · lapsed → Overlap × engagement × prior wins → Drafted intro · pre-filled registration
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-crossbeam-cosell-finder
description: Use when a Channel Chief, RevOps, AE-aligned Channel Manager, or PDM wants to find the best partner(s) to bring into a target account list, by combining Crossbeam overlap data with Introw partner performance signals. Trigger phrases include "find partners that overlap with these accounts", "Crossbeam co-sell", "ELG partner match", "who already has the customer", "ecosystem-led match", "best partner for this target list", "warmest overlap on Account X".
---
# Crossbeam Co-Sell Partner Finder (Vendor)
**Audience**: Vendor, uses **claude.ai Introw** MCP + **claude.ai Crossbeam** MCP.
**Use case**: 02, Partner Segmentation (with strong cross-cut to 08 Deal Registration / 11 Coaching).
## When to use this skill
Use when a Channel Chief, RevOps, AE-aligned Channel Manager, or PDM wants to find the best partner(s) to bring into a target account list, by combining Crossbeam overlap data with Introw partner performance signals.
**Sample prompts that fire this skill:**
- "find partners that overlap with these accounts"
- "Crossbeam co-sell"
- "ELG partner match"
- "who already has the customer"
- "ecosystem-led match"
- "best partner for this target list"
- "warmest overlap on Account X"
## Why this matters
Ecosystem-Led Growth (ELG) only works when the ecosystem data is operationalized. Most channel teams have Crossbeam producing overlap data weekly, and most of that data dies in a spreadsheet because no one has time to translate "Partner X has a customer relationship with Account Y" into a concrete co-sell motion. This skill closes that gap: it cross-checks a target account list against partner overlap data, scores partner-account fit using Introw performance signals (engagement, prior similar wins, certifications), and drafts the partner intro request.
For partners involved in deals: industry research consistently shows partner-influenced deals close at materially higher win rates and larger ACVs than vendor-direct equivalents in the same segment, but only when the *right* partner is matched to the *right* deal.
## Inputs to gather first
- **Target account list**: open opportunities, ABM target accounts, expansion candidates, churned-customer reactivation list, or a stage-filter on the CRM.
- **Motion intent**: warm intro from partner / co-sell / channel-led full ownership / referral / customer reference.
- **Partner constraints**: tier eligibility, region, vertical, partner type (SI, reseller, referral, MSP).
## Process
### Step 1: Pull the target account list
- `Introw:search_crm_objects`: open deals in scope, or filter by stage / segment / region.
- Or accept the account list pasted in by the user.
- Capture each target's domain, segment, vertical, deal value, stage.
### Step 2: Pull overlap data from Crossbeam
- `Crossbeam:*`: for each target account, identify which partners have a customer relationship, opp, or evaluation in flight on that account.
- Capture overlap *type* (customer / opp / champion / lapsed): not just presence. A partner whose customer is your target is much warmer than a partner whose lapsed prospect is your target.
- Capture overlap *recency*, fresh overlaps beat stale ones.
### Step 3: Enrich with Introw partner performance
For each candidate partner-account match:
- `Introw:search_partners`: partner record (tier, region, vertical specialization, partner type).
- `Introw:search_crm_objects`: has this partner closed similar deals before (vertical × deal size × product)?
- `Introw:search_partner_engagement`: recent engagement intensity. A partner with the right overlap who's been silent for 90 days is a different play than one who's actively engaged.
- `Introw:get_tier_information`: tier eligibility for the product/segment.
### Step 4: Score partner-account fit
For each candidate match, combine:
- **Overlap strength** (customer > opp > champion > lapsed)
- **Overlap recency** (last 90 days > older)
- **Partner-deal historical fit** (vertical × deal size × product match)
- **Current engagement** (active vs. dormant)
- **Tier / certification eligibility** (hard pass if not eligible)
- **Channel-conflict cleanliness**: cross-check existing registrations to avoid placing partners on contested accounts.
### Step 5: Match the right partner per account
For each target account, select 1–3 partner candidates with the strongest case. For each, articulate the *why* in one sentence:
- "Partner A, has a 3-year customer relationship at Globex; recent engagement; closed 5 similar healthcare deals; Gold-tier and certified on relevant product."
### Step 6: Draft the motion
- For warm intro: draft a partner-facing message with the specific account, why we're asking, what's in it for them (margin, MDF eligibility, deal protection).
- For co-sell registration: pre-fill `share_lead_or_register_deal` payload and surface for vendor approval.
- For full handoff: draft the AE-to-partner handoff email with prospect context.
### Step 7: Capture and queue
- `Introw:add_comment` on the deal record with the matched partner + rationale.
- `Introw:add_task` for the AE or PDM to make the intro by a target date.
- If auto-action is enabled and conflict is clean: submit the registration via `share_lead_or_register_deal` with the captured context.
## Output format
- **Account-by-account match table**: account, value, stage, top-1/top-3 partner candidates, overlap type, overlap recency, fit score, why.
- **Drafted partner-facing messages** per match, copy-pasteable.
- **Registration payloads** for clean matches, ready for approval.
- **Conflict flags**: accounts with existing registrations or direct claims, surfaced not auto-actioned.
- **Aggregate insight**: which partners had the most matchable overlaps (informs future ABM/recruitment targeting).
## Guardrails & PRM best practice
- **Overlap data has lag.** Crossbeam refreshes typically run nightly or weekly; flag stale data and avoid acting on overlaps > 30 days old without confirmation.
- **Privacy & data sharing rules.** Crossbeam-shared data is scoped to your population groups; only surface overlaps within authorized data-sharing agreements. Never surface partner customer names outside the vendor-internal scope.
- **Channel conflict before action.** Always run conflict detection (existing registrations, direct claim, named-account list) before recommending placement. Crossbeam overlap doesn't override rules of engagement.
- **Don't poach.** Overlap with another partner's customer doesn't mean the second partner gets the deal, surface the existing relationship as context, not as a takeover signal.
- **Why beats overlap.** A weak overlap with strong fit (vertical, prior wins) often beats a strong overlap with weak fit. Don't let raw overlap count dominate scoring.
- **Tier-aware match.** Strategic deals to top-tier partners with proven enterprise motion; transactional deals to volume partners. Mismatching destroys margin and partner energy.
- **No auto-execution on first run.** Surface matches and rationale; let the human approve the first batch. Once the user has validated the matching logic, auto-action mode (auto-registration on clean matches) can be enabled.
- **Capture decisions** via `Introw:add_comment` on each deal, the AE/CAM picking it up next week needs to see why this partner was placed.
- **Respect dormant partners' state.** A perfect-overlap partner who's silent for 90+ days needs an activation play (`vendor-activate-network-with-personalized-campaigns`) before placement, not a deal handoff cold.
- **Cross-skill handoff.** Clean placements that need coaching → `vendor-deal-coach-from-similar-wins`. Conflicts → conflict-resolution flow. Coverage gaps revealed by the analysis → `vendor-acquisition-abm-orchestrator` (we should be recruiting partners for these segments).
```
Drop this file into `.claude/skills/vendor-crossbeam-cosell-finder/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Deal Coach from Similar Wins
Source: https://docs.introw.io/headless/skills/vendor/deal-coach-from-similar-wins
Coach a live partner deal by finding similar past wins (same vertical, deal size, product mix, partner type) and replicating the success patterns.
*Vendor skill for [Use case 11: Deal Coaching](/headless/agentic-use-cases/deal-coaching).*
**Skill ID:** `vendor-deal-coach-from-similar-wins`
Use when a CAM, PDM, or Channel Account Manager wants to coach a specific partner deal by first finding similar past won deals (same vertical, deal size, product mix, partner type), extracting the success patterns from those wins, and producing replication coaching for the live deal. Trigger phrases include "coach this deal from similar wins", "what worked on similar deals", "replicate past success", "find comparable wins for this deal", "how did we close deals like this before".
**Built for:** Channel Account Manager · Partner Development Manager
**Workflow:** The active partner deal in flight → Similar vertical · size · product · partner type → What worked · per stage · objection lines · assets → Persona-aware · in workspace · captured to deal
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-deal-coach-from-similar-wins
description: Use when a CAM, PDM, or Channel Account Manager wants to coach a specific partner deal by first finding similar past won deals (same vertical, deal size, product mix, partner type), extracting the success patterns from those wins, and producing replication coaching for the live deal. Trigger phrases include "coach this deal from similar wins", "what worked on similar deals", "replicate past success", "find comparable wins for this deal", "how did we close deals like this before".
---
# Deal Coach from Similar Wins (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP.
**Use case**: 11, Deal Coaching.
## When to use this skill
Use when a CAM, PDM, or Channel Account Manager wants to coach a specific partner deal by first finding similar past won deals (same vertical, deal size, product mix, partner type), extracting the success patterns from those wins, and producing replication coaching for the live deal.
**Sample prompts that fire this skill:**
- "coach this deal from similar wins"
- "what worked on similar deals"
- "replicate past success"
- "find comparable wins for this deal"
- "how did we close deals like this before"
## Why this matters
AI coaching tools improve win rates by **34% within six months** (Whatfix); structured coaching delivers **32% higher win rates and 28% higher quota attainment** (Korn Ferry); coached reps navigate objections **61% more effectively** (Careertrainer.ai). Partner-attached deals historically close at lower rates than direct because partner sellers haven't received the structured coaching their direct counterparts get weekly.
This skill's defining property: **coaching is grounded in this vendor's actual past wins, not generic playbook**. For every active partner deal, it finds the most analogous closed-won deals, extracts what worked at each stage, and prescribes how the partner can replicate that pattern. The customer-specific context, the objection-handling patterns, the asset usage, the time-to-close, all surfaced as evidence the partner can act on.
## Inputs to gather first
- **The active deal** (ID or named).
- **Specific concern** if any (objection, stalled stage, competitive pressure, close motion). If unspecified, run a full review.
- **Comparable scope**: trailing 12 months default; expand if signal is thin.
## Process
### Step 1: Pull the active deal context
- `Introw:search_crm_objects`: full deal record: stage, value, products, key contacts, last activity, close date, competitor mentions, recent comments.
- `Introw:search_partners`: submitting partner: tier, type (SI / reseller / referral / MSP), certifications, historical win rate.
- `Introw:search_partner_engagement`: recent activity on this deal (comments, asset views, registrations).
- `Introw:search_tasks`: open tasks tied to the deal.
Profile the active deal across the matching dimensions:
- Vertical / industry
- Deal size band
- Product mix
- Customer segment / size
- Geographic region
- Partner type
- Stage and stage-age
- Competitor named (if any)
- Stakeholder roles known
### Step 2: Find the comparable past wins
- `Introw:search_crm_objects`: closed-won deals in the trailing 12 months, filter to similar vertical / deal size / product / customer segment / region.
- Rank by similarity, the closer the customer profile and product mix, the higher the signal.
- Aim for 3–7 high-similarity wins; if fewer exist, expand the window or surface the thin-signal caveat.
If no similar wins exist (e.g., new vertical, new product), say so plainly, fabricated patterns are worse than honest absence.
### Step 3: Extract the success pattern across the wins
For each comparable win, mine the record:
- **Stage progression cadence**: how long in each stage; what signaled readiness to advance.
- **Champion / power dynamics**: who became the champion; how was economic buyer engaged.
- **Objections raised + how handled**: pull from `add_comment` history on those deals.
- **Asset usage**: which battle cards, case studies, ROI calculators were referenced.
- **Pricing motion**: how was deal protection / discounting handled.
- **Close motion**: what was the actual close-step sequence.
- **Time-to-close** distribution.
Synthesize across the wins: what's the *shared* pattern? Which patterns are vertical-specific vs. universal? Which partner-type-specific vs. transferable?
### Step 4: Map pattern to active deal
For the active deal, prescribe:
- **Stage-specific next moves**: what the comparable wins did at this stage age.
- **Champion-development play**: if the analogous wins had executive sponsor at this stage, surface that as a gap-or-confirmed.
- **Objection prep**: recurring objections from the comparables, with the actual handling lines that worked.
- **Asset suggestions**: the specific assets used in comparables, retrievable from the partner's enablement library.
- **Reference customers**: name the comparable closed-won customers (where appropriate to share) as reference candidates.
- **Risk flags**: patterns from comparable lost-or-stalled deals to actively avoid.
- **Close timeline**: realistic close estimate based on comparable cycle length.
### Step 5: Persona-aware delivery
Tailor the coaching by partner type:
- **SI**: emphasize multi-product attach, services revenue, deployment roadmap, executive stakeholder mapping.
- **Reseller**: emphasize margin protection, deal-protection registration, fast quote, transactional close.
- **Referral**: emphasize warm-intro quality, handoff cleanliness, attribution.
- **MSP**: emphasize recurring-revenue framing, multi-tenant fit.
- **Marketplace**: emphasize procurement velocity, billing motion.
### Step 6: Capture and hand off
- `Introw:add_comment` on the active deal, log the comparable wins referenced and the coaching delivered. The next CAM picking up this deal sees the coaching trail.
- `Introw:add_task` for the partner, convert the top 3 next actions into trackable tasks with due dates.
- If the partner is on the `partner-coach-my-deal` flow, this coaching is visible to them via the comment.
## Output format
- **Active deal snapshot**: 2 lines.
- **Comparable wins**: 3–7 most similar closed-won deals with similarity rationale.
- **Extracted pattern**: what worked at each stage, with evidence references.
- **Prescription for this deal**: top 3 next actions, objection-handling lines, assets to use, reference customers, risk flags, close estimate.
- **Logged artifacts**: comment IDs and task IDs created.
## Guardrails & PRM best practice
- **Evidence over generic.** Every coaching point traces to a specific past won deal or pattern across them. "Generic playbook" coaching loses to evidence-grounded coaching every time.
- **Honest signal density.** If comparable wins are thin (< 3), say so. Don't extrapolate from one comparable as if it were a pattern.
- **Persona match is non-negotiable.** Coaching an SI like a transactional reseller breaks both the deal and the relationship.
- **Don't share confidential customer data inappropriately.** Reference customers by name only where the partner is authorized to discuss them; otherwise share the pattern without disclosing the comparable customer's identity.
- **Surface, don't seize.** PDM coaches the partner; the partner runs the deal. Never propose direct outreach from the vendor that bypasses the partner's relationship.
- **Capture the coaching.** `Introw:add_comment` on the deal so the QBR has the trail and the partner can see what was discussed.
- **Time-to-close honesty.** If the comparables suggest a longer cycle than the partner's stated close date, surface the gap, false hope on close dates corrupts the forecast.
- **Risk flags, not just success patterns.** Comparable *lost* deals carry as much signal as comparable wins, surface the avoidance patterns explicitly.
- **Cross-skill handoff.** Coaching reveals a training gap → `vendor-microcourse-from-closed-lost` or `vendor-training-gap-analysis`. Coaching reveals a partner-fit issue → `vendor-pipeline-partner-influence-scout` to consider re-placement.
- **Don't over-coach.** A partner who gets 8 coaching nudges per deal will tune them all out. Top 3 next actions; if the partner needs more, schedule a CAM call.
```
Drop this file into `.claude/skills/vendor-deal-coach-from-similar-wins/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Email Deal Registration Watcher
Source: https://docs.introw.io/headless/skills/vendor/email-deal-registration-watcher
Scan Gmail or Outlook for partner deal and lead registration emails, then auto-extract fields, validate, dedupe against CRM, and process through Introw.
*Vendor skill for [Use case 08: Deal Registration](/headless/agentic-use-cases/deal-registration).*
**Skill ID:** `vendor-email-deal-registration-watcher`
Use when a Channel Ops, RevOps, or PDM user wants to scan the vendor's Gmail or Outlook inbox for partner emails containing deal or lead registrations, auto-extract fields, validate, deduplicate against the CRM, and process the registration through Introw. Trigger phrases include "scan inbox for deal regs", "process partner emails", "watch inbox for registrations", "auto-process deal regs from email", "find off-portal deal regs", "convert email registrations".
**Built for:** Channel Ops Manager · Channel RevOps · Partner Development Manager
**Workflow:** Vendor mailbox sweep → Detect intent · pull fields · attribute → Duplicate · conflict · eligibility → Clean submission · partner notified
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-email-deal-registration-watcher
description: Use when a Channel Ops, RevOps, or PDM user wants to scan the vendor's Gmail or Outlook inbox for partner emails containing deal or lead registrations, auto-extract fields, validate, deduplicate against the CRM, and process the registration through Introw. Trigger phrases include "scan inbox for deal regs", "process partner emails", "watch inbox for registrations", "auto-process deal regs from email", "find off-portal deal regs", "convert email registrations".
---
# Email Deal Registration Watcher (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP + Gmail / Outlook MCP (whichever is installed for the vendor's mailbox).
**Use case**: 08, Deal Registration.
## When to use this skill
Use when a Channel Ops, RevOps, or PDM user wants to scan the vendor's Gmail or Outlook inbox for partner emails containing deal or lead registrations, auto-extract fields, validate, deduplicate against the CRM, and process the registration through Introw.
**Sample prompts that fire this skill:**
- "scan inbox for deal regs"
- "process partner emails"
- "watch inbox for registrations"
- "auto-process deal regs from email"
- "find off-portal deal regs"
- "convert email registrations"
## Why this matters
Deal registration is the foundational transaction of every channel program, but **forms with 7+ fields drop completion 34%** (Computer Market Research), and partner portal adoption falls below 30% when submission takes >2 minutes or approval exceeds 24h. The result: partners email AEs and channel ops directly with deal registrations, creating off-portal submissions that become Salesforce data hygiene projects, attribution gaps, and channel conflict. This skill flips that pattern, instead of forcing partners back into a portal, it **harvests the email submissions they already send** and processes them cleanly through Introw with proper attribution.
Every captured registration carries **10–15 points of additional margin** through deal protection plus access to MDF and pre-sales support.
## Process
### Step 1: Scope the inbox scan
Confirm with the user:
- Which mailbox(es)? Channel-ops shared inbox, AE inboxes, dedicated dealreg@ alias?
- Which time window? Default trailing 7 days, configurable.
- Which sender filters? E.g., only partners (skip internal threads, customer-direct).
### Step 2: Pull candidate emails
Via Gmail / Outlook MCP:
- Search trailing window with intent keywords (deal reg, register, opportunity, lead, prospect, account, lead share, please register, can you flag) plus partner-domain filters.
- Pull email bodies + threads + attachments.
- Skip auto-replies, internal forwards (unless they wrap a partner submission).
### Step 3: Classify per email
For each candidate:
- **Is this a deal/lead registration?** Yes / No / Maybe.
- If Yes: **what fields are present?** (account, contact, value, close date, product, qualification context).
- If Maybe: flag for human review with rationale.
- If No: skip.
### Step 4: Identify the partner
- Match sender domain against `Introw:search_partners` to identify the partner record.
- If domain isn't recognized, surface for human review, don't attribute to "unknown partner".
- Identify the specific contact at the partner (sender name + email).
### Step 5: Extract structured fields
Pull from the email body:
- **Account** (company name, domain).
- **Primary customer contact** (name, role, email, phone).
- **Estimated deal value** + currency.
- **Estimated close date**.
- **Product / segment**.
- **Use case / pain** (1–2 lines from email body).
- **Stage / signal** (just identified, in conversations, evaluating, ready to buy).
- Any vendor-specific custom fields configured in the form schema.
### Step 6: Pre-flight checks
- **Required-field completeness.** If a required field is missing, draft a follow-up reply to the partner asking for it (don't submit incomplete).
- **Duplicate detection.** `Introw:search_form_submissions` and `Introw:search_crm_objects` against account name + domain. If already registered (same partner) → reply with the existing reference rather than creating a duplicate.
- **Channel conflict check.** Cross-check the account against direct pipeline + other partner registrations. If conflict, flag for human review with conflict context (don't auto-submit a contested registration).
- **Tier / eligibility.** Confirm submitting partner's tier/cert covers the product/segment per vendor rules; if not, route for human review.
### Step 7: Submit
For clean, complete, conflict-free, eligible submissions:
- `Introw:share_lead_or_register_deal`: submit with all extracted fields and partner attribution.
- `Introw:add_comment` on the resulting deal record, capture the email source (subject, sender, timestamp) and the qualifying language from the email body so reviewers have full context.
### Step 8: Notify the partner
- Auto-reply (or draft for human send) to the partner email confirming:
- "Received and processed. Reference: #XYZ. Vendor SLA: 24h."
- Deal-protection benefit reminder (10–15 pts margin).
- Link to track status in their portal.
- For incomplete submissions, draft the targeted follow-up question.
### Step 9: Audit trail
- `Introw:add_comment` on the partner record summarizing the processed registration.
- Mark the email read / labeled "processed" so the next sweep doesn't reprocess.
- Track exceptions (incomplete, duplicate, conflict, ineligible) in a digest for the user.
## Output format
- **Inbox sweep summary**: emails scanned, classified counts, processed counts, exceptions.
- **Per-processed**: email source, partner, account, value, submission ID, comment ID.
- **Exceptions list**: incomplete (with drafted follow-up), duplicates (with existing ref), conflicts (with context), ineligibles (with reason).
- **Suggested next actions**: e.g., human review queue.
## Guardrails & PRM best practice
- **Never silent-submit.** Echo the captured fields back in the partner-facing confirmation reply so they can correct mistakes immediately.
- **Confirm the partner identity** by domain match, never guess attribution. "Unknown partner" goes to human review.
- **Channel conflict at intake is non-negotiable.** Don't auto-submit contested registrations, that's exactly the trust-eroding miss the registration process is supposed to prevent.
- **Don't auto-approve.** This skill submits; vendor rules and `vendor-process-approval-queue` decide approval. Frame partner-facing confirmation as "received, in review per SLA," not "approved."
- **Capture the source.** Every submission's audit trail includes the email subject, sender, and timestamp via `add_comment`: auditors will ask.
- **No silent rejections.** If a submission can't be processed (duplicate, ineligible), reply to the partner with reason, silence destroys trust faster than rejection.
- **Don't reply with sensitive context.** Auto-replies confirm receipt; they don't disclose other partners' or vendor-internal data.
- **Idempotency.** Mark processed emails so a second sweep doesn't double-submit. If the inbox lacks labeling, maintain an internal seen-list.
- **Cross-skill handoff.** Conflicts feed `vendor-detect-channel-conflict`; clean submissions feed `vendor-review-deal-registrations` and `vendor-process-approval-queue`.
- **Privacy.** Customer PII in emails is processed for registration only; don't surface it in summaries that travel outside the channel ops scope.
- **Margin reminder in the confirmation reply.** Partners forget what registration earns them; the 10–15 pts deal-protection margin is the lever that drives them to register again next time.
```
Drop this file into `.claude/skills/vendor-email-deal-registration-watcher/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Micro-Courses from Closed-Lost Patterns
Source: https://docs.introw.io/headless/skills/vendor/microcourse-from-closed-lost
Detect patterns in closed-lost partner deals by lost-reason and context, then generate targeted micro-courses that address the gaps behind the losses.
*Vendor skill for [Use case 05: Training](/headless/agentic-use-cases/training).*
**Skill ID:** `vendor-microcourse-from-closed-lost`
Use when a Partner Enablement lead, Channel Chief, or RevOps user wants to detect patterns in closed-lost partner deals, clustering by lost-reason and customer context, and generate / suggest targeted micro-courses that address the specific gaps the losses reveal. Trigger phrases include "what are we losing on", "closed-lost patterns", "training from losses", "micro-courses from lost deals", "what should we train on next", "closed-lost driven enablement".
**Built for:** Partner Enablement Manager · Partner Program Manager · Channel RevOps
**Workflow:** Closed-lost partner deals + lost-reasons → Failure patterns → underlying gap (when loss-driven) → Outline · worked example · open-question rubric → Targeted to partners working similar pipeline
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-microcourse-from-closed-lost
description: Use when a Partner Enablement lead, Channel Chief, or RevOps user wants to detect patterns in closed-lost partner deals, clustering by lost-reason and customer context, and generate / suggest targeted micro-courses that address the specific gaps the losses reveal. Trigger phrases include "what are we losing on", "closed-lost patterns", "training from losses", "micro-courses from lost deals", "what should we train on next", "closed-lost driven enablement".
---
# Micro-Courses from Closed-Lost Patterns (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP.
**Use case**: 05, Training.
## When to use this skill
Use when a Partner Enablement lead, Channel Chief, or RevOps user wants to detect patterns in closed-lost partner deals, clustering by lost-reason and customer context, and generate / suggest targeted micro-courses that address the specific gaps the losses reveal.
**Sample prompts that fire this skill:**
- "what are we losing on"
- "closed-lost patterns"
- "training from losses"
- "micro-courses from lost deals"
- "what should we train on next"
- "closed-lost driven enablement"
## Why this matters
Up to **70% of training content is forgotten within 24 hours, 87% within a week** without reinforcement (Ebbinghaus / industry consensus). Static training catalogs accumulate content nobody uses while real, current losses go un-addressed. The signal that matters most: **partners losing deals tells you exactly what they need to learn**.
Introw can generate and push a 15-minute micro-course to all enabled resellers in **under one hour**: vs. the typical multi-week instructional design cycle. SalesHood / Whatfix research shows AI-coaching delivers **38% skill improvement, 40% faster time to readiness, and 32% win-rate lift** within six months. The leverage move: drive the next micro-course from the gap a closed-lost cluster just exposed.
## Process
### Step 1: Define the loss cohort
Default: closed-lost partner-attached deals over the trailing 90 days. Confirm with the user. Optional scoping: by partner type, region, product, or specific competitor.
### Step 2: Pull the data
- `Introw:search_crm_objects`: closed-lost deals in scope, with full record (vertical, deal size, products, stage at loss, lost-reason, competitor, key contacts, last activity).
- `Introw:search_partner_engagement`: engagement on those deals (was the partner active or absent in the late stages?).
- `Introw:search_partners`: partner profile for each lost deal (tier, certifications held).
- `Introw:search_tasks`: task history (was anything stuck or skipped?).
- Comment history on each deal via `Introw:search_crm_objects` notes for objection / blocker context.
### Step 3: Cluster by failure pattern
Group losses into patterns rather than treating each as one-off. Common clusters:
- **Pricing / packaging objection**: partner couldn't defend price or pitched wrong SKU.
- **Competitor positioning**: partner lost head-to-head against a specific competitor.
- **Technical-fit / capability**: buyer concluded the product didn't fit; partner couldn't address technical objection.
- **Implementation / timeline**: buyer concerned about deployment risk; partner lacked services answer.
- **Champion loss / power gap**: internal champion left or never emerged.
- **No decision**: buyer stalled; partner couldn't drive urgency.
- **Compliance / security**: buyer concern partner couldn't address (HIPAA, SOC 2, GDPR).
- **Late-stage discovery gap**: discovery wasn't deep enough early on.
For each cluster, capture:
- **Volume** (how many deals).
- **Aggregate value lost.**
- **Affected partners** (which partners lost most often in this pattern; which partner types).
- **Affected verticals / regions / products.**
- **Sample evidence**: 2–3 representative deals with quotes from the lost-reason notes.
### Step 4: Diagnose the underlying gap per cluster
What knowledge / skill / asset / motion would have changed the outcome? Examples:
- Pricing objection cluster → partner needs ROI-calculator competency + pricing-defense talk-track.
- Competitor cluster → partner needs current battle card + 2–3 fresh competitive case studies.
- Technical-fit cluster → partner needs deeper product-architecture training for that vertical.
- Implementation cluster → partner needs deployment-services-positioning training.
- Champion-loss cluster → partner needs MEDDIC-style champion-development coaching.
- Compliance cluster → partner needs vertical-specific compliance positioning.
### Step 5: Generate the micro-course outline per gap
For each high-priority cluster, draft a micro-course that meets Introw's training model:
- **Length**: 15–30 min, deployable in under 1 hour.
- **Pulls from**: vendor's existing knowledge base (Notion, Confluence, product docs, asset library): don't fabricate content.
- **Structure**:
- 2-min framing: the pattern that's costing us deals.
- 5-min content: the gap and how to close it.
- 5-min worked example: walk through a real (or anonymized) lost deal and the alternate path.
- **Open-question assessment** (not multiple choice): partner answers a real scenario in their own words; rubric grades response.
- Inline AI tutoring hook, partner can ask follow-ups during the course.
- **Asset bundle**: battle card / ROI calculator / case study / objection-handling cheat sheet attached.
### Step 6: Target the right partners
Per cluster, identify which partners benefit most:
- Partners with high concentration of losses in this pattern.
- Partners working pipeline that fits this profile (use `search_crm_objects` to find current active deals in the same vertical/competitive context).
- Partner-type-aware tailoring (the SI version vs. the reseller version).
- Tier-aware delivery (top tier may get a live walkthrough; long tail gets the async micro-course).
### Step 7: Distribute and track
- Push the course assignment via `Introw:add_task` per partner, with due-date.
- `Introw:add_comment` on each partner record explaining why this course was sent (refers to the loss cluster).
- Establish measurement: re-pull win-rate on similar deals 60 / 90 days post-deployment to validate impact (target: 32%+ win-rate lift on the addressed pattern, per Whatfix benchmarks).
## Output format
- **Loss cohort summary**: total deals, aggregate value, period.
- **Cluster table**: pattern, volume, value, affected partners/verticals, diagnosed gap.
- **Micro-course outlines** per priority cluster, title, learning objective, content sections, assessment scenario, asset bundle.
- **Distribution plan**: partner targets, channel, due-dates.
- **Measurement plan**: what to track, when, with what comparison.
## Guardrails & PRM best practice
- **Evidence-grounded.** Every micro-course traces to a specific cluster with sample lost-deal evidence. Generic "let's train on objection handling" without evidence misallocates effort.
- **Don't over-fragment.** If there's a dominant cluster (>40% of losses), focus there before fragmenting into 6 minor courses. Triage matters.
- **Open-question assessments only.** Multiple-choice quizzes get gamed (industry consensus); rubric-graded open-question assessments measure actual understanding.
- **Knowledge-base sourced.** Course content draws from existing vendor docs over MCP, not fabricated. Cite the source for every section.
- **Don't blame partners for ambiguous losses.** Some losses (no-decision, competitor pre-empted, customer reorg) aren't training gaps. Filter cleanly before clustering.
- **Tier and persona awareness.** A reseller and an SI losing the same way may need different versions of the course, generate variants.
- **Compliance-cluster sensitivity.** Compliance losses (HIPAA, SOC 2, GDPR) may need legal-team review of the course content before distribution, flag it.
- **Don't auto-distribute without human sign-off on first cycle.** Surface the courses + targets; get user approval before pushing tasks.
- **Measure impact.** Pair every course deployment with a post-period win-rate measurement on the addressed pattern. If the pattern's win-rate doesn't improve, the diagnosis or course was wrong, surface that loop.
- **Cross-skill handoff.** Pattern reveals a coaching gap on live deals → `vendor-deal-coach-from-similar-wins`. Pattern reveals a partner-fit issue → `vendor-training-gap-analysis` for tier-coverage view.
```
Drop this file into `.claude/skills/vendor-microcourse-from-closed-lost/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Personalized Onboarding Orchestrator from Transcripts
Source: https://docs.introw.io/headless/skills/vendor/personalized-onboarding-from-transcripts
Spin up a personalized onboarding plan for a new partner from meeting transcripts (kickoff, intro, fit calls), with tasks, owners, and due dates in Introw.
*Vendor skill for [Use case 03: Onboarding](/headless/agentic-use-cases/onboarding).*
**Skill ID:** `vendor-personalized-onboarding-from-transcripts`
Use when a CAM, PDM, or Channel Ops user wants to spin up a personalized onboarding plan for a new partner, using meeting transcripts (kickoff calls, intro meetings, partnership-fit conversations) plus existing partner context, then assigning every task with owner + due date in Introw and managing the project headlessly. Trigger phrases include "set up onboarding for \[partner]", "personalized onboarding plan", "build onboarding from this transcript", "onboard \[partner] based on our kickoff call", "headless onboarding project".
**Built for:** Channel Account Manager · Partner Development Manager · Channel Ops Manager
**Workflow:** Transcript + existing partner data → Commitments · capabilities · constraints (templates from playbook) → Owners · due dates · why-notes → Multi-channel chase + checkpoints
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-personalized-onboarding-from-transcripts
description: Use when a CAM, PDM, or Channel Ops user wants to spin up a personalized onboarding plan for a new partner, using meeting transcripts (kickoff calls, intro meetings, partnership-fit conversations) plus existing partner context, then assigning every task with owner + due date in Introw and managing the project headlessly. Trigger phrases include "set up onboarding for [partner]", "personalized onboarding plan", "build onboarding from this transcript", "onboard [partner] based on our kickoff call", "headless onboarding project".
---
# Personalized Onboarding Orchestrator from Transcripts (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP (+ optional transcript MCP: Otter, Fathom, Gong, Read.ai, Granola, or transcript pasted into the conversation).
**Use case**: 03, Onboarding.
## When to use this skill
Use when a CAM, PDM, or Channel Ops user wants to spin up a personalized onboarding plan for a new partner, using meeting transcripts (kickoff calls, intro meetings, partnership-fit conversations) plus existing partner context, then assigning every task with owner + due date in Introw and managing the project headlessly.
**Sample prompts that fire this skill:**
- "set up onboarding for [partner]"
- "personalized onboarding plan"
- "build onboarding from this transcript"
- "onboard [partner] based on our kickoff call"
- "headless onboarding project"
## Why this matters
Without structured onboarding, average channel partner time-to-productivity is **6–12 months** (Magentrix); structured programs compress this to **60–90 days**. Partners who close their first deal within 90 days are **3–4× more likely** to remain active at one year (Unifyr Channel Atlas). The first 90 days set the partner's belief about what working with this vendor *feels like*. A CAM responsible for 30 partners typically spends **6–8 hours/week** on routine onboarding chasing, **300–400 hours/year** that should be redirected to relationship work, not reminder-bot duty.
The differentiator of this skill: most onboarding plans are template-driven and ignore what the partner actually said in the kickoff call. This one starts from the transcript and personalizes the journey to the partner's stated commitments, capabilities, target verticals, tech stack, and constraints.
## Inputs to gather first
- **Partner identity** + portal/CRM record.
- **Source transcripts**: kickoff call, partnership-fit conversation, technical scoping call. Pasted text or transcript-MCP reference.
- **Partner type**: reseller, SI, referral, MSP, ISV, marketplace, drives default journey shape.
- **Target time-to-first-deal**: default 60–90 days.
- **Owner assignment defaults**: who's the CAM, who's the technical lead, who's the marketing buddy.
## Process
### Step 1: Pull partner context
- `Introw:search_partners`: partner record (tier, categories, region, lifecycle stage).
- `Introw:search_crm_objects`: any pre-existing deals or pipeline.
- `Introw:get_tier_information`: what tier eligibility looks like; what onboarding completion unlocks.
- `Introw:get_goals`: any pre-set goals for this partner / cohort.
### Step 2: Mine the transcripts
Extract structured signal from the meeting transcripts:
- **Stated commitments**: what the partner promised (cert by X date, first deal in Y verticals, attend Z webinar).
- **Capabilities**: current product knowledge, sales motion, tooling, certifications already held.
- **Target customer profile**: verticals, segments, regions they sell into.
- **Tech stack**: what they integrate, what they resell, what they avoid.
- **Constraints**: bandwidth, competing priorities, holiday windows, hiring plans.
- **Stakeholders**: who attends QBRs, who runs marketing, who closes deals.
- **Risks raised**: anything the partner flagged as friction-likely.
If transcripts are absent, surface that and ask the user for the most recent meeting notes, *don't fabricate context*.
### Step 3: Generate the personalized onboarding plan
Build a journey with milestones, not just a task checklist:
- **Day 0–7**: orientation + portal access + first-90-days-orientation call.
- **Day 7–30**: product certification path (tailored to partner's stated capability gaps from transcripts).
- **Day 30–60**: enablement + first co-sell motion + first deal registration target.
- **Day 60–90**: first-deal close + first QBR rhythm established.
For each milestone, generate concrete tasks with:
- **Title** (specific to this partner, not "complete training", but "complete the security competency module, required for the healthcare deals you mentioned").
- **Owner** (vendor-side CAM/technical/marketing OR partner-side stakeholder named in the transcript).
- **Due date** (relative to onboarding start, with respect for stated constraints, don't due-date through Q4 freeze if the partner mentioned it).
- **Why-it-matters note** linking back to the partner's stated commitment from the transcript.
- **Unlock**: what completing it enables (deal protection, MDF eligibility, tier eligibility).
### Step 4: Push tasks into Introw
For every task in the plan:
- `Introw:add_task`: create the task with owner, due date, partner association, description (including the why-it-matters note).
- `Introw:update_crm_object`: update the partner record with onboarding-start date, target time-to-first-deal, stage = onboarding.
- `Introw:add_comment`: log the personalization rationale on the partner record so future CAMs can see *why* the journey was shaped this way.
### Step 5: Set up headless project management
The skill manages this onboarding project headlessly going forward:
- Define **status checkpoints** at day 14, 30, 45, 60, 75, 90, these become standing prompts for the user / agent to re-run a progress audit (`vendor-onboarding-progress-audit`).
- Define **escalation triggers**: task > 7 days overdue → ping CAM; engagement decay → flip to at-risk; day 75 with no first deal → activate the activation campaign skill.
- Capture all of this as comments on the partner record so the project state is queryable later.
### Step 6: Surface the plan to the partner
- Generate a partner-facing summary of the journey (what they'll experience, what unlocks at each milestone).
- This feeds the conversational `partner-my-onboarding-progress` skill on the partner side, when the partner asks "what's next?", they get the same plan.
## Output format
- **Personalization summary**: what was extracted from transcripts and how it shaped the plan.
- **The plan**: milestone-by-milestone, with all tasks, owners, due dates, and unlock notes.
- **Confirmations**: every Introw write recorded (task IDs, comment IDs).
- **Headless management config**: checkpoint dates and escalation triggers.
- **Partner-facing journey summary**: copy-pasteable for the welcome email or portal.
## Guardrails & PRM best practice
- **Personalization > template fidelity.** A 60-task generic plan ignored is worse than a 20-task plan the partner committed to. Cut tasks the transcripts suggest are noise for this partner type.
- **Respect stated constraints.** If the partner said Q4 is a freeze for them, don't due-date critical milestones into it.
- **Don't auto-execute irreversible actions.** Confirm with the user before pushing 20+ tasks to the partner, once tasks are visible to the partner, the relationship reads them as commitments.
- **Capture the "why" trail.** Every task should be traceable back to either a transcript quote or a program-rule rationale. If you can't articulate why this task exists for this partner, drop it.
- **Single source of truth.** The plan lives in Introw, not in a separate doc. All status, progress, and changes route through Introw tools so the partner-facing agent can answer "what's next?" with current state.
- **Owner clarity is non-negotiable.** Every task has a named owner, either vendor-side or partner-side. "TBD" owners create dropped balls. If you don't know, ask.
- **Channel preference.** If the transcripts surfaced a preference (Slack > email, weekly check-in > daily), encode it as the chasing-cadence default.
- **First-deal gravity.** Every plan must include a credible path to first deal by day 75–90. Onboarding without first-deal gravity is just enrollment.
```
Drop this file into `.claude/skills/vendor-personalized-onboarding-from-transcripts/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Pipeline Partner-Influence Scout
Source: https://docs.introw.io/headless/skills/vendor/pipeline-partner-influence-scout
Scan the CRM or Excel pipeline to find open deals and direct-sales accounts that would benefit most from partner influence, including Crossbeam rescue plays.
*Vendor skill for [Use case 08: Deal Registration](/headless/agentic-use-cases/deal-registration).*
**Skill ID:** `vendor-pipeline-partner-influence-scout`
Use when a Channel Chief, RevOps, PDM, or AE wants to scan the vendor's CRM (or Excel pipeline) to identify open deals or direct-sales accounts that would benefit most from partner influence, including direct-deal rescue scenarios where Crossbeam shows a partner already has the customer relationship, then handle the registration / co-sell flagging and post a context-rich comment on the deal. Trigger phrases include "which deals need a partner", "find partner-influence opportunities", "who should we bring into deal X", "scout partner co-sell", "match partners to pipeline", "Excel pipeline + partner match", "Crossbeam direct-deal rescue", "partner has the customer at this account", "use Crossbeam overlap to rescue deals", "find partners that already serve customers in our pipeline".
**Built for:** Partner Program Manager · Channel RevOps · Account Executive
**Workflow:** Direct-sales deals + accounts → Vertical · geo · services · stalled · stack → Existing customer (Crossbeam) + prior wins → Registration · context-rich comment · AE task
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-pipeline-partner-influence-scout
description: Use when a Channel Chief, RevOps, PDM, or AE wants to scan the vendor's CRM (or Excel pipeline) to identify open deals or direct-sales accounts that would benefit most from partner influence, including direct-deal rescue scenarios where Crossbeam shows a partner already has the customer relationship, then handle the registration / co-sell flagging and post a context-rich comment on the deal. Trigger phrases include "which deals need a partner", "find partner-influence opportunities", "who should we bring into deal X", "scout partner co-sell", "match partners to pipeline", "Excel pipeline + partner match", "Crossbeam direct-deal rescue", "partner has the customer at this account", "use Crossbeam overlap to rescue deals", "find partners that already serve customers in our pipeline".
---
# Pipeline Partner-Influence Scout (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP + **optional claude.ai Crossbeam** MCP (+ optional Read for Excel exports if pipeline lives in spreadsheets, optional Salesforce/HubSpot MCPs).
**Use case**: 08, Deal Registration (proactive vendor-driven side; complementary to `partner-register-deal` and `vendor-email-deal-registration-watcher`).
## When to use this skill
Use when a Channel Chief, RevOps, PDM, or AE wants to scan the vendor's CRM (or Excel pipeline) to identify open deals or direct-sales accounts that would benefit most from partner influence, including direct-deal rescue scenarios where Crossbeam shows a partner already has the customer relationship, then handle the registration / co-sell flagging and post a context-rich comment on the deal.
**Sample prompts that fire this skill:**
- "which deals need a partner"
- "find partner-influence opportunities"
- "who should we bring into deal X"
- "scout partner co-sell"
- "match partners to pipeline"
- "Excel pipeline + partner match"
- "Crossbeam direct-deal rescue"
- "partner has the customer at this account"
- "use Crossbeam overlap to rescue deals"
- "find partners that already serve customers in our pipeline"
## Why this matters
Most channel programs are reactive on registration, they wait for partners to submit. But ~35% partner-led revenue uplift (Computer Market Research) compounds further when the vendor proactively *places* partners on deals where partner influence improves the outcome: complex implementations, vertical-specific motions, geographic proximity, services attach, existing-customer relationships. This skill scans the pipeline, identifies high-leverage partner-influence opportunities, and handles the registration mechanics, including a context-rich comment that explains *why this partner on this deal*.
**The direct-deal rescue scenario** is the highest-ROI version of this workflow and the primary reason channel teams care about Ecosystem-Led Growth: when a deal is sitting in *direct sales* and Crossbeam shows that one of the vendor's partners already has an active customer relationship at the prospect, registering with that partner converts a cold direct pursuit into a warm-introduction-led motion, typically compressing sales cycle and lifting close rate. Without Crossbeam, this signal is invisible; with it, it becomes the dominant scoring factor for partner placement on direct-sales pipeline.
The complementary partner-side skill is `partner-pipeline-influence-companion`, which lets a partner see the same view from their side. The proactive (target-list-first) variant, given an external account list rather than open pipeline, is `vendor-crossbeam-cosell-finder`.
## Inputs to gather first
- **Pipeline source**: Introw / connected CRM (`search_crm_objects`), or an Excel/CSV the user provides (then Read it).
- **Filter scope**: open deals only? specific stage range? specific products? specific regions?
- **Partner-influence definition for this vendor**: services-led? vertical-led? geography-led? existing-customer-led? Confirm if not on file.
- **Action mode**: surface only, or auto-register / flag co-sell where match is clean?
## Process
### Step 1: Pull the pipeline
- Primary: `Introw:search_crm_objects` for open deals (filter to stages where partner influence has leverage, usually mid-funnel onward, post-discovery).
- If user provides Excel/CSV: Read the file and treat each row as a deal record; map columns to the standard schema (account, value, stage, close-date, product, owner, region, vertical).
### Step 2: Score each deal for partner-influence leverage
Score per deal across multiple dimensions:
- **Vertical specialization**: is this a healthcare deal where a healthcare-specialist partner would close better?
- **Geographic proximity**: is the customer in a region where a local partner has presence?
- **Services / implementation complexity**: is this a deal where SI delivery would derisk close?
- **Existing-customer relationship**: does any partner already serve this customer in another product line?
- **Stalled / needs-momentum**: has the deal been in-stage > X days without a partner?
- **Tech-stack match**: does the deal involve integrations a specific partner already builds for?
- **Margin / packaging**: would partner-led pricing/packaging unlock the deal?
Output a priority score per deal: how much would partner influence improve the close probability, expected value, or close velocity?
### Step 3: Match each high-leverage deal to a specific partner
For each prioritized deal, evaluate signals in this priority order:
1. **Existing customer relationship at the prospect** (Crossbeam, when MCP connected): **the strongest possible signal.** A partner with an active customer relationship at the prospect's account beats every other signal: warmer than vertical fit, warmer than prior similar wins, dramatically warmer than territory match. Use `Crossbeam:*` to find overlaps; weight overlap *type* (active customer > active opportunity > champion > lapsed prospect) and *recency* (last 90 days > older). Without Crossbeam, this signal isn't directly observable, fall back to the other signals below.
2. `Introw:search_crm_objects`: partners with **prior wins on similar customers** (vertical, deal size, products): strongest CRM-only signal.
3. `Introw:search_partners`: filter by region, vertical, partner type, certifications relevant to the deal.
4. `Introw:search_partner_engagement`: partners actively engaged this quarter (avoid putting deals on dormant partners).
5. `Introw:get_tier_information`: tier requirements affecting eligibility.
6. `Introw:get_goals`: partners pacing on goals where this deal would help.
For each candidate match, articulate the **why** in one sentence:
- "Partner X, Crossbeam shows active customer relationship at Globex (3-year, expansion-eligible); located in same region; certified on the relevant product. Direct-deal rescue candidate."
- "Partner Y, has 3 recent closed-won deals in healthcare AI at similar deal sizes; located in same region as customer; certified on the relevant product."
- "Partner Z, already serves this customer in a different product line; cross-sell motion is the natural play."
### Step 4: Conflict check
Before flagging or registering:
- Cross-check existing registrations on the account (`Introw:search_form_submissions`).
- Cross-check direct sales claim (account in named-account list?).
- Cross-check other partners with open registrations.
- If conflict, surface, don't auto-resolve. Hand off to `vendor-detect-channel-conflict`.
### Step 5: Handle the registration / co-sell flag
For clean matches with no conflict:
- Auto-register the partner (or surface for human approval based on confirmed mode):
- `Introw:share_lead_or_register_deal` with the partner's ID and the deal context.
- Post a context-rich comment on the deal:
- `Introw:add_comment` on the CRM object with the **why this partner**, the prior-win evidence, the suggested co-sell motion, and the recommended next step (intro call, joint pitch, technical deep-dive).
- Notify both the AE and the partner:
- `Introw:add_task` for the AE to make the intro.
- `Introw:add_task` or comment for the partner to confirm engagement.
For conflicted or judgment-call matches:
- Surface to a human reviewer with full context.
### Step 6: Track the placement
- `Introw:search_partner_engagement` and `search_crm_objects` over the next 14/30/60 days to measure whether the placement actually moved the deal.
- Capture outcome via `add_comment` so the next pipeline-scout cycle has training data.
## Output format
- **Pipeline scan summary**: deals scored, distribution by leverage tier.
- **High-leverage match table**: deal, value, stage, recommended partner, why, conflict status, action taken.
- **Confirmed actions**: registrations created, comments posted, tasks assigned.
- **Surfaced for review**: conflict, ambiguous match, or judgment-call cases with full context.
- **Tracking checkpoints**: when to measure placement effectiveness.
## Guardrails & PRM best practice
- **Why beats who.** Every match needs a one-sentence "why this partner" that traces to evidence (prior wins, vertical match, customer relationship). If you can't articulate the why, the match is wrong.
- **Channel conflict before action.** Always run the conflict check before flagging, proactive partner placement that creates conflict is worse than no placement at all.
- **Don't displace working AEs.** When a deal is healthy and progressing, a partner overlay can disrupt, match leverage to deal-state, don't impose partners on deals that don't need them.
- **Tier-aware placement.** Strategic deals to top-tier partners; transactional deals to volume-oriented partners. Mismatching destroys margin and partner energy.
- **No auto-action without confirmation on first run.** First-time use of this skill: surface, don't act. Once the user has validated the matching logic against their judgment, auto-action mode can be enabled.
- **Capture the rationale on the deal record.** The AE who picks up the deal next week needs to see why a partner was placed, don't make them archaeology the comment thread.
- **Goal-relevance.** When two partners are equally well-matched, prefer the one whose `get_goals` shows they're pacing toward a target this deal would help, placement is also an activation lever.
- **Don't poach.** If another partner already has a registration on the account, don't override, that's the conflict path, not the placement path.
- **Excel mode is provisional.** Excel pipelines lack the live attribution Introw has; Excel-based matches surface for human review by default rather than auto-action.
- **Crossbeam data has lag.** Overlap data refreshes typically run nightly or weekly; flag Crossbeam-driven matches where overlap data is > 30 days old and confirm currency before recommending placement.
- **Crossbeam respects data-sharing scope.** Only surface overlaps within authorized population groups / partner-data-sharing agreements. Never surface a partner customer's name outside the vendor-internal scope.
- **Cross-skill handoff.**
- **Proactive variant** (given an external target account list rather than open pipeline) → `vendor-crossbeam-cosell-finder` (UC02). This skill is the *reactive* version (scan pipeline → match partner); cosell-finder is the *proactive* version (given a list → find partners).
- Channel conflict detected → `vendor-detect-channel-conflict`.
- Clean placements that need coaching → `vendor-deal-coach-from-similar-wins`.
- Dormant partner who'd be a great match but is silent → activation lever via `vendor-activate-network-with-personalized-campaigns` before placing the deal.
```
Drop this file into `.claude/skills/vendor-pipeline-partner-influence-scout/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# QBR Preparation: Single-Partner & Book-Wide Coverage
Source: https://docs.introw.io/headless/skills/vendor/qbr-prep
Prep a QBR, MBR, or WBR by assembling pipeline, goals, activity, engagement, commissions, MAP status, and agenda for one partner or the full book.
*Vendor skill for [Use case 12: QBRs / Meeting Prep](/headless/agentic-use-cases/qbrs-meeting-prep).*
**Skill ID:** `vendor-qbr-prep`
Use when a PDM, CAM, or Channel Chief wants to prepare a Quarterly Business Review (or MBR / WBR): instantly assembling pipeline, goals, activity, engagement, commissions, MAP status, and a recommended agenda for one partner OR running a 100% coverage sweep across the entire partner book. Trigger phrases include "prep QBR for \[partner]", "generate this quarter's QBRs", "QBR sweep across the book", "MBR / WBR prep", "100% QBR coverage", "ready every partner review", "quarterly business review preparation".
**Built for:** Partner Development Manager · Channel Account Manager · Partner Program Manager
**Workflow:** Pipeline · goals · engagement · commissions → Full draft · risks at top · agenda (template from playbook) → Single partner OR book-wide → Strategic refinement · ship
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-qbr-prep
description: Use when a PDM, CAM, or Channel Chief wants to prepare a Quarterly Business Review (or MBR / WBR): instantly assembling pipeline, goals, activity, engagement, commissions, MAP status, and a recommended agenda for one partner OR running a 100% coverage sweep across the entire partner book. Trigger phrases include "prep QBR for [partner]", "generate this quarter's QBRs", "QBR sweep across the book", "MBR / WBR prep", "100% QBR coverage", "ready every partner review", "quarterly business review preparation".
---
# QBR Preparation: Single-Partner & Book-Wide Coverage (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP.
**Use case**: 12, QBRs / Meeting Prep.
## When to use this skill
Use when a PDM, CAM, or Channel Chief wants to prepare a Quarterly Business Review (or MBR / WBR): instantly assembling pipeline, goals, activity, engagement, commissions, MAP status, and a recommended agenda for one partner OR running a 100% coverage sweep across the entire partner book.
**Sample prompts that fire this skill:**
- "prep QBR for [partner]"
- "generate this quarter's QBRs"
- "QBR sweep across the book"
- "MBR / WBR prep"
- "100% QBR coverage"
- "ready every partner review"
- "quarterly business review preparation"
## Why this matters
PDMs spend **2–4 hours per QBR** on manual data assembly. A 30-partner book × 4 quarterly reviews = **240–480 hours/year per PDM** of mechanical prep, before the actual meeting, follow-up, or strategic conversation. The honest reality: most programs only achieve **20–30% real QBR coverage** because the prep math makes 100% impossible. Top-tier partners get full reviews, mid-tier get half-baked versions, and the long tail gets a check-in email.
Agentic generation collapses prep to **~10 seconds** for the full draft + **~15 minutes** of PDM editing for strategic refinement. The math reverses: **100% coverage** becomes feasible. Time recovered per PDM: **250–500 hours/year** redirected from spreadsheet wrangling to the strategic conversation, recommendation, and decision work that humans uniquely do well.
This skill operates in two modes, single-partner prep, or a book-wide coverage sweep.
## Modes
### Mode A: Single-partner QBR prep
Generate a complete QBR draft for one named partner.
### Mode B: Book-wide coverage sweep
Generate QBR drafts for every partner in the user's book (or a defined cohort), one per partner, ready for 15 minutes of editing each. The defining outcome: every partner gets the same data depth, Gold to long-tail, and coverage hits 100%.
## Inputs to gather
- **Mode** (A or B).
- **Partner** (Mode A) or **cohort scope** (Mode B, book, tier, region).
- **Review type**: QBR (default), MBR, WBR.
- **Time window**: trailing quarter (default), trailing month, custom.
- **Audience**: PDM-internal review or joint partner-facing review (changes tone).
## Process
### Step 1: Try the dedicated tool first
`Introw:generate_business_review` is purpose-built, call it with the partner ID and review type. For Mode B, iterate across the cohort.
### Step 2: Enrich with current state
For each QBR, pull current state from connected systems:
- `Introw:search_crm_objects`: open pipeline, recent closed-won, slipped/lost deals, deal velocity vs. cohort.
- `Introw:get_goals`: goal targets and progress (MBOs, certification targets, quarterly commitments).
- `Introw:search_partner_engagement`: engagement intensity over the period (meetings, training, content engagement, asset views).
- `Introw:search_commissions`: paid, accrued, projected.
- `Introw:get_tier_information`: current tier, distance to next tier, tier benefits.
- `Introw:search_tasks`: open, completed, overdue.
- `Introw:search_form_submissions`: registration cadence, MDF requests.
### Step 3: Assemble the standard QBR sections
Every QBR includes:
1. **Executive summary (3 bullets)**: state of the partnership, biggest win, biggest risk.
2. **Pipeline & revenue**: quarter actuals vs. plan, top deals, expansion opportunities, slipped deals with reasons.
3. **Goals & MAP**: progress on committed goals, MAP / joint-plan milestones (complete / blocked / due), quarterly commitments status.
4. **Activity & engagement**: registrations submitted, training completed, events attended, content engaged, partner engagement score vs. cohort benchmark.
5. **Tier trajectory**: current tier, run-rate to next tier, gap analysis, what unlocks at promotion.
6. **Commissions**: paid, accrued, projected, any aging payables flagged.
7. **Action items**: top 3–5 for next quarter with owners and dates.
8. **Recommended agenda**: 3–5 priority topics surfaced from the data, with talking points the PDM can carry into the live meeting.
### Step 4: Surface risks and opportunities at the top, not buried
Auto-flag (in the executive summary):
- Aging commissions or payable disputes.
- Goal pacing behind run-rate.
- Engagement decay over the period.
- Stuck pipeline / aging deals.
- MAP commitments slipping.
- Tier trajectory at risk of demotion.
### Step 5: Mode B specifics: coverage sweep mechanics
For book-wide:
- Iterate the partner cohort (default: every active partner the user manages).
- Generate one QBR draft per partner.
- Bundle the drafts in a clean order: high-touch (top tier / strategic) first, transactional last.
- Surface a coverage scorecard: how many drafts, average data quality, partners with thin data (where the QBR may be light).
- Flag any partners where data quality is too low to ship a meaningful QBR, those need PDM input before generation runs.
### Step 6: Capture & hand off
- `Introw:add_comment` on each partner record, note that the QBR was generated and which sections required strategic editing.
- For action items in each QBR, optionally `Introw:add_task` to create trackable follow-ups with owners and dates.
- The QBR draft is ready for the PDM's 15-minute strategic edit pass.
## Output format
- **Mode A**: one complete QBR markdown draft, sectioned, copy-pasteable into slides / docs.
- **Mode B**: one draft per partner + a coverage scorecard showing book-wide coverage status.
- **Risk flags** highlighted at top, not buried.
- **Comparison to last QBR** if data available.
- **Action item list** separate from the QBR body, ready for tasking.
## Guardrails & PRM best practice
- **The 15-minute edit is the value.** PDMs personalize before delivery, the agent generates the scaffold; humans add the relationship intelligence. Don't ship un-edited.
- **One source of truth.** Every number in the QBR traces to a specific tool call. Don't paraphrase metrics; if the data isn't there, flag it as such rather than fabricating.
- **MAP honesty.** If MAP commitments are slipping, surface them, soft-pedaling the joint plan in QBRs is the #1 reason joint plans fail to deliver.
- **No surprises.** Risks in the QBR should have been raised in the trailing month via comments, use `Introw:add_comment` to log risks as they emerge, not just at quarter-end.
- **Tier-trajectory transparency.** Show the partner the path to the next tier even if they're far. Opacity here is a top trust eroder.
- **Coverage discipline.** Encourage Mode B for full books, agentic prep makes 100% feasible; lower-tier partners often deliver the biggest delta from a QBR they wouldn't otherwise receive. The economics of partial coverage are a self-inflicted constraint.
- **Quality consistency.** Every partner, Gold to long-tail, gets the same data depth in their review. Tier should affect strategic emphasis, not data thoroughness.
- **Tone awareness.** Internal-PDM-prep mode and joint-partner-facing mode are different documents. Ask which one is being generated; default to internal prep if unclear.
- **Don't replace the human in the meeting.** Automation replaces the *prep*, not the conversation. Frame outputs as PDM-ready drafts.
- **Pair with adjacent skills.** Coverage sweep that surfaces an at-risk partner → `vendor-detect-at-risk-partners` and `vendor-activate-network-with-personalized-campaigns`. QBR finds a coaching gap → `vendor-deal-coach-from-similar-wins`. QBR shows training gap → `vendor-microcourse-from-closed-lost`.
- **Do the work the PDM would want done, not just possible.** Surface the strategic question hiding in the data, not just the data.
```
Drop this file into `.claude/skills/vendor-qbr-prep/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# QBR Recording → Portal Updates + Follow-Up
Source: https://docs.introw.io/headless/skills/vendor/qbr-recording-to-portal-followup
Turn a QBR, MBR, or partner business review recording or transcript into structured portal updates: tasks, comments, CRM edits, and a polished follow-up email.
*Vendor skill for [Use case 12: QBRs / Meeting Prep](/headless/agentic-use-cases/qbrs-meeting-prep).*
**Skill ID:** `vendor-qbr-recording-to-portal-followup`
Use after a QBR / MBR / partner business review meeting when a PDM, CAM, or Channel Chief wants to turn the meeting recording or transcript into structured portal updates (tasks created, comments added, CRM objects updated, goals adjusted) and a polished follow-up email to attendees. Trigger phrases include "process this QBR transcript", "follow up from the partner meeting", "QBR portal update", "convert this transcript to tasks", "post-QBR action items", "send the QBR recap", "update Introw from the meeting".
**Built for:** Partner Development Manager · Channel Account Manager · Channel Ops Manager
**Workflow:** QBR transcript / recording → Decisions · commitments · risks · next-touch → Tasks · comments · CRM updates · goal flags → Approved writes + drafted attendee email
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-qbr-recording-to-portal-followup
description: Use after a QBR / MBR / partner business review meeting when a PDM, CAM, or Channel Chief wants to turn the meeting recording or transcript into structured portal updates (tasks created, comments added, CRM objects updated, goals adjusted) and a polished follow-up email to attendees. Trigger phrases include "process this QBR transcript", "follow up from the partner meeting", "QBR portal update", "convert this transcript to tasks", "post-QBR action items", "send the QBR recap", "update Introw from the meeting".
---
# QBR Recording → Portal Updates + Follow-Up (Vendor)
**Audience**: Vendor, uses **claude.ai Introw** MCP + transcript MCP (Otter, Fathom, Gong, Read.ai, Granola, or a transcript pasted into the conversation).
**Use case**: 12, QBRs / Meeting Prep (post-meeting companion to `vendor-qbr-prep`).
## When to use this skill
Use after a QBR / MBR / partner business review meeting when a PDM, CAM, or Channel Chief wants to turn the meeting recording or transcript into structured portal updates (tasks created, comments added, CRM objects updated, goals adjusted) and a polished follow-up email to attendees.
**Sample prompts that fire this skill:**
- "process this QBR transcript"
- "follow up from the partner meeting"
- "QBR portal update"
- "convert this transcript to tasks"
- "post-QBR action items"
- "send the QBR recap"
- "update Introw from the meeting"
## Why this matters
Most QBRs end with good intentions and zero follow-through. The PDM types up notes (sometimes), promises to update the portal "later," drafts an email (eventually), and three weeks later the partner is asking what was decided. The decisions made in the meeting age into ambiguity; commitments slip; the next QBR rehashes the same ground.
This skill closes the loop: meeting transcript → structured portal updates → attendee email, same day, automatically, with no PDM tax. It's the post-meeting half of the QBR motion that `vendor-qbr-prep` started. Pair the two and the QBR becomes an actual operating ritual instead of a slide deck.
## Inputs to gather first
- **Source**: meeting transcript (pasted text, transcript MCP reference, or a recording the user has already transcribed elsewhere).
- **Partner identity** + portal/CRM record.
- **Attendees** (pulled from transcript or supplied): needed for the follow-up email.
- **Meeting type**: QBR (default), MBR, WBR, ad-hoc strategic review.
- **Action authorization**: write to portal directly, or surface drafts for PDM approval first?
## Process
### Step 1: Extract structured signal from the transcript
Mine the transcript for:
- **Decisions made**: specific yes/no calls. ("We agreed to expand into healthcare in Q3.")
- **Commitments**: who promised what by when. Vendor commitments AND partner commitments.
- **Action items**: concrete tasks with owners.
- **Blockers / risks raised**: partner flagged something that needs attention.
- **Goal updates**: any commitments to revise or set new goals.
- **Pipeline changes**: deals discussed (new, in-flight, slipped, killed).
- **Tier / program asks**: partner asking for tier promotion, MDF, certification support.
- **Sentiment signals**: any major positive (advocacy moment) or negative (frustration, churn risk).
- **Next QBR / next-touch date.**
For each extraction, capture the source quote (with timestamp if available): the audit trail.
### Step 2: Pull current state for context
Before writing anything, pull current state to avoid duplicating or contradicting existing data:
- `Introw:search_partners`: partner record.
- `Introw:search_tasks`: open tasks already assigned (don't double-create).
- `Introw:search_crm_objects`: open deals that may need updating.
- `Introw:get_goals`: current goals before any revisions.
### Step 3: Stage the writes (preview, don't execute yet)
Build a write plan, not a write. For each extracted item, prepare the corresponding portal action:
| Extracted | Portal action |
|---|---|
| Action item with owner + due date | `Introw:add_task` (with title, owner, due date, partner association, why-note linked to transcript timestamp) |
| Commitment, decision, or sentiment-worthy moment | `Introw:add_comment` on the partner record |
| Deal stage change / value update / new deal mentioned | `Introw:update_crm_object` (or `Introw:share_lead_or_register_deal` if new) |
| Goal revised or new goal committed | Comment + flag for human update (goal write-back may need approval) |
| Tier / MDF ask raised | Comment + task to relevant approver |
| Risk / churn signal | Comment with flag + task to PDM for follow-up |
| Next QBR date | Calendar task with the date |
### Step 4: Surface the write plan
Show the user:
- **Tasks to create**: title, owner, due date, why.
- **Comments to add**: content + which record.
- **CRM updates**: what's changing, before/after.
- **Goals affected**: flagged for separate confirmation (goals carry economic weight).
- **Risks flagged**: anything that warrants escalation.
User approves, edits, or rejects per item. **Default mode: surface; auto-execute only when explicitly authorized.**
### Step 5: Execute approved writes
- `Introw:add_task` for each approved task.
- `Introw:add_comment` for each comment, including the QBR summary as a comprehensive comment on the partner record (so the next QBR has the full thread).
- `Introw:update_crm_object` for each approved CRM update.
- For goal changes: capture as a comment + create a task for the goals-owner to confirm and apply (don't auto-write goal targets).
### Step 6: Draft the follow-up email
Generate an email to the meeting attendees with this structure:
- **Subject**: "Recap & next steps, [Partner] x [Vendor] [QBR / MBR / Review], [Date]"
- **Opening**: thank-you + 1-line meeting purpose recap.
- **What we agreed** (decisions, bulleted, concrete).
- **What we'll do** (vendor-side action items with owners + dates).
- **What you'll do** (partner-side action items with owners + dates).
- **What's next** (next-touch date, what'll be reviewed).
- **Attachments / links**: portal task IDs created, any decks shared, the recording (if attendee policy allows).
Tone: warm but specific. No hedging. The email should be the source of truth the partner can forward to their team. If something was discussed but not decided, say "to revisit next [touchpoint]", don't fudge.
### Step 7: Send (or stage for send)
- **Default**: surface the drafted email for PDM review and send via the PDM's regular email tool.
- If a Gmail/Outlook MCP is connected and the user authorizes auto-send: send directly.
- Capture the sent email body via `Introw:add_comment` on the partner record so the email is part of the audit trail.
## Output format
- **Extraction summary**: what was identified in the transcript, with source quotes.
- **Portal write plan**: tasks, comments, CRM updates, goal flags, risk flags. Each approved/rejected by the user.
- **Confirmation log**: for each executed write, the IDs created/updated.
- **Follow-up email draft**: copy-pasteable or sendable.
- **Open items requiring human follow-through**: anything ambiguous or sensitive flagged for the PDM.
## Guardrails & PRM best practice
- **Don't fabricate.** If the transcript is ambiguous on owner or date, ask the PDM rather than guess. Wrong owners and dates create more friction than no tasks.
- **Preserve nuance.** Some QBR moments aren't decisions, they're explorations. Don't capture an exploratory mention as a commitment. The bar: was there explicit agreement?
- **Sensitive content stays out of broad audiences.** If the meeting included confidential pricing discussion, churn-risk admissions, or competitor intel, scrub those from the follow-up email, capture in vendor-internal comments only.
- **Owners must be named.** "TBD" owners create dropped balls. Every task needs a name.
- **Don't update goals without authorization.** Goal targets carry economic weight (commission impact, tier eligibility). Goal changes get flagged for explicit confirmation, never auto-written.
- **Source quotes on every extraction.** The audit trail is the source quote + timestamp. When the partner disputes an action item six weeks later ("we never agreed to that"), the timestamp resolves it.
- **Don't auto-execute on first run.** First time the user runs this skill: preview everything. After the user has trusted the extraction quality on 2–3 meetings, auto-execution mode can be enabled for low-risk writes (tasks, comments): never goal writes or tier moves.
- **Email tone is editable.** The drafted email is a starting point. The PDM's relationship voice matters; encourage edits. If the partner has a long history of formal English, don't ship a casual draft.
- **Privacy of recordings.** Some partners don't consent to recording, and some jurisdictions have specific rules. Confirm consent context before processing.
- **Escalate risks immediately.** Churn signals, legal flags, security issues, surface to channel leadership the same day, don't bury them in the digest.
- **Cross-skill handoff.** New deals identified → `partner-register-deal` flow or `vendor-pipeline-partner-influence-scout`. Coaching needs surfaced → `vendor-deal-coach-from-similar-wins`. Goal revisions → vendor goals-owner. Tier asks → `vendor-tier-promotion-batch-review` for next cycle. Pairs naturally with `vendor-qbr-prep`: prep generates the meeting, this skill closes the loop after.
```
Drop this file into `.claude/skills/vendor-qbr-recording-to-portal-followup/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Agentic SCORM Course Builder
Source: https://docs.introw.io/headless/skills/vendor/scorm-course-builder
Build a partner training course end to end with AI: author from vendor knowledge sources, apply branding, package as SCORM, and publish to Introw.
*Vendor skill for [Use case 05: Training](/headless/agentic-use-cases/training).*
**Skill ID:** `vendor-scorm-course-builder`
Use when a Partner Enablement lead, Partner Manager, or Channel Ops user wants to build a partner training course end to end with AI: author the content from the vendor's own knowledge sources (docs, Notion, Confluence, Drive, website), apply the vendor's branding, package it as SCORM, and publish it to Introw over MCP - with a certificate, due date, passing score, and auto-enrollment - or update an existing course's settings or replace its package in place. Trigger phrases include "build a course for our partners", "create a partner training course", "make a SCORM course", "turn these docs into a course", "publish this course to Introw", "update the course content", "replace the SCORM package".
**Built for:** Partner Enablement Manager · Partner Program Manager · Channel Ops
**Workflow:** Topic + the vendor's own knowledge sources → outline (confirmed) → branded, visual, self-contained HTML course → SCORM 1.2 zip → upload via `create_scorm_upload` (or a hosted https URL) → `upsert_course` over MCP → verify live with `list_courses` → iterate with in-place package replacement
````md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-scorm-course-builder
description: Use when a Partner Enablement lead, Partner Manager, or Channel Ops user wants to build a partner training course end to end with AI - author the content from the vendor's own knowledge sources (docs, Notion, Confluence, Drive, website), apply the vendor's branding, package it as SCORM, and publish it to Introw over MCP for partners to take, with a certificate, due date, passing score, and auto-enrollment - or update an existing course's settings or replace its package in place. Trigger phrases include "build a course for our partners", "create a partner training course", "make a SCORM course", "turn these docs into a course", "publish this course to Introw", "update the course content", "replace the SCORM package".
---
# Agentic SCORM Course Builder (Vendor)
**Audience**: Vendor, **claude.ai Introw** MCP.
**Use case**: 05, Training.
## When to use this skill
Use when the user wants to create partner training in Introw without authoring inside Introw: build the course content here (from their knowledge sources, in their branding), produce a SCORM package, and create or update the course in Introw over MCP so partners take it from their partner hub - enrollment, scoring, certificates, and CRM sync handled by Introw.
**Sample prompts that fire this skill:**
- "help me build a course for our b2b partners"
- "turn our onboarding docs into a partner course"
- "make a SCORM course on our new pricing and publish it to Introw"
- "create a certification course for resellers"
- "update the course - I fixed chapter 3"
- "replace the SCORM package on the enablement course"
## Why this matters
The split of responsibilities is the point: the AI tool owns content generation (fast, flexible, disposable), Introw owns what must stay centralized - partners take the course from the hub they already use with no separate LMS login, enrollment and scoring are tracked per learner, certificates are issued automatically on passing, and completion syncs to the CRM. One `upsert_course` call bridges the two. Iteration is cheap: re-export and replace the package in place - same course, same link, enrollments and completions intact.
## MCP tools
| Tool | Kind | What it does |
| --- | --- | --- |
| `Introw:list_courses` | read-only | List courses with settings, SCORM import status, and enrollment/completion counts (learners and distinct partners). Source of `courseId`. `scormStatus` is "processing" until the package is live, then "ready". `scormPackageVersion` changes on every successful import/replacement - watch it to confirm a replacement went live. |
| `Introw:list_certificates` | read-only | List the org's certificates (id, name, validity, active partner/learner counts, linked courses) - pick a `certificateId` to link. Certificates are designed in the Introw UI; this skill only links them. |
| `Introw:list_course_enrollments` | read-only | Roster of who is enrolled, in progress, or has completed a course. Filter by `courseId`, `partnerId`, `status`, or a name/email query. |
| `Introw:list_issued_certificates` | read-only | Roster of who currently holds a certificate. Filter by `certificateId`, the `courseId` that grants it, `partnerId`, or a name/email query. Expired awards are omitted unless `includeExpired` is true. |
| `Introw:create_scorm_upload` | mutation | Returns a presigned `uploadUrl` (30-minute expiry, writes exactly one org-scoped object), an `uploadPageUrl` (drag-and-drop page for the same slot, for environments that cannot PUT a file), and the `scormFileKey` to pass to `upsert_course`. Nothing imports until `upsert_course` is called with the key. |
| `Introw:upsert_course` | mutation | Omit `courseId` = create (requires `name` + the zip as `scormFileKey` or `scormFileUrl`). Provide `courseId` = update; only the fields you pass change. Fields: `name`, `description`, `thumbnailUrl` (3:1 banner, any hosted https image URL, stored as-is), `dueDate` (`{isRelative: true, amount, unit}` or `{isRelative: false, date}`), `minimumPassingScore` (0-100), `autoEnrollmentEnabled`, `certificateId` (null unlinks), `lmsMode` (create-only; `SCORM_RUNTIME` default runs the package as-is, `NATIVE` converts it into editable Introw modules), `scormFileKey` (from `create_scorm_upload`) or `scormFileUrl` (publicly downloadable https URL) - on update either one REPLACES the package. |
## Process
### Step 1: Scope the course
Confirm with the user before building:
- **Audience**: which partner type / persona (a reseller's seller vs. an SI's consultant need different courses).
- **Topic and depth**: entry-level overview vs. certification-grade. If the user has no topic, propose 2-3 grounded in their knowledge sources and current gaps.
- **Sources**: which connected knowledge to draw from - docs sites, Notion, Confluence, Drive, the vendor's website, product docs over MCP. Never fabricate content; every module traces to a source.
- **Settings**: certificate? passing score? due date? auto-enroll?
Present a module-by-module outline (2-6 modules, 10-30 min total, one learning objective each) and get sign-off before authoring.
### Step 2: Gather branding
Pull logo, colors, and typography from the vendor's website or brand assets; ask if unavailable. The course must look like the vendor, not like an AI tool. Reuse their real product screenshots, diagrams, and terminology from the sources.
### Step 3: Author the course as a self-contained HTML app
One `index.html` (plus bundled assets) that works offline:
- **Visual and interactive**: styled sections or slides, progress indicator, inline SVG diagrams, expandable examples, knowledge checks between modules. No walls of text - show, then check.
- **Self-contained**: bundle every image, font, and script in the zip. No CDN links, no external requests, no trackers.
- **Assessment**: if the course has a passing score, end with a scored assessment (prefer scenario questions over trivia). No assessment → the course reports completion only.
- **Accessible**: semantic headings, alt text, keyboard-navigable, readable contrast.
### Step 4: Wire the SCORM runtime calls
Introw runs the package in its SCORM runtime player; the SCORM API is exposed by the parent frame. Author against **SCORM 1.2** (default; Introw also detects SCORM 2004 from the manifest). The package MUST report status - a beautiful course that never calls the API shows every partner as never finishing.
```js
function findAPI(win) {
let tries = 0;
while (win && !win.API && tries < 10) {
win = win.parent && win.parent !== win ? win.parent : win.opener;
tries++;
}
return win && win.API ? win.API : null;
}
const api = findAPI(window);
api?.LMSInitialize("");
// After each completed module (so progress survives an early exit):
api?.LMSCommit("");
// No assessment - on the final module:
api?.LMSSetValue("cmi.core.lesson_status", "completed");
// With an assessment - on submit (score 0-100):
api?.LMSSetValue("cmi.core.score.raw", String(score));
api?.LMSSetValue("cmi.core.lesson_status", score >= PASS_SCORE ? "passed" : "failed");
api?.LMSCommit("");
// On unload:
api?.LMSFinish("");
```
Introw evaluates the pass from the reported score against the course's `minimumPassingScore` (or an explicit "passed" status) and issues the linked certificate automatically. Keep `PASS_SCORE` in the package equal to the `minimumPassingScore` you set on the course.
### Step 5: Package as a SCORM zip
- `imsmanifest.xml` at the **zip root** - not inside a subfolder (the #1 import failure).
- The `` launch file must exist in the zip.
- List every file in the manifest's ``; keep the zip under 2 GB.
Minimal SCORM 1.2 manifest:
```xml
ADL SCORM1.2Course titleCourse title
```
Zip from inside the course folder (`zip -X -r ../course.zip .`) so the manifest lands at the archive root. Verify before shipping: list the zip contents, confirm `imsmanifest.xml` is at the root and the launch href exists.
### Step 6: Hand Introw the zip
Preferred - upload it directly, no hosting needed:
1. `Introw:create_scorm_upload` (pass the zip's `fileName`) → returns `uploadUrl` + `scormFileKey`.
2. HTTP PUT the raw zip bytes to `uploadUrl` with header `Content-Type: application/zip` (e.g. `curl --fail -T course.zip -H "Content-Type: application/zip" ""`). The URL expires after 30 minutes - if it lapses, just request a new one.
3. Pass `scormFileKey` to `upsert_course` in the next step.
Fallback - if this environment cannot make HTTP requests with a file body (chat assistants): the same tool response includes `uploadPageUrl`. Give the user that link with the downloadable zip - it is a drag-and-drop page that uploads into the same slot, and requires them to be signed in to Introw in this organisation (they will be redirected to log in if needed). Ask them to say "done", then continue with `scormFileKey`; if `upsert_course` reports no file yet, wait and retry. As a last resort, a publicly downloadable https URL of the zip works as `scormFileUrl` (Introw copies it server-side, so it only needs to live until the call). Never pass local paths or base64. The 3:1 thumbnail is always a hosted https URL (stored as-is, so that one must stay live).
### Step 7: Create the course
1. If a certificate is wanted: `Introw:list_certificates`, confirm the pick with the user (certificate design/branding itself lives in the Introw UI).
2. Recap every setting (name, description, thumbnail, due date, passing score, certificate, auto-enroll, mode) and get explicit approval - this is a write.
3. `Introw:upsert_course` with no `courseId`, passing the zip as `scormFileKey` (or `scormFileUrl`). Default `lmsMode: SCORM_RUNTIME`; use `NATIVE` only if the user wants to continue editing inside Introw afterwards.
4. Import runs in the background: poll `Introw:list_courses` (name filter) until `scormStatus` is "ready", then report the `courseId`. With auto-enroll on, Introw holds the course back from partners until it is actually launchable - safe to enable at create.
### Step 8: Iterate - update settings or replace the package
- **Settings-only change** (due date, certificate, thumbnail, description...): `upsert_course` with `courseId` + just those fields. `null` clears a field.
- **Content change**: re-export, upload again (`create_scorm_upload` → PUT → new `scormFileKey`), then `upsert_course` with `courseId` + the new `scormFileKey` (or a `scormFileUrl`). This replaces the package **in place**: same course, same link, enrollments kept, completions and issued certificates stand - but in-progress learners restart on the new version. **Always confirm with the user before replacing.** The old package keeps serving until the new one is live; confirm the swap by watching `scormPackageVersion` change in `list_courses` (`scormStatus` stays "ready" throughout).
## Output format
- **Course outline** (pre-build, for sign-off): modules, objectives, sources per module, assessment plan.
- **The SCORM zip** + a one-paragraph content summary and where each module's content came from.
- **Publish receipt**: `courseId`, settings applied, import status, certificate linked, what partners will see and when.
- **Iteration note**: what to say to update or replace it later ("replace the package on course X with this new zip").
## Guardrails & PRM best practice
- **Knowledge-sourced, never fabricated.** Every module traces to the vendor's real docs/data over MCP; cite the source. No invented features, pricing, or claims - partner-facing training is customer-facing content.
- **Confirm before every write.** Outline before authoring; full settings recap before `upsert_course`; explicit confirmation before any package replacement (it resets in-progress learners - the tool's own warning says so; relay it).
- **The API wiring is non-negotiable.** Ship no package that doesn't report `lesson_status` (and `score.raw` when a passing score is set). Test the completion path mentally: which user action triggers "completed"/"passed"?
- **Score consistency.** The in-package pass threshold and the course's `minimumPassingScore` must match. Don't set a passing score on a course with no assessment.
- **Self-contained packages.** No external requests, no trackers, no secrets or internal-only data in the zip - partners download and run this content.
- **Audience segments live in the Introw UI.** `autoEnrollmentEnabled` only toggles auto-enrollment; remind the user to review the audience segments in Introw if targeting matters.
- **Plan limits.** Creating a course counts against the org's course limit; if the tool returns a limit error, surface it plainly rather than retrying.
- **Partner-type awareness.** Offer variants when the audience spans partner types (reseller vs. SI vs. referral) rather than one generic course.
- **Cross-skill handoff.** Topic should come from real gaps → `vendor-microcourse-from-closed-lost` (closed-lost patterns) or `vendor-support-content-gap-detector` (support questions). Distribution nudges per partner → `Introw:add_task`.
````
Drop this file into `.claude/skills/vendor-scorm-course-builder/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Weekly Channel Slack Digest
Source: https://docs.introw.io/headless/skills/vendor/slack-weekly-channel-digest
Generate the weekly partner-team Slack digest: wins, registrations, at-risk partners, pending approvals, KPI deltas, and action items, posted to Slack.
*Vendor skill for [Use case 14: Ecosystem Performance](/headless/agentic-use-cases/ecosystem-performance).*
**Skill ID:** `vendor-slack-weekly-channel-digest`
Use when a Channel Chief, Channel Ops, or RevOps user wants to generate the weekly partner-team Slack digest, wins, registrations, at-risk partners, pending approvals, KPI deltas, action items, and post it directly to the channel-team Slack channel. Trigger phrases include "weekly channel digest", "Monday partner update", "post the partner digest", "weekly Slack update", "channel team digest", "what happened with partners this week".
**Built for:** Partner Program Manager · Channel Ops Manager · Channel RevOps
**Workflow:** Trailing 7 days across systems → Wins · regs · at-risk · queue · KPI deltas · anomalies → First run preview · then auto-post → Channel-team Slack · message link logged
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-slack-weekly-channel-digest
description: Use when a Channel Chief, Channel Ops, or RevOps user wants to generate the weekly partner-team Slack digest, wins, registrations, at-risk partners, pending approvals, KPI deltas, action items, and post it directly to the channel-team Slack channel. Trigger phrases include "weekly channel digest", "Monday partner update", "post the partner digest", "weekly Slack update", "channel team digest", "what happened with partners this week".
---
# Weekly Channel Slack Digest (Vendor)
**Audience**: Vendor, uses **claude.ai Introw** MCP + **claude.ai Slack** MCP.
**Use case**: 14, Ecosystem Performance.
## When to use this skill
Use when a Channel Chief, Channel Ops, or RevOps user wants to generate the weekly partner-team Slack digest, wins, registrations, at-risk partners, pending approvals, KPI deltas, action items, and post it directly to the channel-team Slack channel.
**Sample prompts that fire this skill:**
- "weekly channel digest"
- "Monday partner update"
- "post the partner digest"
- "weekly Slack update"
- "channel team digest"
- "what happened with partners this week"
## Why this matters
Most channel teams write their Monday digest by hand: someone opens 5 tabs (CRM, PRM, finance, Slack threads, Linear), copies numbers, paragraphs them up, posts to `#channel-team`. It takes 60–90 minutes and gets skipped half the time. The information ages by Tuesday.
Agentic generation collapses prep to seconds. The digest stops being a chore (and stops getting skipped). The leadership team gets a consistent, current weekly heartbeat. Pair it with `vendor-anomaly-detector` to make the digest predictive, not just retrospective.
## What the digest contains (default sections)
1. **Wins**: closed-won partner-attached deals this week, with partner attribution.
2. **New registrations**: count, total ARR value, top deals.
3. **Movers**: partners pacing up or down notably vs. prior week (engagement, registration cadence, deal velocity).
4. **At risk**: partners who slipped this week (engagement decay, missed milestones, dormant). Top 3 with suggested intervention.
5. **In the queue**: pending approvals, MDF requests, deal-reg conflicts awaiting resolution. Aging items flagged.
6. **KPI snapshot**: activation rate, partner-attached pipeline, tier movement, week-over-week deltas.
7. **Anomalies**: anything unusual surfaced by `vendor-anomaly-detector` worth a human eye.
8. **Action items**: top 3–5 things the team should focus on this week, with owners.
User can configure which sections appear, the time window (default trailing 7 days), and which Slack channel to post to.
## Process
### Step 1: Resolve config
- Default time window: trailing 7 days, ending at run time.
- Default Slack channel: ask the user the first time, then capture.
- Section toggles: ask for any sections to skip (e.g., user only wants Wins + At risk).
### Step 2: Pull data
- `Introw:search_crm_objects`: closed-won deals + new opps in window (partner-attached).
- `Introw:search_form_submissions`: new registrations in window.
- `Introw:search_partner_engagement`: engagement deltas vs. prior period.
- `Introw:search_partners`: partner roster + lifecycle states.
- `Introw:search_tasks`: overdue / aging tasks across the team.
- `Introw:search_commissions`: commission events for context.
- `Introw:get_goals`: pacing vs. quarterly goals.
- Optionally: re-use output from `vendor-anomaly-detector` if it ran.
### Step 3: Compose the digest
Build a Slack-friendly message using Slack's block kit (or simple markdown if user prefers):
- Header block with brand + week-of date range.
- Section blocks for each enabled section.
- Use bullet lists with bold labels.
- Include partner names with hyperlinks back to the partner record in Introw where possible.
- Keep total length under ~3,000 characters, Slack truncates long messages.
- For long sections, summarize in the post + link to a full report.
### Step 4: Post (or surface for approval)
- **First run**: surface the drafted digest to the user for review. Confirm channel + tone. Don't auto-post.
- **After approval**: post via `Slack:*` to the configured channel.
- For recurring runs (e.g., weekly cron), the user can enable auto-post once the format is dialed in.
- Capture the posted message URL via `Introw:add_comment` on a designated "weekly digest log" record (or a custom CRM object) so the audit trail exists.
## Output format
- **The digest itself**: Slack-formatted message (block kit JSON or markdown).
- **Confirmation**: posted-to channel, message link, timestamp.
- **Variants** for different audiences if requested (e.g., a shorter exec version for CRO Slack).
## Guardrails & PRM best practice
- **Don't auto-post on first run.** Always preview + approve. Tone calibration matters, a digest that misreads sentiment ("celebrating" a partner who just churned) burns trust faster than no digest.
- **Be honest about losses.** If the week was bad, the digest should say so. Sugarcoated digests train the team to ignore them.
- **Names matter.** Cite partners and team members by name (with proper Slack mentions where relevant): generic "the team" digests get skimmed.
- **Action items must have owners.** "Need to follow up on X" with no name attached doesn't drive action; either assign or remove.
- **Aging is the alarm bell.** Items aging past SLA (approvals > 24h, conflicts unresolved > 48h) get flagged in red, this is the single most useful section for ops.
- **Respect channel volume.** If the channel is high-traffic, default to a shorter format and link out for detail. If it's quiet, the digest is the headline.
- **No partner-confidential data in public channels.** Commission specifics, strategic-account discussions, tier moves, none of those go in `#channel-team` if it's broadly accessible. Use a private channel for those if needed.
- **Don't post during incidents.** If the team is mid-fire (outage, major customer escalation), defer the digest. The skill should ask before posting if the user wants to skip this week.
- **Cross-skill handoff.** Anomaly section feeds from `vendor-anomaly-detector`; KPI snapshot is essentially the standing health check from `vendor-ecosystem-health-check` if installed; at-risk section can hand off to `vendor-activate-network-with-personalized-campaigns` for follow-up.
- **Iterate the format.** After 4 weeks, ask the team what they actually read. Cut the sections that don't get traction. The best digest is the one people open.
```
Drop this file into `.claude/skills/vendor-slack-weekly-channel-digest/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Support Content Gap Detector
Source: https://docs.introw.io/headless/skills/vendor/support-content-gap-detector
Analyze recurring partner support questions, cluster by intent, and cross-check the knowledge base to find enablement content gaps partners keep hitting.
*Vendor skill for [Use case 06: Enablement Support](/headless/agentic-use-cases/enablement-support).*
**Skill ID:** `vendor-support-content-gap-detector`
Use when a Partner Enablement lead, Channel Ops, or Vendor IT user wants to analyze recurring partner support questions over a window, clustering by intent and cross-checking against the existing knowledge base, to identify the gaps where partners repeatedly ask but no clean answer exists. Outputs ranked content recommendations (battle cards, FAQs, micro-courses) with scope and target partners. Trigger phrases include "support content gaps", "what should we write next", "knowledge base gaps", "partners keep asking the same thing", "where's the content missing", "support deflection roadmap".
**Built for:** Partner Enablement Manager · Channel Ops Manager · Vendor IT
**Workflow:** Tickets · comments · form intake → Pricing · how-to · battle card · compliance · … → Strong / partial / weak / missing per cluster → Top 3–5 content investments ranked by ROI
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-support-content-gap-detector
description: Use when a Partner Enablement lead, Channel Ops, or Vendor IT user wants to analyze recurring partner support questions over a window, clustering by intent and cross-checking against the existing knowledge base, to identify the gaps where partners repeatedly ask but no clean answer exists. Outputs ranked content recommendations (battle cards, FAQs, micro-courses) with scope and target partners. Trigger phrases include "support content gaps", "what should we write next", "knowledge base gaps", "partners keep asking the same thing", "where's the content missing", "support deflection roadmap".
---
# Support Content Gap Detector (Vendor)
**Audience**: Vendor, uses **claude.ai Introw** MCP.
**Use case**: 06, Enablement Support.
## When to use this skill
Use when a Partner Enablement lead, Channel Ops, or Vendor IT user wants to analyze recurring partner support questions over a window, clustering by intent and cross-checking against the existing knowledge base, to identify the gaps where partners repeatedly ask but no clean answer exists. Outputs ranked content recommendations (battle cards, FAQs, micro-courses) with scope and target partners.
**Sample prompts that fire this skill:**
- "support content gaps"
- "what should we write next"
- "knowledge base gaps"
- "partners keep asking the same thing"
- "where's the content missing"
- "support deflection roadmap"
## Why this matters
AI deflects **40–60% of routine partner support tickets** (Gartner / Pylon benchmarks); best-in-class hits 70–80%. The gap between current and best-in-class is almost always the same shape: **partners are asking specific questions the knowledge base doesn't have a clean answer to.** The agent then either improvises (risky) or routes to humans (slow). Either way, the deflection rate stalls.
This skill closes that gap by inverting the analysis: instead of asking "what content do we have?", it asks "**what are partners actually asking that we don't answer well?**", then prescribes the next 3–5 content investments. The output is a content roadmap that's grounded in actual demand, not assumptions.
## Process
### Step 1: Define the analysis window
- Default: trailing 90 days. Long enough for pattern detection, recent enough for relevance.
- Optional scoping: by partner type, region, product line, or tier (Bronze partners often have different questions than Gold).
### Step 2: Pull partner support events
- `Introw:search_crm_objects` (object type = ticket): formal support tickets in window, with category, status, resolution time.
- `Introw:search_partner_engagement`: comments and conversational support events on partner records.
- `Introw:search_tasks`: task-style support items if program uses them.
- `Introw:search_form_submissions`: questions raised through forms (e.g., "ask my CAM" intake).
- Capture: question text (anonymized), product/category, resolver, time-to-resolve, partner tier, partner type.
### Step 3: Cluster by intent
Group questions into intent clusters. Common partner-support clusters:
- **Pricing / quoting / config** ("what's the price for 50 seats with annual billing?")
- **Product / feature how-to** ("how do I set up SSO with Okta?")
- **Provisioning / sandbox** ("can I get a 14-day demo tenant?")
- **Account / license lookup** ("is account X already a customer?")
- **Deal status / commission** (often deflectable to `partner-my-commissions`)
- **Marketing assets** ("where's the latest healthcare battle card?")
- **Compliance** ("are we SOC 2 / HIPAA / GDPR compliant for prospect X?")
- **Integration / API** ("does the API support batch operations?")
- **Competitive positioning** ("how do I respond when prospect mentions Competitor Y?")
- **Bug / outage / escalation** (rarely deflectable; route to engineering).
For each cluster: count, top sample questions, partners affected, average time-to-resolve, top resolvers.
### Step 4: Cross-check against existing knowledge base
For each cluster, score knowledge-base coverage:
- **Strong**: clean, current, easily findable answer exists.
- **Partial**: answer exists but is buried, outdated, or too generic.
- **Weak**: only fragments exist; the support agent is improvising.
- **Missing**: no usable content at all.
Score requires connecting to the vendor's content systems. Use whatever knowledge MCP is installed (Notion, Confluence, Google Drive, Box, etc.). If no knowledge MCP is connected, fall back to user input on coverage estimate per cluster.
### Step 5: Score gap priority
For each cluster:
- **Volume**: how many tickets/comments?
- **MTTR**: how long does resolution take currently?
- **Resolver cost**: who's resolving (CAM time? Engineering? Legal review?)
- **Coverage gap** (Step 4 score)
- **Compliance sensitivity**: does the cluster touch SOC 2 / GDPR / pricing exceptions? (Higher sensitivity = more careful content authoring required.)
Priority score = (volume × MTTR × resolver-cost) ÷ compliance-risk × coverage-gap-severity.
### Step 6: Recommend content per top cluster
For each top-priority cluster, prescribe a specific content asset:
- **Battle card** for competitive / pricing-objection clusters.
- **Step-by-step how-to doc** for product/feature/integration clusters.
- **FAQ entry** for short, repeated questions.
- **Micro-course** for clusters that involve a workflow with multiple steps (hand-off to `vendor-microcourse-from-closed-lost`).
- **Asset library entry** for marketing / collateral clusters.
- **Self-service portal action** for clusters that should be a button rather than a question (e.g., sandbox provisioning).
Each recommendation includes:
- Asset type and rough scope.
- Target audience (which partner types/tiers benefit most).
- Estimated deflection impact (volume reclaimed × time saved).
- Source material the agent can use to draft a first version (existing fragments, similar past tickets, internal docs).
### Step 7: Output the roadmap
- Top 3–5 content recommendations, ranked by priority score.
- Aggregate summary: how much support load could be deflected if all top recommendations shipped.
- "Quick wins" (high volume × low authoring effort) called out separately.
## Output format
- **Cluster table**: cluster name, volume, MTTR, current coverage, gap severity, priority score, sample questions.
- **Top content recommendations**: type, scope, target audience, est. deflection impact, source material.
- **Quick wins** flagged.
- **Compliance flags** for clusters needing legal/security review.
- **Capability-matrix recommendation**: which clusters should the support agent execute autonomously vs. route for approval (compliance-sensitive clusters stay human-approved).
## Guardrails & PRM best practice
- **Demand-driven, not catalog-driven.** Don't recommend content because there's a gap *in theory*; recommend because partners are *actually asking*. The volume column is the discipline.
- **Authoring cost matters.** A high-priority cluster that requires legal review on every word is not a quick win. Surface effort estimates honestly.
- **Anonymize before clustering.** Sample questions surfaced in the output should not contain partner-confidential data (account names, deal sizes). Replace specifics with placeholders.
- **Compliance-sensitive content** (SOC 2 attestations, pricing exceptions, contract terms) requires legal/security review before shipping. Flag, don't draft.
- **Don't deflect what should be human.** Some clusters (escalations, dispute handling, strategic-account discussions) shouldn't be deflected, humans handle them by design. Don't recommend content for those.
- **Pair with measurement.** When a content asset ships, measure the cluster's volume + MTTR over the following 60 days. If the asset doesn't move the metric, it's wrong content (not a deflection failure). Iterate.
- **Tier-aware content.** Bronze partners often ask different questions than Gold (Bronze: how to use the product; Gold: how to position against Competitor Z). Tier the content recommendations.
- **Multilingual scope.** If partners span regions, the content needs language coverage. Flag clusters where the volume is concentrated in non-English markets, translation needs to be in scope.
- **Cross-skill handoff.** Workflow-style clusters → `vendor-microcourse-from-closed-lost` to author. Compliance clusters → flag for legal. Sales-positioning clusters → battle card authoring (often handed off to product marketing). Once content ships, `vendor-support-deflection-audit` (if installed) measures the impact.
```
Drop this file into `.claude/skills/vendor-support-content-gap-detector/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Tier Promotion Batch Review
Source: https://docs.introw.io/headless/skills/vendor/tier-promotion-batch-review
Audit the partner base for tier promotion or demotion eligibility using revenue, certifications, engagement, and goal attainment, then draft partner comms.
*Vendor skill for [Use case 02: Partner Segmentation](/headless/agentic-use-cases/partner-segmentation).*
**Skill ID:** `vendor-tier-promotion-batch-review`
Use quarterly (or on demand) when a Channel Chief, RevOps, or PDM wants to audit the entire partner base for tier promotion or demotion eligibility, combining revenue, certifications, engagement, and goal attainment, and draft the partner-facing comms for each move. Trigger phrases include "tier review", "who's ready for promotion", "tier promotion batch", "who should we demote", "annual tier audit", "Gold/Silver/Bronze review".
**Built for:** Partner Program Manager · Channel RevOps · Partner Development Manager
**Workflow:** Tier · revenue · certs · goals · engagement + tier rules → Eligibility per criterion · sustained-quarter bar → Promote · Hold · Demote · Watch → Drafted per-partner messages · tier writes
```md SKILL.md theme={"theme":{"light":"github-light","dark":"github-dark"}}
---
name: vendor-tier-promotion-batch-review
description: Use quarterly (or on demand) when a Channel Chief, RevOps, or PDM wants to audit the entire partner base for tier promotion or demotion eligibility, combining revenue, certifications, engagement, and goal attainment, and draft the partner-facing comms for each move. Trigger phrases include "tier review", "who's ready for promotion", "tier promotion batch", "who should we demote", "annual tier audit", "Gold/Silver/Bronze review".
---
# Tier Promotion Batch Review (Vendor)
**Audience**: Vendor, uses **claude.ai Introw** MCP.
**Use case**: 02, Partner Segmentation.
## When to use this skill
Use quarterly (or on demand) when a Channel Chief, RevOps, or PDM wants to audit the entire partner base for tier promotion or demotion eligibility, combining revenue, certifications, engagement, and goal attainment, and draft the partner-facing comms for each move.
**Sample prompts that fire this skill:**
- "tier review"
- "who's ready for promotion"
- "tier promotion batch"
- "who should we demote"
- "annual tier audit"
- "Gold/Silver/Bronze review"
## Why this matters
Tier reviews are the most economically consequential ritual in a partner program, they determine margin, MDF eligibility, deal protection priority, and PDM access, and they're also the most commonly **arbitrary or skipped** ritual. Most programs run them once a year, rush the analysis, promote a few favorites, and demote nobody (because nobody wants the conversation). The result: tier inflation that makes the whole tier system meaningless, and partners who *should* have been promoted feeling overlooked.
This skill makes tier reviews **rigorous, consistent, and complete**: every partner gets reviewed against the same criteria; promotions and demotions are evidence-grounded; the comms are drafted so the actual conversation gets had instead of deferred.
## Inputs to gather first
- **Tier definitions**: revenue thresholds, certification requirements, sustained-quarter requirements per tier. Pull from `Introw:get_tier_information` if encoded; else ask.
- **Review window**: trailing 4 quarters (default), trailing 2 quarters (more reactive), trailing year-to-date, custom.
- **Move policy**: do you allow demotion? Do you allow tier-jumps (Bronze → Gold) or only adjacent moves (Bronze → Silver)?
- **Notification policy**: how much advance notice do partners get on demotion (default 60–90 days)?
## Process
### Step 1: Pull the partner base
- `Introw:search_partners`: full active partner roster with tier, lifecycle stage, categories, region.
- `Introw:get_tier_information`: current tier rules and requirements.
- For each partner, capture current tier and tenure-in-tier.
### Step 2: Compute eligibility per partner per tier
For each partner, against each tier's requirements:
- **Revenue criteria**: closed-won partner-attached ARR over the review window. Use `Introw:search_crm_objects` filtered to closed-won and `Introw:search_commissions`.
- **Certification criteria**: required certs present? Use `Introw:search_partner_engagement` for completion records.
- **Engagement criteria**: minimum activity thresholds? Use `Introw:search_partner_engagement`.
- **Goal attainment**: pacing on committed goals? Use `Introw:get_goals`.
- **Sustained-quarter criteria**: were they at this performance level for ≥ N consecutive quarters? Critical to avoid promoting on a single mega-deal.
Score: meets / exceeds / approaches / below for each criterion.
### Step 3: Generate move recommendations
Bucket each partner:
- **Promote**: meets or exceeds all next-tier criteria, sustained.
- **Hold (target review next quarter)**: approaching next tier, but one criterion lagging.
- **Hold (stable)**: meets current tier squarely; nothing to change.
- **Demote**: falls below current tier criteria, sustained ≥ 2 quarters, not recoverable through near-term intervention.
- **Watch (demotion candidate)**: falls below current tier this quarter only; needs runway + intervention before demotion.
### Step 4: Apply tier-move guardrails
- No tier-jumps unless policy allows (most programs limit to adjacent moves).
- Demotions require ≥ 2 quarters of underperformance, single-bad-quarter demotions destroy partner trust.
- Notice period applied: demotions get the configured advance notice (e.g., effective in 90 days).
- Any partner with a major in-flight strategic deal gets flagged for human override consideration before demotion.
### Step 5: Draft per-partner comms
Three templates to generate:
**Promotion comms** (celebratory + concrete unlocks):
- Subject: "Welcome to [Tier], [Partner Name], and what unlocks for you"
- Lead with the celebration.
- Concretely list new benefits (margin uplift, deal protection upgrades, MDF access, dedicated PDM, etc.).
- Soft close with an invitation to a 30-min call to walk through what changes.
**Demotion comms** (empathetic + path-forward):
- Subject: "[Partner Name], a heads-up about your tier status and how we get back on track"
- Lead with appreciation for the partnership.
- State the move and the why (specific criteria not met, with numbers).
- Offer a clear path back (what would qualify them for promotion next review).
- Invitation to a CAM call to plan the recovery.
- Effective date with the configured runway.
**Hold-watch comms** (proactive heads-up):
- Subject: "[Partner Name], staying at [Tier], with one thing to watch"
- Where they stand, what's strong, what's at risk.
- What to focus on this quarter.
- This is the most-skipped category and the highest-leverage one.
### Step 6: Surface for executive review
- Bundle the recommendations into a reviewable packet:
- Promotion list (count, ARR represented).
- Demotion list (count, ARR at risk).
- Hold-watch list.
- Override candidates flagged.
- Channel Chief signs off.
- Once approved: schedule comms send (don't auto-send unless explicitly authorized).
### Step 7: Capture and execute
- For approved moves: `Introw:update_crm_object` to update tier on each partner record.
- `Introw:add_comment` on each partner with the rationale + the criteria scoring.
- `Introw:add_task` for the relevant CAM/PDM to follow up post-comms with a call.
- For any partner where the agent's recommendation was overridden by a human, log the override + reason, feeds rule evolution next cycle.
## Output format
- **Tier review summary**: bucket counts, ARR represented, comparison to last review.
- **Per-partner detail table**: name, current tier, recommended move, criteria scoring, evidence references, drafted comms.
- **Override candidates** with full context.
- **Comms drafts** ready for review.
- **Rule-tightness diagnostic**: criteria that almost nobody meets (probably set too high) or almost everybody meets (probably set too low).
## Guardrails & PRM best practice
- **Sustained performance, not single-quarter.** Promoting on a mega-deal sets the partner up to be demoted next quarter. Use ≥ 2-quarter sustained performance as the bar.
- **Demotions need runway.** Surprise demotions destroy partner trust. Configured notice period (default 60–90 days) with a clear path-back is non-negotiable.
- **No silent moves.** Every promotion and demotion is communicated to the partner with reasoning. Tier moves the partner discovers in the portal six months later are the #1 cause of churn for mid-tier partners.
- **Override transparency.** When channel leadership overrides the agent's recommendation, capture the rationale via `Introw:add_comment`. Pattern overrides should evolve the rules.
- **Tier rules audit.** If the criteria are so loose that 80% of partners are eligible for promotion, the criteria are wrong. If only 1 partner per cycle ever promotes, also wrong. Use this skill's output to surface that diagnostic.
- **No tier inflation.** Resist the temptation to promote across the board to avoid hard conversations. Inflation makes the entire tier system meaningless.
- **Strategic deal protection.** Partners with a major in-flight deal don't get demoted mid-cycle even if the criteria say so, surface for human override.
- **Don't auto-execute.** Surface recommendations + comms drafts; require executive sign-off before any tier change is written or any comms are sent.
- **Capture the audit trail.** Every move must have a comment trail showing the criteria evaluated and the decision rationale. Auditors and disputing partners will ask.
- **Cross-skill handoff.** Promotion candidates who look strong but lag on certifications → `vendor-microcourse-from-closed-lost` or `vendor-training-gap-analysis` to close the gap before next review. Demotion-candidates with recoverable engagement issues → `vendor-activate-network-with-personalized-campaigns` for intervention.
```
Drop this file into `.claude/skills/vendor-tier-promotion-batch-review/SKILL.md` in your repo and Claude Code triggers it on the prompts in its `description`. Or run the same play in plain language from Claude, ChatGPT, Slack, Teams, or your CRM through [Introw's MCP server](/features/developer/mcp): every action writes back to your CRM source of truth.
# Explore Introw
Source: https://docs.introw.io/home
Jump straight into Introw, the AI-native, CRM-native PRM - every domain, feature, and guide from one place, plus the partner types it powers and the API to build on.
> The agentic PRM that meets your team and partners where they work, built into HubSpot and Salesforce. Pick an area below to dive into its features, setup guides, and API.
## Start here
Take one real partner live on the free plan. No time limit, no call first.
The vision and strategy behind the platform.
How Introw reshapes the daily rhythm for partner managers and every partner type.
Guided, why-first implementation tracks to go live in weeks, per partner type.
Run your whole partner program in plain language from Claude, ChatGPT, Slack, and your CRM.
## Explore the product
Every area of the platform, grouped the way partner teams evaluate it: manage the program, collaborate on deals, enable partners, and the platform underneath.
### Partner management
Detect, organize, and progress partners.
Most of it already runs; build the rest yourself.
No-code forms that sync to your CRM.
### Partner performance
Analytics for vendors and partners.
### Referrals, incentives and payouts
Off-portal lead sharing that pays out.
Calculate, review, and pay incentives.
Run MDF from request to ROI.
Tracked links with fraud protection.
### Deal registration and co-selling
Give every partner live visibility into their CRM records - and let them self-serve on each one.
Register and protect partner-owned deals.
Partner-built quotes with governed pricing.
### Partner engagement
Every nudge, notification, and announcement, on auto-pilot.
### AI agents
Headless partnerships - meet partners where they work.
AI assistants for partners and sellers.
### Partner portal
White-labeled portals on your domain.
### Partner enablement
One governed library for every surface.
Train and certify your partners.
### Platform
Keep the CRM the source of truth.
Serve partners in their language and currency.
Control who sees and does what.
Build on and embed Introw.
# Welcome to Introw
Source: https://docs.introw.io/introduction
Introw is the agentic PRM and partner portal for HubSpot and Salesforce: your team and partners work where they already are, the branded portal governs the program, and the operators who own it configure everything.
> Introw is the agentic PRM that meets your team and partners where they work. It runs inside HubSpot or Salesforce, partners and vendors act from the CRM, Slack, Teams, email, or their own AI assistant, and the branded partner portal stays the governance layer and the shop window of the program. AI agents handle the busywork, so the people who own the program spend their time on strategy instead of operations.
## Why Introw exists
Partner teams were stuck between two bad options. Legacy PRMs promised everything and then needed a consultant for every change. CRM-native portals were powerful, but every adjustment was an engineering ticket behind the product roadmap. Either way, the operators who owned the partner program owned none of the software that ran it - and partner activity drifted away from the CRM, the place sales actually works.
Introw ends that. The partnerships team can change anything themselves - no code, no dev tickets, no delays. The CRM stays the source of truth, always. And partners never have to leave the tools they already use.
Introw is AI-native, not AI-bolted-on. Agents take on the mechanical work - data entry, follow-ups, content drafting, deal and lead registration, partner support - so a small team can run a large program. The result is less time on busywork and more time on the things that actually compound: building relationships, enabling partners to sell, and driving revenue.
## Is Introw a PRM?
Yes. PRM - partner relationship management - is the category, and Introw is what a PRM looks like rebuilt from scratch. Everything a PRM is bought for is here: partner records and tiers, branded partner portals, deal and lead registration, enablement and training, commissions and MDF, goals and reporting. What is different is the foundation under it. The CRM is the system of record rather than a second database to reconcile. Agents do the mechanical work rather than a chatbot sitting beside it. The partner team configures the whole thing rather than a consultant. And the portal is one way in rather than the only one.
Buyers also call this category partner portal software. Introw is both: the PRM runs in your CRM, and the branded partner portal is where your program is defined and where partners see it.
## How Introw is different
These are the bets that decide what we build, and what we refuse to build.
Each card opens a page on that difference.
CRM-native by design: your program runs inside HubSpot or Salesforce. Everything syncs both ways, so your CRM stays the single source of truth.
Partners and teams act from the CRM, Slack, email, and AI assistants. No new tool to adopt, and the portal is never the only way in.
No consultants, no dev tickets. Your team configures forms, portals, and automations itself - so the program stays cheap to run.
Agents handle the busywork across the lifecycle, with humans in the loop where judgment matters.
Configuration, not construction. Go live in weeks, not quarters - no middleware, no custom build.
Run large, multi-motion programs with confidence. SSO, granular access, and governance keep it secure as you scale.
## Less friction, more partner revenue
Every partner program runs on the same chain. Remove friction for your team and for your partners, and more partners take part. More partners taking part means more partner-sourced and partner-influenced revenue. More revenue from the same team is a higher return on the program.
That is why Introw meets both sides where they already work - the CRM, Slack or Teams, and their AI assistant - while the branded portal stays the governance layer that sets the rules and the professional shop window partners and prospects see. It is also why everything partnerships runs in one place, at the lowest cost to own and the fastest time to value, owned end to end by the program or partner ops manager rather than by engineering or a consultant.
## Prove it on your own CRM
The part of Introw worth testing first is the CRM integration, because that is where partner programs lose most of their time. Start on the free plan or a trial, connect HubSpot or Salesforce, and run a real partner through it: partners are detected from your records, a registered deal lands on your own pipeline, and every partner action writes back to the right object. You see the manual chasing and reconciling disappear on your own data, before you sign anything, and that is what frees partnership leaders to talk strategy instead of operations.
One real partner live on your own CRM. No time limit, no call first.
## Where it all adds up
These bets are not separate features - they compound into a single return: a program that costs less to run and produces more partner-attached revenue. We break that down the same way we break down each bet above - with a dedicated deep dive.
Where the return comes from - more partner-attached pipeline, faster activation and onboarding, lower cost to run, and protected margin - with cited benchmarks, the dominant levers by partner type, and a model that scales to the size of your ecosystem.
## The value we create
* **Live in weeks, not quarters.** Setup is configuration, not construction. There is no middleware to wire up and no custom build, so most teams are up and running in weeks: Tensis went live in under 2 weeks.
* **Cheap to run and own.** Forms, portals, automations, content, access - all changeable by the partnerships team without engineering or product. No consultants, no dev tickets, no waiting, so the total cost of ownership stays low.
* **Everyone works where they already are.** Enablement, training, deal coaching, deal updates, and deal registration all happen in the tools partners and teams already use, which is what actually keeps partners engaged.
* **Your CRM stays true.** Every partner action syncs back automatically, so attribution and reporting are real-time and trustworthy.
Teams see the result in the numbers that matter: more partner pipeline, faster onboarding, and more partner-influenced revenue - all visible in the CRM, not a side dashboard.
## Where we're going
The next generation of partner programs is headless. The portal stays the home of the program, and it is no longer the only place partnerships run: they also run where work already happens.
We are building toward a world where agents do the mechanical work across the entire partner lifecycle and humans stay in the loop where judgment matters. A deal registers itself from a Slack message in under two minutes. Every strategic partner gets a QBR generated in seconds and shipped after a quick edit. Every deal gets a coach. Every partner question gets a 24/7 answer in their own language. RevOps stops being the bottleneck for "can you pull a list of...", and channel conflict is caught the moment it happens, not three weeks later.
The portal does not go away in that world, it becomes the place the experience is defined - what each partner may see, do, and earn - and the shop window of a professional program. The CRM, Slack, Teams, email, and any MCP-connected assistant then become equally valid ways in, and every one of them enforces the same rules. Introw is the layer that orchestrates it, scoped to permissions and auditable by design.
## Where to next
Every domain, feature, and guide from one place.
See which features power affiliate, referral, co-sell, reseller, distributor, and implementation programs.
Authenticate and build on the Introw REST API.
# Partner types
Source: https://docs.introw.io/partner-types
Run the full partner spectrum in Introw: affiliate, referral, co-sell, hyperscaler, reseller, distributor, and implementation, each with a tailored experience.
> Real partner ecosystems are not one shape. The same vendor runs affiliates who only drive clicks, referrers who make warm intros, co-sellers who run deals side by side, hyperscalers who co-sell from their own portals and marketplaces, resellers who own the sale, distributors who stand above a whole reseller network, and implementation partners who deliver the outcome after the deal is won. Introw supports the full spectrum, and lets you give each type its own branded, scoped experience.
## The partner spectrum
Partner types differ most in one question: who closes the deal. That single axis shapes almost
everything else, from what the partner needs in the portal to how they get paid.
| Type | Who closes | What they do |
| - | - | - |
| **Affiliate** | Vendor | Drives awareness and clicks at scale through a tracked link. |
| **Referral** | Vendor | Makes a warm, named introduction and steps back. |
| **Co-sell** | Shared | Sells side by side with your team on shared accounts. |
| **Hyperscaler** | Shared | Co-sells with your team; their marketplace carries the transaction. |
| **Reseller** | Partner | Owns the full sale, margin, and often delivery. |
| **Distributor** | Partner network | Recruits and enables a whole reseller network, two tiers up. |
| **Implementation** | Someone else closed | Deploys, integrates, and onboards the customer after the sale. |
The last type is the exception that proves the axis: an implementation partner never closes the
deal at all. Someone else wins it, and the implementation partner is pulled in afterward to make the
customer succeed. Its needs follow from delivery, not from selling.
You rarely run just one. Introw lets you support several at once and give each the experience that
fits how they actually work.
## Affiliate
Promotes the product to a large audience through a tracked link and earns a commission on what
converts, without ever touching the deal. Affiliates want self-serve links, a live earnings
dashboard, ready-to-use creative, and frictionless payouts.
See how affiliates self-serve campaigns, links, earnings, and payouts.
Tracked referral links with attribution and abuse protection.
Automated, pay-per-outcome payouts.
Clicks, conversions, and earnings.
## Referral
Makes a warm, named introduction from their own network and earns a fee if it closes, while your
team runs the actual sale. Referrers want a dead-simple way to refer off-portal, visibility into
status, and confidence they will be paid.
See how referrers submit intros, track status, and trust rewards.
Off-portal lead sharing, auto-updates, and rewards.
No-code referral and registration capture.
Referral fees and revenue share.
## Co-sell
Sells side by side with your team on shared accounts, with joint account mapping, joint planning,
and orchestrated execution. Co-sellers want to collaborate on the live CRM deal without a CRM seat,
shared pipeline, joint action plans, and co-branded assets.
See how co-sellers work overlap, shared deals, tasks, and attribution.
Register, collaborate, and close on shared records.
Co-branded assets to fund joint campaigns.
Fund joint marketing together.
## Hyperscaler
Every other partner type logs into your portal. A hyperscaler - AWS, Microsoft, or Google Cloud -
never will: they run their own. You work their co-sell program inside AWS Partner Central,
Microsoft Partner Center, or Google Cloud Partner Advantage, and their marketplace often carries
the transaction itself, because buyers want to draw the purchase down against cloud spend they
have already committed.
### How the co-sell motion works: ACE, referrals, and private offers
AWS runs the most developed version of the pattern. Co-selling happens through **ACE (APN
Customer Engagements)**: you share opportunities with AWS through the ACE Pipeline Manager in AWS
Partner Central, AWS routes AWS-originated referrals back to you, and AWS field sellers engage on
the deals where the better-together story is strong. The transaction itself often closes as an
**AWS Marketplace private offer**, because the purchase draws down the customer's committed cloud
spend (an EDP) and the AWS seller retires quota on marketplace-transacted co-sell - so procurement
accelerates and the field is incentivized to push. Microsoft mirrors the motion with Partner
Center co-sell referrals, Azure Marketplace, MACC (Microsoft Azure Consumption Commitment)
drawdown, and multiparty private offers; Google Cloud with Partner Advantage and Google Cloud
Marketplace private offers.
None of that touches your portal - and it doesn't need to, because the whole motion converges on
your CRM. AWS ships the **AWS Partner CRM Connector** for Salesforce, syncing ACE opportunities,
ACE leads, and Marketplace private offers two-way; Microsoft ships co-sell connectors for
Salesforce and Dynamics 365; and marketplace platforms such as Tackle, Clazar, WorkSpan, or Suger
sync all three clouds into HubSpot and Salesforce. In practice, an ACE opportunity or a private
offer is an opportunity record in your CRM - and the CRM is exactly where Introw runs.
### What you want the motion to look like - and how Introw runs it
Ask a SaaS vendor what good hyperscaler collaboration looks like and you hear the same five
things. Each one maps onto what Introw already does with the CRM record:
| You want | Introw runs it |
| - | - |
| **One pipeline.** ACE opportunities, Partner Center referrals, and private offers next to your direct deals - no swivel-chair between Partner Central and the CRM. | The hyperscaler's connectors land them in the CRM; Introw picks each one up as a first-class program deal the moment it is attributed to the hyperscaler partner. |
| **Attribution both sides trust.** Hyperscaler-sourced and -influenced revenue defensible to your CRO, and a co-sell pipeline that programs like AWS ISV Accelerate gate on. | Partner attribution lives on the CRM record itself, so sourced vs. influenced reporting and shared pipeline views come from the one source of truth your revenue team already trusts. |
| **Field sellers who engage without adopting a tool.** Hyperscaler sellers rotate often and carry hundreds of vendors; any motion that requires a login loses. | Add a seller to the shared deal and they collaborate off-portal from day one: live deal status and updates by email, Slack, or Teams, replies tracked back on the record, visibility scoped to just the deals you share. |
| **Sellers enabled on the better-together story.** Battlecards, reference architectures, and joint pitch decks in the seller's hands when the deal needs them. | Announcements push launches and co-sell content straight to their inbox, no login required, and the content library scopes those assets to a hyperscaler segment. |
| **A motion that survives rotation.** Counterparts change constantly; the program can't restart every time. | A counterpart change is a contact swap on the deal, not a portal re-onboarding - deal history, notifications, and enablement continue uninterrupted. |
And when a channel partner carries the marketplace transaction - CPPO (channel partner private
offers) on AWS Marketplace, a multiparty private offer on Azure - the reseller and the hyperscaler
sit on the same CRM deal, each attributed and each credited.
ACE opportunities and marketplace deals land in the CRM and become first-class Introw deals.
Live shared-deal collaboration by email and chat - no CRM seat, no portal login.
Broadcast launches and better-together content to hyperscaler sellers.
Battlecards, reference architectures, and joint pitch decks, scoped to their sellers.
Introw has no native ACE, Partner Center, or marketplace connector - by design. AWS's Partner
CRM Connector, Microsoft's co-sell connectors, and the marketplace platforms already land this
pipeline in HubSpot or Salesforce. Introw is the program layer on top of that record:
attribution, collaboration, and enablement start the moment a deal hits the CRM.
## Reseller
Buys and resells the product to their own customers, owning the sale, the margin, and usually
delivery. Resellers want self-serve quoting, certification and enablement, deal registration that
protects their margin, and clear visibility into what they earn.
See how resellers register, quote, get support, and track earnings.
Register, protect, and edit reseller-owned deals.
Partner-built quotes with governed pricing.
Certify resellers to sell and deliver.
## Distributor
Sits above resellers, recruiting, enabling, and aggregating a whole reseller network on your behalf
in a two-tier model. Distributors and their resellers need shared credit and visibility on the same
deal, which Introw delivers through multi-tier attribution on the CRM record.
See how distributors manage attribution, access, enablement, and sell-through.
Credit and visibility across distributor and reseller.
Scope who sees and does what across tiers.
Attributed pipeline across the channel.
Introw represents two tiers through multiple partner attributions on the same CRM deal, not a
parent-child partner hierarchy or automatic roll-up reporting across a reseller network.
## Implementation
Delivers the outcome: deploys, integrates, customizes, migrates data, and onboards the end customer
so they actually go live. Someone else closed the deal - the vendor, a reseller, or a co-seller - so
the implementation partner is measured on go-live and adoption, not the signature. It is not purely
post-sale, though: implementation partners are often pulled into the deal as solution architects to
scope the work, design the solution, and lend the delivery credibility that de-risks the purchase.
Then their deep integrations, migrated data, and trained users embed the product into the customer's
workflows, which raises switching costs and drives renewal, expansion, and stickiness. Implementation
partners want a clean handoff with full deal and account context, project and onboarding tracking on
the record, deep certification to be authorised to deliver, and a governed library of solution docs
and runbooks.
See how implementation partners take a handoff, scope, and drive go-live.
Certify consultants to deliver and keep them current.
Governed solution docs, runbooks, and technical assets.
Take the handoff and collaborate on the won deal without a CRM seat.
## One platform, many branded experiences
A bigger ecosystem should never feel like a one-size-fits-all portal. With Introw you build multiple
branded experiences, so each partner type lands in something that feels made for them: the affiliate
sees a lightweight earnings hub, the reseller sees enablement and deal registration, the distributor
sees their network's pipeline, the hyperscaler seller sees just the shared deals and co-sell content,
and the implementation partner sees delivery projects and certification. Each experience carries your branding on a custom domain, while the CRM stays the
single source of truth underneath.
Build personalized, white-labeled experiences per partner type.
Assemble an experience tailored to an audience.
## Tailor each experience with segmentation
Branded experiences set the frame; segmentation decides what each partner persona actually sees
inside it. Group partners into segments, then scope assets, courses, announcements, pipeline, and
permissions to the right segment. A distributor's resellers see reseller enablement, your top-tier
co-sellers see strategic content, implementation consultants see certification and delivery
runbooks, and affiliates see only what they need, all from the same platform.
Group partners and scope what each segment sees and can do.
Limit access by partner persona.
## Where to go next
The upside of each partner type, modeled by ecosystem scale.
Every domain, feature, and guide from one place.
Detect, organize, and progress partners in the CRM.
# Start free
Source: https://docs.introw.io/start-free
Run a real partner program on the free plan: your own CRM, your own partners, one partner live, no time limit. What you get on day one, what your first 30 minutes look like, and when you outgrow it.
> You do not need a contract, a call, or a sandbox to find out whether Introw works for your program. Sign up, connect your CRM, and take one real partner live. The free plan has no time limit, so the only thing you are committing is the half hour it takes to set up.
Sign up at app.introw\.io/signup. No credit card, no time limit.
## What free actually includes
No trial countdown, and no feature crippled to make a point. The free plan is the whole product at the scale of one partner.
| What you get | On the free plan |
| - | - |
| **CRM Connection** | Deep, native integrations including custom objects |
| **Slack / MS Teams** | Agents and automatic nudges |
| **MCP Connectors** | Claude, ChatGPT, Gemini, Copilot and more |
| **Partners in your list** | As many as your CRM has. Importing is unlimited |
| **Forms** | As many as you want, integrated with your CRM |
| **Announcements** | As many as you want |
| **Tasks / Journeys** | As many as you want |
| **Assets** | As many as you want |
| **Experiences** | As many as you want |
| **Partner portals** | 1 |
| **Goals** | 1 |
| **Reports** | 1 |
| **Courses** | 1 |
| **Languages** | 1 |
| **Workflows** | 1 |
| **Certificates** | 1 |
| **Deal Coaching** | 1 |
| **Commission plans** | 1 |
| **API** | Free monthly allowance of requests. See [API credits](/general/api-credits) |
| **Time limit** | None |
The number that matters is **portals, and a portal is what a partner gets when you publish an experience to them**. So import your whole ecosystem on day one: a partner sitting in your list costs nothing. The limit only bites when you take the second partner live.
## What is already built when you arrive
Your workspace is not empty. It is seeded from a working demo program, so the first thing you do is edit something rather than face a blank page.
A referral experience and a reseller experience, built and ready to publish.
Deal registration and lead sharing, already mapped to CRM fields.
Tiers with requirements, internal roles, and a segment holding all partners.
Starter assets in folders, plus the hub that surfaces them in a portal.
An onboarding path you can assign to a new partner.
A seeded set, plus announcements and reusable synced sections.
## Your first 30 minutes
This is the spine every [setup track](/tracks) shares, whatever kind of partner you run. Do it in this order: step 2 is what decides whether anything downstream works.
HubSpot connects with OAuth. On Salesforce, an admin installs the Introw package, then authorizes from the **Introw Setup** app in Salesforce: Introw connects through an External Client App that ships in the package, so there is no separate OAuth app to approve and no key to paste. This is the step most people underestimate, because it usually needs someone with admin rights in the CRM rather than the person running partnerships. If that is not you, send it to whoever holds the keys and keep going: you can add partners by hand in the meantime.
Before you ask them, [HubSpot permissions and scopes](/features/integrations/crm/guides/hubspot-permissions-and-scopes) and [Salesforce permissions and scopes](/features/integrations/crm/guides/salesforce-permissions-and-scopes) tell them exactly what Introw reads and writes.
Two steps: which records in your CRM are partners, and which objects link to a partner. Deals above all. Get the filter right here and your pipeline, attribution and commissions all resolve on their own.
See [Detect partners from your CRM](/features/partners/partner-management/guides/detect-partners-from-your-crm) and [Configure deal attribution](/features/co-selling/shared-pipelines/guides/configure-deal-attribution).
Import them from the CRM filter, or add one by hand. Their contacts come with them. Import as many as you like: this does not touch the free limit.
See [Sync partners and contacts](/features/integrations/crm/guides/sync-partners-and-contacts).
Open the deal-registration form that is already there rather than building one. Cut the fields you do not need, confirm the CRM mapping, then submit it once yourself and watch the record land in your CRM. That single test is the fastest proof that the whole thing works.
See [Test a form before partners see it](/features/forms/form-builder/guides/test-a-form-before-partners-see-it).
Start from a seeded experience, change the parts that are obviously ours, and publish it to a single partner: ideally a real one you have a relationship with, who will tell you when something is confusing.
See [Build and publish a portal experience](/features/portal/experiences/guides/build-and-publish-a-portal-experience) and, before you send anything, [Draft, published and preview](/features/portal/experiences/guides/draft-publish-and-preview).
Granting access and sending an invitation are two different actions, so a partner can be able to sign in and not know it. Invite them deliberately, then check whether they actually opened it.
See [Launch the portal and run the first two weeks](/features/portal/portal-access/guides/launch-and-the-first-weeks).
## What you can prove for free
One partner is enough to run the whole loop end to end, which is the point of the free plan. With a single partner live you can prove:
* A partner **registers a deal** in their portal and it lands in your CRM, attributed to them, with your naming and your owner.
* A **submission goes through an approval gate**, and the partner is told the outcome in words you wrote.
* The partner **sees their own pipeline** and only their own records.
* They **open an asset** and you can see that they did.
* They **finish an onboarding journey** and a task closes.
* Your team gets the whole thing **in HubSpot or Salesforce**, on the record they were already looking at.
If that works for one partner, it works for two hundred. Nothing about the mechanics changes with scale, which is why the free plan is a real test rather than a demo.
## Then pick the track for your partner type
The steps above are the common half. What comes next depends on who closes the deal, and each track only sends you to configure what that partner type actually uses.
Off-portal registration, conflict protection, referral fees. The vendor closes.
Tracked links, conversion attribution, fraud rules, payouts. The vendor closes.
Collaboration on the live CRM deal, shared pipeline, co-branded assets, MDF.
Tiering, deal registration that protects margin, self-serve quoting, certification.
Multi-tier attribution on one deal, sub-partner access, sell-through reporting.
A clean handoff on the won deal, scoped delivery access, go-live tracking.
Not sure which one you run? Start from [partner types](/partner-types).
## Taking your whole ecosystem live
The second partner is the moment the free plan ends, and it is a deliberate line: one partner proves the product, an ecosystem is a program.
When you get there, three things change and none of them is a rebuild.
Publishing an experience to partners who have no portal yet is what consumes them, and the check counts only the partners you are adding. Editing a live experience is never blocked.
See [Understand what your plan meters](/features/access/team-management/guides/understand-your-plan-limits).
Commissions, courses and certificates, MDF, partner quoting, affiliate campaigns, custom domains, SSO and the rest are per-plan. An area showing an upgrade prompt is a module question, not a count you can free up.
Take a cohort live, get half of them active, then widen. The pattern that fails is inviting everyone on day one and finding out a month later that nobody opened it.
See [Launch the portal and run the first two weeks](/features/portal/portal-access/guides/launch-and-the-first-weeks).
For what each plan includes and what it costs, see [introw.io/pricing](https://introw.io/pricing). For a guided proof of concept with a CSM alongside you, talk to us rather than working from this page.
## Why teams pick Introw
The free plan is the argument, not the marketing. But if you want the thesis before you spend the half hour:
Your CRM stays the source of truth. Nothing to reconcile.
Live in weeks. The setup is configuration, not construction.
No consultants to change a field. Your team configures it.
Partners work in their CRM, Slack, email or an AI assistant.
Agents take scoped actions, with a human approving.
SSO, SCIM, scoped access and an auditable trail.
Sign up at app.introw\.io/signup and connect your CRM. One partner live in about half an hour.
# Affiliate track
Source: https://docs.introw.io/tracks/affiliate
Stand up an affiliate program in Introw: tracked links at scale, signed click-to-conversion attribution, fraud protection, and automated payouts from your CRM.
> An [affiliate](/partner-types#affiliate) promotes you to a large audience through a tracked link and earns on what converts, never touching the deal. They want self-serve links, a live earnings view, ready-to-use creative, and payouts that just happen. You want attribution you can trust and fraud protection at volume, because at scale fraud comes straight out of margin. This track sets up exactly that and nothing more.
**Time to first value:** a working link-and-payout program in about half a day. **Owned by:** Partner Marketing and Partner Operations, with Finance for payouts. No engineering required.
## What an affiliate actually needs
Affiliates run hands-off at scale, so the program is designed to need almost no per-partner management. Their priorities, in order: get a link instantly, see what they have earned, grab creative without an approval cycle, and get paid without invoicing. Everything you configure should serve those four things. You deliberately skip intake forms, deal registration, channel conflict, shared pipeline, training, and tiering, because an affiliate touches none of them. Setting up less is the win.
## Set up the foundation
**Why it matters.** Affiliate conversions become contacts and deals in your CRM. Connecting first means every signup and sale an affiliate drives is reconciled against the same source of truth your direct funnel uses, so earnings can never drift from reality.
Connect HubSpot or Salesforce and let Introw read and write as the system of record.
**Time:** 20 to 30 min · **Who:** CRM Administrator, Partner Operations
* 
[**Connect your CRM**](/features/integrations/crm/technical)
Connect HubSpot or Salesforce and set where affiliates are stored.
**Why it matters.** A program that scales cannot onboard partners by hand. Letting affiliates self-serve their way in keeps your cost per partner near zero, which is the whole economic case for the affiliate motion.
Import an initial list or let affiliates sign themselves up, and their contact records come with them so payouts have a payee.
**Time:** 30 min · **Who:** Partner Operations
* 
[**Bring affiliates in**](/features/partners/partner-management/technical)
Detect affiliates from the CRM, with their contact as the payee.
## Launch the link-and-earn motion
**Why it matters.** The tracked link is the entire product for an affiliate. Self-serve, per-campaign links mean a creator is promoting you within minutes of joining, with zero work from your team.
Create a campaign, set its commission, and generate the tracked links; affiliates then copy their link from the portal and can create their own vanity aliases.
**Time:** 30 to 45 min · **Who:** Partner Marketing
* 
[**Create a campaign and issue tracked links**](/features/affiliate/campaigns/technical)
Set the commission, the attribution window, and the model.
**Why it matters.** Attribution is the affiliate program's source of truth. Signed, automatic click-to-conversion tracking removes manual crediting and the disputes that come with it, which is what keeps affiliates trusting (and promoting) the program.
Install the tracking script and capture conversions from your site, your CRM forms, or the API.
**Time:** 30 to 60 min · **Who:** Partner Operations, with a Developer if you track via the API
* 
[**Install conversion tracking**](/features/affiliate/conversion-tracking/technical)
Capture conversions from your site, your CRM forms, or the API.
**Why it matters.** At volume, self-referrals, disposable-email signups, and double-counted conversions drain margin directly. Screening conversions before they earn is what makes pay-per-outcome economics actually safe to scale.
Block self-referrals and disposable emails, deduplicate, and gate new-customer conversions.
**Time:** 20 to 30 min · **Who:** Partner Operations, Finance
* 
[**Turn on fraud protection**](/features/affiliate/fraud-protection/technical)
Block self-referrals and disposable emails, and deduplicate.
**Why it matters.** Affiliates promote harder when they can see pending earnings live. A lightweight earnings hub is all the portal an affiliate needs, so build that and resist adding more.
Set the campaign commission, then publish a simple earnings experience showing clicks, conversions, and pending payout.
**Time:** 1 to 2 hours · **Who:** Partner Marketing, Partner Operations
* 
[**Set the commission and the earnings view**](/features/affiliate/campaigns/technical)
A fixed fee or a percentage, and how often it pays.
**Why it matters.** Frictionless payouts are the affiliate's whole reason to trust you. Automating the run, reconciled to the CRM conversions, removes invoicing back-and-forth and keeps Finance out of spreadsheets.
Batch approved earnings into payouts and generate statements, all tied back to the tracked conversions.
**Time:** 30 to 60 min · **Who:** Finance, Partner Operations
* 
[**Pay out automatically**](/features/commissions/payouts/technical)
Batch approved earnings and issue an auditable statement.
## Go deeper once you are live
These are optional refinements for an affiliate program, not setup blockers. Add them once the basics are running.
* 
[**Vanity link aliases**](/features/affiliate/links-attribution/technical)
Let top affiliates use branded, memorable links.
* 
[**Monitor traffic quality**](/features/affiliate/fraud-protection/technical)
Watch for abuse patterns as volume grows.
* 
[**Read affiliate analytics**](/features/reporting/partner-analytics/technical)
See clicks, conversions, and earnings by affiliate.
* [**The full Affiliate domain**](/features/affiliate)
Campaigns, links, conversion tracking, and fraud in depth.
## You are live
You have a self-serve, fraud-protected, pay-per-outcome affiliate program that reconciles to your CRM and pays out without manual work. Your team manages the program, not each partner, which is exactly how the affiliate motion is meant to run.
Pick another partner-type track.
Go deeper on incentive calculation and payouts.
# Co-sell track
Source: https://docs.introw.io/tracks/co-sell
Stand up a co-selling program in Introw: seatless collaboration on the live CRM deal, account overlap discovery, shared pipeline, co-branded assets, and MDF.
> A [co-sell partner](/partner-types#co-sell) sells side by side with your team on shared accounts, so neither side owns the customer alone. That is exactly why rules of engagement, clean attribution, and a single shared view of the deal matter most here. This track sets up collaboration on the live CRM record, overlap discovery, and a shared pipeline both teams trust, then funds joint demand with assets and MDF.
**Time to first value:** partners collaborating on shared deals within about two days. **Owned by:** the Partner Manager and Partner Operations, with Sales, RevOps, and the CRO on rules of engagement and attribution.
## What a co-sell partner actually needs
A co-sell partner is a full org that mirrors your sales team: an alliance manager, reps, and a solutions engineer. They need to work the live deal with your AE without a CRM seat, discover which accounts overlap, share a pipeline view, and align on who does what so the direct team stays bought in. Money here is influence and sourcing credit, not resale margin, so commissions stay light and attribution trust is everything. CPQ, certification, and deal-reg-for-margin belong to the reseller motion, not this one.
## Set up the foundation
**Why it matters.** Co-selling is collaboration on a real CRM deal. A live two-way sync means both sides always see the same deal truth, which is the precondition for the CRO and RevOps to trust a shared-credit motion at all.
Connect HubSpot or Salesforce with two-way sync as the system of record.
**Time:** 20 to 30 min · **Who:** CRM Administrator, Revenue Operations
* 
[**Connect your CRM**](/features/integrations/crm/technical)
Two-way sync, and where partner records live in the CRM.
**Why it matters.** Co-sell partners bring multiple people to a deal: an alliance manager, reps, an SE. Importing partners with their full contact set means you can collaborate with the right person on each record from day one.
Detect co-sell partners from the CRM and bring their teams in as contacts.
**Time:** 30 to 60 min · **Who:** Partner Operations
* 
[**Import partners and their contacts**](/features/partners/partner-management/technical)
The alliance manager, the reps, and the SE on one account.
**Why it matters.** The defining co-sell capability is letting a partner work the live deal without a CRM seat. Choosing which objects they collaborate on and exactly which properties they see lets them contribute on the record while you keep full control of sensitive fields. This is collaboration that is CRM-native, not a copy in a side tool.
Link the CRM deals partners co-sell on, attribute their contribution on the record, then share the objects and pick the properties they can see and edit.
**Time:** 1 to 2 hours · **Who:** Partner Operations, CRM Administrator
* 
[**Set up collaboration on the right objects**](/features/co-selling/shared-pipelines/technical)
Share the deal, attribute the partner, pick visible fields.
## Build the co-sell motion
**Why it matters.** Co-selling starts with knowing where you and the partner both have presence. Overlap discovery points the joint motion at the accounts most likely to close, instead of guessing, so the first co-sell wins come fast.
Connect Crossbeam, map partners to their Crossbeam records, and surface overlap to target.
**Time:** 1 to 2 hours · **Who:** Partner Operations, Revenue Operations
* 
[**Discover account overlap**](/features/integrations/crossbeam/technical)
Target the accounts you and the partner both touch.
**Why it matters.** Shared deals are where channel conflict erupts and the direct team revolts. Clear rules of engagement plus AI conflict detection and an approval gate keep the two teams aligned and make the attribution defensible, which is what protects the program politically.
Define rules of engagement, detect overlap with direct or other-partner deals, and gate registrations for review with the AI agent on first pass.
**Time:** Half a day · **Who:** Partner Operations, Sales, CRO, with the Partner Manager
* 
[**Set rules of engagement**](/features/ai/deal-coaching/technical)
Codify who does what at each stage of a shared deal.
**Why it matters.** Both teams managing the same deals need one pipeline view they agree on. A shared pipeline with the right attribution settings is what lets the partner see their joint deals and lets the CRO see partner-influenced revenue in the same place as direct.
Add a pipeline to the experience, configure deal attribution, and control which deals each partner sees.
**Time:** 2 to 3 hours · **Who:** Partner Operations, Revenue Operations
* 
[**Configure the shared pipeline**](/features/co-selling/shared-pipelines/technical)
One board both teams agree on, scoped per partner.
**Why it matters.** A co-sell partner needs a place to land that combines their pipeline, the deals they collaborate on, and the assets to run joint plays. Start with that minimum viable partner portal; experience building goes much further and you can enrich it after launch.
Publish a co-sell experience with the shared pipeline and collaboration, then expand later.
**Time:** 2 to 3 hours · **Who:** Partner Operations, Partner Marketing
* 
[**Stand up a minimal co-sell experience**](/features/portal/experiences/technical)
The shared pipeline and collaboration, enriched later.
## Go deeper: fund and accelerate joint demand
Once partners are collaborating on shared deals, add the modules that make co-selling produce more pipeline. These are the co-sell-relevant extensions, in priority order.
**Why it matters.** Joint selling needs joint collateral. Co-branded assets in a governed hub let both sides run the same plays on-message, without a design cycle per deal.
**Time:** Half a day · **Who:** Partner Marketing
* 
[**Co-branded assets and an asset hub**](/features/content/asset-hub/technical)
Joint collateral one click away, scoped per partner.
**Why it matters.** Co-sell demand often needs joint-marketing money. Running MDF as CRM-linked requests and claims lets you fund campaigns with partners and prove the ROI, instead of trading spreadsheets.
**Time:** Half a day · **Who:** Partner Marketing, Finance
* 
[**MDF to fund joint marketing**](/features/mdf/projects/technical)
Requests through to claims, with the ROI reported back.
**Why it matters.** To keep the CRO and RevOps confident, partner-influenced versus partner-sourced revenue has to be clear, and reps need stage-specific guidance on complex joint deals. AI coaching plus partner analytics close that loop.
**Time:** Half a day · **Who:** Revenue Operations, Partner Manager
* 
[**Deal coaching and trustworthy reporting**](/features/reporting/partner-analytics/technical)
Influenced against sourced pipeline, both defensible.
## You are live
Partners co-sell on the live CRM deal without a seat, you target real account overlap, both teams trust one shared pipeline and clear rules of engagement, and joint demand is funded and measured. The direct team stays aligned because attribution is defensible and everything lives in the CRM.
Pick another partner-type track.
Go deeper on registration, collaboration, and shared pipeline.
# Distributor track
Source: https://docs.introw.io/tracks/distributor
Stand up two-tier distribution in Introw: multi-tier attribution credits distributor and reseller on one CRM deal, plus scoped access and roll-up reporting.
> A [distributor](/partner-types#distributor) sits above resellers: it does not sell to end customers, it recruits, finances, enables, and aggregates a whole reseller network on your behalf. It is a partner to you and vendor-like to its own resellers. This track sets up the two things that make two-tier work in Introw, multi-tier attribution on a single CRM deal and scoped access so a distributor can manage its sub-partners, then gives you the roll-up reporting to see sell-through.
**Time to first value:** distributor-and-reseller credit visible on shared deals within a few days. **Owned by:** Partner Operations and the Partnerships Lead, with Finance and RevOps on attribution and roll-up.
Introw represents two tiers through **multiple partner attributions on the same CRM deal**, not a parent-child partner hierarchy or automatic roll-up across a reseller network. This track sets up that attribution-based model. Keep it in mind as you design tiers.
## What a distributor actually needs
A distributor is dual-natured: an alliance manager owns the relationship up to you, while a channel-management function recruits, enables, and finances the downstream reseller network. On your side this is a strategic, CPO-level relationship run through ops and finance, not a single PAM. The distributor needs to manage sub-partners and their access, see credit and visibility on the same deals their resellers work, and get consolidated roll-up across many deals. The single most useful thing you configure is two-tier attribution on one deal.
## Set up the foundation
**Why it matters.** Two-tier credit has to resolve to one source of truth or the demand signal is lost. Connecting the CRM first means distributor and reseller attribution both write to the same deal record, which is the only way sell-through stays auditable.
Connect HubSpot or Salesforce as the system of record.
**Time:** 20 to 30 min · **Who:** CRM Administrator, Revenue Operations
* 
[**Connect your CRM**](/features/integrations/crm/technical)
Two-way sync, and where distributor records live in the CRM.
**Why it matters.** A distributor brings several people: an alliance manager facing you and a channel manager facing its resellers. Importing the distributor with its contacts is what lets you scope the right people's access in the next step.
Detect distributors from the CRM and bring their contacts in.
**Time:** 30 to 60 min · **Who:** Partner Operations
* 
[**Import partners and their contacts**](/features/partners/partner-management/technical)
Detect distributors and bring their people in as contacts.
**Why it matters.** This is the defining setup for distribution. Crediting both the distributor and the reseller on one CRM deal, and sharing visibility across the tiers, is what lets you pierce the demand opacity that normally hides two-tier channels. Without it you only see the distributor, never the sell-through underneath.
Add a distributor field to your deals, attribute a deal to both a distributor and a reseller, and share visibility across tiers.
**Time:** Half a day · **Who:** Partner Operations, Revenue Operations
* 
[**Attribute deals across two tiers**](/features/deal-registration/multi-tier/technical)
Credit distributor and reseller on one CRM deal.
## Build the two-tier motion
**Why it matters.** A distributor is vendor-like downstream, so it needs to manage sub-partners and their people without seeing the rest of your program. Partner team roles and per-user scoping give the distributor self-serve control over its own network while you keep governance, which is what makes managing a few distributors instead of a thousand resellers possible.
Create partner team roles, assign them, and limit each user to the partners they manage.
**Time:** Half a day · **Who:** Partner Operations, with the Partnerships Lead
* 
[**Scope access so the distributor manages its network**](/features/access/team-management/technical)
Partner team roles, each user limited to their partners.
**Why it matters.** When a reseller registers a deal, the distributor above it has to be captured and the claim screened for conflict, so credit and governance hold across both tiers. The AI agent doing first-pass screening keeps this fast even across a large network.
Capture the distributor on the registration form, detect conflict, and gate for approval.
**Time:** Half a day · **Who:** Partner Operations
* 
[**Register deals with conflict screening**](/features/ai/channel-conflict/technical)
Screen every claim across the network before it is accepted.
**Why it matters.** A distributor needs one place to see its network's pipeline, and its resellers need to work their own deals without a CRM seat: edit the fields you let them control and build quotes themselves. Letting the network self-serve on the shared pipeline is what keeps a two-tier channel moving without routing every update and quote through you. You choose which fields are editable, so governance stays intact down the chain.
Publish a distributor experience with the network pipeline, let resellers edit the fields they own, and let them quote on their deals. Experience building can add far more later.
**Time:** 2 to 4 hours · **Who:** Partner Operations
* 
[**Stand up a distributor experience**](/features/portal/experiences/technical)
The network pipeline, editable fields, and self-serve quoting.
## Go deeper once you are live
Add these once two-tier attribution and access are working. Roll-up reporting is the highest-value next step, because sell-through visibility is the whole point of distribution.
**Why it matters.** Distribution economics reward breadth and velocity across the network, not single deals. Partner analytics and dashboards built on the two-tier attribution give you the sell-through view that keeps pricing control and demand signal from disappearing into the channel.
**Time:** Half a day · **Who:** Revenue Operations, Partnerships Lead
* 
[**Roll-up and sell-through reporting**](/features/reporting/partner-analytics/technical)
Sell-through across the network, and a view for the distributor.
**Why it matters.** Distributors earn thin aggregation margin on sell-through volume, and it must reconcile to the CRM. Commission plans with tier-based rates, calculated from the source-of-truth deals, keep commission and margin accounting auditable across the whole tier.
**Time:** Half a day · **Who:** Finance, Partner Operations
* 
[**Account commission and margin across the tier**](/features/commissions/commission-plans/technical)
Tier-based commission rates, calculated from the CRM.
## You are live
One CRM deal now carries both distributor and reseller credit, the distributor manages its own network through scoped access, and you can see sell-through across the tier with margin reconciled to the CRM. You reach a whole reseller network through a handful of managed relationships, without losing the demand signal underneath.
Pick another partner-type track.
Go deeper on two-tier credit and visibility.
# Implementation track
Source: https://docs.introw.io/tracks/implementation
Stand up the implementation motion in Introw: clean sales-to-delivery handoff on the CRM deal, scoped access, go-live tracking, and delivery certification.
> An [implementation partner](/partner-types#implementation) does not close the deal - it delivers the outcome after someone else wins it. This track sets up the three things that make delivery work in Introw: a clean handoff that attaches the implementation partner to the won deal, scoped access so consultants see only the accounts they deliver on, and certification that gates who is authorised to deliver. Then it adds the onboarding, enablement, and health tracking that drive go-live.
**Time to first value:** an implementation partner working a handed-off deal on the CRM record within a few days. **Owned by:** Partner Operations and the Partner Manager, with Partner Marketing on certification and enablement.
An implementation partner is measured on go-live and adoption, not on the signature. This track configures delivery on the same CRM record the deal closed on - not a separate services system - so the vendor keeps visibility from close through go-live.
## What an implementation partner actually needs
An implementation partner is a delivery organisation: a practice lead owns the vendor relationship and certification standing, while consultants own scoping, configuration, and go-live for each customer. There is rarely a quota-carrying rep, because the deal is closed elsewhere. The partner needs a clean handoff with full deal and account context, scoped access to only the accounts they deliver on, onboarding and go-live tracking on the record, and certification to be authorised to deliver. The single most useful thing you configure is the handoff onto the CRM deal.
## Set up the foundation
**Why it matters.** Delivery has to happen on the same record the deal closed on, or the vendor loses sight of the customer between close and go-live. Connecting the CRM first means the implementation partner works the won deal and its context directly, with nothing to reconcile later.
Connect HubSpot or Salesforce as the system of record.
**Time:** 20 to 30 min · **Who:** CRM Administrator, Revenue Operations
* 
[**Connect your CRM**](/features/integrations/crm/technical)
Two-way sync, and where partner records live in the CRM.
**Why it matters.** An implementation partner brings a practice lead facing you and consultants facing the customer. Importing the partner with its contacts is what lets you scope the right people's access in the next step.
Detect implementation partners from the CRM and bring their contacts in.
**Time:** 30 to 60 min · **Who:** Partner Operations
* 
[**Import partners and their contacts**](/features/partners/partner-management/technical)
The practice lead, and the consultants who deliver.
**Why it matters.** This is the defining setup for implementation. Attaching the implementation partner to the closed deal, and letting them collaborate on the record without a CRM seat, is what turns a forwarded email into a clean handoff with full context. Without it, delivery starts blind and the vendor loses the thread between close and go-live.
Attribute the implementation partner on the deal and let them collaborate on the shared record.
**Time:** Half a day · **Who:** Partner Operations, Partner Manager
* 
[**Hand off the won deal to the implementation partner**](/features/co-selling/shared-pipelines/technical)
Attributed on the deal, working the record without a seat.
## Build the delivery motion
**Why it matters.** An implementation partner should see the accounts it delivers on and nothing else. Partner team roles and per-user scoping give consultants self-serve access to their own projects while you keep governance over the rest of the program.
Create partner team roles, assign them, and limit each user to the accounts they deliver on.
**Time:** Half a day · **Who:** Partner Operations, with the Partner Manager
* 
[**Scope access so consultants see only their accounts**](/features/access/team-management/technical)
The accounts they deliver on, and nothing else.
**Why it matters.** Delivery is a checklist with owners and dates: configuration, integration, data migration, sign-off. Tracking those steps on the CRM deal keeps the go-live moving without status meetings, and lets the partner self-serve the next step while the vendor sees progress on the record.
Build an onboarding path and show delivery tasks on the deal.
**Time:** 2 to 4 hours · **Who:** Partner Operations
* 
[**Track onboarding and go-live on the deal**](/features/partners/onboarding/technical)
The delivery checklist on the record, with owners and dates.
**Why it matters.** Only qualified consultants should deliver, or quality drifts as the team grows. Certification gates who is authorised, and the status syncs back to the CRM so you can trust who is on a project.
Build delivery courses, enroll consultants, and issue certificates that sync to the CRM.
**Time:** Half a day · **Who:** Partner Marketing, Partner Operations
* 
[**Certify consultants before they deliver**](/features/courses/certificates/technical)
Authorise who delivers, with the status synced to the CRM.
**Why it matters.** An implementation partner needs one place to see its projects, the runbooks it delivers with, and its certification status. A focused delivery experience keeps consultants self-serve without a CRM seat. Experience building can add far more later.
Publish a delivery experience with the project pipeline, a governed asset library, and certification.
**Time:** 2 to 4 hours · **Who:** Partner Operations
* 
[**Stand up a minimal delivery experience**](/features/portal/experiences/technical)
Projects, runbooks, and certification in one place.
## Go deeper once you are live
Add these once the handoff, access, and certification are working. Delivery health is the highest-value next step, because go-live quality is what protects renewal and expansion.
**Why it matters.** The whole point of an implementation partner is that the customer succeeds. Partner analytics and dashboards built on the delivery data give you the go-live and health view that ties delivery quality back to renewal.
**Time:** Half a day · **Who:** Revenue Operations, Partner Manager
* 
[**Delivery health and reporting**](/features/reporting/partner-analytics/technical)
Go-live and health across accounts, and a partner-facing view.
**Why it matters.** Implementation partners earn services revenue and often an influence credit for deals they help source during delivery. Commission plans calculated from the source-of-truth deals keep any incentive auditable and reconciled to the CRM.
**Time:** Half a day · **Who:** Finance, Partner Operations
* 
[**Account services and influence credit**](/features/commissions/commission-plans/technical)
Services revenue or influence credit, from the CRM deal.
## You are live
The implementation partner now takes a clean handoff on the won CRM deal, works only the accounts it delivers on, tracks onboarding and go-live on the record, and stays certified to deliver. You keep visibility from close through go-live, and a customer you already won actually succeeds with the product.
Pick another partner-type track.
See the implementation partner's day end to end.
# Setup tracks
Source: https://docs.introw.io/tracks/index
Guided setup tracks per partner type. Start from the partner you run, configure only the modules that type needs, and go live in weeks with your CRM as truth.
> A partner program is not one shape, so its setup is not one checklist. These tracks walk you click by click through configuring Introw for the specific partner type you run, starting from what that partner actually needs to work with you, and linking into the in-depth guide at every step.
## Pick the track for the partner you run
Partner types differ most in one question: who closes the deal. That single axis decides what the partner needs from you, which modules you set up, and the order you do it in. Start from the [partner types overview](/partner-types) if you are not sure which one you are running, then open its track below.
Every track assumes you have a workspace. You do not need a contract for one: the free plan takes a real partner live with no time limit, and its first half hour is the part every track below shares. See [Start free](/start-free).
Tracked links at scale, conversion attribution, fraud protection, and frictionless payouts. The vendor closes.
Dead-simple off-portal registration, channel-conflict protection, auto status updates, and referral fees. The vendor closes.
Collaboration on the live CRM deal, account mapping, a shared pipeline, co-branded assets, and MDF. Shared close.
Tiering, deal registration that protects margin, self-serve CPQ, certification, and margin accounting. The partner closes.
Multi-tier attribution on one CRM deal, sub-partner team access, and sell-through roll-up reporting. A partner network closes.
A clean sales-to-delivery handoff on the CRM deal, scoped delivery access, onboarding and go-live tracking, and certification. Someone else closed.
## How every track works
Each track is built the same way, so you always know what you are looking at.
Each step opens with why it matters for this partner type, tied to the outcome you are trying to create, not just the click path.
The opening steps get you live with the smallest real program. The deeper steps add modules only when this partner type needs them.
A track never sends you to configure something this partner type does not use. Setting up less is the point: lower cost, faster launch.
A best-effort time estimate and the personas to involve, so you can plan the rollout and pull in the CRM admin or finance at the right moment.
## The shape every track shares
However different the partner types are, the foundation is identical because the CRM is always the source of truth. Every track starts here before it diverges:
Introw reads and writes to HubSpot or Salesforce as the system of record. Nothing to migrate, nothing to reconcile.
Partners are detected from your CRM, and their contacts come with them, so attribution and access have something to attach to.
Decide which CRM objects this partner type links, edits, or collaborates on, and how their contribution is credited on the record.
From there each track follows the motion that fits how that partner actually works. The result is the same in every case: a program owned by your partnerships team, configured without engineering, live in weeks, and trustworthy because it runs on the CRM.
## Where to go next
Compare the full partner spectrum before you pick a track.
The upside of each partner type, modeled by ecosystem scale.
Every domain, feature, and guide from one place.
# Referral track
Source: https://docs.introw.io/tracks/referral
Launch a referral program in Introw with off-portal registration forms, channel-conflict protection, referrer status updates, and CRM-synced fees.
> A [referral partner](/partner-types#referral) makes a warm, named introduction and steps back while your team runs the sale. The relationship is high quality but fragile: one disputed or slow-paid referral ends future intros. So the whole track optimizes for two things the referrer cares about most, unambiguous credit and visible, trustworthy payout, while keeping submission effortless and off-portal.
**Time to first value:** referrals flowing in and updating automatically within about a day. **Owned by:** Partner Operations and the Partner Manager, with Finance for rewards. The AE runs the actual deal.
## What a referral partner actually needs
A referrer is usually one person or a small advisory firm. They want a way to refer in seconds from wherever they are, proof that the registration protects their credit, visibility into the deal they sourced, and confidence they will get paid. They do not quote, close, or collaborate on the deal, so you skip CPQ, reseller editing, and heavy enablement. Focus every step on capture, credit, and trust.
## Set up the foundation
**Why it matters.** A referred deal is a real opportunity on your CRM. Connecting first means the sourced deal, its status, and the credit all live on the record your AEs already work, with no separate system to reconcile.
Connect HubSpot or Salesforce so referred deals attach to the system of record.
**Time:** 20 to 30 min · **Who:** CRM Administrator, Partner Operations
* 
[**Connect your CRM**](/features/integrations/crm/technical)
Connect Salesforce or HubSpot and set where referrers are stored.
**Why it matters.** Credit and payouts attach to a partner and a person. Importing referrers and their contacts up front means every referral can be linked to the right payee automatically, instead of being matched by hand later.
Detect referrers from the CRM and bring their contacts along.
**Time:** 30 to 60 min · **Who:** Partner Operations
* 
[**Import partners and their contacts**](/features/partners/partner-management/technical)
Detect referrers from the CRM and bring in the payee contact.
**Why it matters.** Unambiguous attribution is the referral program's foundation of trust. Mapping how a sourced deal is credited on the CRM record means the referrer's contribution is recorded the moment a deal is registered, not argued about at payout time.
Choose the revenue-attribution method and map partner attribution onto deals.
**Time:** 30 to 60 min · **Who:** Partner Operations, Revenue Operations
* 
[**Attribute referred deals to the referrer**](/features/integrations/crm/attribution)
Record who sourced the deal, and how the revenue is credited.
## Build the referral motion
**Why it matters.** The intake form is where data quality and attribution are won or lost. A short form with the right fields, mapped to CRM properties and auto-linked to the referring partner, means every referral lands clean and credited with no ops cleanup. That is the difference between a program that scales and a spreadsheet.
Create the form, add only the fields you need, map each to a CRM property, and auto-attribute the submission to the partner.
**Time:** 30 to 45 min · **Who:** Partner Operations
* 
[**Build the referral intake form**](/features/forms/form-builder/technical)
The few fields a referral needs, each mapped to the CRM.
**Why it matters.** A referrer's confidence rests entirely on not losing the credit to the direct team or another partner. Conflict detection plus an approval gate, with the AI agent doing the first-pass screening, gives fast, consistent acknowledgement, which is exactly what keeps referrers referring.
Detect duplicates and conflicts on submit, route to an approval gate, and let the AI agent auto-screen the clear cases.
**Time:** 30 to 45 min · **Who:** Partner Operations, with the Partner Manager and Sales on the rules
* 
[**Protect credit with conflict detection**](/features/ai/channel-conflict/technical)
Flag overlap with direct or partner deals before approval.
**Why it matters.** A referrer should never have to log in to help you. Sharing a referral link, an email path, or an AI submission lets them refer from wherever they already are, which removes the single biggest source of referral drop-off.
Give referrers a share link, an embeddable form, and an email or AI submission path.
**Time:** 20 to 30 min · **Who:** Partner Operations, Partner Marketing
* 
[**Let partners refer off-portal**](/features/referrals/lead-sharing/technical)
A link, an embed, email, Slack, Teams, an AI assistant, the API.
**Why it matters.** Silence after a referral kills trust. Automatic status updates back to the referrer, with no work from your AE, prove the program is alive and are the cheapest way to earn the next introduction.
Turn on deal-progress updates so referrers hear about movement and closed-won automatically, in the portal or over Slack, Teams, or email.
**Time:** 20 to 30 min · **Who:** Partner Operations
* 
[**Auto-update the referrer as the deal moves**](/features/referrals/deal-updates/technical)
Stage changes and closed-won, in the portal, mail, or chat.
**Why it matters.** Referrers need one place to confirm a deal is progressing and see what they will earn. A lightweight portal showing their referred deals and pending rewards is enough; you can enrich it later. Build the minimum that earns trust.
Publish a simple experience that shows the referrer their sourced deals and earnings. Experience building goes much deeper, link that for later.
**Time:** 1 to 2 hours · **Who:** Partner Operations, Partner Marketing
* 
[**Stand up a minimal referral experience**](/features/portal/experiences/technical)
The referrer's own sourced deals and pending earnings.
**Why it matters.** Getting paid correctly and on time is the entire promise of the referral motion. Fees calculated from the CRM-attributed deal and paid in clean batches mean no disputes, no spreadsheets, and a referrer who comes back.
Set up the referral fee or revenue share and pay out from the attributed, closed-won deals.
**Time:** 1 to 2 hours · **Who:** Finance, Partner Operations
* 
[**Pay referral fees reconciled to the CRM**](/features/referrals/rewards/technical)
A flat fee or a revenue share on the closed-won deal.
## Go deeper once you are live
Optional once the core loop of capture, protect, update, and pay is running.
* 
[**Embed a referral form**](/features/referrals/lead-sharing/technical)
Put the referral form on your partner's own site.
* 
[**Announce a closed-won deal**](/features/referrals/deal-updates/technical)
Celebrate wins to drive the next referral.
* 
[**Create a revenue-share plan**](/features/referrals/rewards/technical)
Move from flat fees to ongoing revenue share.
* [**The full Referrals domain**](/features/referrals)
Lead sharing, deal updates, and rewards in depth.
## You are live
Referrers can submit in seconds from anywhere, their credit is locked in by conflict detection and approvals, they are kept warm by automatic updates, and they are paid from the CRM source of truth. That is a referral program partners trust enough to keep feeding.
Pick another partner-type track.
Go deeper on intake, mapping, and approvals.
# Reseller track
Source: https://docs.introw.io/tracks/reseller
Run a reseller program in Introw with partner tiering, deal registration, self-serve CPQ, certification, content library, and CRM margin accounting.
> A [reseller](/partner-types#reseller) owns the full sale, the margin, and usually delivery, acting as a second sales force you may never meet the end customer through. Your job shifts from selling to enabling: authorize them, protect their deal-reg investment, let them quote themselves, certify them to deliver, and account their margin accurately. This track sets up that enablement engine, in the order a reseller needs it.
**Time to first value:** an authorized reseller registering and quoting deals within a few days. **Owned by:** Partner Operations and Partner Marketing, with Finance for margin and the Partner Manager on tiering.
## What a reseller actually needs
A reseller is a full sales organization: an alliance manager who owns tier status, AEs who close independently, and SEs who must stay certified to deliver. They want self-serve quoting with the right pricing for their tier, certification and content to sell and deliver well, deal registration that locks in their margin against your direct team and other partners, and clear visibility into what they earn. Affiliate links and referral-style fees do not apply; this is a margin business that runs on enablement.
## Set up the foundation
**Why it matters.** Reseller-owned deals, the margin on them, and the registration that protects them all live on the CRM record. Connecting first keeps the channel motion reconciled to the same source of truth as direct, so margin accounting is never in doubt.
Connect HubSpot or Salesforce as the system of record.
**Time:** 20 to 30 min · **Who:** CRM Administrator, Partner Operations
* 
[**Connect your CRM**](/features/integrations/crm/technical)
Two-way sync, and where reseller records live in the CRM.
**Why it matters.** A reseller brings AEs and SEs who register, quote, and get certified. Importing the partner with their full team means you can assign tiers, enrollments, and deal access to the right people from the start.
Detect resellers from the CRM and bring their teams in as contacts.
**Time:** 30 to 60 min · **Who:** Partner Operations
* 
[**Import partners and their contacts**](/features/partners/partner-management/technical)
The reseller's AEs and SEs, on one partner account.
**Why it matters.** A reseller owns the deal, so they should be able to work it without a CRM seat: edit the fields you let them control, manage their own line items, and build quotes on the deal themselves. Setting up attribution plus those self-serve edit and quote rights writes their work straight to the CRM record, keeps margin and ownership unambiguous, and takes you out of the loop on every update. You choose exactly which fields are editable, so control stays with you.
Map partner attribution, choose which deal fields and line items resellers can edit, and let them build quotes on their own deals. CPQ pricing and templates are configured in depth later in this track.
**Time:** 30 to 60 min · **Who:** Partner Operations, Revenue Operations
* 
[**Let resellers work the deals they own**](/features/deal-registration/shared-pipeline/technical)
Attribution, the fields they may edit, and their line items.
## Authorize and protect the reseller
**Why it matters.** Resellers are not equal, and pricing, content, and access should reflect that. Tiers and segments are the control surface that grades a reseller and unlocks the right discounts, enablement, and deal-reg rules. Get this right and almost everything downstream scopes itself automatically.
Create a tier program with requirements and benefits, segment resellers, and sync tiers to the CRM.
**Time:** Half a day · **Who:** Partner Manager, Partner Operations
* 
[**Set up tiers and segments**](/features/partners/tiers/technical)
Requirements and benefits per tier, synced to the CRM.
**Why it matters.** Deal registration is what gives a reseller the confidence to invest in an opportunity: it locks in their margin against your direct team and other partners. Conflict detection plus an approval gate, with the AI agent screening the clear cases, makes that protection fast and consistent.
Let resellers register deals, detect conflict, gate for approval, and protect the registered margin.
**Time:** Half a day · **Who:** Partner Operations, with the Partner Manager and Sales on the rules
* 
[**Set up deal registration that protects margin**](/features/deal-registration/registration/technical)
Screen the claim, gate it, and lock in the discount.
## Enable the reseller to sell and deliver
**Why it matters.** A reseller who can quote themselves, with pricing governed by their tier, sells without waiting on you. Self-serve CPQ removes you as the bottleneck on every deal while keeping pricing and discounts under your control.
Enable quote creation on deals, set templates, govern tier and segment discounts.
**Time:** Half a day · **Who:** Partner Operations, Finance
* 
[**Turn on self-serve CPQ**](/features/cpq/quotes/technical)
Resellers quote themselves, on pricing you govern.
**Why it matters.** Resellers sell and deliver on your behalf, so certification gates who is authorized and a governed content library keeps everyone on the current message. Auto-enrolling a segment and auto-issuing certificates on completion makes this run without manual chasing.
Build courses, auto-enroll segments, auto-issue certificates, and publish a governed asset library.
**Time:** 1 to 2 days · **Who:** Partner Marketing
* 
[**Certify resellers and govern enablement content**](/features/courses/authoring/technical)
Courses, auto-enrolment, certificates, a governed library.
**Why it matters.** Resellers need one place that brings together deal registration, quoting, enablement, and what is new. Start with a minimum viable reseller portal carrying those essentials; experience building can layer on much more once you are live.
Publish a reseller experience with registration, quoting, and enablement, scoped by segment.
**Time:** 2 to 4 hours · **Who:** Partner Operations, Partner Marketing
* 
[**Stand up the reseller experience**](/features/portal/experiences/technical)
Registration, quoting, and enablement, scoped by segment.
## Go deeper once you are live
Add these once resellers are registering and quoting. Margin accounting is the highest-value next step.
**Why it matters.** What a reseller earns has to be correct and reconciled to the CRM, or disputes erode the channel. Commission plans calculated from the source-of-truth deal keep margin accounting clean and auditable for Finance.
**Time:** Half a day · **Who:** Finance, Partner Operations
* 
[**Account reseller margin and commissions**](/features/commissions/commission-plans/technical)
Margin and incentives, calculated from the CRM deal.
**Why it matters.** New resellers activate faster when the program reveals itself as they qualify. A progressive onboarding path tied to segments unlocks tabs, assets, and abilities step by step, so a reseller grows into the program instead of facing everything at once.
**Time:** Half a day · **Who:** Partner Operations, Partner Marketing
* 
[**Add a progressive onboarding journey**](/features/partners/onboarding/technical)
Unlock tabs and abilities as a reseller qualifies.
## You are live
Resellers are tiered and authorized, their margin is protected by clean deal registration, they quote themselves with governed pricing, they are certified to sell and deliver, and what they earn is accounted to the CRM. You enable the channel instead of selling every deal in it.
Pick another partner-type track.
Go deeper on registration, editing, and multi-tier.
# Every automation that runs out of the box
Source: https://docs.introw.io/features/automation/built-in-automation/guides/every-automation-that-runs-out-of-the-box
A full inventory of what Introw automates without a workflow: partner detection, property and tier sync, segments, portal access, records, learning, incentives, messaging, and AI.
Most of the automation a partner program needs is already in Introw, and most of it starts working the moment your CRM is connected. This inventory lists it area by area: what each automation does, whether it is on by default or something you switch on, and where it is configured. Read it before you build anything on the [Workflows](/features/automation/workflows) canvas, because the list of rules you actually have to build yourself is shorter than it looks.
## What you'll achieve
A complete, checkable picture of Introw's out-of-the-box automation, so you can switch on the pieces your program needs, stop enforcing them by hand, and reduce your workflow backlog to the rules that are genuinely specific to how you run partnerships.
## Before you start
Most of this list is a consequence of the CRM connection. See [CRM integrations](/features/integrations/crm).
**Always on** needs no switch, only configuration. **Switch on** is off until you enable it, because it changes what partners receive or what happens to your data. **Build it** means there is no built-in automation and a workflow is the answer.
## Partners and their people
Everything here follows from partner detection, and it is the layer worth getting right first: it decides who your partners are and what data the rest of the program automates against.
| Automation | What it does | State | Where |
| - | - | - | - |
| Partner detection | A CRM object plus filters decide which records are partners; only matching records become partners in Introw | Always on | [Detect partners from your CRM](/features/partners/partner-management/guides/detect-partners-from-your-crm) |
| Automatic partner sync | New CRM records matching your filters become partners on their own, with no import to re-run | Switch on | CRM settings |
| Contact import | The contacts on a detected partner's company arrive under the partner's **People**, ready for portal access | Always on | [Provisioning](/features/access/provisioning) |
| Owner suggestion | The partner's CRM account owner is suggested as a team member to accept and set as their manager | Always on | [Wire partner ownership](/features/partners/team/guides/wire-partner-ownership) |
| Attributed records | Deals, tickets, and custom objects linked to a partner appear on their record and in their portal | Always on | [Configure deal attribution](/features/co-selling/shared-pipelines/guides/configure-deal-attribution) |
| Two-way property sync | Mapped partner properties travel between Introw and the CRM in the direction you set | Always on | [CRM integrations](/features/integrations/crm) |
| Tier sync | A tier assigned in Introw is written to a CRM property, and a tier already set in the CRM flows in | Switch on | [Build a tier program](/features/partners/tiers/guides/build-a-tier-program) |
| Partner-edited fields | Fields you make editable are written straight back to the CRM when a partner changes them | Switch on | [Set up a shared pipeline](/features/co-selling/shared-pipelines/guides/set-up-a-shared-pipeline) |
## Audiences
| Automation | What it does | State | Where |
| - | - | - | - |
| Dynamic segments | Conditions over live partner, contact, and CRM data are re-evaluated on a schedule, so membership follows the data | Always on | [Create a dynamic segment](/features/partners/segments/guides/create-a-dynamic-segment) |
| Segment-driven notifications | Recipients for every notification event are decided by the organisation default and per-segment overrides | Always on | [Control who gets notified](/features/engagement/notifications/guides/control-who-gets-notified) |
| Segment-driven access | Portal tabs, content, and assets appear only for the segments you scope them to | Switch on | [Restrict a tab to segments](/features/portal/portal-access/guides/restrict-a-tab-to-segments) |
| Segment-driven pricing | Tier and segment discounts apply themselves to the right partners' quotes | Switch on | [Set tier-based discounts](/features/cpq/discounts/guides/set-tier-based-discounts) |
Segments are the single highest-leverage automation in Introw, because so much keys off them. A dynamic segment is also the way to trigger on things no event names directly: "quiet for 30 days", "crossed a revenue threshold", "certified but not transacting". Define the segment, then point a workflow's **Segment membership** trigger at it.
## Portal access
| Automation | What it does | State | Where |
| - | - | - | - |
| Access from a CRM property | A CRM contact property decides which contacts get portal access, so access follows the CRM | Switch on | [Map contact portal access](/features/integrations/crm/guides/map-contact-portal-access) |
| Domain-based access | Anyone on the partner's verified domain can reach the portal without an individual invite | Switch on | [Set up portal access](/features/portal/portal-access/guides/set-up-portal-access) |
| Portal SSO provisioning | A partner signing in through SSO is provisioned into the right portal on first login | Switch on | [Set up portal SSO](/features/access/sso/guides/set-up-portal-sso) |
| Team SCIM provisioning | Your own team members are created, updated, and deactivated from your identity provider | Switch on | [Provision your team with SCIM](/features/access/provisioning/guides/provision-your-team-with-scim) |
## Records and submissions
| Automation | What it does | State | Where |
| - | - | - | - |
| Form to CRM | A submission creates or updates the CRM objects behind it, from the field mapping you set | Switch on | [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm) |
| Record matching | Submissions are matched against existing CRM records and update them instead of creating duplicates | Switch on | [CRM automations](/features/forms/crm-automations) |
| Partner attribution | Everything a submission creates is attributed to the partner who sent it | Always on | [CRM automations](/features/forms/crm-automations) |
| Fill if empty | Enrichment fields only write where the CRM has no value, so partner input never overwrites your data | Switch on | [CRM automations](/features/forms/crm-automations) |
| Approval routing | A submission is routed to reviewers, and accepted, declined, or returned before anything lands | Switch on | [Run a submission approval workflow](/features/forms/submissions-approvals/guides/run-a-submission-approval-workflow) |
| Conflict detection | A registration overlapping a deal already in your CRM is flagged with an assessment and a recommendation | Switch on | [Catch and resolve channel conflict](/features/ai/channel-conflict/guides/catch-and-resolve-channel-conflict) |
| Watched-property updates | You choose which properties count as a change, so partners are told when something meaningful moves, not on every sync | Switch on | Pipeline section, **Notifications** |
## Journeys and tasks
| Automation | What it does | State | Where |
| - | - | - | - |
| Journey on experience | A journey attached to an experience is applied as partners get that experience, so onboarding starts on its own | Switch on | [Auto-apply a journey from the experience](/features/partners/journeys/guides/auto-apply-a-journey-from-the-experience) |
| Task due dates | A journey's tasks get their due dates from days-after-assigned, so every partner's dates are right for when they started | Always on | [Build a journey from scratch](/features/partners/journeys/guides/build-a-journey-from-scratch) |
| Task reminders | Partners are reminded about assigned tasks that are coming due | Switch on | [Notifications](/features/engagement/notifications) |
| Progressive unlocking | Completing onboarding moves a partner into the segment that unlocks the next set of content and tabs | Switch on | [Build a progressive onboarding path](/features/partners/onboarding/guides/build-a-progressive-onboarding-path) |
## Learning
| Automation | What it does | State | Where |
| - | - | - | - |
| Auto-enrollment | Every partner in the segments you attach is enrolled in the course, including partners who join the segment later | Switch on | [Configure enrollment rules](/features/courses/enrollments/guides/configure-enrollment-rules) |
| Auto-issued certificates | A certificate attached to a course is awarded on completion, gated on the passing score where the course sets one | Switch on | [Create a certificate](/features/courses/certificates/guides/create-a-certificate) |
| Progress sync | Course progress and certificates are written back to the CRM | Always on | [Progress tracking](/features/courses/progress-tracking) |
| Incomplete-learner nudges | Learners who started but did not finish are reminded | Switch on | [Nudge incomplete learners](/features/courses/enrollments/guides/nudge-incomplete-learners) |
| Certificate expiry | A certificate with a validity period expires on its own, so recertification is visible rather than assumed | Always on | [Certificates](/features/courses/certificates) |
## Incentives and money
| Automation | What it does | State | Where |
| - | - | - | - |
| Earned commission lines | Plans generate lines from CRM and billing data as deals close and invoices are paid, against your eligibility rules and rates | Switch on | [Build and launch a commission plan](/features/commissions/commission-plans/guides/build-and-launch-a-commission-plan) |
| Recalculation on change | A change to the CRM or billing record behind a line re-evaluates that line rather than leaving a stale amount | Always on | [Review and adjust commission lines](/features/commissions/commission-lines/guides/review-and-adjust-commission-lines) |
| Automatic payout runs | Payout batches advance on the schedule you set instead of someone starting each one | Switch on | [Configure commission payout settings](/features/commissions/settings/guides/configure-commission-payout-settings) |
| Payout status sync | Introw Pay moves each payout's status on its own as your invoice is paid and each partner payment lands | Always on | [Introw Pay](/features/commissions/introw-pay/technical) |
| Affiliate attribution | Link clicks and conversions are attributed to the right partner and campaign, with fraud checks | Switch on | [Set up affiliate conversion tracking](/features/affiliate/conversion-tracking/guides/set-up-affiliate-conversion-tracking) |
| MDF lifecycle | Requests, approvals, claims, and remaining budget move through the fund without a spreadsheet | Switch on | [Funds and allocation](/features/mdf/funds-allocation) |
## Messaging
| Automation | What it does | State | Where |
| - | - | - | - |
| Lifecycle notifications | Deal, task, submission, learning, and commission events reach the audiences you scoped | Switch on | [Every notification Introw sends](/features/engagement/notifications/guides/every-notification-introw-sends) |
| Sleeping-deal nudges | A deal sitting in a stage past your inactivity window prompts the responsible partner | Switch on | [Nudge stalled deals](/features/engagement/notifications/guides/nudge-stalled-deals) |
| Off-portal delivery | Notifications reach partners by email and in each partner's mapped Slack or Teams channel | Switch on | [Channels](/features/engagement/channels) |
| Reply-by-email | A partner replying to a notification has their reply tracked back onto the record for every collaborator | Switch on | [Configure partner notifications by email](/features/engagement/channels/guides/configure-partner-notifications-by-email) |
| Referrer updates | The partner who referred a deal is kept up to date as it moves, with no manual status email | Switch on | [Keep referrers updated](/features/referrals/deal-updates/guides/keep-referrers-updated) |
## AI
| Automation | What it does | State | Where |
| - | - | - | - |
| Partner support agent | Partner questions are answered from your own content, wherever the partner asks | Switch on | [Launch the partner support agent](/features/ai/partner-support/guides/launch-the-partner-support-agent) |
| Deal coaching | A deal notification carries a specific next step, not just the fact that something changed | Switch on | [Set up an AI deal coach](/features/ai/deal-coaching/guides/set-up-an-ai-deal-coach) |
| Announcement suggestions | Your partner-relevant LinkedIn posts arrive weekly as announcement drafts, rewritten for partners | Switch on | [Publish AI-suggested announcements](/features/engagement/announcements/guides/publish-ai-suggested-announcements) |
| Knowledge crawling | Your public content is crawled and kept in the agent's knowledge base so answers stay current | Switch on | [Fill the knowledge base](/features/ai/knowledge-base/guides/fill-the-knowledge-base) |
## What is left to build
After all of the above, the rules that still need a [workflow](/features/automation/workflows) are the ones tied to your own program design rather than to the mechanics of running a partner program:
* **Promotion on achievement.** Tier a partner up, add them to a segment, and log it in the CRM when they certify or finish onboarding. See [Reward a finished journey](/features/automation/workflows/guides/reward-a-finished-journey).
* **Deadline chases with escalation.** Remind the partner before a task is due, again after it slips, and hand it to the partner manager. See [Chase a task to its due date](/features/automation/workflows/guides/chase-a-task-to-its-due-date).
* **Fixed rewards.** A flat bonus for an action, rather than a percentage of a deal. See [Reward a finished journey](/features/automation/workflows/guides/reward-a-finished-journey).
* **Reacting to your own CRM fields.** A partner's segment, region, or program field changing in the CRM moving them onto a different experience. See [React to a CRM change on a partner](/features/automation/workflows/guides/react-to-a-crm-change-on-a-partner).
* **Multi-step re-engagement.** A sequence that nudges, waits, checks whether it worked, and only then involves a human. See [Re-engage quiet partners](/features/automation/workflows/guides/re-engage-quiet-partners).
## Verify it worked
Walk the list against your own program and you should be able to point at each row and say "on, off on purpose, or not for us". The test that the built-in layer is doing its job: new partners appear without anyone importing them, your partner list and the CRM agree, segment membership is current, submissions arrive as CRM records rather than as messages someone retypes, and the reminders your partners get are ones nobody sent.
## Related
Build the rules the built-in layer does not cover.
The full catalog of automatic messages, with triggers and recipients.
Set up the detection and sync layer everything else follows from.
Build the audiences the rest of the program keys off.
# Built-in Automation
Source: https://docs.introw.io/features/automation/built-in-automation/index
The automations Introw runs out of the box: partners and contacts detected from CRM filters, two-way property sync, self-evaluating segments, form-driven CRM writes, notifications, and earned commissions.
> Most of a partner program is already automated in Introw before you configure a single rule. Connecting your CRM is what switches it on.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Automation is an implementation project | It runs the week you connect |
| The partner list is stale on day two | CRM filters keep finding partners |
| Data drifts between PRM and CRM | Tiers and fields sync both ways |
| Submissions become ops tickets | The form writes the CRM record |
| Every reminder needs a human | The signals go out on their own |
## Impact
The programs partners rate highest are the ones where nothing goes missing. Most of that is not effort. It is what already runs by default the day your CRM is connected.
for your business
* **Live in days**
The automation layer is on before anyone configures a rule, so a program goes live in weeks rather than after an implementation
* **Cost to run**
No consultants and no dev tickets to make the basics work, and everything left over is configuration
* **In your CRM**
Every built-in automation reads and writes HubSpot or Salesforce, so there is no second copy of the truth to reconcile
for your partners
* **Self-serve**
They appear with portal access, the right experience, and their own contacts already attached
* **Enabled**
Deal updates, task reminders, learning nudges, and payout notices reach them without anyone sending them
* **Efficient**
A form they submit becomes the CRM record, deduplicated and attributed, so nothing is retyped on either side
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - the mechanics running by configuring
* **Partner Managers** - a list that stays current by itself
* **VP Partnerships** - a program live without an implementation
## See it work
* 
**Data stays true**
Tier, phase, champion, currency and language, each backed by a CRM property.
* 
**Audiences maintain themselves**
Conditions decide who qualifies, and membership re-evaluates itself.
* 
**The program talks**
Signals like the sleeping-deal nudge go out without anyone sending them.
## How it works
The usual assumption about a partner platform is that automation is a project: someone scopes the rules, someone builds them, and the program starts working a quarter later. Introw inverts that. The automations that every program needs are already in the product, and they start the moment your CRM is connected.
Partners detect themselves. You point Introw at a CRM object and a set of filters. Every record that matches becomes a partner. The contacts on that account are imported as their people, and the CRM account owner is suggested as their manager. Turn on automatic sync and any new matching record becomes a partner on its own, without anyone re-running an import.
Data stays true in both directions. Tiers map to a CRM property, so an assignment in Introw reaches the CRM and a tier already set in the CRM flows in. Partner properties, deal attribution, and the fields partners edit in the portal write straight back to HubSpot or Salesforce.
Audiences maintain themselves. A dynamic segment is a set of conditions over live partner, contact and CRM data, re-evaluated on a schedule. It drives notification recipients, portal tab visibility, content visibility, discounts and course enrollment. You define who qualifies once; membership follows the data.
Records and money follow the work. A submitted form creates or updates the CRM objects behind it, matched against existing records so you do not collect duplicates, attributed to the partner who sent it, and routed through approval. Commission plans earn lines from CRM or billing data as deals close and invoices are paid, and payout runs can advance on a schedule. Certificates issue on course completion. Journeys apply themselves when an experience is published.
And the program talks on its own: deal updates, sleeping-deal nudges, task reminders, submission outcomes, learning reminders, and payout notifications go out by email, Slack, and Teams to the audiences you scoped.
Instead of buying a platform and then paying to make it do things, the program starts automated. Partners, their people, and their data arrive and stay current from the CRM; audiences, records, reminders, and money keep moving on their own. What is left over is the handful of rules specific to how you run partnerships, and those are a canvas away in [Workflows](/features/automation/workflows) rather than a project.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
connect["Connect HubSpot or Salesforce"] --> detect["Partners and contacts detected"]
detect --> sync["Properties and tiers sync both ways"]
sync --> segments["Segments re-evaluate themselves"]
segments --> signals["Records, reminders, and payouts move on"]
```
## Going deeper
Setup, configuration, and all how-to guides.
Endpoints and code.
**Works with**
Build a workflow for the program-specific rules the built-in layer does not cover.
New partners, their contacts, and their account owner arrive from your CRM filters on their own.
A submitted form creates and updates the CRM records behind it, attributed to the right partner.
The automatic deal, task, form, learning, and commission signals are the largest group of built-in automations.
# Built-in Automation
Source: https://docs.introw.io/features/automation/built-in-automation/technical/index
Which Introw automations are on by default, which you switch on, and where each one is configured, from CRM partner detection to segments, forms, notifications, and payout runs.
## Where it lives
Built-in automation is configured in two places under **Settings**: [CRM settings](https://app.introw.io/settings/integrations) switches on the detection and sync layer, and [Segments](https://app.introw.io/settings/segments/default) holds the audiences everything else keys off.
## Before you start
| You need | Why | Fix it |
| - | - | - |
| A connected CRM | Almost every automation reads it | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
| Integration settings access | Detection and sync switch on there | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A published experience | The portal-side automations need one | [Publish an experience](/features/portal/experiences/guides/build-and-publish-a-portal-experience) |
## How it works
Introw's automation comes in three layers, and knowing which layer you are in tells you where to go and how much work it is.
1. **Always on.** Things Introw does as a consequence of being connected: partner detection, contact and owner import, property sync, dedupe on submissions, attribution, segment re-evaluation, progress tracking. There is no switch, only configuration that shapes them.
2. **On by choice.** Things that are off until you enable them because they change what partners receive or what happens to your data: automatic partner sync, tier sync, auto-enrollment on a course, auto-issue of a certificate, sleeping-deal nudges, automatic payout runs, AI announcement suggestions.
3. **Built by you.** The rules specific to your program, on the [Workflows](/features/automation/workflows) canvas.
The order to set them up in follows the same logic. The CRM connection decides who your partners are and what data they carry. Segments turn that data into audiences. Almost everything else, from notification recipients to portal tab visibility to course enrollment to discounts, keys off those segments. Getting the first two right is what makes the rest configuration rather than maintenance.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
crm["HubSpot or Salesforce"] --> detect["Partner and contact detection"]
detect --> data["Synced properties, tiers, attribution"]
data --> segments["Dynamic segments"]
segments --> program["Notifications, access, content, courses, incentives"]
program --> crmBack["Written back to the CRM"]
```
## Settings & configuration
The full inventory, automation by automation, is in [Every automation that runs out of the box](/features/automation/built-in-automation/guides/every-automation-that-runs-out-of-the-box). What follows is the map: the surfaces that own the automation layer, in the order you should visit them.
### The CRM connection
**CRM settings** is where the largest group of automations lives. **Partner detection** picks the CRM object your partners are, and the filters that narrow it to the records that really are partners: only matching records become partners. Detection also brings the people, not just the account, so each partner's contacts are imported under their **People** and the CRM account owner is suggested as a team member you accept with one click.
**Automatic sync** is the switch that turns detection from an import into an automation: with it on, any new CRM record matching your filters becomes a partner on its own. Leave it off while you are still tuning filters, then turn it on once detection covers the right set. See [Detect partners from your CRM](/features/partners/partner-management/guides/detect-partners-from-your-crm).
**Field mapping** decides which properties travel and in which direction, which is what keeps partner data true on both sides without anyone reconciling it.
### Segments
Segments are the audience layer the rest of the program keys off, so they are the second thing to get right. A **dynamic** segment is a set of conditions over live partner, contact, and CRM data, re-evaluated on a schedule, so membership follows the data rather than a list someone maintains. A **static** segment is a list you curate, and it is the only kind a workflow can add a partner to.
Segment membership drives notification recipients, portal tab visibility, content and asset visibility, course auto-enrollment, tier and partner-based discounts, and announcement targeting. See [Segments](/features/partners/segments).
### Notifications and nudges
**Notification settings** is the catalog of what your program sends on its own: deal and record updates, submission outcomes, task assignments and reminders, learning and certificate signals, commissions and payouts. Recipients are set once organisation-wide on **Default settings** and overridden per segment; chat delivery is configured per platform on the chat integration. See [Notifications](/features/engagement/notifications).
Two nudges are configured on the pipeline section of an experience rather than in the catalog, and both are off until you set them: **Sleeping deal**, which emails the partner when a deal sits too long in a stage, and **Deal updated**, where you choose the properties that count as an update so partners are only told when something meaningful changes. The same setting exists per record type you sync, named after that record.
### Forms
A form's **Automation** is what makes a submission an operation rather than a message. It maps answers to CRM properties, creates or updates the CRM objects behind the submission, matches against existing records so you do not collect duplicates, attributes everything to the submitting partner, and can fill only the fields that are still empty. Approvals route the submission before any of it lands. See [CRM automations](/features/forms/crm-automations) and [Submissions and approvals](/features/forms/submissions-approvals).
### Learning
A course's **Enrollment** can auto-enroll every partner in the segments you attach, including partners who join the segment later. A course's **Certificate** can auto-issue on completion, gated on the passing score if the course has a quiz. Progress and certificates sync back to the CRM. See [Enrollments](/features/courses/enrollments) and [Certificates](/features/courses/certificates).
### Incentives
**Commission plans** earn lines on their own from CRM or billing data as deals close and invoices are paid, against the eligibility conditions and rates you set. **Payout settings** can advance payout runs on a schedule instead of someone starting each one. See [Commission plans](/features/commissions/commission-plans) and [Payout settings](/features/commissions/settings).
### Journeys and experiences
A journey attached to an experience is applied to partners as they get that experience, so onboarding starts without anyone pressing **Apply**. See [Auto-apply a journey from the experience](/features/partners/journeys/guides/auto-apply-a-journey-from-the-experience).
### AI
The AI layer runs on its own once configured: the partner support agent answers partner questions from your content, deal coaching attaches a next step to deal notifications, channel conflict detection flags overlaps on registrations, and weekly announcement suggestions arrive as drafts for review. See [AI Agents](/features/ai).
## How-to guides
* [**Every automation that runs out of the box**](/features/automation/built-in-automation/guides/every-automation-that-runs-out-of-the-box)
A full inventory of what Introw automates without a workflow: partner detection, property and tier sync, segments, portal access, records, learning, incentives, messaging, and AI.
## Troubleshooting
Automatic partner sync only creates partners that match your filters, so a partner missing from Introw is almost always a filter question rather than a sync failure. Tier sync needs every tier mapped before it runs. Dynamic segment membership follows a schedule rather than changing the instant a CRM field does, so an automation keyed off a segment starts shortly after the data moves, not at the same moment. Auto-enrollment on a course applies while it is on and does not retroactively enroll partners for the period it was off. Certificates auto-issue only when one is attached to the course, and only to learners who meet the passing score if the course sets one.
Check the detection filters first, then whether automatic sync is on. Only matching records become partners.
Contacts arrive with detection from the accounts associated with the partner's company. See [Provisioning](/features/access/provisioning).
The tier mapping is incomplete. Every tier has to be mapped before sync will run.
Read the notification cascade on their contact: the organisation default, the segments that override it, and their own opt-outs. See [Control who gets notified](/features/engagement/notifications/guides/control-who-gets-notified).
Confirm the partner is actually in the segment; dynamic membership is recalculated on a schedule.
Check the form's automation mapping and whether record matching found an existing record to update instead. See [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm).
Check this list first. Tiering on certification, chasing a task, and rewarding onboarding are workflows; auto-enrollment, certificate issuance, and deal nudges already exist.
# Automation
Source: https://docs.introw.io/features/automation/index
Everything Introw runs on its own once the CRM is connected, plus the no-code Workflows canvas for the program-specific automations only you would think of.
> Automation is the part of your partner program that runs without anybody touching it. Most of it is already on the day you connect your CRM. Workflows is where you build the rest, on a canvas, with no code.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Someone has to remember it all | The program enforces its own rules |
| Admin is the first thing to slip | Routine work runs without anyone |
| Automation means a paid project | A canvas, a rehearsal, a switch |
| Each new partner adds admin | More partners, the same work |
## Impact
Partners judge a program on whether things happen when they should. Rewards booked the day they are earned and nudges that arrive before a deadline are what a well-run program feels like from outside.
for your business
* **Live in days**
The built-in automations are running the week you connect your CRM, so a new program never waits on an automation project
* **Cost to run**
Partner operations builds and changes the whole automation layer on a canvas, with no consultants and nothing to deploy
* **In your CRM**
Every automation reads live CRM data and writes back to it, so the program automates against what your sales team already trusts
for your partners
* **Self-serve**
The journey, the experience, and the tier they should be on are applied to them, with nothing to request
* **Enabled**
The nudge, the certificate, and the next step arrive on time, on the channel they already use
* **Efficient**
Nobody waits on a partner manager to remember: rewards are booked and tasks appear as they are earned
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - the automation layer without a project
* **Partner Managers** - the chasing done without doing it
* **VP Partnerships** - more partners per manager
## How this area works
Partner programs die of admin. Someone chases the onboarding checklist, someone remembers to move a partner up a tier, someone copies a deal update into an email, someone books the referral fee. None of that work is strategic, and all of it is the first thing to slip in a busy quarter.
The built-in layer keeps partner data, records, and signals current; a workflow watches that same data and acts on it.
**Where this sits in a setup.** Automate after the manual version works. Every [setup track](/tracks) gets the program live first, then replaces the repeated parts with a workflow.
* 
[**Workflows**](./workflows)
Define a program rule once and it runs for every partner.
[How to · 7 guides](./workflows/technical)
* 
[**Built-in Automation**](./built-in-automation)
Everything already running the week you connect the CRM.
[How to · 1 guide](./built-in-automation/technical)
Introw removes most of it before you configure anything. Connect HubSpot or Salesforce and partners appear from your CRM filters with their contacts and their account owner. Tiers and partner properties sync both ways. Segments re-evaluate themselves against live CRM data. Form submissions create and update CRM records, attributed to the right partner. Notifications and nudges go out on their own. Commission lines are earned from CRM or billing data and flow into payout runs. That is the out-of-the-box layer, and for most programs it is the majority of the automation they will ever need.
What is left is specific to how you run partnerships. Tier a partner up the moment they certify. Chase a task toward its due date, and escalate to the partner manager if it slips. Book a fixed bonus when onboarding completes. Move a partner onto a different portal experience when a field changes in the CRM. That is what Workflows is for. You define the rule once: pick a trigger, narrow it to the partners and events you mean, add conditions and waits, and pick the actions. It saves as a draft, you rehearse it against a real partner, and then you switch it on. From then on Introw enforces it for every partner, the same way every time, and adding partners adds runs rather than headcount.
# Build your first workflow
Source: https://docs.introw.io/features/automation/workflows/guides/build-your-first-workflow
Create a workflow that moves a partner up a tier the moment they earn a certification, from an empty canvas through a rehearsal to an enabled automation.
Tiering a partner up when they certify is the classic partner-program rule that never gets enforced: the certification lands, and the tier follows whenever somebody notices. This guide builds it as a workflow, end to end: pick the trigger, narrow it to the certificate that counts, write the tier onto the partner, tell them, rehearse the whole thing against a real partner without changing anything, and switch it on. Everything you learn here, the two-part narrowing, the write mode, the rehearsal, and the enable gate, applies to every other workflow you build.
## What you'll achieve
An enabled workflow that, from the moment you switch it on, moves any partner whose contact earns your certification onto the next tier, records it on their CRM record, and emails the partner to tell them, with a rehearsal behind you proving the flow does what you meant.
## Before you start
**Workflows** has to be in your left-hand navigation under **Engage**, and your role needs write access to it. If the menu item is missing, your role does not have the **Workflows** switch on; ask an admin to turn it on in your role.
This workflow triggers on a certificate being issued and writes a tier, so both need to exist. See [Create a certificate](/features/courses/certificates/guides/create-a-certificate) and [Build a tier program](/features/partners/tiers/guides/build-a-tier-program).
The test run needs one partner and, ideally, one of their contacts. Any partner will do: nothing is written.
## Watch it
## Steps
### Create the workflow
Go to [Workflows](https://app.introw.io/workflows) and select **New workflow**. On an empty account, choose **Start from scratch** on the first-run screen. Introw creates a draft named **Untitled workflow** and opens the canvas, which is a single trigger node with a **+** under it.
Leave the name for now. You can rename it in the page title at any time, and **Generate with AI** will name it from the finished canvas later.
### Set the trigger
Select the trigger node. The panel lists the triggers in four groups: **Tasks & journeys**, **Forms**, **Learning**, and **Partners**. Under **Learning**, choose **Certificate issued**. It fires when a certificate is awarded to a partner contact, and re-issuing the same certificate to the same contact does not fire it again.
The panel now shows the trigger's own narrowing and its filter. Work through them in order:
* **Which certificates count** - the certificates that qualify. Pick your certification. Leaving it empty means any certificate, which would tier partners up for a webinar attendance badge, so this is the one narrowing you should not skip.
* **Only for partners in** - the segments the partner has to be in. This is checked before the workflow starts, so partners outside these segments leave no run behind. Leave it empty for your first workflow, or point it at a segment of the partner types the tier program applies to if your program has several.
* **Only for partners matching** - conditions on the partner's own Introw and CRM fields, for a check you would not keep a segment for. Leave it empty here, or use it to hold the promotion to the partners it applies to, for example **Partner tier** **is any of** Bronze or Silver so an Elite partner is not "promoted" downwards.
* **Only for certificates matching** - conditions on the event itself, over **Certificate**, **Issued at**, and **Expires at**. You have already narrowed by certificate, so leave this empty. It is where you would add something like an expiry date more than 30 days out.
The rule to remember: the first two blocks are about the partner, the last one is about the event, and all three are ANDed. Reach for a segment when the audience is one you already maintain or want to reuse, and for **Only for partners matching** when it is a one-off check this workflow alone cares about.
### Add the actions
Select the **+** under the trigger and choose **Action**, then **Update partner properties** from the **Partner** group. Each row is one property:
* **Property** - a searchable list of everything a workflow can write: **Partner tier**, **Partner phase**, **Partner categories**, **Partner owner**, the partner's **Experience**, and every writable CRM property on their company or custom partner object. Each is marked with Introw's logo or your CRM's, so two same-named fields are distinguishable. Pick **Partner tier**.
* **Value** - the tier to set, from your tier program's own list.
* **Write mode** - **Overwrite** always replaces what is there; **Fill in if not known** leaves an existing value alone. This is the most consequential setting on the panel. For a promotion, **Overwrite** is right: the point is to move a partner who already has a tier. For anything a partner manager sets by hand and would not want an automation undoing, choose **Fill in if not known**.
Select **Add property** to write a second field in the same step, with its own write mode. **Partner phase** on **Fill in if not known** is a good second row: a partner who already has a phase keeps it, and one who has none gets set. Every writable CRM property on the partner's company or custom partner object is in the same list too, so the same step can stamp the promotion onto the record your sales team is already looking at.
Select the **+** under the action, choose **Action**, then **Send an email** from the **Messages** group.
* **Send to** - because this trigger names a contact, the list includes **The contact this is about**, which reaches exactly the person who earned the certificate. The other options are **All contacts of the partner**, **The partner champion**, **Contacts in a segment**, and **Your partner team**, which is your own colleagues assigned to this partner rather than anyone at the partner. Choose **The contact this is about**.
* **Email** - select the card to open the editor. It is the same editor announcements use, so variables resolve per recipient and CTA buttons point at that partner's portal. Give it a **Subject**, which stays plain text, and write the body. **Generate with AI** drafts a subject and two or three paragraphs from where this step sits in the flow, with the greeting and sign-off added for you, so you can start there and edit.
Save the email and you are back on the canvas with a card showing the subject, who it goes to, and its opening lines.
### Rehearse it
Select the play button beside the trigger node. In **Test workflow**, pick a **Partner** and, since this flow emails the contact the trigger is about, a **Contact** as well.
Read the card before you run it. Every test is a dry run: delays resolve instantly, nothing is written and nothing is sent, conditions are evaluated against live data, and the trigger's filter is not applied, because you chose the partner by hand. That last point matters: a test proves the shape of the flow, not the audience.
Select **Run test**. The canvas updates as each step resolves, and nodes the run touched are badged **Simulated**.
Every node should read **Simulated**. A node badged **Failed** carries its reason, and a node that stopped the run short says why, for example that the partner has no portal contacts for the email to reach. Fix what you find and run the test again.
### Name it and switch it on
Open **Settings**. Select **Generate with AI** to write both fields from the canvas, then edit them.
* **Name** - what the workflow does, in a few words. It is the column your colleagues scan on the workflows list.
* **Description** - one or two sentences for whoever reads this workflow next, including you in six months.
Switch **Enable** on and select **Save**.
If **Enable** is unavailable, **Not ready to enable yet** lists exactly what is missing: a trigger, at least one action, a value left unset on a step, or a pairing that cannot work. Clear the list and the switch becomes available. If a locked **Enable** button sits where the switch should be, your plan's active workflows are all in use: switch another workflow off, or select it to upgrade. Drafts never count toward that limit.
Enabling is not retroactive. Only partners who earn the certificate from this moment on enter the workflow; nothing replays history. If you need to catch up the partners who already certified, do that once by hand or with a bulk update.
## Verify it worked
The workflows list shows the workflow as **Active** with its trigger, its step count, and you as the owner. Issue the certificate to a test contact, then switch the canvas header to **Runs**: a run appears named after that partner, its nodes read **Ran**, and the partner's tier has moved. The contact has the email in their inbox, and the property you wrote is on the partner's record in HubSpot or Salesforce.
## Related
Add delays and conditions to build a nudge chain that escalates.
What a rehearsal proves, and how to read every node outcome.
Check what already runs before building the next one.
Every trigger, action, condition, and delay option.
# Chase a task to its due date and escalate
Source: https://docs.introw.io/features/automation/workflows/guides/chase-a-task-to-its-due-date
Build a nudge chain that reminds a partner three days before a task is due, again two days after it slips, and hands it to the partner manager five days after.
A task with a due date and no chase is a task that gets done late or not at all. The usual fix is a calendar of manual reminders, which is the first thing to fall over in a busy quarter. This guide builds the chase as one workflow: a reminder three days before the task is due, a second one two days after it has slipped, and an escalation to the partner manager five days after, with every step checking whether the partner has since done the work so nobody is nudged about something they finished.
## What you'll achieve
An enabled workflow that, for every partner assigned the task you name, sends the reminder before the deadline, the follow-up after it, and the escalation to your own team, all measured from that task's own due date, and stops the moment the task is marked done.
## Before you start
The chase is worth building for a specific task, not for every task in the program. Have the journey and know the exact name of the task inside it. See [Build a journey from scratch](/features/partners/journeys/guides/build-a-journey-from-scratch).
The whole chain is measured from the task's due date, and a task without one stops the workflow at the first wait. On a journey's task, the due date is set as days after assigned. Check it is set before you build this.
The escalation reaches your own colleagues assigned to the partner, optionally narrowed by the partner team role they hold. If you want it to reach only partner managers rather than the whole internal team, set up those roles first. See [Set up partner team roles](/features/access/team-management/guides/set-up-partner-team-roles).
## Watch it
## Steps
### Set the trigger
Go to [Workflows](https://app.introw.io/workflows), select **New workflow**, then select the trigger node and choose **Task assigned** under **Tasks & journeys**.
**Task assigned** fires when a partner acquires a task, which means when it is created. Reassigning an existing task between people does not fire it, so the chain does not restart every time a manager tidies up ownership. It is also the only trigger that offers a wait anchored to the task's due date, which is what the rest of this workflow is built on. **Task completed** would be too late: the clock has to start when the work appears, not when it is done.
Under **Only for tasks matching**, build two conditions:
* **Journey** **is** your journey. Narrowing by journey first is what makes the next condition exact, because the **Task** list is then scoped to that journey's tasks instead of every task in the program.
* **Task** **is** the task you are chasing, picked from that scoped list.
Leave **Only for partners in** empty to chase every partner, or point it at a segment if only some partner types get this treatment. Leave the timestamp fields alone; **Due date** and **Assigned at** are there for narrowing by date, which you do not need here.
Without these conditions the workflow chases every task every partner is ever given, which is a lot of email. Narrow it.
### Nudge before the deadline
Select the **+** under the trigger and choose **Delay**.
* **Wait** - choose **Around the task's due date**. This option only appears because the trigger is **Task assigned**. The alternative, **After the previous step**, is a plain pause and would mean "three days after the task appeared", which is not the same thing at all and drifts as soon as anyone edits a due date.
* **How far from the due date** - enter **3**, unit **Days**, direction **Before due**. Zero would wait until the due date itself.
The moment is read fresh when the run reaches this step, so moving the task's due date moves the nudge with it. If the task is assigned less than three days before it is due, the wait is already over and the run carries straight on, which is the honest reading of "at three days before due". Read the note under the panel: when the task has no due date at all, nothing after this step runs, and the node will say so.
Select the **+** under the delay and choose **Condition**. Under the trigger's own condition block, add:
* **Task status right now** **is not** **Done**.
The words "right now" are the point. Every other field on the canvas answers about the moment the workflow started, when the task was obviously not done. This one is read from the current state at the instant the condition is decided, which after a multi-day wait is a different answer. Get this wrong and you nudge every partner who has already finished.
Leave **Partners in** and **Partner matches** empty: you narrowed the audience on the trigger, and this fork is about the task, not the partner. Those two blocks are read when the fork runs, so they are where you would put a check that has to be true *at the moment of the nudge*, for example not chasing a partner whose tier has since been downgraded.
On the **Yes** path, add an **Action**, then **Send an email**.
* **Send to** - **Whoever the task is assigned to**. This option appears only on task triggers, and it resolves when the email sends, so it reaches whoever currently owes the task rather than whoever owed it when the workflow started. Be aware it can be one of your own team if the task was assigned internally, so write the copy so it reads sensibly either way.
* **Email** - a short, friendly reminder with the deadline in it. **Generate with AI** drafts it from this position in the flow, which means it already knows it is a pre-deadline nudge.
Leave the **No** path empty. The partner finished on time, so there is nothing to do.
### Nudge again once it slips
Still on the **Yes** path, under the email you just added, add another **Delay**.
* **Wait** - **Around the task's due date** again. A second anchored wait is measured from the same due date, not from the previous step, so you express each moment in the chain absolutely rather than accumulating offsets in your head.
* **How far from the due date** - **2**, **Days**, **After due**.
Because the first nudge went out three days before, this wait is about five days long in practice, and it re-reads the due date, so a deadline the partner asked to move takes the whole rest of the chain with it.
Add a **Condition** with the same **Task status right now** **is not** **Done** check. The partner may have acted on the first reminder, and this is what stops the second one reaching them.
On its **Yes** path, add **Send an email** to **Whoever the task is assigned to** again, with copy that acknowledges the deadline has passed.
If your partners live in Slack or Teams, this is a good place for **Send a chat message** instead of, or as well as, the email: pick **The partner's channel** to post into the shared channel mapped on the partner's page, and write `{{partner}}` where you want the partner's name. A message in a channel a partner already watches outperforms a third email. This needs a connected Slack or Microsoft Teams workspace. See [Chat integrations](/features/integrations/chat).
### Escalate to the partner manager
Under the second nudge, add a third **Delay**: **Around the task's due date**, **5**, **Days**, **After due**. Three days after the second nudge, and still anchored to the same date.
Add a **Condition** with **Task status right now** **is not** **Done**. Two nudges have gone unanswered, so this fork is what separates a partner who needs a human from one who simply took their time.
On the **Yes** path, add **Send an email**.
* **Send to** - **Your partner team**, which shows as your organisation's name followed by "partner team". This is the one audience that is always internal: your own colleagues assigned to this partner. A **Roles** picker appears under it. Pick the partner manager role to reach only them; leave it empty and everyone on the partner's team gets it. Roles are resolved when the email sends.
* **Email** - name the partner, the task, and how long it is overdue, and say the automated nudges have already gone out, so the manager knows what the partner has already heard.
Two more steps are worth adding beside the email, both on the same **Yes** path:
* **Give a task** with **Assignee** set to one of your own team, **Task name** something like "Call the partner about overdue onboarding", and **Due date** two days after assigned. An email is read and forgotten; a task appears on someone's list until it is done. Set **Visibility** to **Internal** so the partner never sees the escalation.
* **Log a CRM note** so the escalation is on the partner's record in HubSpot or Salesforce for whoever picks the account up next. Write `{{partner}}` for the partner's name.
A workflow that triggers on **Task assigned** and also gives a task could set itself off. Introw refuses to enable that pairing, unless the trigger is narrowed to specific journeys, because a task a workflow creates belongs to no journey and so can never re-trigger it. The **Journey** condition you set on the trigger is what makes this escalation task safe. If **Enable** complains that the workflow would give partners the task that triggers it, that condition is missing.
### Rehearse and enable
Select the play button beside the trigger, pick a partner, and select **Run test**. Delays resolve instantly in a rehearsal, so the whole chain plays out in seconds and you can see which side of each fork the run took without waiting a week. Nothing is written and nothing is sent.
Remember the rehearsal does not apply the trigger's filter, so it will run for the partner you picked whether or not they have the task. What you are checking here is the shape: three delays, three forks, the right audiences.
Open **Settings**, use **Generate with AI** to name and describe it, switch **Enable** on, and **Save**. Only tasks assigned from this moment on enter the chase; tasks already outstanding are not picked up.
## Verify it worked
Assign the task to a test partner with a due date a few days out and switch the canvas header to **Runs**. A run appears, and its first delay reads **Waiting** with the rest of the canvas **Not reached**, which is exactly right: the run is parked until three days before the due date. Mark the task done and the next condition sends the run down its **No** path, leaving the remaining nudges **Not taken**. Leave it undone and the reminder lands in the assignee's inbox on schedule, the escalation reaches the partner manager five days after the deadline, and the note is on the partner's CRM record.
## Related
The same chase pattern, started by a partner going quiet instead of a deadline.
Put the partner on the journey these tasks come from.
The built-in nudge for deals sitting too long in a stage.
Every delay anchor, condition field, and email audience.
# Onboard a new partner automatically
Source: https://docs.introw.io/features/automation/workflows/guides/onboard-a-new-partner-automatically
Put every new partner on the onboarding journey, welcome them, and chase the ones who stall, from the moment the partner appears from your CRM.
Partner onboarding is usually consistent for the first ten partners and improvised after that. This guide makes it the same every time: the moment a partner appears, whether someone added them or your CRM detected them, they are put on the onboarding journey, welcomed, and then checked on. Partners who have not started a week later get a nudge; partners still stalled two weeks later become their manager's problem, on purpose.
## What you'll achieve
An enabled workflow that turns a new partner into an onboarding partner without anyone setting it up: the journey is applied, the welcome email goes out, and the stall handling runs itself so a quiet partner is chased rather than forgotten.
## Before you start
The workflow enrolls partners in a journey, so it has to exist. Give its tasks due dates as days after assigned, so each partner's dates are right for when they started. See [Build a journey from scratch](/features/partners/journeys/guides/build-a-journey-from-scratch).
If your onboarding experience already has this journey attached, partners get it when the experience is published and this workflow should not enroll them again. Check [Auto-apply a journey from the experience](/features/partners/journeys/guides/auto-apply-a-journey-from-the-experience) first, and use this workflow for the cases the experience does not cover, or for the welcome and chase half only.
If partners are detected from CRM filters, this workflow runs for every newly detected partner, which is usually what you want. Confirm your filters are narrow enough that only real partners are detected. See [Detect partners from your CRM](/features/partners/partner-management/guides/detect-partners-from-your-crm).
## Watch it
## Steps
### Start from the new partner
Go to [Workflows](https://app.introw.io/workflows), select **New workflow**, select the trigger node, and choose **Partner created** under **Partners**.
**Partner created** fires when a new partner appears, whether added by hand or brought in by CRM detection. It is deliberately separate from **Partner updated**: adding a partner and editing one are different moments, and a welcome sequence must not re-run because someone corrected a company name two weeks later.
A create event carries very little, because there is nothing about a brand new partner to ask beyond the partner itself.
* **Only for partners in** - the segments the partner has to be in. If your program onboards resellers differently from referral partners, this is where you split them, and you would build one workflow per path. Note that a partner has to already match the segment when the run starts, so a segment keyed off a CRM property that arrives with detection works, while one keyed off something you set later does not.
* **Only for partners matching** - the same split without maintaining a segment, over the partner's own Introw and CRM fields. A partner detected from your CRM arrives with its company properties already synced, so **Company Type** **is** Reseller works here on the first event.
**Partner created** shows no event-conditions block, because a brand new partner's event carries nothing to ask about beyond the partner itself. The two blocks above are the whole filter.
### Set the partner up
Select the **+** under the trigger, choose **Action**, then **Enroll in a journey** from the **Tasks & journeys** group, and pick your onboarding journey.
This is the same operation as **Apply** on the partner page, so a partner already on the journey keeps their progress and only the steps they do not have yet are added. The tasks arrive with their due dates calculated from now, so each partner's deadlines are right for when they actually started.
Add an **Action**, then **Update partner properties**, and set the defaults you would otherwise fill in by hand:
* **Partner phase** - the starting lifecycle phase, so the partner shows correctly in your reporting from the first day. Use **Write mode** **Fill in if not known** so a partner who arrived with a phase already set is left alone.
* **Experience** - the onboarding experience, if the partner does not get one another way. Setting this publishes the experience to the partner: their portal is created if they have none, and its content, journeys, and goals are applied. It has no write mode, and it counts against your plan's portal limit for partners who do not already have a portal.
* **Partner owner** - only if there is a sensible default. Where ownership comes from your CRM account owner, leave this out and let the built-in owner suggestion do its job. See [Wire partner ownership](/features/partners/team/guides/wire-partner-ownership).
Add an **Action**, then **Send an email**.
* **Send to** - **The partner champion** for a single personal welcome, or **All contacts of the partner** if several people arrived with the partner and all of them need the portal.
* **Email** - what the partnership is, what to do first, and a button into their portal. Variables resolve per recipient and CTA buttons point at that partner's portal, exactly as in an announcement, so one email works for every partner. **Generate with AI** drafts it from this point in the flow.
This is not the portal invitation. Portal access is granted separately, through your access setup or by inviting the contact, and a welcome email is a poor substitute for it. See [Invite partners and their teams](/features/portal/portal-access/guides/invite-partners-and-their-teams).
### Chase the ones who stall
Add a **Delay** under the email.
* **Wait** - **After the previous step**. The due-date anchors are not offered here, because **Partner created** carries no task or course to read a due date from, and the panel only shows the choice when there is one to make.
* **For how long** - **7**, unit **Days**. The pause survives restarts and deploys, so a week-long wait is safe.
Add a **Condition** under the delay. There are no journey fields to ask about, because the trigger is about the partner rather than the journey. So use the two partner blocks instead:
* **Partners in** - a static or dynamic segment of partners who have not started onboarding. The most reliable version is a dynamic segment over partner activity or a CRM field your journey's first task writes, which is a good reason to make that first task write something.
* **Partner matches** - or skip the segment and read the partner's own fields here. This block is evaluated when the fork runs, not when the workflow started, so **Partner last activity** or the CRM field your first task writes tells you what is true a week later rather than a week ago.
Alternatively, keep the check simple and unconditional: send a friendly "here is where to start" nudge to everyone at the one-week mark. A second email to a partner who has already started is a small cost; not chasing the ones who have not is a large one.
On the **Yes** path, add **Send an email** to **The partner champion** with a short "shall we get started" message, and where your partners live in chat, add **Send a chat message** to **The partner's channel**. Write `{{partner}}` for the partner's name. Chat needs a connected Slack or Microsoft Teams workspace and a channel mapped on the partner's page; a partner without one stops the run at that step with a note rather than failing it.
Still on the **Yes** path, add a second **Delay** of **7 Days**, then **Give a task** from the **Tasks & journeys** group:
* **Task name** - something a manager can act on, for example "Call the partner: onboarding not started after two weeks".
* **Assignee** - one of your own team. Use a partner team role rather than a named person so the task follows whoever owns the partner.
* **Visibility** - **Internal**, so the partner never sees the escalation. Internal visibility is only available on a task assigned to your own team.
* **Due date** - **2** days after assigned, so it does not sit indefinitely.
* **Description** - what has already been sent, so the manager does not repeat the automated nudges.
Add **Log a CRM note** beside it if you want the stall visible to the account team on the partner's CRM record.
### Rehearse and enable
Select the play button beside the trigger, pick an existing partner, and select **Run test**. Delays resolve instantly, so the whole two-week arc plays out in seconds and you can see both paths. Nothing is written, so no journey is applied and no experience is published.
Open **Settings**, name and describe it, switch **Enable** on, and **Save**. Only partners created from this moment on are onboarded by the workflow. Existing partners who never got the journey are a one-time bulk apply, not something this workflow will pick up.
## Verify it worked
Create a partner, or let your CRM detection bring one in, then switch the canvas header to **Runs**. A run appears named after that partner with the enrollment and email nodes reading **Ran**, and the delay reading **Waiting** with everything after it **Not reached**. Open the partner: the journey's tasks are on their record with due dates counted from today, their phase and experience are set, and the champion has the welcome email. A week later the run resumes and takes the path the condition decides.
## Related
Close the loop: pay and promote when this onboarding completes.
Chase the individual onboarding tasks, not just the whole journey.
Unlock the portal in stages as onboarding advances.
Every trigger, action, condition, and delay option.
# Personalize workflow steps with variables
Source: https://docs.introw.io/features/automation/workflows/guides/personalize-workflow-steps-with-variables
Write a CRM note, task, commission line, email or chat message that fills in the partner, the event and earlier steps per run, with variables you pick where each value belongs.
A workflow step that writes fixed text says the same thing for every partner.
The CRM note reads "Partner finished onboarding", the task says "Call the partner", and whoever opens it has to go and find out which partner, which journey and how much.
Variables fill those specifics in per run.
You type `{` where a value belongs, pick it, and every run writes the real partner name, journey, amount or date in its place.
## What you'll achieve
A saved, rehearsed workflow whose steps write per partner: a commission line described with the partner and the journey they finished, a CRM note that records the amount the previous step booked and a follow-up date, and an email whose subject and body name the partner and the journey.
You also know what happens when a step a variable depends on is removed, and how Introw stops that workflow from going live half-empty.
## Before you start
Workflows are released per organization, and your role needs the **Workflows** permission to build and test.
A role that can only read opens the canvas but cannot type into a step.
See [Create an internal role](/features/access/team-management/guides/create-an-internal-role).
The trigger decides which values a step can use.
A **Journey completed** workflow can name the journey, a **Task assigned** workflow the task and its assignee, a **Certificate issued** workflow the certificate and the contact who earned it.
Pick the trigger first, then write the text.
A step can only use what earlier steps on its own path produced.
Put the commission step above the note that quotes its amount.
## Watch it
## Steps
### Pick the trigger that carries the values
Go to [Workflows](https://app.introw.io/workflows), select **New workflow**, select the trigger node, and choose the event the message is about.
This guide uses **Journey completed**, with **Which journeys count** set to the onboarding journey.
Every trigger carries the partner.
Most carry one more thing, and that is the group you will see under **From trigger** later:
* **Task assigned** and **Task completed** carry the **Task**: its name, status, due date and assignee.
* **Enrolled in journey** and **Journey completed** carry the **Journey** name.
* **Course started** and **Course completed** carry the course, the enrollment's due date and the learner.
* **Certificate issued** carries the certificate, when it was issued, its URL and the contact who earned it.
* **Partner contact added** and **Partner contact updated** carry the **Contact**: name, email, job title and when they were added.
* **Segment membership** carries the **Segment** name.
* **CRM record updated** carries the record: its ID, type and link, and every CRM property on it.
* **Partner created** and **Partner updated** carry the partner only.
### Insert a variable
Add an action that writes something a person will read.
Variables work in every text a step writes:
* **Give a task**: the task name and the description.
* **Give commission**: the description the partner sees on their commission tab and payout.
* **Log a CRM note**: the note.
* **Send an email**: the subject and the body.
* **Send a chat message**: the message.
Here, add **Give commission** and set the amount.
Amounts, currencies and pickers take fixed values, so variables only appear in the text fields.
Click into the field, write the fixed part, and type `{` where the value goes.
A list opens in three sections:
* **Always available** holds what every run has: **Organization** (your name, domain, logo, time zone, country, currency and creation date), **Date**, and **Links**, such as the portal link or a link to a form or course you pick, for an email or chat message.
* **From trigger** holds what the event carries: **Partner**, the trigger's own group, such as **Journey**, and one group for each partner team role you have set up.
* **From actions** holds what earlier steps on this path produced. It is empty on the first step.
Select a group to open it, then select the field.
**Partner** lists the Introw fields first, the partner name, domain, logo, manager email, phase, tier and categories, then every property on the partner's company or custom partner object in your CRM.
A partner team role group, such as **Partner Manager**, gives the name, email, phone, job title and LinkedIn URL of whoever holds that role on this partner.
Type in **Search** to find a CRM property by name instead of scrolling.
The value lands as a pill.
Everything around it stays fixed text, so you can read at a glance what is written once and what is filled in per run.
Add as many as the text needs: this description reads "Bonus for **Partner name**, **Journey name**".
### Use what an earlier step produced
Add **Log a CRM note** below the commission step and start the note the same way, with the partner and the journey.
Then type `{` again and look at **From actions**.
It lists the steps that run before this one, on this path only: a step on the other side of a condition is not offered, because a run never passes through both.
Hover a group in the list, or a pill you already placed, and the step it comes from is outlined on the canvas.
On a long chain with two emails and two tasks, this is how you tell **Send email 1** from **Send email 2** without counting.
Open the step's group and pick the field.
What each step hands on:
* **Give commission**: **Line ID**, **Amount**, **Currency**, **Description** and **Formatted amount**, which reads the amount in the line's currency.
* **Log a CRM note**: the **Note URL**, so a later email or task can link straight to it.
* **Give a task**: **Task ID**, **Name**, **Assignee name** and **Due date**.
* **Send an email**: when it was queued and sent, and its **Subject**.
* **Enroll in a journey**: **Journey name** and how many tasks it created.
* **Issue a certificate**: the **Certificate URL**.
Use **Formatted amount** here, so the note says the amount the partner will actually see.
### Add a date
Under **Always available**, open **Date** and pick **Today**.
Choose a **Format** and select **Insert**.
The date is the day the step runs, not the day you wrote it.
Pick **Relative date** instead for a deadline or a follow-up.
Set **When** to **Days from now**, **Days ago**, **Hours from now**, **Hours ago**, **Minutes from now** or **Minutes ago**, and the number.
Set **Format** to **Date**, **Date with weekday**, **Date with time**, **Date with weekday and time**, **Numeric date** or **ISO timestamp**.
The **Example** line shows what the reader will see, then select **Insert**.
The pill reads the offset, such as **In 7 days**.
### Personalize the email
Add **Send an email**, choose who it goes to, and open the email editor.
The **Subject** takes the same list: type `{` and pick **Partner name**, then finish the line.
The body is the announcement editor, so `/` inserts blocks and buttons and `{` opens the variable list.
Name the journey the partner finished, and select **Done**.
### Save and rehearse
Open **Settings**, give the workflow a name, and **Save**.
The canvas only commits on **Save**.
Select the play button on the trigger, pick a partner, and run the test.
A test is a dry run: nothing is booked, logged or sent, and each step the run reached is badged **Simulated**.
See [Test a workflow and read its runs](./test-a-workflow-and-read-its-runs).
### Keep every variable reachable
A pill points at a trigger or a step.
Remove that step, or change the trigger to one that does not carry the value, and the pill has nothing to read.
The step that holds it gets a warning badge that reads **This step uses variables that are no longer available**.
A workflow in that state cannot be switched on, and an active one cannot be saved in it.
**Settings** lists it under **Not ready to enable yet** as **Replace variables that are no longer available**.
Open the flagged step and replace or remove the pill, or put the step back.
If you have not saved yet, reloading the page brings back the saved canvas.
## Verify it worked
The saved workflow shows each step's text with its pills, and the test run badges every step **Simulated**.
Once you enable it, the first real run writes the note on the partner's CRM record with their name, the journey, the booked amount and the dates filled in, and the email arrives with the partner's name in the subject.
Open a run from **Runs** to see which path it took.
## Related
Build, test and enable a workflow from an empty canvas.
Book a bonus, issue a certificate and tell the partner.
Rehearse against a real partner and read every run.
Every trigger, action and the variables each one offers.
# Re-engage partners who go quiet
Source: https://docs.introw.io/features/automation/workflows/guides/re-engage-quiet-partners
Turn a dynamic segment into a trigger: nudge a partner the moment they go quiet, wait, check whether it worked, and hand the ones who stay quiet to their manager.
No event fires when a partner stops doing things. That is why partner attrition is usually discovered in a report rather than caught in the moment. A dynamic segment solves it: a segment whose audience says "no activity in 30 days" re-evaluates itself against live data, and a partner crossing into it is an event a workflow can start from. This guide uses that to build a re-engagement sequence that nudges, waits, checks whether the nudge worked, and only involves a human when it did not.
## What you'll achieve
An enabled workflow that reaches a partner in the days after they go quiet, on the channel they actually watch, checks a week later whether they came back, and puts the ones who did not on their manager's task list with the history already written down.
## Before you start
This whole workflow hangs off a **dynamic** segment whose audience defines "quiet" for your program: no portal activity in 30 days, no new deal in a quarter, or a CRM field your own scoring writes. Dynamic segments re-evaluate on a schedule, which is what makes membership an event. See [Create a dynamic segment](/features/partners/segments/guides/create-a-dynamic-segment) and [Re-activate inactive partners](/features/partners/segments/guides/re-activate-inactive-partners).
The mid-flow check needs something to test. The simplest reliable version is a second segment, or the same segment read again: a partner who has become active again is no longer in the quiet segment.
Posting to a partner's shared channel needs Slack or Microsoft Teams connected and a channel mapped on the partner's page. See [Chat integrations](/features/integrations/chat).
## Watch it
## Steps
### Trigger on the segment
Go to [Workflows](https://app.introw.io/workflows), select **New workflow**, select the trigger node, and choose **Segment membership** under **Partners**.
This is the trigger that answers questions no other trigger can. A dynamic segment carries time constraints and partner, contact, and CRM conditions, and its membership is recalculated on a schedule, so "has not traded in 30 days", "reached Gold", and "is certified but not transacting" are all this one trigger pointed at a different segment.
* **Entering or leaving** - choose **The partner enters the segment**. It fires when a partner starts matching, or is added. **The partner leaves the segment** is the mirror, and is what you would use to stop a sequence or to celebrate a partner who climbed out of a risk cohort.
* **Which segments count** - pick your quiet segment. Leave it empty and any segment movement anywhere starts a run, which on an account with a dozen segments is a lot of noise. Pick one.
The panel reminds you of one useful guarantee: segments this workflow adds partners to never re-trigger it, so a sequence that tags partners as it goes cannot set itself off.
**Only for partners in** narrows the audience on top of the trigger's own segment: any of the segments you pick matching is enough. Use it to exclude the partners you do not want chased, for example by adding a segment of active-tier partners only, so a dormant affiliate does not get a reseller's re-engagement sequence.
**Only for partners matching** reads the partner's own Introw and CRM fields instead of a segment, which is the shortest way to say "only chase the partners worth chasing": **Partner tier** **is any of** Silver, Gold, Elite, and a dormant affiliate never enters the sequence.
**Only for segments matching** offers the event's own **Segment** field, which is useful when the trigger names several segments and you want a mid-flow fork on which one the partner joined.
### Reach the partner where they are
Select the **+** under the trigger, choose **Action**, then **Send a chat message** from the **Messages** group.
* **Provider** - **Slack** or **Microsoft Teams**. Only connected and active workspaces are offered, and with one connected there is no choice to make.
* **Channel** - **The partner's channel** posts into the shared channel mapped on that partner's page, resolved when the message sends, so remapping a partner later moves every workflow with it. **One fixed channel** posts every run into the same place, which is for internal alerting rather than for reaching a partner.
* **Message** - plain text, short. Write `{{partner}}` where you want the partner's name.
Chat first is deliberate: a partner who has stopped opening the portal has probably stopped opening your emails too, and a message in a channel they already watch is the one that gets read. A partner with no mapped channel stops the run here with a note saying so rather than failing it, which is worth knowing before you make this your only nudge.
Add **Send an email**.
* **Send to** - **The partner champion** for a personal note, or **Contacts in a segment** if you maintain a segment of the people worth reaching at each partner. **The contact this is about** is not offered on this trigger, because a segment movement is about the partner, not one person.
* **Email** - give the partner a reason to come back rather than an observation that they left: a new asset, an open campaign, a deal of theirs that needs attention. CTA buttons point at that partner's own portal, so a button can land them exactly where the reason is.
Add **Give a task** with **Assignee** left as the partner's company, or set to a partner team role if you know who to reach. A task appears in the partner's portal, is visible to both sides, and shows up in the built-in task reminders, which means the re-engagement keeps working after your email has been buried.
Set **Due date** to a handful of days after assigned and write a **Description** that says why you are asking. Keep **Visibility** as **Public** so the partner can see it.
### Check whether it worked
Add a **Delay**: **After the previous step**, **7**, **Days**. A segment trigger carries no due date to anchor on, so a plain wait is the only option here and the panel simply says so.
Add a **Condition**. Under **Partners in**, pick your quiet segment again.
Read it carefully, because the logic inverts: a partner still in the quiet segment takes the **Yes** path, which is the escalation path, and a partner who has become active again has dropped out of the segment and takes **No**, where there is nothing left to do. The segment is re-read when the condition is decided, not when the run started, which is exactly why this works.
Remember that dynamic membership follows a schedule rather than changing the instant a partner acts, so leave the wait long enough for at least one re-evaluation to have happened. A week is comfortable; an hour would not be.
### Hand it to a human
On the **Yes** path, add **Give a task**:
* **Task name** - "Call the partner: quiet for six weeks", or whatever your window adds up to.
* **Assignee** - one of your own team, ideally a partner team role rather than a named person, so the task follows whoever owns the partner.
* **Visibility** - **Internal**, so the partner never sees it. Internal is only available on a task assigned to your own team.
* **Due date** - a few days after assigned.
* **Description** - list what the partner has already received, the chat nudge, the email, and the portal task, so the manager opens the conversation knowing what has been tried.
Add **Send an email** with **Send to** set to **Your partner team**, shown as your organisation's name followed by "partner team". This is the one always-internal audience: your own colleagues assigned to this partner. A **Roles** picker appears under it; pick the partner manager role to reach only them, or leave it empty for the whole team.
Then add **Log a CRM note** so the sequence and its outcome are on the partner's CRM record. When the account team next opens the record in HubSpot or Salesforce, the history of the re-engagement attempt is there rather than in a workflow log nobody thinks to check.
Add **Add to a segment** and pick a static at-risk segment. It gives you a durable list to report on and to target with announcements, and because so much keys off segments, it can also change what the partner sees. Only static segments are offered, since a dynamic segment's membership is decided by its own audience.
### Rehearse and enable
Select the play button beside the trigger, pick a partner, and select **Run test**. Delays resolve instantly, so both weeks pass in seconds. Conditions are evaluated against live data, so the fork tells you the truth about whether that partner is in the quiet segment right now, which makes this a genuinely useful rehearsal. Nothing is written and no message is sent.
Open **Settings**, name and describe it, switch **Enable** on, and **Save**.
Enabling is not retroactive, and on this trigger that has a specific consequence: partners already sitting in the quiet segment do not start a run, because they did not enter it after you switched the workflow on. Handle that backlog once, then let the workflow catch everyone who goes quiet from now on.
## Verify it worked
Switch the canvas header to **Runs** a day or two after enabling. Runs appear named after each partner who crossed into the quiet segment, with the chat, email, and task nodes reading **Ran** and the delay reading **Waiting**. Open one of those partners: the chat message is in their shared channel, the task is on their portal, and the champion has the email. A week later the fork resolves, and the partners who came back show the escalation branch as **Not taken** while the ones who stayed quiet have a task on their manager's list and a note on their CRM record.
## Related
Build the quiet segment this workflow triggers on.
The same escalation pattern, measured from a deadline.
Trigger on a single field instead of a whole audience.
Every trigger, action, condition, and delay option.
# React to a CRM change on a partner
Source: https://docs.introw.io/features/automation/workflows/guides/react-to-a-crm-change-on-a-partner
Trigger a workflow when a partner field changes in HubSpot or Salesforce, then move that partner onto a different portal experience, retag them, and log it back on the CRM record.
Your CRM is where a partner's classification actually changes: a rep updates the partner type, a program field moves from Registered to Managed, a region is corrected. In most partner tools that change reaches the portal when somebody remembers to make it again by hand. This guide wires it up so the CRM change is the thing that moves the partner: their portal experience switches, their categories are retagged, and the move is logged back on the CRM record so the account team can see it happened.
## What you'll achieve
An enabled workflow that watches one partner-level CRM property and, when it changes to the value you care about, publishes a different portal experience to that partner, updates their Introw fields, and writes a note on their CRM record. The partner's portal changes without anyone touching Introw.
## Before you start
The trigger reads the partner's company or custom partner object, so those properties have to be synced. See [CRM integrations](/features/integrations/crm) and [Detect partners from your CRM](/features/partners/partner-management/guides/detect-partners-from-your-crm).
Pick one partner-level property in HubSpot or Salesforce, and the value that should cause the change. A property with a fixed set of options is easier to build a reliable condition on than free text.
The workflow publishes an experience to the partner, so it has to exist and be ready for partners. See [Build and publish a portal experience](/features/portal/experiences/guides/build-and-publish-a-portal-experience).
Setting an experience creates a portal for a partner who does not have one, so it counts against your plan's portal limit. Partners who already have a portal move regardless.
## Watch it
## Steps
### Trigger on the field changing
Go to [Workflows](https://app.introw.io/workflows), select **New workflow**, select the trigger node, and choose **Partner updated** under **Partners**.
**Partner updated** fires on a partner's field changing, whether the change was made in Introw or came in from your CRM. It is one trigger over both sources on purpose: from a partner-program point of view, "the partner's program field changed" is one event, and where the edit happened is not a distinction you should have to build around.
**Which changes count** is a searchable list holding **Partner tier**, **Partner phase**, **Partner categories**, **Partner owner**, and every partner-level CRM property on the company and your custom partner object. Each entry is marked with Introw's logo or your CRM's, which matters here: an Introw **Tier** and a HubSpot property also called Tier are different fields, and picking the wrong one gives you a workflow that never fires.
Pick the one CRM property you are reacting to. Leaving the list empty means any triggerable field changing runs the workflow, which is almost never what you want on this trigger: every owner reassignment and every category edit would start a run.
Contact properties are deliberately not in this list. A contact changing is a different object changing, and **Partner contact updated** is the trigger that carries it.
The trigger tells you *which field* changed, not what it changed to. The value check is the next block down.
* **Only for partners matching** - a condition builder over the partner's own Introw and CRM fields. Add your property **is** the value you care about, for example the CRM program field **is** Managed. It is read as the event arrives, so "this field changed, **and** it now holds Managed" is one trigger. A partner whose field moved to some other value leaves no run behind.
* **Only for partners in** - segments, ANDed on top. Use it when the rule only applies to some partner types, for example resellers, and skip it otherwise. A segment is the better home for the same check when several workflows share it, or when the audience also depends on contact-level data, which this block deliberately does not offer. See [Create a dynamic segment](/features/partners/segments/guides/create-a-dynamic-segment).
**Partner updated** shows no event-conditions block at all, and that is deliberate rather than missing: its event *is* the partner. Which fields moved is already **Which changes count** above, and everything else worth asking is a question about the partner, which the block you just filled in answers directly.
### Change what the partner sees
Select the **+** under the trigger, choose **Action**, then **Update partner properties**.
Set **Property** to the partner's **Experience** and **Value** to the experience you want them on. This row behaves differently from every other one, and the panel says so: setting an experience does not patch a field, it publishes that experience to the partner. Their portal is created if they have none, and its content, journeys, and goals are applied. A partner already in another experience is moved to this one, so this is a genuine move rather than an addition.
Because of that, the **Experience** row has no write mode. If your plan has no portals left, partners who already have a portal still move and partners without one are skipped until you free up or add portals, and the panel warns you when that is the case.
Select **Add property** and add the Introw fields that should follow the CRM change, so the partner's classification is consistent everywhere:
* **Partner categories** - the tags your segments, content visibility, and reporting filter on. This is a multi-value field, so give it the full set you want the partner to end up with.
* **Partner phase** or **Partner tier** - if the CRM change also means a lifecycle move.
For each of these, set **Write mode** deliberately:
* **Overwrite** always replaces what is there. Correct when the CRM is the authority for that field and the whole point is to bring Introw in line.
* **Fill in if not known** leaves an existing value alone. Correct for anything a partner manager sets by hand and would not want an automation quietly undoing.
You can also write back the other way in this same step: any writable CRM property on the partner's company or custom partner object is in the same **Property** list, so a workflow can stamp a "portal experience applied" date onto the CRM record while it moves them.
Add another **Action**, then **Log a CRM note** from the **Messages** group. Write a line saying which experience the partner was moved to and why. Use `{{partner}}` for the partner's name.
The note lands on the partner's own record in HubSpot or Salesforce, their company or your custom partner object, so the rep who changed the field sees the consequence on the record they were already looking at. There is no record picker, because the partner's own record is the one record every run can name.
A portal that looks different without warning reads as a bug. If the move brings new content, a new journey, or new benefits, add **Send an email** with **Send to** set to **The partner champion** or **All contacts of the partner**, and say what has changed and what they can now do.
**The contact this is about** is not offered here: **Partner updated** is about the partner, not about one person, so there is no contact for it to resolve to. If the option is missing from a list where you expected it, that is why.
### Rehearse and enable
Select the play button beside the trigger, pick a partner, and select **Run test**. Nothing is written, so the experience is not actually published and no note reaches your CRM. What the rehearsal proves is that the steps are complete and the values resolve.
Because this workflow moves partners between portals, it is worth doing one deliberate live check after enabling rather than relying on the rehearsal alone: change the CRM field on a single test partner and read the run.
Open **Settings**, name and describe it, switch **Enable** on, and **Save**.
Two things to keep in mind. Enabling is not retroactive, so partners whose field already holds the target value are not moved; do that batch once with a bulk update. And changes the workflow makes itself never re-trigger it, so writing partner categories in a workflow that triggers on partner categories does not loop.
## Verify it worked
Change the property on one partner in HubSpot or Salesforce. Within the sync interval, switch the canvas header to **Runs**: a run appears named after that partner with its nodes reading **Ran**. Open the partner in Introw and their **Experience** is the new one; open their portal as a partner would and the new content, journeys, and goals are there. The note is on their CRM record, and the categories you wrote are on the partner, which means any segment keyed off those categories now includes them too.
## Related
Build the audience this workflow narrows on.
Build the experience the workflow moves partners onto.
Trigger on a segment instead, for the changes no single field names.
Every writable property, write mode, and trigger narrowing.
# Reward a partner for finishing a journey
Source: https://docs.introw.io/features/automation/workflows/guides/reward-a-finished-journey
Book a one-off commission bonus, issue a certificate, move the partner into the activated segment, and tell them, the moment they complete an onboarding journey.
A completion bonus is easy to promise and hard to deliver. Onboarding finishes, and then somebody has to notice, raise the reward with ops, tag the partner as activated, and send a congratulations note, which is four handoffs for a payment you already decided on. This guide makes the completion itself do all of it: a fixed commission line, a certificate, the activated segment, and the email, in one workflow.
## What you'll achieve
An enabled workflow that, whenever a partner completes your onboarding journey, books a one-off bonus of a fixed amount, awards them the completion certificate, moves them into the segment that unlocks the next stage of your program, and emails them, with the reward landing in your normal approval and payout run rather than beside it.
## Before you start
The trigger fires when every task of a journey is done, so the journey needs to be one that genuinely ends. See [Build a journey from scratch](/features/partners/journeys/guides/build-a-journey-from-scratch).
The workflow books a commission line for a fixed amount. Confirm the figure and that it should go through your usual payout process. See [Configure commission payout settings](/features/commissions/settings/guides/configure-commission-payout-settings).
Both are picked from lists of things that already exist. The segment has to be a **static** one, because that is the only kind a workflow can add a partner to. See [Create a certificate](/features/courses/certificates/guides/create-a-certificate) and [Create a static segment](/features/partners/segments/guides/create-a-static-segment).
## Watch it
## Steps
### Trigger on completion
Go to [Workflows](https://app.introw.io/workflows), select **New workflow**, select the trigger node, and choose **Journey completed** under **Tasks & journeys**.
**Journey completed** fires when every task of the journey is done, not when the last one happens to be ticked in isolation, so it is a real completion event rather than a task event you have to reason about.
* **Which journeys count** - pick your onboarding journey. Leave it empty and finishing any journey pays the bonus, which is exactly the kind of mistake that is expensive rather than merely wrong. Pick one.
* **Only for partners in** - the segments a partner has to be in to qualify. Use this if the bonus applies to some partner types and not others, for example resellers but not referral partners. Leave it empty to reward everyone.
* **Only for partners matching** - the same qualification over the partner's own Introw and CRM fields, for a rule you would not keep a segment for. A bonus that only applies above a tier is **Partner tier** **is any of** Silver, Gold, Elite here.
* **Only for journeys matching** - conditions on the event's own fields, **Journey** and **Completed at**. You have already narrowed by journey, so leave this empty.
### Pay the reward
Select the **+** under the trigger, choose **Action**, then **Give commission** from the **Rewards** group.
* **Amount** - the fixed figure, for example `50`. Use a positive number with at most two decimal places.
* **Currency** - a new step starts on your company currency, which is right when the bonus is the same number of the same currency for everyone. Clear it (the field reads **Empty uses the partner's currency**) and the amount is resolved in each partner's own currency when the run happens, so one workflow stays correct across a program that bills in several.
* **Description** - what the commission is for, for example "Onboarding completion bonus". It is shown on the partner's commission tab and on the payout, so write it for the partner reading their statement, not for yourself.
This books a single manual line, not a plan. A plan earns lines over time from CRM or billing data, and lives under [Commission plans](/features/commissions/commission-plans); this is the "fixed amount for doing a thing" case. The line is created as pending, so it still goes through your normal approval and payout run, and nothing is paid without the usual review.
Add another **Action**, then **Issue a certificate**.
* **Certificate** - the onboarding completion certificate.
* **Who earns it** - **All contacts of the partner** or **The partner champion**. On this trigger, **The contact this is about** is not offered: a journey belongs to the partner rather than to one person, so there is no contact for it to resolve to. Choose **The partner champion** when the certificate represents the partnership, and **All contacts of the partner** when everyone at the partner should be able to show it.
Recipients are notified exactly as they are for a certificate issued by hand, so there is nothing extra to configure for the partner to receive it.
### Promote them
Add an **Action**, then **Add to a segment** from the **Partner** group, and pick your activated segment.
Only static segments are offered. A dynamic segment's members are whoever matches its audience, so an enrollment there would be undone at the next evaluation, and the picker refuses to offer one rather than letting you build something that silently unwinds. The partner keeps every segment they are already in, and adding a partner twice does nothing.
This step is what makes the reward compound. Portal tab visibility, content and asset visibility, course auto-enrollment, discounts, and notification recipients all key off segments, so one enrollment can unlock the whole next stage of your program at once. See [Layer segments to progressively unlock capabilities](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
If completing onboarding also means a tier move, add **Update partner properties** and set **Partner tier**, with **Write mode** set to **Overwrite** so a partner who already holds a lower tier actually moves. If the tier is something your team also sets by hand and you do not want an automation overriding, use **Fill in if not known** instead.
If activated partners move onto a second program, add **Enroll in a journey** and pick it. A partner already on that journey keeps their progress, and only the steps they do not have yet are added, so re-enrollment is safe.
Do not point this at the journey that triggers the workflow. Introw refuses to enable a workflow that enrolls partners in the journey whose completion started it, because it would cause itself.
### Tell them, then enable
Add **Send an email**.
* **Send to** - **All contacts of the partner** so everyone who worked through onboarding hears it, or **The partner champion** for a single message to the main relationship.
* **Email** - name the bonus, the certificate, and what is now available to them. **Generate with AI** drafts it from this position in the flow, so it already knows a reward and a certificate came before it. Variables and CTA buttons behave as they do in an announcement, so a button can take the partner straight to the newly unlocked part of their portal.
Select the play button beside the trigger, pick a partner, and select **Run test**. Nothing is written: no commission line is booked, no certificate is issued, no email is sent. Every node the run touched is badged **Simulated**. This is the rehearsal to do carefully, because this workflow spends money.
Open **Settings**, name and describe it, switch **Enable** on, and **Save**. Only journeys completed from this moment on earn the bonus; partners who already finished are not paid retroactively, so handle that batch deliberately if you owe it.
## Verify it worked
Complete the journey for a test partner and switch the canvas header to **Runs**. The run reads **Completed** with every node **Ran**. On the partner's record, the commission line is there as pending with your description on it, ready for the next payout run; the certificate is issued to the recipients you chose and visible on their portal; the partner is in the activated segment, which means anything scoped to that segment has appeared in their portal; and the email is in their inbox.
## Related
Enroll the partner in the journey this workflow rewards.
The same kind of line, booked by hand.
Make the segment enrollment unlock the next stage.
Every reward action and its options.
# Test a workflow and read its runs
Source: https://docs.introw.io/features/automation/workflows/guides/test-a-workflow-and-read-its-runs
Rehearse a workflow against a real partner without changing anything, then read every run on the canvas to see which path it took and why it stopped where it did.
An automation you cannot see is an automation you cannot trust, and "why did nothing happen" is the hardest question to answer about one. Introw gives you two ways to look: a rehearsal that runs the canvas against a real partner without writing anything, and a run log that paints every real run back onto the same canvas. This guide covers both, including what a rehearsal genuinely proves and what it does not, and how to read every outcome a node can show.
## What you'll achieve
Confidence in a workflow before you enable it, and a reliable way to answer what it did afterwards: which partners it ran for, which path each run took, what each run changed, and where and why a run stopped short.
## Before you start
A blank canvas has nothing to rehearse, and the panel says so. See [Build your first workflow](./build-your-first-workflow).
Any real partner works, because nothing is written. If the workflow has steps that address the contact the trigger is about, pick one of their contacts too.
## Watch it
## Steps
### Rehearse it
Go to [Workflows](https://app.introw.io/workflows), open the workflow, and select the play button beside the trigger node. The **Test workflow** panel opens beside the canvas.
It rehearses the canvas **as it stands in the editor**, not as it was last saved. That is deliberate: the version worth testing is the one you are looking at, so you can try a change before committing it.
* **Partner** - the partner the rehearsal is about. Every run is about exactly one partner, so this is what the steps target.
* **Contact** - optional, and only used by steps that address "the contact this is about", such as an email to the trigger's contact, a certificate issued to them, or a task assigned to them. Leave it empty and those steps have no one to resolve to, which is itself useful to see.
The card in the middle of the panel states the mode and its four consequences. All four matter:
* **Delays resolve instantly.** A chain with three waits in it plays out in seconds, so you can see the whole arc without waiting a week.
* **The trigger's filter is not applied.** You chose the partner by hand, so the run starts at the first step regardless of whether that partner would have qualified. This is the one thing a rehearsal cannot check for you.
* **Nothing is written and nothing is sent.** No field is changed, no commission line is booked, no certificate is issued, no email or chat message leaves.
* **Conditions are evaluated against live data.** The forks tell you the truth about that partner right now, which is what makes the rehearsal worth doing at all.
**Run in live mode** is present and unavailable: every test is a dry run today. It is shown rather than hidden so you know it is not silently on.
Select **Run test**. The canvas updates as each step resolves, and the panel says when it is done.
Nodes the run executed are badged **Simulated** rather than **Ran**, in a different colour, so a rehearsal can never be mistaken for the real thing. Everything else reads exactly as it does for a live run, which is covered in the next phase.
Select **Run again** after an edit. Two identical rehearsals are two runs, not one, so you can iterate freely.
### Read the run log
Switch the header from **Build** to **Runs**. The canvas stays put and a run list opens beside it. Reading a workflow's history on the workflow itself is the point: a list of step names would make you rebuild the shape of the flow in your head.
Each row is one run: the partner it was about, when it started, a **Test** marker if it was a rehearsal, and a status. Rehearsals sit in the same log as live runs on purpose, because they are the same kind of evidence and hiding them would make "why did nothing happen" harder to answer.
The statuses are:
* **Completed** - the run finished.
* **Failed** - a step errored. The node carries the reason.
* **Running** - in progress.
* **Queued** - accepted, not started yet.
* **Waiting** - parked at a delay, which for a long chain is where most runs sit most of the time.
* **Needs approval** - held pending an approval.
* **Cancelled** - stopped before finishing.
An empty list on an enabled workflow means no matching event has arrived yet, which is usually a narrowing question rather than a fault: check the trigger's segments and event conditions.
Select a run and it is painted onto the canvas. Every node carries an outcome:
* **Ran** - the step executed and did what it was configured to do.
* **Simulated** - the same, in a rehearsal, with nothing written.
* **Waited** - a delay whose wait is over, and the run carried on past it.
* **Waiting** - a delay still counting down, or a step held for an approval.
* **Running** - still going.
* **Failed** - errored, with the message on the node.
* **Not taken** - the fork above went the other way, so this side was passed over. Drawn dimmed and dashed.
* **Not reached** - the run ended, or has not got this far yet. Drawn dimmed.
On a condition node, the outcome also tells you which side the run took, so a chain of forks reads as a path rather than as a set of statuses. A node that changed something records what it touched, so a run is evidence of the change and not only of the attempt.
Some steps cannot do their job for a specific partner and stop the run rather than failing it. Those nodes carry a plain-language note, and it is usually the whole answer:
* **No due date to wait for** - an anchored delay had no task or course due date to measure from. Normal for some partners rather than a mistake, because a due date is optional.
* **The due date is more than a year out** - the anchored instant was implausibly far away, usually a mis-imported date.
* **The partner has no mapped channel** - the chat step could not resolve the partner's shared Slack or Teams channel.
* **The partner has no champion with portal access** - an audience of "the partner champion" resolved to nobody.
* **The partner has no portal contacts** - an email audience resolved to nobody at all.
In each case, nothing after the node ran, and the nodes below read **Not reached**. That is the honest picture: the pre-deadline nudge did not go to everyone whose task has no deadline.
### Use the two together
Split the two questions and each becomes easy. A rehearsal answers "is the flow the one I drew, and do the steps resolve for a real partner". Only a live run answers "does the trigger fire for the partners I meant", because the rehearsal deliberately skips the trigger's filter.
So the sequence is: rehearse until the shape is right, enable, then read the first real runs to confirm the audience. If the run list stays empty, the narrowing is wrong, not the steps.
The workflows list carries a **Runs** column, so you can spot a workflow that has never fired and one that is firing far more than expected without opening either. Sort by it after a week of running.
No single partner starts more than ten runs of the same workflow in an hour. It exists to stop two automations triggering each other into a loop, and beyond the cap triggers for that partner and workflow are dropped.
If a busy partner's runs stop appearing, check whether one workflow writes a field another one triggers on. Changes a workflow makes itself never re-trigger that same workflow, but a cycle across two workflows is not something either of them can see.
## Verify it worked
You should be able to answer three questions about any workflow you own, without leaving its page: how many times it has run and for which partners, which path the most recent run took and what it changed, and if a run stopped early, which node stopped it and why. When a colleague asks whether the automation is working, the answer is a run on a canvas rather than an opinion.
## Related
Build something to rehearse.
A chain where most runs sit in Waiting, and reading the canvas matters.
Every trigger, action, condition, and delay option.
# Workflows
Source: https://docs.introw.io/features/automation/workflows/index
A no-code canvas where partner operations defines a program rule once and Introw enforces it for every partner, every time: pick a trigger, narrow it, add conditions and waits, and choose the actions.
> A workflow is a rule of your program that Introw enforces for you. It watches for something happening to a partner, checks whether it is the case you care about, waits if it should, and acts. You define it once by picking from a list, and it runs the same way for every partner, however many you have.
## The problem it solves
Most programs already know their rules. The cost is enforcing them by hand, for every partner, every time.
| Without Introw | With Introw |
| - | - |
| You enforce every rule by hand | Define it once, it runs every time |
| More partners means more partner managers | More partners, the same team |
| The result depends on who remembers | Same rule, same result, every partner |
| Chasing is a calendar of reminders | Nudges anchored to the due date |
| Rewarding a partner is a ticket | Booked the moment it is earned |
## Impact
A partner cannot tell whether your program is well run until something is late. Workflows keeps it from ever being late, at fifty partners or five thousand, with the same team.
for your business
* **Cost to run**
Define a rule once and it runs for every partner, so going from fifty partners to five hundred adds workflows, not partner managers
* **Live in days**
A first workflow is a trigger, an action, a rehearsal, and a switch, with no code and nothing to deploy, so it ships the same afternoon
* **AI, not admin**
AI names and describes the workflow from the canvas, and writes the email body of a send step in context
for your partners
* **Self-serve**
The tier, the experience, and the next journey are applied the moment they earn it, the same for every partner
* **Enabled**
A reminder three days before a task is due, on the channel they use, instead of a chase after it slipped
* **Efficient**
Their manager is pulled in only when a human is genuinely needed, so nothing sits in a queue
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - the program's rules defined once, run for all
* **Partner Managers** - escalation instead of chasing
* **VP Partnerships** - more partners without more headcount
* **Partners** - the right nudge at the right moment, every time
## See it work
* 
**Pick a trigger**
Something happening to a partner: a task, a course, a certificate, a segment.
* 
**Wait for the right moment**
A delay can hang off a due date, so 'three days before' is expressible.
* 
**Branch and act**
One workflow covers the partner who acted and the one who did not.
* 
**Rehearse, then switch on**
Test against one real partner without writing or sending anything.
## How it works
Every partner program runs on a handful of rules, and most of them are already written down. When a partner certifies, move them up a tier. When onboarding finishes, pay the sign-up bonus. When a task is about to be late, remind the partner, and if it goes late anyway, tell the partner manager. When a field changes on the partner's account in the CRM, put them on a different portal experience. The rules are not the problem. Enforcing them is. Each one has to be remembered and carried out by a person, for every partner, every time it applies. At twenty partners that is a checklist. At two hundred it is a job, and the usual answer is another partner manager.
Workflows turns each rule into something Introw does on its own, every time it applies. You start from a trigger. A task assigned or completed. A partner or contact created or updated. A form submitted, or a submission accepted, declined or returned. A journey or a course started or finished. A certificate earned. A deal or other CRM record linked to the partner changing. A partner entering or leaving a segment. You narrow it, so the workflow only runs for the partners and the events you actually mean. Then you lay out what happens. Write fields on the partner, move them to another portal experience, add them to a segment, or enroll them in a journey. Give them or your own team a task, issue a certificate, or book a commission line. Email their contacts, post a Slack or Teams nudge, or log a note on their CRM record. Every note, task, email and message can name the partner, the event and what the steps before it did, so it reads as if someone wrote it for that partner.
Between those actions you can wait and you can branch. A wait can be a plain pause, or it can be anchored to a due date. That is what makes "three days before it is due" and "two days after it was due" expressible at all. A branch splits the flow in two, so one workflow covers both the partner who did the thing and the partner who did not.
Nothing goes live by accident. A workflow saves as a draft, Introw tells you exactly what is still unfinished, you rehearse it against one real partner without writing anything, and only then do you switch it on. Every run afterwards is logged and painted back onto the same canvas, so you can see which path a partner took.
Because the rule is defined once, it is applied the same way to every partner. Same trigger, same conditions, same outcome, whether it fires once a month or two hundred times a day. No partner is tiered up late because their manager was on holiday, and no two partners get a different answer to the same situation. That consistency is what lets a program grow without the team growing with it. More partners means more runs, not more people.
Instead of a partner manager holding a checklist and a calendar of follow-ups, the program enforces itself. Introw acts on the moment worth acting on. The partner hears from you at the right time, on the right channel. The record is updated on both sides. And the manager is pulled in only when a human is genuinely needed.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
manual["A person enforces each rule, per partner"] --> late["Late, uneven, and one more hire"]
event["Something happens to a partner"] --> workflow["Workflow checks and waits"]
workflow --> acted["Partner nudged, updated, rewarded"]
acted --> scale["Same rule for every partner, same team"]
```
## Going deeper
Setup, configuration, and all how-to guides.
Endpoints and code.
**Works with**
Start with what already runs, and build a workflow only for what is left.
A segment decides which partners a workflow is for, and entering one can start it.
Finishing a journey starts a workflow, and a workflow puts the next partner on one.
Certify a partner the moment they finish a course, without anyone issuing it by hand.
Book a one-off reward that still goes through your normal approval and payout run.
Chase a task to its due date, and create one for your own team when it slips.
Start from a partner appearing or a field changing, and write fields back.
React to a CRM change, and write properties and notes back onto the record.
Send the messages only your own program needs, on your own timing.
# Workflows
Source: https://docs.introw.io/features/automation/workflows/technical/index
Build a workflow in Introw: pick one of the fifteen triggers, narrow it with segments, partner conditions and event conditions, add conditions and waits, choose the actions, rehearse it, and enable it.
## Where it lives
Workflows lives at [Workflows](https://app.introw.io/workflows).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Room under your active-workflow limit | Your plan caps how many workflows run at once; drafts never count | Switch another workflow off, or use the locked **Enable** in the workflow's **Settings** to upgrade |
| A role with Workflows access | Read shows it, write builds it | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Whatever the workflow reaches for | A picker cannot offer nothing | [Build a workflow](/features/automation/workflows/guides/build-your-first-workflow) |
| A connected CRM, for CRM triggers | Only for CRM-driven workflows | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
Not in your left-hand navigation under **Engage**? Your role does not have the **Workflows** permission; ask an admin to turn it on in your role.
## How it works
A workflow is one trigger followed by a chain of steps, drawn on a canvas. The trigger says what Introw watches for. Each step is either an **Action** (something done to the partner), a **Condition** (a Yes or No fork), or a **Delay** (a wait).
Every run is about exactly one partner. That is the single most useful thing to hold on to: whatever the trigger was, the run knows which partner it happened to, so every action targets that partner and every email goes to that partner's people. Some triggers also know which **contact**, which **task**, which **course enrolment**, or which **form submission** they were about, and a few steps only become available on those.
Narrowing happens in three independent blocks, and mixing them up is the usual reason a workflow never fires:
* **Which partners, by segment.** You pick segments, and any one of them matching is enough. Reach for this when the audience is one you already maintain, or want to reuse.
* **Which partners, by their own fields.** A condition builder over the partner's Introw and CRM properties, for the one-off answer a segment would be overkill for. "The tier changed, and it is now Gold" is this block.
* **Which events.** Conditions on the fields the triggering event itself carries: which journey, which task, which course, which form, which portal access state, when it happened.
The trigger's own narrowing is checked before a run exists, so partners and events outside it leave nothing behind. A condition step narrows a run that is already going, which is what lets one workflow handle both the partner who did the thing and the partner who did not.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
event["Something happens to a partner"] --> trigger["Trigger, narrowed by segments and event conditions"]
trigger --> steps["Actions, conditions, and delays"]
steps --> writes["Partner, portal, CRM, and messages"]
steps --> runs["Painted back onto the canvas under Runs"]
```
### What workflows reach
Workflows do not add a parallel system. Every trigger is an event a feature you already
configure emits, and every action is something you can do by hand on the same feature, which
is the whole reason a workflow needs no code: the vocabulary is the product's own. This is the
map, and each feature's own reference carries the same detail from its side.
| Feature | Triggers it fires | Actions that write to it |
| - | - | - |
| [Tasks](/features/partners/tasks) | Task assigned, Task completed | Give a task |
| [Journeys](/features/partners/journeys) | Enrolled in journey, Journey completed | Enroll in a journey |
| [Forms](/features/forms) | Form submitted, Submission status changed | |
| [Segments](/features/partners/segments) | Segment membership | Add to a segment |
| [Partner management](/features/partners/partner-management) | Partner created, Partner updated | Update partner properties |
| [Tiers](/features/partners/tiers) | | Update partner properties, on Partner tier |
| [Portal experiences](/features/portal/experiences) | | Update partner properties, on Experience |
| [Portal access](/features/portal/portal-access) | Partner contact added, Partner contact updated | Update partner contact properties |
| [Courses](/features/courses/enrollments) | Course started, Course completed | |
| [Certificates](/features/courses/certificates) | Certificate issued | Issue a certificate |
| [Commission lines](/features/commissions/commission-lines) | | Give commission |
| [Notifications](/features/engagement/notifications) | | Send an email |
| [Chat integrations](/features/integrations/chat) | | Send a chat message |
| [CRM integrations](/features/integrations/crm) | Partner updated, on any partner-level CRM property | Log a CRM note, Update partner properties |
One gap in that table is deliberate rather than missing. There is no enroll-in-a-course action,
because course auto-enrollment is decided by segments, so **Add to a segment** is the route.
## Settings & configuration
### Creating and finding workflows
**New workflow** on [Workflows](https://app.introw.io/workflows) creates a draft called **Untitled workflow** and opens the canvas straight away. The list is the usual overview table, filterable and sortable on **Name**, **Status** (Active or Draft), **Trigger**, **Steps**, **Runs**, **Owner** (whoever saved it last), and **Last updated**, so you can answer "what do we have running, and who touched it" without opening anything. Select rows to delete several at once.
The canvas header carries the workflow's name (editable in place), a **Build** and **Runs** switch, the Active or Draft status with a tooltip explaining why it is still a draft, **Settings**, and **Save**. The canvas does not save as you type: **Save** commits it.
Who sees what follows the **Workflows** permission on the person's role. Without it, **Workflows** is not in the navigation and the page sends them home. With read access only, they open every workflow and its runs, but the canvas, the name and the step panels are read-only and there is no **Test workflow**. Building, testing, enabling and deleting need write access.
### Triggers
A workflow has exactly one trigger, picked from four groups. Every trigger also carries the two-part filter described under [Narrowing](#narrowing-which-partners-and-which-events).
#### Tasks & journeys
**Task assigned** runs when a partner acquires a [task](/features/partners/tasks), which means when the task is created. Reassigning an existing task between people does not run it, so a nudge chain does not restart every time a manager tidies up. It is the trigger to start a deadline chase from, and the only one that offers a wait anchored to the task's due date.
**Task completed** runs when a task is marked done.
**Enrolled in journey** runs once when a partner is put on a [journey](/features/partners/journeys). **Which journeys count** narrows it; pick none and any journey qualifies. Adding a task to a journey a partner is already on does not run it again.
**Journey completed** runs when every task of a journey is done. **Which journeys count** narrows it the same way.
#### Forms
**Form submitted** runs once, when a partner submits a [form](/features/forms), such as a deal registration or a shared lead. **Which forms count** narrows it; pick none and any form qualifies. Accepting, declining or returning the submission later does not run it again. The forms you pick also decide which fields the steps can use: each one becomes its own group of [variables](#variables). Submissions that are not tied to a partner do not run it.
**Submission status changed** runs when a partner's existing submission moves to another status, typically when it is accepted, declined or returned. It narrows twice: **Which forms count**, the same list as on **Form submitted**, and **Which statuses count**, the status the submission moved to: **Pending review**, **Accepted**, **Auto-accepted**, **Declined**, **Returned to the partner**, or **Failed to process**. Pick none and any status change runs it. The status a submission lands with when the partner submits it does not run this trigger, so a deal registration that is accepted on arrival runs **Form submitted** only. Switching a workflow between the two form triggers keeps every form field already used in its steps.
#### Learning
**Course started** runs the first time a partner contact opens a [course](/features/courses/enrollments). Being enrolled without opening it does not run it. **Which courses count** narrows it.
**Course completed** runs when the last module is finished. Progress before that does not run it.
**Certificate issued** runs when a [certificate](/features/courses/certificates) is awarded to a partner contact. **Which certificates count** narrows it, and re-issuing the same certificate to the same contact does not run it again.
#### Partners
**Partner created** runs when a new [partner](/features/partners/partner-management) appears, whether added by hand or brought in by [CRM detection](/features/partners/partner-management/guides/detect-partners-from-your-crm).
**Partner updated** runs when a partner's field changes, in Introw or in your [CRM](/features/integrations/crm). **Which changes count** is a searchable list of **Partner tier**, **Partner phase**, **Partner categories**, **Partner owner**, and every partner-level CRM property on the company or your custom partner object. Pick none and any of them changing runs the workflow. Changes the workflow makes itself never re-trigger it.
**Partner contact added** runs when a contact appears on a partner's [portal](/features/portal/portal-access). **Which access states they arrive in** narrows it to **Invited, not signed in yet**, **Has portal access**, **Asked for access**, or **Access removed**.
**Partner contact updated** runs when an existing contact's portal access moves or one of their fields changes. It narrows on both the access state and **Which changes count**, which here lists **Portal access**, **Email address**, **First name**, **Last name**, **Job title**, **Language**, **Email deliverability**, and every CRM contact property. Portal visits and emails sent to the contact do not run it.
**CRM record updated** runs when a CRM record linked to the partner changes, such as a deal they sourced or a ticket on their account. **Which record counts** picks one record type, from the types your CRM integration attributes to partners; with no attribution mapping set up, the list is empty and says so. **Which changes count** then lists every CRM property on that record type. Pick none and any change runs the workflow, except a change where the only fields that moved are CRM bookkeeping (last modified, created or updated by, record source), because imports rewrite those without anyone editing the record. A record Introw sees for the first time, and a full CRM resync, cannot say which property moved, so they only run a workflow with no field picked. A sync that finds the record unchanged runs nothing.
**Segment membership** runs when a partner enters or leaves a [segment](/features/partners/segments): **The partner enters the segment** or **The partner leaves the segment**, then **Which segments count**. This is the most useful trigger on the canvas, because a dynamic segment re-evaluates itself against live partner, contact, and CRM data on a schedule. "Has not traded in 30 days", "crossed a revenue threshold", "is certified" are all this one trigger pointed at a different segment. Segments the workflow itself adds partners to never re-trigger it.
### Narrowing: which partners, and which events
Both the trigger panel and every condition step carry the same three blocks, in the same order.
**Segments** answers which partners, reusably. On the trigger it reads **Only for partners in**, on a condition just **Partners in**, and on the trigger it is checked before the workflow starts, so partners outside the chosen segments leave no run behind. Any one of the selected segments matching is enough. Leave it empty for every partner.
**Partner properties** answers which partners, one-off. It reads **Only for partners matching** on the trigger and **Partner matches** on a condition, and it is a condition builder over the partner's own fields: **Partner tier**, **Partner phase**, **Partner categories**, **Partner owner**, each partner team role, and every partner-level CRM property on the company or your custom partner object. Every field carries Introw's mark or your CRM's, so an Introw **Tier** and a CRM property also called Tier are distinguishable.
Use it for the check that would otherwise need a segment per value. On the trigger it is read as the event arrives, so "the tier changed, **and** it is now Gold" is one trigger rather than a trigger plus a maintained segment. On a condition it is read **when that step runs**, so after a ten-day delay a tier condition sees the tier the partner has now. The two blocks are ANDed: a partner has to be in one of the segments *and* match the conditions.
Contact and deal fields are deliberately absent from this block. A run acts on a partner, so those would offer filters the runner cannot answer; contact conditions belong in a segment.
**Event conditions** answers which events, over the fields that trigger carries. The block is labelled for the trigger (**Only for tasks matching**, **Only for certificates matching**, **Only for segments matching**), and the fields on offer change with it:
* Task triggers offer **Journey**, **Task**, and the timestamps (**Due date** and **Assigned at** on an assignment, **Completed at** on a completion). Picking a journey scopes the **Task** list to that journey's tasks.
* Journey triggers offer **Journey** and **Enrolled at** or **Completed at**.
* **Form submitted** reads **Only for submissions matching** and offers **Form** and **Submitted at**.
* **Submission status changed** reads **Only for changes matching** and offers **Form**, **Status**, **Previous status**, **Submitted at**, and **Status changed at**. **Previous status** is how you tell "accepted after being returned" apart from "accepted straight away".
* Course triggers offer **Course** plus **Started at** and **Completed at**.
* **Certificate issued** offers **Certificate**, **Issued at**, and **Expires at**.
* **Partner contact added** offers **Portal access**; **Partner contact updated** adds **Changed fields** and **Updated at**.
* **Segment membership** offers **Segment**.
* **CRM record updated** reads **Record matches** and offers every CRM property on the record type you picked, so "the deal is now in Closed won and over 50,000" is one condition on the record itself.
* **Partner created** and **Partner updated** offer nothing, so the block is not shown at all. Their event *is* the partner: which fields moved is already the trigger's **Which changes count** picker, and everything else worth asking is a question about the partner, which the partner-properties block answers directly.
Conditions use the usual builder: **is**, **is not**, **is any of**, **is none of**, **contains**, **is known**, **is not known**, and comparisons on numbers and dates. Date fields accept a fixed calendar date or a relative one (**Today**, **7 days ago**, **30 days from now**), which is what makes "due within the next week" a condition rather than a calculation. Rows in a group are ANDed and groups are ORed. Leave the block empty and every event of that kind qualifies.
Three fields answer about **right now** rather than about the moment the workflow started, and they are the ones that make a nudge chain honest: **Task status right now**, **Journey progress right now**, and **Course progress right now**. They are read from the current state when the condition is decided, so after a ten-day wait they tell you whether the partner has since done the thing. Every other field answers about the triggering event.
### Actions
Ten actions, in four groups on the picker.
#### Partner
**Update partner properties** writes values onto the partner, one row per property. Each row is a property, a value, and a **Write mode**: **Overwrite** always replaces what is there, **Fill in if not known** leaves an existing value alone. The write mode is the setting that decides whether an automation quietly undoes work a partner manager did by hand, so choose it deliberately. The properties on offer are **Partner tier** (from your [tier program](/features/partners/tiers)), **Partner phase**, **Partner categories**, **Partner owner**, the partner's **Experience** (from your [portal experiences](/features/portal/experiences)), and every writable CRM property on their company or custom partner object, each marked with Introw's logo or your CRM's so you can tell two same-named fields apart.
Setting the **Experience** is not an ordinary field write: it publishes that experience to the partner. Their portal is created if they have none, and its content, journeys, and goals are applied. A partner already in another experience is moved to this one. Because it can create a portal, it is subject to your plan's portal limit: partners who already have a portal still move, and partners without one are skipped until you free up or add portals. The **Experience** row has no write mode for that reason.
**Update partner contact properties** writes values onto the one contact the run is about, so it needs a trigger that names a contact: a contact added or updated, a course started or completed, or a certificate issued.
The workflow cannot be switched on until the trigger names one.
It offers two kinds of field: **Portal access** and every writable CRM contact property, with the same **Overwrite** and **Fill in if not known** write modes as the partner step.
**Portal access** takes **Active** or **Revoked** and has no write mode, because a contact always has an access state.
Setting it does exactly what the access switch on the partner's people page does, notification included.
Changes the workflow makes itself never re-trigger it.
**Add to a segment** enrolls the partner in a **static** [segment](/features/partners/segments). Only static segments are offered: a dynamic segment's members are whoever matches its audience, so an enrollment there would be undone at the next evaluation. The partner keeps every segment they are already in, and adding a partner twice does nothing.
#### Tasks & journeys
**Give a task** creates one portal [task](/features/partners/tasks), for the partner or for your own team. It is the same task detail a journey's tasks have: **Task name**, a **Due date** expressed as days after assigned (assignment being this step running, so the date is right for every run rather than only the first, and the task is due at the end of that day in the **Company timezone** set under [Company settings](https://app.introw.io/settings/company), or UTC when none is set), **Assignee**, **Visibility**, **Status**, an **Action** the partner must complete, a rich **Description**, and an attachment. On a trigger that names a contact, the assignee list also offers **The contact this is about**, resolved per run.
**Enroll in a journey** gives the partner the tasks of a [journey](/features/partners/journeys). It is the same operation as **Apply** on the partner page, so a partner already on that journey keeps their progress and only the steps they do not have yet are added.
#### Rewards
**Give commission** books a one-off [commission line](/features/commissions/commission-lines) for the partner: an **Amount**, a **Currency**, and a **Description**. A new step starts on your company currency. Clear the currency and the line is booked in each partner's own currency, resolved per partner when the run happens (the field reads **Empty uses the partner's currency**), so one workflow stays correct across a program that bills in several. This is the "500 for the referral" case, not a plan: it lands as a manual line, created as pending, so it still goes through your normal approval and payout run. Plans that earn lines from CRM or billing data live under [Commission plans](/features/commissions/commission-plans).
**Issue a certificate** awards a [certificate](/features/courses/certificates) to **The contact this is about** (only on a trigger that names one), **The partner champion**, or **All contacts of the partner**. Recipients are notified exactly as they are for a certificate issued by hand.
#### Messages
**Send an email** emails the partner's contacts, alongside the [notifications](/features/engagement/notifications) Introw already sends on its own. **Send to** offers **All contacts of the partner**, **The partner champion**, **Contacts in a segment** (which narrows this partner's contacts, not other partners), and two options that appear only on the triggers that can answer them: **The contact this is about** on a contact trigger, and **Whoever the task is assigned to** on a task trigger. The task assignee is read fresh when the email sends and can be one of your own team if the task is assigned internally. **Your partner team** is the one audience that is always internal: your own colleagues assigned to this partner, optionally narrowed by the partner team roles they hold, which is how a chain escalates to the partner manager. The body is written in the announcement editor, so variables and CTA buttons behave exactly as they do in an [announcement](/features/engagement/announcements), and it is stored with the step, so it cannot be edited or deleted from under a live workflow. The **Subject** is its own one-line field and takes variables too. A workflow email is an explicit send, so it goes out even when your organization has partner announcement emails switched off in its notification defaults; a contact who unsubscribed from announcements themselves still does not get it.
**Send a chat message** posts a short plain-text nudge to Slack or Microsoft Teams. **The partner's channel** posts to the shared channel mapped on the partner's page, resolved at send time so remapping a partner moves every workflow with it; **One fixed channel** posts every run into the same place. Type `{` in the message to insert a variable, such as the partner's name. Only connected and active providers are offered, and with one connected there is no provider choice to make. See [Chat integrations](/features/integrations/chat).
**Log a CRM note** writes a note on the partner's own [CRM](/features/integrations/crm) record, their company or your custom partner object. There is no record picker, because that is the one record every run can name. The note body takes variables too.
### Variables
Any text a step writes can carry values the run resolves: the task name and description on **Give a task**, the description on **Give commission**, the note on **Log a CRM note**, the subject and body on **Send an email**, and the message on **Send a chat message**. Type `{` where the value belongs and pick it from the list. It becomes a pill in the field, so you can see at a glance what is fixed text and what is filled in per run. Amounts, currencies and pickers take fixed values only.
The list has three sections:
* **Always available** - what every run has: **Organization** (name, domain, logo, time zone, country, currency and creation date) and **Date**, with **Today** and a **Relative date** such as 7 days from now or 2 hours ago, each in the format you pick: **Date**, **Date with weekday**, **Date with time**, **Date with weekday and time**, **Numeric date** or **ISO timestamp**. **Links** adds a link to drop into an email or chat message: the **Portal Link**, a **Collaboration Link** that opens the record on the run in the partner's room, a **Task Link** on a task trigger, and **Form Links** and **Course Links**, where you pick the form or course. On a form or course trigger, **Current form** and **Current course** point at the one the run is about.
* **From trigger** - what the event carries. **Partner** is always there: the Introw fields (name, domain, logo, manager email, created at, phase, tier and categories) and every CRM property on the partner's company or custom partner object. Each partner team role you have set up is its own group, with the name, email, phone, job title and LinkedIn URL of whoever holds that role on this partner. The trigger then adds its own group: **Task** on a task trigger, **Journey** on a journey trigger, the course, enrollment due date and learner on a course trigger, the certificate and the contact who earned it on **Certificate issued**, **Contact** on a contact trigger, **Segment** on **Segment membership**, and the record with all of its CRM properties on **CRM record updated**. On a form trigger it adds **Form submission** (the submitter, the form name, the status, when it was submitted, and the accept or decline message), followed by one group per form picked under **Which forms count**, named after the form and listing its fields. With no form picked there are no field groups, because no field is shared by every form. A step that uses a field from a form you later take off the trigger counts as a variable that is no longer available.
* **From actions** - what earlier steps on this path produced, one group per step, numbered when the same kind of step appears twice (**Send email 1**, **Send email 2**). **Give commission** hands on the line ID, amount, currency, description and a **Formatted amount**; **Log a CRM note** the **Note URL**; **Give a task** the task ID, name, assignee name and due date; **Send an email** when it was queued and sent and its subject; **Enroll in a journey** the journey name and how many tasks it created; **Issue a certificate** the certificate URL. Steps on the other side of a condition are not offered, because a run never passes through both.
Hovering a group in the list, or a pill already in a field, outlines the trigger or step it comes from on the canvas, so a long chain stays readable.
A pill can lose its source: the step it reads from is removed, or the trigger is changed to one that does not carry the value. The step holding it then carries a warning badge, **This step uses variables that are no longer available**, and **Not ready to enable yet** lists **Replace variables that are no longer available**. A workflow in that state cannot be enabled, and a live workflow cannot be saved in it. See [Personalize workflow steps with variables](/features/automation/workflows/guides/personalize-workflow-steps-with-variables).
### Conditions
A **Condition** step splits the flow: everything matching takes the **Yes** path, everything else takes **No**, and exactly one path runs. It uses the same two-block filter as the trigger, labelled **Partners in** and the trigger's own event-condition label, so you can branch on the partner's segments, on the event's fields, or on both.
There is no merge node by design: each side runs to its own end. A condition is therefore always the last step of the chain it sits in, and both paths can hold further steps, including further conditions. Adding a condition in the middle of an existing chain moves the steps that followed it onto the **Yes** path.
### Delays
A **Delay** pauses the run and then carries on down the same path. The pause survives restarts and deploys.
**Wait** chooses what the pause is measured from:
* **After the previous step** is a plain wait: an amount and a unit of **Minutes**, **Hours**, or **Days**.
* **Around the task's due date**, offered only on **Task assigned**, waits until an offset from that task's due date.
* **Around the course's due date**, offered only on **Course started**, does the same for a course enrolment's due date.
On an anchored wait the same two inputs stop meaning "how long to pause" and start meaning **How far from the due date**, and a third control appears: **Before due** or **After due**. Zero waits until the due date itself. This is the only way to express "three days before it is due", because that instant is not knowable when the workflow is written and moves when someone edits the date. The moment is read fresh each run, so moving a due date moves the wait.
Keep a plain delay, and the offset on an anchored one, at 180 days or less.
### Workflow settings
**Settings** in the canvas header holds the **Name**, the **Description** for whoever reads the workflow next, the **Enable** switch, and **Delete workflow**.
**Enabling is not retroactive.** Only partners who meet the trigger from the moment you switch it on enter the workflow. Nothing replays history.
### Active workflow limit
Every organisation has Workflows. Your plan caps how many workflows are **Active** at the same time; drafts never count, so you can build, test and save as many as you like. Only switching a draft on takes a slot. Saving or re-enabling a workflow that is already Active never does, and switching one off frees its slot straight away. Some plans have no cap at all. See [introw.io/pricing](https://introw.io/pricing) for what yours includes.
When every slot is in use, a draft's **Settings** shows a locked **Enable** button in place of the switch, and its tooltip says how many active workflows your plan runs. Switch another workflow off to make room, or select the locked **Enable** to book a call with Introw about upgrading. If another workflow takes the last slot while you have the dialog open, **Save** still saves the canvas, keeps the workflow as a draft, and tells you so with **Workflow saved as a draft**.
**Enable** is unavailable while the canvas is unfinished, and the dialog lists exactly what is missing under **Not ready to enable yet**: a trigger, at least one action, an unset value on a step, a variable the step can no longer resolve, or a pairing that cannot work, such as an email addressed to the contact the trigger is about on a trigger that does not name one. The same list is behind the **Draft** tooltip in the header.
**Generate with AI** writes the name and description from the canvas as it stands, even unsaved. There is a matching **Generate with AI** in the email editor that drafts a subject and body from where the step sits in the flow, greeting and sign-off added for you. Both leave the result in the form for you to edit before saving, and both need AI to be configured for your environment.
### Testing and run history
**Test workflow**, on the play button beside the trigger, rehearses the canvas as it stands against one partner you pick, and optionally one of their contacts. Every test is a dry run: delays resolve instantly, nothing is written and nothing is sent, conditions are evaluated against live data, and the trigger's own filter is not applied, because you chose the partner by hand. Nodes the run touched are badged **Simulated** on the canvas.
**Runs** in the header switches the canvas from building to reading. The panel lists every time the workflow fired, newest first, named by the partner it was about, with a **Test** marker on rehearsals and a status: **Completed**, **Failed**, **Running**, **Queued**, **Waiting**, **Needs approval**, or **Cancelled**. Picking a run paints it onto the canvas: each node reads **Ran**, **Failed**, **Running**, **Waited**, **Waiting**, **Not taken** (the fork went the other way), or **Not reached**, and a node that stopped the run short says why.
## How-to guides
* 
[**Build your first workflow**](/features/automation/workflows/guides/build-your-first-workflow)
Create a workflow that moves a partner up a tier the moment they earn a certification, from an empty canvas through a rehearsal to an enabled automation.
* 
[**Chase a task to its due date and escalate**](/features/automation/workflows/guides/chase-a-task-to-its-due-date)
Build a nudge chain that reminds a partner three days before a task is due, again two days after it slips, and hands it to the partner manager five days after.
* 
[**Onboard a new partner automatically**](/features/automation/workflows/guides/onboard-a-new-partner-automatically)
Put every new partner on the onboarding journey, welcome them, and chase the ones who stall, from the moment the partner appears from your CRM.
* 
[**Re-engage partners who go quiet**](/features/automation/workflows/guides/re-engage-quiet-partners)
Turn a dynamic segment into a trigger: nudge a partner the moment they go quiet, wait, check whether it worked, and hand the ones who stay quiet to their manager.
* 
[**React to a CRM change on a partner**](/features/automation/workflows/guides/react-to-a-crm-change-on-a-partner)
Trigger a workflow when a partner field changes in HubSpot or Salesforce, then move that partner onto a different portal experience, retag them, and log it back on the CRM record.
* 
[**Reward a partner for finishing a journey**](/features/automation/workflows/guides/reward-a-finished-journey)
Book a one-off commission bonus, issue a certificate, move the partner into the activated segment, and tell them, the moment they complete an onboarding journey.
* 
[**Personalize workflow steps with variables**](/features/automation/workflows/guides/personalize-workflow-steps-with-variables)
Write a CRM note, task, commission line, email or chat message that fills in the partner, the event and earlier steps per run, with variables you pick where each value belongs.
* 
[**Test a workflow and read its runs**](/features/automation/workflows/guides/test-a-workflow-and-read-its-runs)
Rehearse a workflow against a real partner without changing anything, then read every run on the canvas to see which path it took and why it stopped where it did.
## Troubleshooting
Enabling is not retroactive, so a workflow never acts on partners who already met its trigger. Partner and contact properties cannot be used as conditions anywhere on the canvas: filter partners with a segment instead, and a partner filter saved in the wrong block is refused when you save. A condition is always the last step of its chain, because there is no merge node. Delays cap at 180 days, and an anchored delay stops the run when the task or course has no due date set, which is the normal case for some partners rather than a mistake. No single partner starts more than ten runs of the same workflow in an hour; beyond that, triggers are dropped to stop automations looping into each other. Changing a workflow's trigger clears the event conditions written against the old one, because they belong to that trigger's fields; segments stay.
Check it is **Active**, not **Draft**, and remember enabling is not retroactive. Then check the two narrowing blocks on the trigger: a segment that no longer matches the partner, or an event condition on a field the event does not carry, both produce a workflow that looks configured and fires for nobody.
Open **Settings** and read **Not ready to enable yet**, or hover **Draft** in the header. It names the unfinished node.
Your plan's active workflows are all in use. Switch another workflow off, or select the locked **Enable** to upgrade. See [Active workflow limit](#active-workflow-limit).
The node says why. **No due date to wait for** means the task or course had none, so the anchored delay had nothing to wait on. **The partner has no mapped channel** means the chat step could not resolve the partner's shared channel. **The partner has no champion with portal access** and **The partner has no portal contacts** mean the audience resolved to nobody.
The condition above it went the other way. Open the condition node to see which path the run took.
Re-read **Send to**. **Whoever the task is assigned to** can resolve to your own team, and **Your partner team** always does.
The step's **Write mode** is **Overwrite**. Switch it to **Fill in if not known** so manual values are left alone.
A test does not apply the trigger's filter and writes nothing, so it proves the shape of the flow, not the audience. To check the audience, enable the workflow and read the first real runs.
The hourly run cap for that workflow and partner has been reached, usually because two workflows are triggering each other. Check whether one workflow writes a field the other triggers on.
# Add a manual commission line
Source: https://docs.introw.io/features/commissions/commission-lines/guides/add-a-manual-commission-line
Add a manual commission line to apply an adjustment, bonus, or one-off correction directly to a partner's payout without changing the plan.
Some payments do not fit any plan: a one-off correction, a goodwill bonus, a negotiated arrangement, or a true-up. Adding a manual commission line puts the right amount straight onto a partner's payout so the edge case is handled cleanly, without bending your plan rules or holding up the rest of the cycle. Reach for it when a partner is owed something the automatic calculation will never produce.
## What you'll achieve
A manual commission line on the partner's payout, with a clear amount and description, that pays out alongside their calculated lines and leaves an auditable record of why the adjustment was made.
## Before you start
You need write access to commissions.
The partner should have a payout in the current cycle to attach the line to. Create one first if needed.
## Steps
Go to [Payouts](https://app.introw.io/commission?section=payouts), open the relevant payout, and open the partner's payout panel. Their existing commission items are listed under **Commission items**.
Choose **Add commission** to open the manual line dialog, and fill in the details:
* **Name** - the label for the line that appears on the partner's payout and statement, for example "Q1 goodwill bonus" or "Renewal true-up". Make it self-explanatory.
* **Description** - optional context explaining the adjustment; use it to record why the line exists for the audit trail.
* **Commission** - the amount payable to the partner, in your organisation currency. This is what gets paid.
* **Source amount** - optional: the underlying deal or revenue amount the commission is based on, if the adjustment relates to one. Fill it in and the partner's statement prints the calculation, `EUR 4,200.00 x 10%`, instead of the amount alone. Leave it blank for a flat bonus or correction, which prints as a single figure.
Choose **Add commission item** to save. The line is attached to the partner's payout and is included in the payable total for the cycle.
## Verify it worked
The manual line appears under the partner's **Commission items** with your name, amount, and description, and the payout total reflects the adjustment. When the payout is paid, the partner sees the line on their statement in the portal alongside their calculated commission.
## Related
Check, decline, postpone, or correct calculated lines.
Pay out the adjusted total.
Full configuration options.
# Review and adjust commission lines
Source: https://docs.introw.io/features/commissions/commission-lines/guides/review-and-adjust-commission-lines
Review calculated commission line by line, then decline, postpone, restore, or correct amounts before any partner payout is generated.
Reviewing commission before money moves is how you catch duplicates, ineligible deals, and lines that are correct but not yet ready, so payouts go out right the first time. This guide takes you through reading the calculated lines, then every adjustment you can make: decline a line to void it, restore one declined in error, postpone a line that should wait, and correct a line's amount or description. Reach for it every cycle, before you create a payout.
## What you'll achieve
A reviewed, clean set of commission lines: the ones that should pay are approved and accurate, the ones that should not are voided with a recorded reason, and anything not ready is held for a later cycle. You finish confident that the next payout reflects exactly what each partner has earned.
## Before you start
You need write access to commissions.
Active commission plans with enrolled partners should already have generated lines for qualifying records.
## Watch it
## Steps
### Phase 1 - Review what was calculated
Go to [Commission](https://app.introw.io/commission). The dashboard shows the money in motion across a few cards: **Expected** (earned but not yet on a payout), **Upcoming payouts** (on approved or scheduled payouts, not yet paid), **Total paid**, and **Declined** (lines that were declined and can be restored). These give you the totals to reconcile against before paying.
Select a card, such as **Expected**, to open the list of commission lines behind it. Each line carries a status pill so you know where it sits: **Potential** and **Expected** are not yet on a payout, **Approved** is attached to a payout, **Postponed** is held back, and **Declined** is voided. Use this to focus your review on the lines that still need a decision.
Open a line to see its commission amount, the partner it belongs to, its status, and the source record it was calculated from. Trace anything that looks off back to its deal or billing record so you can decide whether it should pay, wait, or be voided. You can also open a partner's payout panel to review all of that partner's commission items together.
### Phase 2 - Adjust the lines
For a line that is wrong (a duplicate, an ineligible deal, or one already paid elsewhere), use **Decline** (**Decline commission** when you select lines from a card). Choose a reason so the decision is auditable:
* **Duplicate commission**, **Ineligible commission**, **Already paid**, **Disputed by partner**, or **Outside commission policy** for a canned reason, or
* **Custom**, which requires you to type the specific reason.
Declining voids the line and detaches it from any payout, so it will never be paid. Prefer declining over deleting, because a declined line keeps the record and can be restored.
If you declined something you should not have, open it from the **Declined** card and choose **Restore commission**, or choose **Restore** in the partner's payout panel. This un-voids the line and returns it to the flow so it can be approved and paid in a later payout. Restore is the correct fix rather than recreating the line by hand.
For a line that is correct but should wait (for example while a deal is still being confirmed), use **Postpone to next cycle**. This frees the line from the current payout without voiding it, holding it for later. When it is ready, choose **Unpostpone** to make it available to the next payout again.
When a line is right in principle but the amount or wording needs fixing, use **Edit commission** to adjust it:
* **Name** - the label that appears on the line and the partner's statement.
* **Description** - optional context for the adjustment.
* **Commission** - the amount payable to the partner, in your organisation currency.
* **Source amount** - the optional underlying deal or revenue amount the commission is based on; clear it if it no longer applies.
Editing is for genuine corrections; document why in the description so the change is traceable.
## Verify it worked
Each line shows the status you intended: lines to pay read **Approved** (or **Potential** / **Expected** until batched), voided lines read **Declined** with a recorded reason, and held lines read **Postponed**. The dashboard cards reconcile to those decisions, and the partner sees only the commission that should pay in their portal. Your next payout will pick up exactly the approved, unpostponed lines.
## Related
Add an adjustment a plan cannot calculate.
Turn the approved lines into paid payouts.
Fix at the source if lines are consistently wrong.
Full configuration options.
# Commission Lines
Source: https://docs.introw.io/features/commissions/commission-lines/index
See every calculated commission line by line - review amounts, decline, postpone, and adjust each entry before it turns into a partner payout.
> Commission Lines are the calculated detail behind every payout: each qualifying record becomes a line you can review, decline, postpone, or adjust, so what partners get paid is always correct.
## The problem it solves
Paying partners on un-reviewed calculations is how disputes and overpayments happen:
| Without Introw | With Introw |
| - | - |
| Calculations go straight to payment | Lines are reviewed first |
| A bad line slips through | Decline what should not pay |
| The timing is wrong for some | Postpone until it is ready |
| Adjustments are impossible | Add a manual line |
## Impact
One wrong payment costs more trust than ten right ones earn. A reviewable line between calculation and payment is how you stay the vendor whose numbers are never questioned.
for your business
* **Cost to run**
Partner ops sees every line before it becomes money, so a mistake is caught in review rather than clawed back
* **In your CRM**
Each line traces back to the CRM or billing record that created it, which is what makes it auditable
for your partners
* **Self-serve**
They see what is potential, what is expected and what is approved, line by line
* **Enabled**
The detail behind a payout is visible, so a disagreement is about one line and not the whole statement
* **Efficient**
An error is corrected with a manual line instead of a payout being reversed
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - every line checked first
* **Finance** - auditable, line-level detail
## How it works
A commission line is a single calculated commission tied to a qualifying record and a partner.
Introw generates lines automatically from your plans, and each line moves through clear states,
from potential to expected to approved, with its own payment status. Your team reviews these lines
before they become payouts, so errors and edge cases are caught early rather than after a partner
is paid.
You stay in control of every line. Decline a line that should not be paid, postpone one that is
not ready, restore a line that was declined in error, or add a manual line for an adjustment. The
same line data is available through the API, so finance systems can read and act on it
programmatically.
Commission Lines give you a reviewable layer between calculation and payment. Inspect each line,
decline or postpone the ones that need it, and adjust where necessary. Partners get paid the
right amount because every line was checked first.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
calculated["Calculated line"] --> review["Review, decline, adjust"]
review --> paid["Partner paid the right amount"]
```
## Run it from your AI assistant
* Show the commission lines generated for Acme this quarter and the deals behind them.
* What's earned-but-unpaid for Acme right now?
* Which deals drove the most commission this month across all partners?
* Break down this quarter's commission by partner.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Lines are produced by plan rules.
Approved lines batch into payouts.
Earned commission rolls into analytics.
Book a one-off reward automatically when a partner earns it.
# Commission Lines
Source: https://docs.introw.io/features/commissions/commission-lines/technical/index
Review commission line statuses, decline, postpone, or restore lines, and add manual commission entries for bonuses and adjustments in Introw.
## Where it lives
Commission Lines sits under **Commission**, at [Commission](https://app.introw.io/commission).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Write access to commissions | To adjust and approve lines | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A plan generating lines | Lines come from an enrolled plan | [Commission plans](/features/commissions/commission-plans/guides/build-and-launch-a-commission-plan) |
## How it works
Commission lines are generated automatically from your plans and surface through the commission
dashboard and partner payout panels. Each line has a workflow status that the dashboard labels as
potential, expected, approved, or declined, and a separate payment status once it is on a payout.
You review lines in the dashboard's metric views and on each partner's payout panel, where you can
act on them.
Line actions include declining a line so it is voided and detached, postponing a line to hold it
back from a payout, restoring a previously declined line, and adding a manual line for an
adjustment. The same operations are available through the commission lines API.
## Settings & configuration
Lines are reviewed from [Commission](https://app.introw.io/commission) and within partner payout
panels.
### Understanding line status
A line's workflow status reflects where it is: potential and expected lines are not yet approved,
approved lines are attached to a payout, and declined lines are voided. Payment status tracks the
money once a line is on a payout.
### Reviewing lines
Open a dashboard metric, such as potential or expected commission, to see the lines behind it, or
open a partner's payout panel to review their commission items. A metric's list filters on the
partner, their **Partner tier** and **Partner phase**, **Close date**, **Amount**, **Commission**,
**Commission plan**, **Attribution**, **Source** (Plan, Manual, Api, Workflow or Affiliate), **Is postponed**, and the **Affiliate
campaign**, **Workflow** or **Form** a line came from; the payout panel filters on **Close date**,
**Amount**, **Commission** and **Source**. From **Forecasted** or **Expected** you can select lines and
decline them in one go, and from **Expected** also create a payout for them.
Partners see the same lists in their portal without **Source**, **Affiliate campaign**, **Workflow** and **Form**: those filters describe how you run the program, so the portal does not offer them. **Is postponed** works with **is**, **is not**, **is known** and **is not known**.
The **Plan** column names the plan a line was earned on, followed by its installment, such as `(2/5)`,
when the plan pays in several. A line with no plan behind it, added by hand, through the API, by a
workflow or by an affiliate campaign, shows the rate its own figures work out to instead, such as
`10%`, or **Fixed amount** when its commission is not a share of anything; the info icon says where it
came from. It is the same rate the commission statement prints.
### Declining and restoring
Decline a line to void it and detach it from a payout. Restore a declined line if it was declined
in error.
### Postponing
Postpone a line to free it from the current payout and hold it for later; unpostpone to make it
available again.
### Manual lines
Add a manual commission line on a payout for an adjustment, or edit an existing line where needed.
### Imported lines
Lines from a **File upload** plan arrive pending like any other, and they carry where they came from:
the file, the worksheet, the row number and the row's own ID. That is what answers "which row is this
number" without going back to the sender. Review, decline, postpone and payout all behave the same.
See [Import commissions from a file](/features/commissions/commission-plans/guides/import-commissions-from-a-file).
### Automate it with a workflow
**Give commission** is the [workflow](/features/automation/workflows/technical) action that books a line without anyone raising a ticket: an **Amount**, a **Currency**, and a **Description** the partner reads on their statement. A new step starts on your company currency. Clear the currency and the line is booked in each partner's own currency, resolved per partner when the run happens (the field reads **Empty uses the partner's currency**), so one workflow stays correct across a program that bills in several. Lines it books are marked **Workflow** rather than **Manual**, so a review can tell an automation's output from a person's adjustment.
It lands as a normal manual line, created as pending, so it still goes through your usual approval and payout run: the automation removes the chasing, not the review. Plans that earn lines from CRM or billing data over time are a different tool, and live under [Commission plans](/features/commissions/commission-plans).
The triggers worth hanging it off are the ones that mark an achievement: **Journey completed**, **Certificate issued**, or a partner entering a segment. See [Reward a finished journey](/features/automation/workflows/guides/reward-a-finished-journey).
## How-to guides
* [**Add a manual commission line**](/features/commissions/commission-lines/guides/add-a-manual-commission-line)
Add a manual commission line to apply an adjustment, bonus, or one-off correction directly to a partner's payout without changing the plan.
* [**Review and adjust commission lines**](/features/commissions/commission-lines/guides/review-and-adjust-commission-lines)
Review calculated commission line by line, then decline, postpone, restore, or correct amounts before any partner payout is generated.
## Troubleshooting
Declining a line voids and detaches it, so restore it rather than recreating it if you change your mind. Postponing frees a line from its current payout, so remember to unpostpone it when it is ready. Manual lines bypass plan calculation, so use them for genuine adjustments and document why.
It is potential or expected, postponed, or declined.
It was restored, which un-voids it.
Confirm it was added to the right partner's payout.
# Build and launch a commission plan
Source: https://docs.introw.io/features/commissions/commission-plans/guides/build-and-launch-a-commission-plan
Build a commission plan end to end - configure the data source, eligibility, rewards, and enrolled partners, then launch it so partners start earning.
A commission plan only rewards partners once five things are in place: where the numbers come from, which records qualify, how much partners earn and how often, and who the plan applies to. This guide walks the whole wizard end to end so qualifying deals start generating commission for the right partners, reconciled to the records your sales and finance teams already trust. Reach for it whenever you launch a new incentive, a referral fee, a revenue share, or a tiered reseller margin.
## What you'll achieve
A live commission plan that reads from your CRM or billing system, filters to the deals you actually want to reward, pays a fixed fee or a percentage on the cadence you choose, and is enrolled to the right partners, so Introw calculates each partner's commission lines automatically and they can watch their earnings build in the portal.
## Before you start
You need write access to commission plans.
Connect the source the plan will read from: your CRM, or a billing integration like Stripe or Chargebee. The plan cannot calculate without one.
Decide which partners the plan applies to. If you want to target by segment or tier, set those up first so you can enroll and rate by them.
## Watch it
## Steps
The plan builder is a five-step wizard: **General**, **Data source**, **Conditions**, **Reward**, and **Enrollment**. Work through them in order; the **Continue** button moves you forward and you can jump back with **Back** or the step list on the left at any time.
### Phase 1 - Create the plan
Go to [Commission plans](https://app.introw.io/commission?section=plans) and choose **Create new plan**. You can start from a blank plan or pick one of the starter templates under **Or start from a template**:
* **Fixed Fee** - a one-time flat payout for each qualifying record, good for per-lead or per-deal bounties.
* **Revenue Share** - a one-time percentage of the closed deal value, the most common referral or co-sell reward.
* **Tiered** - a recurring yearly percentage that can step down over time (for example 15% in year one, 10% in year two), suited to reseller or subscription margins.
A template pre-fills the reward shape so you adjust rather than build from scratch; a blank plan starts you on a clean **General** step. Either way you land in the wizard and can change anything later.
On the **General** step, describe the plan and bound when it earns:
* **Plan name** - the internal name you and your team recognise the plan by (for example "Referral Plan 2026"). Required.
* **Description** - optional context on what the plan rewards and why; helpful when several plans run at once.
* **Plan period** - the **Start date** and end date that bound which events qualify. Events qualify from the start date onward (it defaults to the plan's creation date if you leave it), and events after the end date do not qualify. Leave the end open with **No end date** for an ongoing plan, or set one for a time-boxed promotion.
Choose **Continue** to move to the data source.
### Phase 2 - Connect the data source
On the **Data source** step, under **Select a data source**, choose the system the plan calculates from. Only connected sources are selectable; a disconnected one shows **Connect** (or **Upgrade plan** if your plan does not include it).
* **Your CRM** (shown as **HubSpot**, **Salesforce**, or **TeamLeader** depending on what you connected) - calculate commissions from deals and other records already in your pipeline. This is the right choice for almost every co-sell, referral, and reseller program because payouts then reconcile to the exact records sales and finance use.
* **Stripe** - pull billing data such as customers, subscriptions, and invoices directly from Stripe. Use this when commissions track recognised or billed revenue rather than a CRM deal.
* **Chargebee** - the same billing-based calculation sourced from Chargebee.
Pick the source that owns the number you want to reward on. The choice drives which objects and properties you can select next.
Tell the plan which records to read and how to time them:
* **Select object where the commission data is stored** - the record type the plan watches. For a CRM source this is typically your deal object; for a billing source it is the billing object (for example **Subscription**, **Invoice**, or **Customer**). Every qualifying record of this type can generate a commission line.
* **Commission date field** - the date Introw uses to decide when a commission event occurred, which determines the period a resulting line falls into. Pick the date that best represents "earned" for your program, such as the close date for deals or the billing date for invoices.
Open the **Data preview** (use **Show data** in the header if the panel is hidden) to sanity-check the source before you go further. It reports how many records would qualify over a baseline window you choose - **90 days**, **180 days**, or **1 year** - so you can confirm the volume looks right. Use **Configure** to pick which properties appear as columns in the preview table. If the count is zero or wildly off, revisit the object and date selections before adding conditions.
### Phase 3 - Decide which records qualify
On the **Conditions** step, narrow the source down to only the records that should earn. The step reads "A commission is earned when a record matches the following" and starts with no conditions, which means everything qualifies, so add filters to be deliberate.
* **Add condition** - add a property filter, such as deal stage is Closed Won or amount is greater than a threshold. Stack several and they combine with **And**, so a record must meet all of them.
* **Add 'OR' condition** - start a separate group that qualifies records meeting a different set of rules, letting you express "this set, or that set" eligibility.
Build the conditions that match your policy exactly. Re-check the **Data preview** count as you go; it updates to reflect only the records that now qualify.
### Phase 4 - Configure the reward
On the **Reward** step, set what a qualifying record pays and how often:
* **Reward type** - choose **Fixed fee** for a flat payout per qualifying event, or **Percentage** for a percentage of a CRM amount property. Fixed fee suits per-lead bounties; percentage suits revenue share and margin. A fixed fee is paid in your company currency, also on a deal in another currency.
* **Calculation property** - shown for **Percentage** rewards only: the amount property the percentage is applied to (for example the deal value). This is the base the rate multiplies.
* **Pay-out frequency** - choose **One time** for a single payout per record, or **Every month** or **Every year** for a recurring reward that pays across periods (useful for subscription or retainer commissions). A recurring frequency turns on the period schedule below.
* **Frequency periods** - for recurring rewards, define the **Start** and **End** months or years that the reward runs across, using **Add period** for additional bands. Leave the final period open with **Never ends** for an open-ended tail that keeps paying as long as the record qualifies.
Use the rates table to set how much partners earn, and whether everyone earns the same:
* **Type** - choose how rates are targeted: **Partner-based**, **Segment-based**, or **Tier-based**. Tier and segment targeting let you reward stronger partners or specific groups differently from the default.
* **Reward** rate - the amount or percentage for each row. The default row labelled **All** applies to every enrolled partner who is not matched by a more specific row.
* Add specific rows with **Add tier**, **Add segment**, or **Add partner** to override the default for those audiences. Partner-specific rates take precedence over tier and segment rates, so use them for genuine exceptions.
* **Maximum reward** - an optional cap per row that limits how much a single rate can pay; leave it **Unlimited** unless you need to bound exposure. Set it deliberately, as a low cap can quietly shrink payouts.
Together these rows let one plan pay a baseline to everyone and richer rates to your best partners or segments.
### Phase 5 - Enroll partners and launch
On the **Enrollment** step, choose who the plan applies to. A plan only generates commission for enrolled partners, so this step is what activates it.
* Select partners directly from the list with the checkboxes, or
* Apply filters such as **Phase**, **Tier**, **Experience**, or **Manager** to target a group, or pick a partner **segment** to enroll many at once and keep the audience aligned with that segment.
Enroll exactly the partners who should earn under this plan's rules and rates.
Choose **Create Plan** (or **Save** when editing) to launch it. The plan becomes active for the enrolled partners and Introw begins calculating commission lines for their qualifying records.
If you later edit a live plan, the **Update commission plan** dialog appears. When you changed **Starts on** or **Ends on**, it opens with a **Plan period has changed** notice that tells you to turn on **Recalculate expected commission** to recalculate all expected lines, including the ones outside the new period. Without it, lines that already exist stay as they are. By default already-earned expected commission stays as it is; turn on **Recalculate expected commission** and set the **Since** date if you want the change to reprocess pending lines from that point. Use this deliberately, since it recomputes amounts partners may already be expecting.
## Verify it worked
The plan shows as active in the plans list with the partners you enrolled. As qualifying records come in, commission lines appear on the commission dashboard and on each partner's payout panel, traceable back to their source record, and enrolled partners can see their building commission in the portal. If no lines appear, confirm enrolled partners have records that meet the conditions and that the data preview returned matching records.
## What your partners experience
Once the plan is live and you have added a commissions section to their experience, enrolled partners watch their earnings build in real time in the portal: each qualifying deal, the expected amount, and - once you run a payout - a statement they can open. This is what lets a partner self-serve "what am I earning, and when do I get paid?" without asking your team, so the work you do here shows up directly as trust on the partner side.
## Related
Check, decline, postpone, or correct the lines this plan generates.
Turn approved lines into paid partner payouts.
Enroll and rate partners by segment.
Full configuration options.
# Import commissions from a file
Source: https://docs.introw.io/features/commissions/commission-plans/guides/import-commissions-from-a-file
Set up a File upload commission plan, map a sample CSV or Excel export once, then import each period's file, resolve the rows on hold, and book the commission.
> For the revenue that arrives as a spreadsheet: distributor sell-through, marketplace statements, a usage export from billing.
Not every euro a partner earns passes through your CRM. Distributors report sell-through monthly, marketplaces settle on their own statement, and usage-based revenue often lives in a billing database nobody has connected. That money still has to be paid on the same rules as the rest of the program. A **File upload** plan is where it goes: you map the columns of one sample file, and from then on each period is an upload, a short review, and a set of commission lines that behave like every other line in Introw.
## What you'll achieve
A commission plan that reads files, a mapping saved on it so nobody re-does the column work, and this period's file imported into pending commission lines, each one traceable back to the row it came from.
## Before you start
You need permission to build plans and to run imports.
See [Internal roles](/features/access/team-management/guides/create-an-internal-role).
Rows match against partners that already exist. A row for a partner Introw does not know goes on hold, so import your partners first.
See [Partner management](/features/partners/partner-management/technical).
A CSV or `.xlsx` up to 50 MB, with the columns a normal period carries. Use a real export rather than a hand-made example: the mapping you build here is the one every future file has to fit.
## Steps
### Build the plan
Go to [Commission plans](https://app.introw.io/commission?section=plans) and create a plan. Name it for the file it will read, such as "Distributor sell-through", then on **Data source** choose **File upload**, described as "Import commission events from a CSV or Excel file".
A file plan skips two steps you know from CRM plans. There is no **Conditions** step, because the file is the filter: the rows you upload are the rows that earn. There is no **Enrollment** step either, because the plan's partners are whoever its rows match.
Upload your sample file. Introw reads it, shows the worksheet and header row it used, and lists the columns it found. Nothing is imported at this point: a sample only builds the mapping.
Map the columns that matter:
* **Partner** - the column that names the partner, plus **Select how to match**: **Introw partner ID**, **Partner external ID**, **Partner name**, **Partner domain**, or a CRM record through its record ID or one of its properties. Introw proposes a match field from the sample itself and shows how many sampled rows resolve, and to which partners, before you commit.
* **Amount** - the money the row is worth. Add a **Currency** column when the file mixes currencies.
* A date, so rows land in the right plan period.
* **Description**, which prints on the commission line and on the partner's statement.
* **Unique row ID** - the identifier your source system already gives each row.
On **Reward**, pick one of three, paid once per row:
* **Full amount** pays the amount in the row as provided. Use it when the file already carries the commission.
* **Percentage** takes a percentage of the row amount.
* **Fixed amount** pays a set reward per row, whatever the row is worth.
Rates target the default, a partner, a segment or a tier, in the same rates table as a CRM plan, and each row pays at the rate of the partner it matched: a rate for Gold partners only pays rows that matched a Gold partner. A maximum cap still applies. With **Full amount**, every rate pays 100% of the row and cannot be edited. Recurring frequencies and installments are not offered here, because an imported row is an event that already happened.
### Import a file
Go to [Imports](https://app.introw.io/commission?section=imports), start an import, and pick the file upload plan it belongs to. Introw uploads the file, reads it against the plan's mapping, and checks every row. It runs in the background, so you can leave the page and come back.
Rows arrive as **Ready**, **On hold** or **Conflict**, and every held row says why: no partner match, an ambiguous one, no rate that applies to that partner, a date outside the plan period, a currency that cannot be converted, or an amount too large to store.
Assign a partner to a held row, or skip it, one row at a time or over a selection. Skipped rows create nothing. **Needs attention** filters the list down to the imports that still have rows waiting on someone.
**Finish import** books the commission. You can finish with rows still unresolved, and the button says how many you are leaving behind, so it is a decision rather than an accident. Lines are created in the background, and no payment is sent by finishing an import.
## Verify it worked
The import reads **Import complete**, and its rows read **Imported**. The commission lines are on [Commission lines](https://app.introw.io/commission) as pending lines against the matched partners, ready for your normal review and the next payout run, and each one carries the file, the worksheet, the row number and the row ID it came from. Partners see their share in the portal as they do for any other line.
## Good to know
* **A wrong import can be corrected.** On a completed import, select imported rows and skip them: their unpaid commission lines are voided and their row IDs are freed, so the corrected file imports them again. Rows whose commission is already paid cannot be skipped.
* **A wrong file can be reverted in one step.** Choose **Revert** in the row menu on the **Imports** tab, or in the header of the import. The **Revert import** dialog lists each partner with their lines and commission before you confirm. Reverting voids every commission line the file created, skips every row still open, frees the row IDs so a corrected file can book the same rows again, and marks the import **Reverted**. The import stays in the list for the audit trail and cannot be discarded afterwards. When a later file corrected a row you had already booked, the revert follows the file that last set the line: reverting the first file leaves the corrected line alone, and reverting the second voids it.
* **Revert is all or nothing.** It is refused when any line from the file is already in a payout (the dialog says to decline those there first), when the import has not reached **Import complete**, and for a user whose role limits them to their own partners, because a revert voids every partner's lines in the file.
* **Re-uploading is safe.** With a **Unique row ID** mapped, a row that was already imported is skipped on the next file, and a row whose figures changed under an ID you already used is flagged for you rather than silently overwritten. Without one, Introw falls back to exact deduplication on the file name and row number.
* **Negative amounts are credits.** A clawback row reverses, so a correction file nets against what you already booked instead of needing a manual adjustment.
* **The mapping is the plan's, not the file's.** Editing it applies to future imports; imports that already ran keep the mapping and the rates they ran with.
* **Every import is kept.** A file that never created lines can be discarded; a completed one stays for the audit trail and for the duplicate check on the next file, and a reverted one stays too.
## Related
The CRM and billing version of the same wizard.
Review, adjust and approve what a plan produced.
Turn approved lines into money in partner accounts.
Data sources, rewards, versions and enrollment.
# Set eligibility conditions
Source: https://docs.introw.io/features/commissions/commission-plans/guides/set-eligibility-conditions
Define exactly which records earn on a commission plan using property filters, And/Or groups, partner-attributed deals, and a live data preview.
## What you'll achieve
A commission plan whose eligibility rules match your incentive policy precisely: only the records you intend generate commission lines, verified against a live count of qualifying records before the plan goes live, so partners earn on the right deals and finance has nothing to claw back.
## Before you start
Eligibility conditions are the **Conditions** step of the plan wizard. Create or edit a plan and reach that step. The full wizard is covered in [Build and launch a commission plan](/features/commissions/commission-plans/guides/build-and-launch-a-commission-plan).
Conditions filter the object you chose on the **Data source** step (a CRM deal, or a billing object like an invoice or subscription). The available properties come from that object, so set it first.
Write down, in plain language, which records should earn - for example "Closed Won deals over 5,000 in the New Business pipeline, sourced by the partner." You will translate that sentence into conditions.
## Watch it
## Steps
The Conditions step reads **"A commission is earned when a record matches the following."** It starts with **no conditions**, and no conditions means **every record of the object qualifies** - so an empty step pays on everything. Adding conditions narrows that set. Be deliberate: the goal is to add exactly enough rules that only the records your policy intends remain.
Choose **Add condition** and build a property filter: pick the property, the operator, and the value. Typical first conditions:
* **Deal stage is Closed Won** - only reward deals that actually closed. The most common condition on any plan.
* **Amount is greater than a threshold** - exclude small deals from a bounty, or set a floor for a revenue share.
* **Pipeline / deal type is a specific value** - scope the plan to the pipeline or deal type the incentive covers, so unrelated deals never earn.
Each condition compares one property to a value; the record must satisfy it to stay eligible.
Add more conditions in the same group to require **all** of them - they combine with **And**, so a record must meet every condition to qualify. Use this to express a precise policy, for example *stage is Closed Won* **and** *amount over 5,000* **and** *pipeline is New Business*. Add only the conditions your policy actually needs; every extra And narrows the set further.
When two different sets of records should both earn, choose **Add 'OR' condition** to start a separate group. A record qualifies if it matches **any** group, so you can express "this set, **or** that set" - for example *New Business deals over 5,000* **or** *Renewal deals over 10,000*. Keep each group internally combined with And, and use Or groups sparingly so the rule stays legible.
To make a plan pay only on deals a partner is actually credited on - the step that turns a generic plan into a referral or reseller reward - add a condition that filters on **partner attribution**. This uses the attribution you configured on the deal object, so only deals sourced or influenced by the enrolled partner earn, not every deal the partner merely touched. Layer your other qualifiers (amount, pipeline) on top of it. Attribution itself is set up in [Configure deal attribution](/features/co-selling/shared-pipelines/guides/configure-deal-attribution); using it as a reward filter is covered in [Set up referral rewards](/features/referrals/rewards/guides/set-up-referral-rewards).
Open the **Data preview** (use **Show data** in the header if it is hidden). It reports how many records qualify over a baseline window (**90 days**, **180 days**, or **1 year**) and updates as you edit conditions. Use it as your safety check:
* **Count is zero** - a condition is too strict or a value is wrong (a coded picklist value, a typo). Loosen or fix it.
* **Count looks too high** - a condition is missing or too broad; you are about to pay on records you did not intend. Add or tighten a condition.
* **Count looks right** - spot-check a couple of the previewed records to confirm they are genuinely records that should earn.
Only move on once the preview reflects exactly the records your policy describes.
## Verify it worked
The Conditions step shows your rules, and the data preview count matches the records you expect to reward. After the plan is live, commission lines appear only for records that meet these conditions - and each line traces back to a record that genuinely qualifies. If a line appears for a record that should not earn (or is missing for one that should), revisit the conditions and re-check the preview.
## Related
The full plan wizard this step is part of.
Use an attribution condition to pay only on sourced deals.
Set the partner attribution these conditions can filter on.
Check the lines your conditions generate before payout.
# Commission Plans
Source: https://docs.introw.io/features/commissions/commission-plans/index
Define how partners earn - revenue shares, fixed fees, tiered rates, and one-time bonuses - calculated automatically from your CRM or billing data.
> Commission Plans define exactly how partners earn, and Introw does the math: set the rules once and every qualifying deal turns into a calculated commission, straight from your CRM or billing source of truth.
## The problem it solves
Spreadsheet-run incentives are slow, opaque, and constantly disputed:
| Without Introw | With Introw |
| - | - |
| Commissions are calculated by hand | Introw calculates every line |
| Your rules are hard to express | Conditions, rates, tiers, bonuses |
| The numbers do not reconcile | Plans read your source of truth |
| Building a plan is daunting | Start from a template |
## Impact
Partners choose where to spend their week on expected return. A plan they can reason about, that pays without being chased, is how you win that comparison.
for your business
* **In your CRM**
A plan reads deals, subscriptions or invoices from HubSpot, Salesforce or your billing system directly
* **Live in days**
Pick a template, set the conditions and the reward, enroll partners: a plan is live the same afternoon
* **Cost to run**
Partner ops builds and versions plans, and a data preview shows what would qualify before anything is live
for your partners
* **Self-serve**
The rule they earn under is a rule, not a negotiation, so they can work out what a deal is worth
* **Enabled**
Tier-based and segment-based rates mean progressing in the program pays visibly more
* **Efficient**
Nothing to submit for a commission to exist: a qualifying deal creates the line
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - the plans partners earn under
* **Finance** - calculations that reconcile
* **Partners** - a rule they can count on
## See it work
* 
**Start from a template**
Fixed fee, revenue share or tiered, or from scratch.
* 
**Set what qualifies**
Stack conditions, and preview which records would match.
* 
**Choose the reward**
A fixed fee or a percentage, paid once or recurring.
* 
**Rate by audience**
One rate for everyone, or per tier, segment or partner.
## How it works
A commission plan is the rulebook for partner earnings. You choose the data source, set the
conditions that make a deal or record qualify, and define the reward: a revenue share, a fixed
fee, a tiered rate, or a one-time bonus that works like a SPIFF. You then enroll the partners the
plan applies to. From that point, Introw calculates commission lines automatically as qualifying
records appear in your CRM or billing system.
Templates get you started fast with common structures like fixed fee per lead, revenue share, or
tiered annual commission. Because plans read from your source of truth, the numbers reconcile to
the same records sales already trusts, ending the spreadsheet guesswork that makes partners doubt
their payouts.
Commission Plans turn incentive rules into automatic math. Define the source, conditions, and
reward, enroll partners, and let Introw calculate. The result is trustworthy, reconciled
commission data instead of a spreadsheet nobody believes.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
rules["Define source, conditions, reward"] --> enroll["Enroll partners"]
enroll --> calculate["Introw calculates"]
calculate --> lines["Commission lines"]
```
## Run it from your AI assistant
* Explain how Acme's commission plan pays out, including rate tiers and installments.
* Which commission plans are active, and what source object does each read from?
* What rate applies to a new-business resale deal versus a renewal?
* Which partners are on the referral plan versus the reseller plan?
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Plans generate the commission lines.
Pay partners for the deals they register.
Calculate on real billing revenue.
Power referral fees and revenue share.
# Commission Plans
Source: https://docs.introw.io/features/commissions/commission-plans/technical/index
Build commission plans in Introw with a chosen data source, eligibility conditions, tiered rewards, and the partners enrolled to earn on the plan.
## Where it lives
Commission Plans sits under **Commission**, at [Commission plans](https://app.introw.io/commission?section=plans).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Write access to commission plans | To build and launch one | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A connected data source | Your CRM, a billing integration, or a file you upload | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
Billing sources (Stripe, Chargebee) are connected separately, and the relevant module has to be on your plan.
## How it works
Commission plans are built in a wizard with five steps: general details, data source, conditions,
reward, and enrollment. The data source connects the plan to your CRM or a billing system, the
conditions decide which records qualify, and the reward defines how much partners earn and how
often. Once partners are enrolled, Introw calculates commission lines for qualifying records on a
schedule.
A plan can also read a file instead of a system. A **File upload** plan takes a CSV or Excel export,
matches each row to a partner, and books the commission it earns, which is how revenue that never
reaches your CRM still pays out on the same rules as everything else. See
[File upload plans](#file-upload-plans).
You can start from a template, such as a fixed fee, a revenue share, or a tiered commission, and
adjust it. Plans can be duplicated, archived, and edited, and editing can optionally recompute
pending lines.
## Settings & configuration
Plans are built at [Commission plans](https://app.introw.io/commission?section=plans); start a
new one at `/commission/plans/new`.
### General
Name the plan, describe it, and set its start and end dates.
### Data source
Choose where the plan reads from: your CRM, a billing system, or **File upload**. For a CRM source
you pick the object type and the amount and date properties; for billing you connect the relevant
integration; for a file you map the columns of a sample once and then import files against it. See
[File upload plans](#file-upload-plans).
### Conditions
Set the conditions a record must meet to qualify, using property filters, so only the right deals
or records generate commission.
### Reward
Choose a fixed fee or a percentage, set the frequency (one-time, monthly, quarterly, or yearly), and define
the rate, tiers, and any maximum cap. You can target rates by partner, segment, or tier, and set
installment amounts for recurring rewards. A fixed fee is always an amount in your company
currency, whatever currency the deal is in: it is not converted, and a negative fixed amount still
works as a one-time recoupment.
### Versions and duration
A plan is a chain of **versions**. Editing rates or conditions creates a new version, and every
commission line records the version it was priced on - so changing a plan never re-prices lines that
were already generated, and a deal keeps the terms that were in force when it was registered.
A version's **end date is optional**. Leave it empty and the plan runs open-ended; combine that with a
recurring plan and its frequency and the plan keeps generating lines for the life of the customer
rather than stopping on a fixed date.
### Enrollment
Enroll the partners the plan applies to, individually or via filters and segments.
### File upload plans
**File upload** reads commissionable rows out of a CSV or Excel file instead of a system. It is the
plan type for revenue Introw cannot see: a distributor's monthly sell-through report, a marketplace
statement, a usage export from your own billing database.
A file plan has three wizard steps rather than five. **Conditions** is gone, because the file is the
filter: the rows you upload are the rows that earn. **Enrollment** is gone too, because a file plan's
partners are whoever its rows match.
On **Data source**, upload a sample file (CSV or XLSX, up to 50 MB) and build the mapping the plan
keeps:
* **Worksheet** and the header row, for a workbook with more than one sheet.
* **Partner** - the column that names the partner, plus **Select how to match**: **Introw partner
ID**, **Partner external ID**, **Partner name**, **Partner domain**, or a CRM record through its
record ID or one of its properties. Introw proposes a match field from the sample and shows how
many of the sampled rows resolve, and to which partners, before you save anything.
* **Amount**, and optionally **Currency**, a date, a **Description** that lands on the commission
line, and a **Unique row ID**.
* **Unique row ID** is what makes a re-upload safe. With it, a row that was already imported is
skipped, and a row whose figures changed under an ID you already used is flagged rather than
silently overwritten. Without it, Introw falls back to exact row deduplication on the file name and
row number.
Inspecting a sample never creates commission lines. The mapping is saved on the plan and reused by
every import that runs against it, so the person uploading next month's file does not repeat this.
On **Reward**, a file plan pays one of three ways, one time per row: **Full amount** pays the amount
in the row as provided, **Percentage** takes a percentage of it, and **Fixed amount** pays a set
reward per row. Rates target the default, a partner, a segment or a tier exactly as on a CRM plan, in the
same rates table, and each imported row is paid at the rate that applies to the partner it matched. A
maximum cap still applies. With **Full amount**, every rate you add pays 100% of the row and cannot be
edited.
Recurring frequencies and installments are not offered, because a row is an event that already
happened.
Editing the mapping or the rates applies to future imports. Imports that already ran keep the mapping
and the reward rules they were run with, exactly as CRM plans keep their version.
### Importing a file
Imports live on their own tab, at [Imports](https://app.introw.io/commission?section=imports), with
**All imports** and **Needs attention** and a row per file: **File**, **Plan**, **Status**, **Rows**,
**On hold**, **Commission** and **Uploaded at**, all filterable and sortable.
Uploading runs in stages you can watch and leave: the file uploads, Introw reads it against the
plan's mapping, and every row is checked. Rows land as **Ready**, **On hold**, or **Conflict**, and
each held row says why: no partner match, an ambiguous one, no rate that applies to that partner, a
date outside the plan period, a currency that cannot be converted, or an amount the ledger cannot
store. Assign a partner to a held row, or skip it, one at a time or over a selection. Finishing with
rows still unresolved is allowed and the button says so, and skipped rows create nothing.
**Finish import** books the lines in the background. They are ordinary commission lines from there:
pending, visible on the partner, and carried into the next payout run. Each one keeps its provenance,
the file, the worksheet, the row number and the row ID, so a partner asking "where does this number
come from" is one click rather than an investigation. A negative amount is a credit and reverses, so
a clawback file nets against what you already booked.
An import that has not created lines yet can be discarded. A completed one stays for the audit trail
and for the duplicate check on the next file, and its imported rows can still be skipped: skipping
voids the unpaid commission lines they created and frees their row IDs, so a corrected file can be
uploaded in their place. A row whose commission is already paid cannot be skipped.
To undo a whole completed file, choose **Revert** in the import's row menu or header. The **Revert
import** dialog shows the partners, lines and commission it will void. A revert voids every line the
file created, with the reason "Reverted by user", skips every open row, frees the row IDs and sets
the import to **Reverted**, which stays listed and cannot be discarded. It is refused when any line
is already in a payout, when the import has not reached **Import complete**, or when your role limits you to your
own partners. When a later file replaced a booked row, the line belongs to the file that replaced it,
so reverting the earlier file leaves it booked.
## How-to guides
* 
[**Build and launch a commission plan**](/features/commissions/commission-plans/guides/build-and-launch-a-commission-plan)
Build a commission plan end to end - configure the data source, eligibility, rewards, and enrolled partners, then launch it so partners start earning.
* [**Import commissions from a file**](/features/commissions/commission-plans/guides/import-commissions-from-a-file)
Set up a File upload commission plan, map a sample CSV or Excel export once, then import each period's file, resolve the rows on hold, and book the commission.
* 
[**Set eligibility conditions**](/features/commissions/commission-plans/guides/set-eligibility-conditions)
Define exactly which records earn on a commission plan using property filters, And/Or groups, partner-attributed deals, and a live data preview.
## Troubleshooting
Billing data sources require the relevant integration to be connected and enabled. Editing a live plan can change future calculations, and recomputing pending lines reprocesses them, so review before saving. A maximum cap limits reward per rate, so set it deliberately to avoid unexpectedly small payouts.
No enrolled partners have qualifying records yet, or the conditions exclude them.
The billing integration is not connected or the module is off.
A maximum cap or tier targeting is limiting it.
# Commissions & SPIFFs
Source: https://docs.introw.io/features/commissions/index
Calculate, review, and pay partner incentives from your CRM or billing source of truth, with Introw Pay settling every partner from one consolidated invoice and partners watching their earnings in real time.
> Commissions & SPIFFs is how you reward partners without spreadsheets: define plans, let Introw calculate what each partner earns from your CRM or billing data, review the results, and pay everyone from one invoice through Introw Pay. Partners see their earnings any time.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Incentives run on a spreadsheet | Introw does the math |
| 500 payments keyed in by finance | One invoice, every partner paid |
| Identity and bank details chased by email | Partners verify themselves |
| Partners keep a mirror spreadsheet | They see the same numbers you do |
| A new SPIFF takes a quarter | A plan is live in a day |
## Impact
Nothing decides whether a partner keeps selling for you like being paid correctly and on time. A number they can check themselves, tracing back to a real deal and landing in their account without a chase, is what makes the program credible.
for your business
* **In your CRM**
Commission calculates from the CRM or billing records finance already trusts, with no export-and-recalculate step
* **Live in days**
Model a plan from a template and run the first payout in a day, so a new incentive is live while it still matters
* **Cost to run**
Partner ops builds plans and reviews batches; finance pays one consolidated invoice per cycle and Introw Pay does the rest
* **No new tool**
Finance that prefers its own stack pulls the same data as CSV or through the API, and status flows back
for your partners
* **Self-serve**
Forecasted, expected, upcoming and paid earnings are visible in the portal, or by asking an AI assistant
* **Enabled**
They see which deals earned what, so the plan is something they can sell against and never have to reconstruct
* **Efficient**
Verified once, paid in their own currency with a statement per payout, without writing an invoice
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - plans and payouts, no spreadsheet
* **Finance** - one invoice a cycle, lines that reconcile to source
* **VP Partnerships** - incentives partners believe
* **Partners** - what they earned, any time, paid without a chase
## How this area works
Partner incentives are usually run in fragile spreadsheets that nobody trusts, and then paid by hand. This area replaces both. You define commission plans, including revenue shares, fixed fees and one-time bonuses, and Introw calculates commission lines from your CRM or billing source of truth. On your cadence the lines become a payout batch, and Introw Pay settles the whole batch from one invoice to you. Revenue that never reaches those systems, a distributor's sell-through report or a marketplace statement, comes in as a file upload and earns on the same rules.
Incentives flow from a plan to a paid partner, reconciled to your source of truth and settled with a single payment.
**Where this sits in a setup.** Commissions come after attribution is right, since a plan pays on the deals attribution resolves. The [reseller](/tracks/reseller), [referral](/tracks/referral) and [affiliate](/tracks/affiliate) tracks each place it at that point.
* 
[**Commission Plans**](./commission-plans)
How partners earn: shares, fees, bonuses, recurring rewards.
[How to · 2 guides](./commission-plans/technical)
* 
[**Commission Lines**](./commission-lines)
Review, decline, postpone, and adjust calculated commission line items.
[How to · 2 guides](./commission-lines/technical)
* 
[**Payouts**](./payouts)
One payout per partner per period, with a statement, tracked to paid.
[How to · 3 guides](./payouts/technical)
* 
[**Introw Pay**](./introw-pay)
Pay every partner from one consolidated invoice; verification and tax handled.
[How to · 3 guides](./introw-pay/technical)
* [**Settings**](./settings)
Payout method, schedule, minimums, currency and billing details.
[How to · 1 guide](./settings/technical)
From there, your team reviews the calculated lines, and each partner's payout carries the statement behind it. Choose **Pay now** and Introw Pay issues one invoice to your company for the whole batch, verifies each partner and confirms their bank account, and sends every partner their money in their own currency. If your finance stack owns payments, keep manual invoicing instead: the same data leaves as CSV or through the API, and status flows back so the portal stays right. Partners see their forecasted, expected, upcoming and paid earnings in the portal and can ask an AI assistant about commission status, so the constant "where's my commission?" questions disappear. Global settings control the payout method, schedule, minimums, currency and billing details so the whole program runs predictably.
## Run it from your AI assistant
* What's our total earned-but-unpaid commission, and what's due to be paid next month?
* How much commission has Acme earned this quarter, and on which deals?
* Explain how Acme's commission plan pays out - rates, tiers, and installments.
* Show the most recent payouts across all partners and their stage.
* Which partners have the most pipeline commission at stake this quarter?
# Activate Introw Pay
Source: https://docs.introw.io/features/commissions/introw-pay/guides/activate-introw-pay
Switch partner payouts to Introw Pay: complete billing info, confirm your company currency, switch Introw Pay on with a schedule, and make sure partners can set themselves up from the portal.
Today a payout cycle ends with a spreadsheet: partner ops exports the earned commission, finance keys in a transfer per partner, and both sides reconcile afterwards. Introw Pay replaces that tail with one invoice. This guide makes the switch end to end. It covers the company details that print on statements and your invoice, the currency your invoice is issued in, the Introw Pay option in Payout Settings and its cadence, and the portal section partners use to set themselves up. Do it once, then every cycle is a review and one payment.
## What you'll achieve
Payouts run on Introw Pay. The Commission area shows a **Payments** tab, every batch offers **Pay now**, and statements carry your billing details. Partners with money waiting see a prompt in the portal to link a bank account and get verified. Finance pays one invoice per cycle and Introw Pay does the rest.
## Before you start
Introw Pay is included in every plan. Introw charges a percentage fee on the transactions it processes, so there is nothing extra on your subscription.
You need write access to commissions and admin access to company settings.
Have your legal company name, address, finance email address, company number and VAT number ready. They print on every partner statement and on your consolidated invoice.
## Watch it
## Steps
### Phase 1 - Complete the details your invoice depends on
Go to [Company settings](https://app.introw.io/settings/company) and check **Company currency**. Introw Pay invoices in **US dollars only** for now, paid by US bank transfer, also for a company in EUR. Your company currency has to be **EUR** or **USD**, and in any other currency **Pay now** stays disabled, so confirm this before switching the method. Each invoice line converts from the partner's payout currency. Partners are still paid in their own currency; this setting only governs how Introw reads your totals.
While you are here, confirm **Fiscal year start date** if you intend to pay every fiscal quarter, because that schedule is anchored on it.
Open the **Billing Info** tab, or go to [Billing info](https://app.introw.io/settings/company/billing-info), and fill in every field:
* **Company Name** - your legal entity, exactly as it should appear on statements and your invoice.
* **Address Line 1**, **Address Line 2**, **Postal Code**, **City** and **Country** - your billing address.
* **Finance Email Address** - where partners direct billing questions, and who is copied on payout emails.
* **Company Number** and **VAT Number** - your registration and tax numbers. Introw validates the VAT number when you save, so a rejected number is caught here rather than on an invoice.
Choose **Save**. Until billing info is complete, **Pay now**, **Request partner invoice** and statement generation are blocked with **Billing info required**.
### Phase 2 - Switch the payout method
Go to [Payout Settings](https://app.introw.io/commission?section=settings). Under **How will payments be sent to partner?**, select **Introw Pay**: you send a single payment to Introw, Introw Pay distributes it to all your partners, and verification is performed per partner. The other option, **Manual invoicing**, keeps Introw emailing statements while your team pays outside Introw and marks payouts paid.
Set **Payout schedule** to the rhythm you pay on:
* **Every month** or **Every quarter** - a batch is created on the first day after each calendar period closes, covering that period.
* **Every fiscal quarter** - the same, anchored on your fiscal year start.
* **Manual** - no automatic batches; you choose **Create payout** when you are ready, for example once a year.
A scheduled cadence is what removes the last manual step: the batch is waiting for you, and your only job is to review it and pay.
On any schedule other than **Manual**, **Minimum payout amount** is required and must be above zero:
* **Minimum payout amount** - balances below it roll forward to a later cycle instead of creating a tiny payout.
* **Per partner** applies the minimum to each partner's own balance. **Organisation total** applies it to the whole batch, so either everyone is paid or the cycle is skipped.
A per-partner minimum in the range of a typical small commission keeps the invoice free of trivial lines. Choose **Save** in the page header; the confirmation reads **Payout settings saved**.
### Phase 3 - Make sure partners can set themselves up
Partners set up how they get paid and follow their payouts from two sections of your partner portal. Open the [Experience builder](https://app.introw.io/templates), edit the experience your partners use, and add both from **Smart sections** if they are not there yet. **Commission** shows their **Forecasted**, **Expected**, **Upcoming payouts** and **Total paid** amounts, the list of payouts, and the **Choose payout method** prompt as soon as a payout is waiting for them. **Payout setup** walks them through **Business details**, **Payout method** and **Verification**, and shows the account they are paid to once they are verified. See [Choose what partners see in the Commissions section](/features/commissions/payouts/guides/choose-what-partners-see-in-the-commissions-section) for both sections and their columns.
Introw Pay pays each partner in the currency on their partner record. Open a partner and set **Currency** in the partner info card, or set it for many partners at once from the partner list. Partners without a currency are paid in your company currency. The field shows when [Multi-currency](/features/localization/multi-currency) is enabled on your plan.
## Verify it worked
The **Commission** area shows a **Payments** tab next to **Payouts**, **Commission Plans** and **Payout Settings**. Open any payout batch: the header offers **Pay now** instead of the **Manual Payout** pill, and each partner's payout carries a **Payment details** indicator that reads **Not connected** on hover until they set up. In the partner portal, a partner with a payable payout sees **Unlock** their amount **from** your company, with a **Choose payout method** button. Continue with [Pay a payout cycle with Introw Pay](./pay-partners-with-introw-pay).
## Related
Run the first cycle from batch to paid partners.
What partners do once, and how to nudge the ones who have not.
Schedule, minimum and billing info in full.
Every setting, status and failure state.
# Get partners ready to be paid
Source: https://docs.introw.io/features/commissions/introw-pay/guides/get-partners-ready-to-be-paid
What a partner does once to receive money through Introw Pay, the verification statuses you see on your side, and how to remind the partners who have not finished.
Collecting a partner's bank details and identity documents used to be an email thread per partner, and a folder somewhere that nobody wanted to own. With Introw Pay the partner does it themselves, once per vendor, inside your portal, and your team only ever sees a status. This guide walks the partner's side so you can explain it to them, then your side: the readiness statuses on every payout, the reminder that gets a partner unstuck, and the currency they are paid in.
## What you'll achieve
Every partner with money waiting knows exactly what to do, does it in a few minutes, and shows **Verified** on your side. Partners who have not finished are reminded automatically with a link straight to the step they left, and nobody on your team ever handles a bank detail.
## Before you start
**Introw Pay** is your payout method. See [Activate Introw Pay](./activate-introw-pay).
Your partner portal experience includes the **Payout setup** section, where partners set themselves up, and the **Commission** section, where they follow their payouts, and the partner's contacts have access to the portal. See [Choose what partners see in the Commissions section](/features/commissions/payouts/guides/choose-what-partners-see-in-the-commissions-section).
Payout reminders go to the partner champion. Set one on the partner record if it is empty, or the reminder cannot be sent. If the tab holding **Payout setup** is limited to segments, the champion has to be in one of them. Introw checks both before it emails anyone, as described under **Fix what blocks the reminder** below.
## Watch it
## Steps
### Phase 1 - What the partner does, once
The **Payout setup** section shows the partner a **Getting paid** card with the three steps, **Business details**, **Payout method** and **Verification**, each marked **To do**, **In progress** or **Done**, and a **Choose payout method** button, or **Continue setup** when they stopped halfway. When money is waiting, the card leads with it: **Unlock** the amount **from** your company. **Learn more** opens **How payouts work**, which walks the same steps, compares the payout methods their country allows on cost and speed, and says that your team never sees their bank details.
As soon as a payout is payable, the **Commission** section of your portal shows the partner a banner: **Unlock** the amount **from** your company, with the note that this is a one-time setup, usually a few minutes. The button reads **Choose payout method**, or **Continue setup** when they stopped halfway. The same prompt appears when they open the payout and in the payout list's empty state, so they cannot miss it. Until then the section already shows their **Forecasted**, **Expected**, **Upcoming payouts** and **Total paid** amounts and every payout with its status.
**Choose payout method** opens a two-step dialog. Step 1, **Your business details**, asks for the **Legal business name**, **Country**, a **VAT number** or a **Company number** (one of the two is enough), the address (**Street and number**, **Postal code**, **City**) and a **Finance email**. The fields are prefilled from what you have on the partner where Introw has it. This is the legal entity the money goes to, and the **Country** decides which payout methods they can pick, so it is worth telling partners to check both. Each rule that fails says in plain words what to enter. They choose **Continue**, which saves the details. A partner who already has every detail on file skips straight to step 2.
Step 2, **Choose how to get paid**, shows the payout methods side by side, with a **Not available in** their country pill on any method their country does not support. Then they tick that they accept the Introw partner payout terms, which Introw records with the country they chose.
* **Bank transfer via Stripe** carries a **Recommended** pill. It arrives in two to five business days and needs identity verification. The button reads **Continue to Stripe**. Stripe asks the partner to confirm the address, VAT number and company number they just gave, instead of asking again.
* **PayPal** shows greyed out with a **Coming soon** pill and cannot be chosen yet.
Bank transfer is offered in 119 countries, listed under [Countries partners can be paid in](/features/commissions/introw-pay/technical#countries-partners-can-be-paid-in). When no method covers their country, the dialog says so and tells them their approved payout stays waiting, so you and the partner can agree on another way to pay.
Introw Pay verifies the identity of the person setting up, and the business details and ownership where the country requires them. It confirms the bank account the money should land in. Verification can take up to seven days; most partners are approved much faster. None of these details are stored in Introw or visible to your team. They are returned to your portal when they are done.
Back in the portal, the partner's **Payment details** row on their payout reads **Verification in progress** and then **Verified**. If something is still missing the row reads **More information needed** with a **Continue setup** button that resumes exactly where they left off. A partner who started setup before business details were collected opens the business details page first, and **Continue to Stripe** there saves them and resumes the same Stripe onboarding. From then on they can **Change bank details** at any time from the same row, and every future payout from you is paid without another step. In the **Payout setup** section the card now reads **Verified**, shows the account they are paid to and when each step was finished, and lists the payouts **Paid to this account**. It has no menu once verified, and shows **Change payout method** only in a country that offers more than one method, which is no country today. If their payout provider puts payouts on hold or the account is unlinked, the card says only they can resolve it, keeps their approved commission waiting, and offers the button that fixes it.
### Phase 2 - What you see and do
Go to [Payouts](https://app.introw.io/commission?section=payouts), open a batch, and open a partner's payout. When the payout is ready to pay and the partner has not set up payouts, it opens with a banner that says so, **UnitedHealth Group hasn't set up payouts** (or **hasn't finished payout setup** once they started), and a **Remind partner** button. Introw checks first that the reminder can work, and swaps the banner when it cannot (see the next step). Otherwise the **Payment details** row shows their readiness as a status indicator, with the state and what resolves it in its tooltip. The batch table can be filtered on **Introw Pay Ready** either way:
* **Not connected** - they have not chosen a payout method. Remind them.
* **Incomplete** - they started a bank transfer setup, but verification details or a usable bank account are still missing. Remind them; the link resumes their setup.
* **Verified** - Introw Pay can pay them. Nothing to do.
* **Restricted** - payouts to their bank account are on hold until they provide more details. Remind them.
* **Deauthorized** - their payout method is no longer linked. Remind them; they choose **Reconnect payout method**.
A partner who is not **Verified** is never blocked from seeing their earnings; they are only left out of a payment run until they are.
A reminder only helps when the partner can act on it, so Introw checks the partner's portal before it offers **Remind partner**. The first check that fails replaces the banner:
* ** can't collect this payment** - the partner has no portal experience, or the experience has no **Payout setup** section. Choose **Link experience** or **Add payout setup**. **Add payout setup** opens the experience builder on the tab that holds the **Commission** section, with the section picker open on **Smart sections** and **Payout setup** highlighted. Publish, then use the **Back to** strip at the top of the builder to return to the payout, where **Remind partner** is available.
* ** can't open payout setup** - the **Payout setup** tab is limited to segments the champion is not in. Choose **Manage tab access** to open that tab's access, or **Change champion** to pick someone who can open it.
* **No champion** keeps the usual banner, but the reminder is skipped because there is nobody to email. Set a champion on the partner record.
The checks run again when you come back to the page, so the banner clears itself once the fix is published.
Select one or more partners and choose **Remind to set up payouts** (or **Remind partners to set up payouts**), then **Send reminder**. The dialog shows a **Lands on** row with the tab the partner will open. Each partner champion gets an email with a **Set up payouts** link that opens that tab with the setup dialog already open (or **Continue setup** where they started), and your partner owner as the contact for questions. To avoid noise, a reminder goes out at most once per payout recipient per day; partners already **Verified** are skipped. A bulk reminder also skips partners whose portal fails the checks above, says how many it will skip before you send, and reports the count afterwards. A contact who opens the link but cannot open that tab sees a page that says they do not have access and names the partner owner to ask. You can also send it from the **Pending payout setup** group in the **Pay commissions** dialog, so a reminder never delays paying the partners who are ready.
Introw Pay pays each partner in the currency on their partner record. Open the partner and set **Currency** in the partner info card, or set it for many at once from the partner list; the field shows when [Multi-currency](/features/localization/multi-currency) is on your plan. Their statement and the payout email use that currency too. A partner without one is paid in your company currency.
## Verify it worked
The partner's **Payment details** indicator reads **Verified** on your side and in their portal, the **Introw Pay Ready** filter includes them, and they no longer appear under **Pending payout setup** when you choose **Pay now**. On the next run they are paid without any action from you or them, and they receive the payout email with the statement in their currency.
## Related
Pay the ready partners, hold the rest for next time.
The one-time switch, including the Commissions section partners need.
Show and pay partners in their own currency.
Every status and what resolves it.
# Pay a payout cycle with Introw Pay
Source: https://docs.introw.io/features/commissions/introw-pay/guides/pay-partners-with-introw-pay
Take a payout batch from review to paid partners with one invoice: check the batch, choose Pay now, pay the consolidated invoice, and watch Introw Pay send every partner their share.
This is the cycle Introw Pay was built to shorten. A batch is waiting, one payout per partner, with the earned lines and a statement behind each. You review it, choose **Pay now**, and pay one invoice. Introw Pay sends every partner their money in their own currency, moves each payout to **Paid**, and emails them. This guide runs that job end to end, including the partners who are not ready yet and the rare payment that bounces, so you finish every cycle with a clean batch and a matching record on the **Payments** tab.
## What you'll achieve
A payout batch settled with a single payment. Every ready partner is paid in their own currency, and every payout sits at **Paid** with a statement the partner can download. Partners who were not ready are reminded and held for the next run. The invoice and each partner payment are visible on the **Payments** tab for finance.
## Before you start
**Introw Pay** is your payout method and billing info is complete. See [Activate Introw Pay](./activate-introw-pay).
You need write access to commissions to choose **Pay now**.
On a scheduled cadence the batch is created for you when the period closes. On a manual schedule, choose **Create payout** on the Payouts list and select the period; see [Run a payout cycle](/features/commissions/payouts/guides/run-a-payout-cycle) for the batch itself.
## Watch it
## Steps
### Phase 1 - Review the batch
Go to [Payouts](https://app.introw.io/commission?section=payouts) and open the batch for the period you are paying. The **Payout details** page lists one row per partner with **Amount**, **Commission**, **Status**, **Last modified** and **Invoice**. Use the **All**, **Pending**, **Paid** and **Declined** tabs to see what is still open.
Open a partner's payout to see the lines behind it. **Decline** a line with a reason, such as **Duplicate commission** or **Disputed by partner**, to void it; **Postpone to next cycle** to hold a valid line back without voiding it; **Restore** anything declined in error. A partner whose lines are all declined drops to **Declined** and is left out of the run. Whole payouts can be declined or postponed the same way from the row actions.
Filter the table on **Introw Pay Ready** to see which partners Introw Pay can pay. Open the payout of a partner who is not ready and it shows what blocks it. If the partner can set up payouts in your portal, the panel offers **Remind partner**. If their portal has no **Payout setup** section, or their champion cannot open its tab, a banner says so and links to the fix (**Add payout setup**, or **Manage tab access** and **Change champion**), because a reminder would lead nowhere. A partner who is set up reads **Verified** in the **Payment details** row and can be paid. Anyone **Not connected**, **Incomplete**, **Restricted** or **Deauthorized** cannot receive money yet. Select them and choose **Remind partners to set up payouts**, then **Send reminders**: each partner champion gets a **Set up payouts** email, at most once per payout per day. See [Get partners ready to be paid](./get-partners-ready-to-be-paid) for what they do next.
### Phase 2 - Pay the batch
Choose **Pay now** in the batch header to pay every ready partner, or select partners and use the bulk **Pay now** action to pay a subset. The **Pay commissions** dialog shows exactly what is about to happen:
* **Total commission** - the sum of the ready partners' payouts, in your company currency.
* **Introw Platform fee** - the fee your arrangement bills to you, if any. When your arrangement deducts the fee from partners instead, this line is zero and partners receive the commission net of it.
* **Total due** - what your invoice will say.
* **Pending payout setup** - partners who are not **Verified**. They are left out of this invoice and stay in the batch. Nudge them from here; the dialog previews the reminder email.
If nobody in the batch is verified yet, the dialog holds the whole amount under **Pending payout setup**, notes that no funds will be collected yet, and offers **Nudge N partners** or **Postpone and nudge N partners** instead of a payment.
Confirm with **Pay** the amount **now**. Introw Pay locks the lines it covers and issues one invoice to your company, with one line per partner.
The header now reads **Waiting for payment**, and **View and pay invoice** opens your invoice. Pay it by US bank transfer from your own bank, as you would any supplier invoice. The invoice is in US dollars, also for a company in EUR, while the **Pay commissions** dialog shows totals in your company currency, so the invoice total can differ from **Total due** by the exchange rate. On the **Payments** tab it appears as a **Customer Collection** at **Open** until the funds arrive. If you need to stop the run before paying, choose **Void invoice** in the dialog; the lines are released back into the batch and nothing is owed.
### Phase 3 - Let Introw Pay settle it
When your payment lands, the header switches to **Processing**. Introw Pay creates one payment per partner, in the partner's currency, and each payout moves from **Pending payment** through **Scheduled** to **Paid** on its own. On the **Payments** tab your collection reads **Completed** and each **Partner Disbursement** moves from **Processing** to **Completed**. Every partner gets an email that the money is on its way, naming the masked bank account it went to, with the statement regenerated in their currency.
If a partner's bank rejects the payment, the header reads **Action required** and that payout shows **Blocked** or **Failed** with the reason, most often bank details that need updating. The partner corrects them from the **Payment details** row in the portal; then you choose **Retry transfer** (or **Retry transfers**) on the batch. Nothing else in the batch is held up by one partner. If the invoice was only partially paid, every payout on it stays blocked until finance settles the remainder.
## Verify it worked
The batch moves into the **Paid** tab on the Payouts list and **Total paid** on the commission dashboard reflects the run. Each partner's payout reads **Paid** with a **Commission Statement** they can download from the portal, and they have received the payout email. On the **Payments** tab, the **Customer Collection** for the run and every **Partner Disbursement** read **Completed**, which is the record finance reconciles against your one bank transfer.
## Related
What partners do once, and how to nudge the ones who have not.
Creating the batch, and the stages a payout moves through.
Export the run, or read it through the API.
Every setting, status and failure state.
# Introw Pay
Source: https://docs.introw.io/features/commissions/introw-pay/index
Pay every partner from one consolidated invoice. Introw Pay verifies each partner, confirms their bank account, and sends the money, so finance settles one payment per cycle instead of hundreds.
> Introw Pay is the payment engine behind commissions. At the end of the month, quarter or year you pay one consolidated invoice, and Introw Pay verifies each partner, confirms their bank account, and sends every partner their money in their own currency.
## The problem it solves
Paying partners is where a commission program turns into headcount. The math is done, and then somebody spends the week moving money:
| Without Introw | With Introw |
| - | - |
| 500 partner payments, one by one | One invoice, every partner paid |
| A spreadsheet goes to finance each cycle | Finance pays once and is done |
| Identity and bank details chased by email | Partners verify themselves |
| Partners keep a mirror spreadsheet | They see the same numbers you do |
| Nobody knows when the money lands | A status and a statement per payout |
## Impact
Partners keep selling for the vendor who pays correctly, on time, without making them chase. Introw Pay makes that the default, whether you have five partners or five hundred.
for your business
* **Cost to run**
One consolidated invoice per cycle replaces hundreds of transfers, a spreadsheet handed to finance, and the reconciliation that followed it
* **Trustworthy**
Every amount on the invoice traces to a partner, a statement and the lines behind it, so finance and partners reconcile to one record
* **Enterprise**
Identity checks and bank verification run per partner inside Introw Pay, with nothing for your team to collect or store
for your partners
* **Self-serve**
Forecasted, expected, upcoming and paid earnings sit in the portal, with a statement per payout and a status on each
* **Enabled**
They verify once, link a bank account, and every future payout from you lands without an invoice or a follow-up email
* **Efficient**
Paid in their own currency, with a statement that matches their books, so the mirror spreadsheet is retired
[A day in the life of your partners](/days-in-the-life)
* **Finance** - one invoice per cycle, not hundreds of transfers
* **Partner Operations** - no spreadsheet handed over each month
* **VP Partnerships / Chief Partner Officer** - partners paid on time, every time
* **Partners** - see it, verify once, get paid
## See it work
* 
**Pay every ready partner at once**
One Pay now, one invoice. Partners not set up yet stay in the batch and get nudged.
* 
**See who can be paid**
Each payout carries the partner's verification status, so finance never asks.
* 
**Reconcile on one tab**
Your invoice in, each partner payment out, on the Payments tab.
## How it works
Commission plans calculate what each partner earned from your CRM or billing data. On the cadence you choose, every month, every quarter or every fiscal quarter, or whenever you decide, Introw groups the earned lines into a payout batch: one payout per partner, with the statement behind it. You review the batch, hold back or decline what should not pay, and choose **Pay now**. Introw Pay turns the whole batch into one invoice to your company, with one line per partner. You pay that invoice once, in US dollars by US bank transfer, also when your company currency is EUR. Introw Pay then sends each partner their share, in their own currency, and marks every payout paid.
Partners set themselves up once per vendor. The first time you have money waiting for them, the portal shows the amount and asks them to link a bank account. Introw Pay verifies their identity and business and confirms the bank account. From then on partners see every payout, its status and a downloadable statement in the portal, and they get an email the moment the money is sent. The mirror spreadsheet a partner used to keep to check your numbers has nothing left to check.
There is nothing for you to connect. Introw Pay is not the Stripe integration under [Billing & Subscriptions](/features/integrations/billing): that one only reads your invoices so commission plans can calculate on real revenue, and it moves no money at all. Introw Pay is the other side, the payment itself, and it is Introw's own product end to end, from the invoice you pay to the statement your partner downloads. You complete your billing info, choose Introw Pay, and pay one invoice a cycle. Your partners link a payout destination once, and neither of you needs a Stripe account for any of it.
Introw Pay is included in every plan, and Introw charges a percentage fee on the transactions it processes. It is one of two ways to settle. If your finance stack owns payments, keep manual invoicing: Introw still calculates, batches, produces statements and tracks status, and your team pays from a CSV export or through the API and marks payouts paid. Either way you can book one-off rewards along the way, from a workflow or the API, and they join the next batch like any other line.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
lines["Earned commission lines"] --> batch["Payout batch, one payout per partner"]
batch --> payNow["Pay now"]
payNow --> invoice["One consolidated invoice"]
invoice --> introwPay["Introw Pay verifies and sends"]
introwPay --> paid["Partners paid, statements in the portal"]
```
## Run it from your AI assistant
* What was paid out to partners last quarter, and to whom?
* How much commission is on upcoming payouts right now?
* Show Acme's most recent payouts and where each one stands.
* Which payouts are still waiting on payment?
## Going deeper
Activation, the payment run, partner readiness, and all how-to guides.
Read payouts and commission lines, or book rewards from your own systems.
**Works with**
Pay now settles a whole payout batch.
Switch the payout method to Introw Pay.
Every amount paid traces to a line and a record.
Partners are paid in their own currency.
Billing data feeds the calculation, never the payment.
# Introw Pay
Source: https://docs.introw.io/features/commissions/introw-pay/technical/index
Activate Introw Pay in Introw, pay a whole payout batch from one consolidated invoice, get partners verified and payout-ready, and track every payment on the Payments tab.
## Where it lives
Introw Pay is switched on from [Payout Settings](https://app.introw.io/commission?section=settings), where it is the option labeled **Introw Pay** under **How will payments be sent to partner?**. Once it is on, the **Commission** area gains a **Payments** tab and every payout batch gets a **Pay now** action.
Partners meet Introw Pay inside your partner portal, in two sections you add from **Smart sections** in the experience builder. **Payout setup** is where they set up and check how they get paid: the steps left, what is waiting to be collected, and, once they are verified, the account they are paid to and what it has received. **Commission** lists every payout with its status and statement, and shows a **Choose payout method** prompt on the first payable payout of a partner who has not set up yet. Partners see nothing in **Payout setup** while you pay by manual invoicing. See [Choose what partners see in the Commissions section](/features/commissions/payouts/guides/choose-what-partners-see-in-the-commissions-section).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Company currency in EUR or USD | Introw Pay only enables **Pay now** for these two; the invoice itself is in US dollars | [Company settings](https://app.introw.io/settings/company) |
| Complete billing info | Prints on every statement and on your invoice | [Billing info](https://app.introw.io/settings/company/billing-info) |
| Write access to commissions | To change payout settings and choose **Pay now** | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| **Payout setup** and **Commission** sections in your experience | Partners set up and track payouts from them | [Choose what partners see](/features/commissions/payouts/guides/choose-what-partners-see-in-the-commissions-section) |
## How it works
Three things move, and Introw Pay connects them.
**Your payout batch.** Commission plans turn CRM or billing records into earned lines. On your schedule, or when you choose **Create payout**, Introw groups the earned lines into a batch with one payout per partner. That batch is what you review: decline what should not pay, postpone what is not ready, and remind partners who have not finished their payout setup.
**One invoice to you.** **Pay now** locks the ready payouts in the batch and issues one invoice to your company: one line per partner, plus an **Introw Platform fee** line when your fee arrangement bills the fee to you. The invoice is in US dollars and you pay it by US bank transfer, also when your company currency is EUR. Each line is converted from the partner's payout currency, and the **Pay commissions** dialog keeps showing totals in your company currency. Nothing moves to partners until that payment lands.
**Many payments to partners.** When your payment arrives, Introw Pay sends each partner their share in their own currency, moves their payout through **Pending payment** and **Scheduled** to **Paid**, regenerates the statement in the partner's currency, and emails them. The person who chose **Pay now**, and the partner managers of the partners on that invoice, also get a vendor email that the invoice was paid. Turn that email on or off under [Notification settings](https://app.introw.io/settings/notifications) as **Payout invoice paid**. Every movement, yours in and theirs out, is a row on the **Payments** tab. A bank transfer takes three to seven days to reach a partner's account, and that time depends on the banks involved, not on where the partner is based.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
plans["Commission plans"] -->|"earned lines"| batch["Payout batch"]
batch -->|"Pay now"| invoice["Consolidated invoice to you"]
invoice -->|"bank transfer"| introwPay["Introw Pay"]
introwPay -->|"per partner"| partnerBank["Partner bank account"]
introwPay -->|"status, statement, email"| portal["Partner portal"]
introwPay --> payments["Payments tab"]
```
A payout is visible to the partner as soon as it leaves **Draft**, whatever stage it moves to, including **Pending approval**, **Approved** and **Blocked**. Approval is a decision for your team and does not hide the payout. Only **Draft** stays on your side.
### What you connect, and what you do not
Nothing on your side connects to a payment provider. You complete your billing info, select **Introw Pay** as the payout method, and pay one invoice a cycle by bank transfer. That is the whole setup.
The Stripe tile under [Billing & Subscriptions](/features/integrations/billing) is a different thing entirely, and the name is all the two share. That one is a read-only import of your Stripe customers, subscriptions and invoices so a commission plan can calculate on invoiced revenue; it moves no money, and Introw Pay never reads it. Run Introw Pay with no billing integration at all, or import Stripe billing data and still pay your partners by hand. The test is one word: **calculating** what a partner earned is the billing integration's side, **sending** it is Introw Pay's.
Partners connect one thing, and it is theirs, not yours: a payout method, set up once from the **Payout setup** section of your portal, or from the prompt on their first payable payout. They enter their business details first: the legal name, country, address, finance email and a VAT number or a company number. The country decides which payout methods they can pick. The details are saved on the partner, prefilled into Stripe's onboarding, and printed in a **For** block on the commission statement. They then accept the Introw partner payout terms, which Introw records with the country they chose, and choose a method:
* **Bank transfer via Stripe**, marked **Recommended**. Introw Pay verifies their identity and business and confirms the bank account the money should land in.
* **PayPal** is listed as **Coming soon** and cannot be chosen yet.
A partner needs no account with you and nothing from your billing integration. Bank and identity details collected by Stripe are not stored in Introw or visible to your team.
### Countries partners can be paid in
Bank transfer is available to partners based in the 119 countries below. The partner's country is the one in their business details, not where their bank is.
Albania, Austria, Belgium, Bosnia and Herzegovina, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Gibraltar, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Moldova, Monaco, Netherlands, North Macedonia, Norway, Poland, Portugal, Romania, San Marino, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, United Kingdom
Antigua and Barbuda, Bahamas, Canada, Costa Rica, Dominican Republic, El Salvador, Guatemala, Jamaica, Mexico, Panama, Saint Lucia, Trinidad and Tobago, United States
Argentina, Bolivia, Chile, Colombia, Ecuador, Guyana, Paraguay, Peru, Uruguay
Armenia, Azerbaijan, Bahrain, Bangladesh, Bhutan, Brunei, Cambodia, Hong Kong, Indonesia, Israel, Japan, Jordan, Kazakhstan, Kuwait, Laos, Macao, Malaysia, Mongolia, Oman, Pakistan, Philippines, Qatar, Saudi Arabia, Singapore, South Korea, Sri Lanka, Taiwan, Thailand, Türkiye, United Arab Emirates, Uzbekistan, Vietnam
Algeria, Angola, Benin, Botswana, Côte d'Ivoire, Egypt, Ethiopia, Gabon, Gambia, Ghana, Kenya, Madagascar, Mauritius, Morocco, Mozambique, Namibia, Niger, Nigeria, Rwanda, Senegal, South Africa, Tanzania, Tunisia
Australia, New Zealand
Partners in Brazil, China and India cannot be paid by bank transfer yet. Their setup dialog says payouts are not available in their country, and their approved payout stays waiting.
## Settings & configuration
### Payout method
**How will payments be sent to partner?** on [Payout Settings](https://app.introw.io/commission?section=settings) has two options. **Manual invoicing** means Introw emails partners their statement and invoice instructions, and your team pays outside Introw and marks payouts paid. **Introw Pay**: you pay one invoice and Introw Pay distributes it to every partner, with verification done per partner. It is included in every plan and stays locked, showing an **Upgrade** pill, until it is switched on for your account. Choose **Save** in the page header; the confirmation reads **Payout settings saved**.
### Payout schedule and minimum
**Payout schedule** sets when batches are created: **Every month**, **Every quarter**, **Every fiscal quarter**, or **Manual**. On any schedule other than manual, **Minimum payout amount** is required and must be above zero. It holds small balances back until they are worth paying, either **Per partner** or as an **Organisation total**. Both settings are shared with manual invoicing and are covered in full in [Configure commission and payout settings](/features/commissions/settings/guides/configure-commission-payout-settings).
### Billing info
[Billing info](https://app.introw.io/settings/company/billing-info) holds your legal company name, address, **Finance Email Address**, **Company Number** and **VAT Number**. It prints on every partner statement and is used to issue your consolidated invoice. Introw validates the VAT number when you save it, so a rejected number never reaches an invoice. Until billing info is complete, **Pay now**, **Request partner invoice** and statement generation are all blocked with **Billing info required**.
### Company currency
Your company currency is set in [Company settings](https://app.introw.io/settings/company). Introw Pay invoices in **US dollars only** for now, paid by US bank transfer. Your company currency can be **EUR** or **USD**: a EUR company still pays a USD invoice, and each line converts from the partner's payout currency at the exchange rate of that payout. In any other company currency, **Pay now** is disabled with a **Currency not supported** message; contact support to discuss other currencies. Partners are paid in their own currency regardless, taken from the **Currency** field on their partner record.
### Fee arrangement
Introw Pay is included in every plan. Introw charges a percentage fee on the transactions it processes, and there is nothing extra on your subscription. How that fee is applied is agreed with Introw when Introw Pay is activated and is not a setting you change yourself. Either the platform fee is billed to you on top of the commission, as a single **Introw Platform fee** line on the invoice so partners receive their full commission, or it is deducted from what partners receive. The **Pay commissions** dialog shows **Total commission**, **Introw Platform fee** and **Total due** before you confirm, so there is never a surprise on the invoice.
### The Pay now action
On a batch, **Pay now** is available in the header, as a bulk action over selected partners, and in the footer of a single partner's payout, where the dialog it opens is titled **Pay partner commission**. The button reflects where the run stands:
| Label | Means |
| - | - |
| **Pay now** | Ready partners can be paid |
| **Waiting for payment** | Your invoice is issued; **View and pay invoice** opens it |
| **Processing** | Your payment landed and partner payments are on their way |
| **Action required** | A partner payment failed or the invoice was only partially paid |
Partners who have not finished their payout setup appear in the dialog under **Pending payout setup**. They are left out of this invoice, stay in the batch, and can be reminded from the same dialog. When nobody in the batch is verified yet, the dialog holds the whole amount there, says no funds will be collected yet, and offers **Nudge N partners** or **Postpone and nudge N partners** instead of a payment.
### The Payments tab
[Payments](https://app.introw.io/commission?section=payments) lists every money movement on Introw Pay. **Customer Collection** rows are your invoices; **Partner Disbursement** rows are the payments to partners. Columns are **Source**, **Type**, **Amount**, **Status**, **Date**, **Actor** and **Details**.
| Status | Means |
| - | - |
| **Open** | Invoice issued and waiting for payment |
| **Partially paid** | Some of the invoice amount has been received |
| **Processing** | Payment is in progress, including partner payouts after a collection |
| **Completed** | Payment has settled |
| **Voided** | Invoice was canceled before it was paid |
| **Disputed** | Payment is under dispute |
| **Reversed** | A settled payment was reversed |
| **Failed** | Payment did not go through |
### Partner readiness
Each partner's payout shows a **Payment details** row with a status indicator; hover it to read the state and what resolves it. The batch table can be filtered on **Introw Pay Ready**. The states are:
| Status | Means | What happens next |
| - | - | - |
| **Not connected** | The partner has not chosen a payout method | Remind them; they choose **Choose payout method** |
| **Incomplete** | Verification details or a usable bank account are missing | They choose **Continue setup** |
| **Verified** | Introw Pay can pay this partner | Nothing; they can **Change bank details** any time |
| **Restricted** | Payouts are on hold until more details are provided | They provide the missing details |
| **Deauthorized** | The payout method is no longer linked | They choose **Reconnect payout method** |
**Payment details** names the partner's business name and country once a method is set.
Verification, including identity, business details and the bank account, happens inside Introw Pay. It can take up to seven days and is usually much faster. Your team never sees or stores those details.
**Remind to set up payouts** emails the partner champion a **Set up payouts** link, at most once per payout per day. Before it offers the reminder, Introw checks the partner's portal: the partner needs an experience with a visible **Payout setup** section, a champion, and a champion who can open the tab that holds it. When a check fails, the payout shows ** can't collect this payment** with **Link experience** or **Add payout setup**, or ** can't open payout setup** with **Manage tab access** and **Change champion**, and a bulk reminder skips that partner and reports how many it skipped. The link opens the partner's tab with the setup dialog open.
### Statements and emails
A **Commission Statement** PDF is generated for every payout from your billing info and the lines it covers, always in the partner's currency on Introw Pay. Partners get an email when a payout is sent to them, with the statement attached, and another when the money is on its way, naming the masked bank account it went to. Your team is emailed when a partner uploads an invoice.
## How-to guides
* 
[**Activate Introw Pay**](/features/commissions/introw-pay/guides/activate-introw-pay)
Switch partner payouts to Introw Pay: complete billing info, confirm your company currency, switch Introw Pay on with a schedule, and make sure partners can set themselves up from the portal.
* 
[**Get partners ready to be paid**](/features/commissions/introw-pay/guides/get-partners-ready-to-be-paid)
What a partner does once to receive money through Introw Pay, the verification statuses you see on your side, and how to remind the partners who have not finished.
* 
[**Pay a payout cycle with Introw Pay**](/features/commissions/introw-pay/guides/pay-partners-with-introw-pay)
Take a payout batch from review to paid partners with one invoice: check the batch, choose Pay now, pay the consolidated invoice, and watch Introw Pay send every partner their share.
## Troubleshooting
**Pay now** issues a real invoice, so review the batch first: decline or postpone what should not pay, and remind partners who are not ready. Partners left out of a run are not lost; they stay in the batch for the next one. Once Introw Pay owns a payment, **Mark as unpaid** is unavailable on that payout.
No. Introw Pay has nothing for you to connect. The Stripe tile under **Settings → Integrations → Billing** is a billing data source for commission calculations and has no part in paying partners.
Those are two different systems. Select **Introw Pay** in [Payout Settings](https://app.introw.io/commission?section=settings) and complete your billing info; the billing integration plays no part in a payment run.
Your payout method is **Manual invoicing**. Select **Introw Pay** in Payout Settings and save.
Your company currency is not EUR or USD. Contact support to discuss other currencies.
Complete your billing info, or correct the VAT number, then try again.
They are not **Verified** yet. Remind them from the dialog; they are paid in a later run.
Bank transfer is only offered in the [countries partners can be paid in](#countries-partners-can-be-paid-in), and the partner's card reads **Not available in** their country otherwise. A partner who entered the wrong country fixes it under **Edit business details** in the card's menu, before they verify. Once verified, the card has no menu.
Introw checks the partner's portal first. Add a **Payout setup** section to the experience the partner uses and publish it, give the champion access to the tab that holds it, or set a champion on the partner record. The banner on the payout names which one it is.
A partner's bank rejected the payment, usually because their bank details are wrong. They update them from the portal, then you choose **Retry transfer**.
The invoice was only partially paid. Payouts stay blocked until finance reviews and settles it.
While the invoice is unpaid, choose **Void invoice** in the Pay commissions dialog. The lines are released back to the batch.
# Choose what partners see in the Commissions section
Source: https://docs.introw.io/features/commissions/payouts/guides/choose-what-partners-see-in-the-commissions-section
Add the Commission section to a portal experience, choose which payout and commission item columns partners see and what they are called, add the Payout setup section on Introw Pay, and publish.
> **Use case:** you want partners to read their payouts in your words, see only the fields that mean something to them, and download their statement themselves. For partner managers and partner operations.
Partners check their commission in the portal more than anywhere else, and every column they do not understand becomes an email to you. This guide puts the **Commission** section on a tab, picks the columns partners see per payout and per commission item, renames them to the words your program already uses, and publishes it. On Introw Pay it also adds the **Payout setup** section, so partners set up how they get paid on the same tab they check their money on.
## What you'll achieve
Every partner on the experience opens a Commissions tab that shows their totals, their payouts with only the columns you chose, under the names you chose, and a statement they can download per payout. Opening a payout lists each commission item with the detail columns you kept. On Introw Pay, the same tab shows them how far their payout setup is and what is left to do.
## Before you start
You need a role that can edit experiences. The **Configure** button on the section only shows for it.
The experience is published to the partners who should see it. Changes reach them when you publish again.
The **Payout setup** section only shows partners anything while **Introw Pay** is your payout method. See [Activate Introw Pay](/features/commissions/introw-pay/guides/activate-introw-pay). The **Commission** section works on either payout method.
## Watch it
## Steps
### Phase 1 - Put the Commission section on a tab
Go to [Experience builder](https://app.introw.io/templates) and open the experience your partners use. If one of its tabs already holds a **Commission** section, open that tab and skip to Phase 2.
Choose **Add**, keep **Tab** as the **Type**, and give it a **Name** partners recognise, such as **Payouts** or **Get paid**. A tab of its own makes earnings one click from anywhere in the portal. Choose **Add tab**.
On the empty tab, open **Smart sections** and choose **Commission**. Smart sections fill themselves with each partner's own data, so you add the section once and every partner sees their own figures. It lands with the heading **Commissions** and a line under it that you can rewrite like any other text.
The section shows four totals, **Forecasted**, **Expected**, **Upcoming payouts** and **Total paid**, each of which lists the lines behind it when a partner clicks it. Under them sits a table with one row per payout. In the builder the table reads **No payouts yet**, because an experience has no partner of its own; partners see their payouts once it is published.
### Phase 2 - Choose the columns
Choose **Configure** above the payouts table. A side panel opens with two lists, and each list starts with every column the section can show.
**Payouts table** decides what partners see per payout:
* **Amount** - what the payout pays, in the partner's currency.
* **Owner** - the person on your team the payout came from, with their avatar.
* **Period** - the dates the payout covers.
* **Status** - where the payout stands, from **Pending Partner Invoice** to **Paid**. Partners never see a payout while it is in **Draft**; every later stage is visible to them.
* **PO Number** - the purchase order number, once you set one. Remove it if your program does not use them.
* **Invoice link** - a **Download invoice** link once the partner has uploaded their invoice.
* **Commission statement** - a **Download statement** link on every payout. The statement is rendered from the payout's current lines when the partner clicks, so the file is never older than the payout. A payout with no commission items on it says **No statement yet**.
To rename a column, type over its label and press Enter; hover the info icon to see its original name. Use the words your partners use: **Payout amount**, **Your contact**, **Statement**. To remove a column, choose its bin icon. To reorder, drag a column by its handle; partners read the table left to right in this order. **Add column** brings back a column you removed. Keep at least one column, or **Save** stays unavailable.
**Payout details** decides what partners see per commission item when they open a payout:
* **Commission item** - the deal, or the description of the line. It always shows, first, because it names each row and carries the **Total** line. You can rename it, to **Deal** for example, but not remove or move it.
* **Close date** - the close date of the deal behind the item, or the date of the line.
* **Amount** - the value the commission was calculated on, such as the deal amount.
* **Commission** - what the partner earns on it.
* **Plan** - the plan and rate it was paid under, or the rate a manual or API line works out to.
Rename, remove, reorder and add work the same way as in the payouts table. Remove **Plan** when your plans carry internal names you would rather partners did not read.
Choose **Save**. The columns are saved on this section only, so another experience, or a second Commission section, can show partners a different set. A section you never configure keeps showing every column in the default order, including **Commission statement**.
Columns are presentation, not permissions: hiding one changes what the table shows. Contacts who only see the deals they collaborate on get a narrower view either way, see [What partners see in the Commissions section](/features/commissions/payouts/technical#what-partners-see-in-the-commissions-section).
### Phase 3 - Add Payout setup and publish
On Introw Pay, hover the Commission section, choose **Add Section**, open **Smart sections** and choose **Payout setup**. It lands under the Commission section with the heading **Payout setup** and the line **Choose how you want to get paid and follow your setup below.**, both of which you can rewrite.
Each partner sees their own card, titled **Getting paid**:
* Until they are set up, it lists the three steps, **Business details**, **Payout method** and **Verification**, each marked **To do**, **In progress** or **Done**, with **Choose payout method** or **Continue setup** under them. When money is waiting it says so first: **Unlock** the amount **from** your company. **Learn more** opens **How payouts work**, which explains the steps, what each payout method costs and how fast it lands, and that your team never sees their bank details.
* When their payout provider needs something only they can give, the card asks for it and keeps their approved commission waiting for them.
* Once they are **Verified**, it shows the account they are paid to, when each step was finished, and the payouts **Paid to this account** with **View all payouts**. The card has no menu once verified, and shows **Change payout method** only where a partner's country offers more than one method.
You never see a partner's card. In the builder and in a portal preview you see the same card greyed out, under **This is a preview of the partner experience**. While you pay by manual invoicing, partners see nothing in this section, and the preview tells you so. On manual invoicing the section picker marks **Payout setup** with a **Needs Introw Pay** pill, and the section in the builder reads **Partners won't see payout setup yet** with **Open payout settings**, or **Payout setup needs Introw Pay** with **Upgrade to Introw Pay** when your plan does not include it.
Choose **Publish**. The partners already on this experience are selected; add any others who should get it. Choose **Publish without email** to update their portals quietly, or **Publish and notify** to tell them. Their Commissions tab changes the moment you publish.
## Verify it worked
Open a partner with a payout, choose **View portal**, and open the tab. The payouts table carries your columns under your names, and **Download statement** returns the statement for that payout. Open a payout: each commission item is a row with the detail columns you kept, and a **Total** line under them.
## Related
Stages, statements, and what each partner contact can see.
What partners do in the Payout setup section, and how you remind them.
Build the payouts partners read here.
Tabs, sections and publishing in full.
# Feed your finance stack from Introw
Source: https://docs.introw.io/features/commissions/payouts/guides/export-commission-data-to-your-finance-stack
Get commission and payout data into your ERP or accounting tool as CSV or through the API, write payment status back, and book one-off rewards from workflows or the API so they join the next payout.
Introw is the source of truth for what each partner earned; your finance stack may still be the source of truth for what was paid. This guide covers the hand-offs in both directions, with no spreadsheet in between. Export commission lines and payouts as CSV, or pull the same data through the API. Write payment status and PO numbers back when your ERP pays. Book one-off rewards from a workflow or any system, and they land in the next payout like any other line. Reach for it when you keep **Manual invoicing** as your payout method, or when you run Introw Pay and finance still wants the detail in its own system.
## What you'll achieve
Your finance system holds the commission detail for every period, in the columns it needs, with statuses that match Introw. Payouts you settle elsewhere read **Paid** in Introw and in the partner portal, with the PO number on the statement. Rewards decided outside a commission plan, a bonus for finishing onboarding or a spiff booked by an agent, arrive as normal commission lines and are paid in the next run.
## Before you start
You need read access to commissions for exports, write access to advance payouts, and an API key with the **commissions:read** or **commissions:write** scope for the API steps. See [Create and manage API keys](/features/developer/api/guides/create-and-manage-api-keys).
Exporting and reading need nothing else. Writing status back assumes your payout method is **Manual invoicing**; on Introw Pay the stages advance on their own once you pay the consolidated invoice.
## Steps
### Phase 1 - Export commission lines as CSV
Go to [Reports](https://app.introw.io/reports) and create a report with **Commissions** as its data source. Each row is one commission line, and the default columns are **Partner**, **Commission Item**, **Commission Plan**, **Amount**, **Currency**, **Status**, **Origin**, **Source** and **Date**. **Commission Item** is the deal or description the partner reads on their statement. **Commission Plan** carries the installment after the plan name, such as `(2/5)`, and a line with no plan shows how it was made instead, such as **Manual**. **Origin** says how the line was made: **Plan**, **Manual**, **Api**, **Workflow** or **Affiliate**. **Source** says where its figures came from, such as **CRM**, **Stripe**, **Chargebee**, **File upload**, **Manual** or **API**. Add partner CRM properties as extra columns when your finance system keys partners on a CRM id or a supplier number. Filter on **Status** and **Date** to match the period you are booking, and on **Commission Item**, **Origin** or **Source** to split a file import or the manual adjustments out of a run. **Potential** is forecast on open pipeline, **Expected** is earned but not yet on a payout, **In Payout** is on a payout, **Paid** is settled and **Voided** was declined.
Open the report's **Data** tab and export the rows to CSV. Money columns carry a matching currency column so multi-currency programs import cleanly. The same tab works on any saved commissions report, so save one per period or per finance entity and re-export it each cycle. See [Export report data to CSV](/features/reporting/report-builder/guides/export-report-data-to-csv) for the export itself.
For a quick pull, go to [Payouts](https://app.introw.io/commission?section=payouts) and click a metric card such as **Expected**, **Upcoming payouts**, **Total paid** or **Declined**. The dialog lists the lines behind that figure with **Partner**, **Commission item**, **Close date**, **Amount**, **Commission** and **Plan**, plus **Status** and **Description** for declined or postponed lines, and exports them to CSV named after the metric.
### Phase 2 - Read and write through the API
List payouts for a period or a stage, then the commission lines on each. A payout carries the partner, the period, the amount in your company currency, its stage and the PO number. A line carries the partner, the amount and currency, the plan it came from, its status and the payout it sits on, if any. This is the same data as the CSV, without the export step, and it is how an ERP polls for new payouts to book.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl "https://api.introw.io/api/v1/payouts?stage=PENDING_REVIEW" \
-H "x-api-key: $INTROW_API_KEY"
```
When your ERP approves or pays a payout, update its stage and PO number in Introw so the partner sees the same status in the portal and the statement carries the PO. Advance through **APPROVED** and **PENDING\_PAYMENT** to **PAID** as your process moves.
Send `metadata` to print your own free text on the statement PDF, below the commission table: a remittance reference, the account the money left, or who to contact about it. Newlines in the value become line breaks on the PDF, up to 2000 characters, and passing `null` clears it. The statement is regenerated when the PO number or the statement note changes, so the partner's next download carries the new text.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X PATCH "https://api.introw.io/api/v1/payouts/{payoutId}" \
-H "x-api-key: $INTROW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"stage": "PAID",
"poNumber": "PO-2026-Q3-0042",
"metadata": "Remittance reference: ACME-Q3-0042\nPaid from our EUR account\n\nQuestions? finance@yourcompany.com"
}'
```
The full walkthrough and every stage value are in the [Commissions API](/general/commission-overview).
### Phase 3 - Book rewards along the way
Open [Workflows](https://app.introw.io/workflows) and add the **Give commission** action under **Rewards** to any trigger that marks an achievement, such as **Journey completed** or **Certificate issued**. Set **Amount**, leave **Currency** on **Partner's currency** unless the bonus is fixed in one currency, and write a **Description** the partner will read on their statement. The line is created as pending and joins the next payout batch, so it still goes through your normal review. See [Reward a partner for finishing a journey](/features/automation/workflows/guides/reward-a-finished-journey).
Create a commission line through the API when the decision lives elsewhere: a spiff approved in your CRM, a bonus from a sales contest tool, or an agent acting on your rules. Give it the partner, an amount, a currency and a description; leave the payout out and it waits in the pending pool for the next batch, or pass a payout to attach it straight away. Lines created this way are labeled **Api** in the source column, so finance can tell them from plan-calculated lines.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "https://api.introw.io/api/v1/commission-lines" \
-H "x-api-key: $INTROW_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "partnerId": "{partnerId}", "amount": "500.00", "currency": "USD", "description": "Q3 onboarding bonus" }'
```
### Phase 4 - Build a whole payout over the API
Create the payout for one partner and one period. It opens empty and in **Draft**, so you decide what goes on it. Pass `metadata` to write the statement note in the same call, or set it later with `PATCH /api/v1/payouts/{id}`. Pass `attachPendingLines: true` instead if you want the partner's pending lines for that period pulled in, the way creating a payout in the app does.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "https://api.introw.io/api/v1/payouts" \
-H "x-api-key: $INTROW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"partnerId": "{partnerId}",
"periodStart": "2026-01-01T00:00:00.000Z",
"periodEnd": "2026-03-31T23:59:59.000Z",
"metadata": "Remittance reference: ACME-Q1-2026"
}'
```
A payout covers one partner. The **batch** is the run around them: one period holding one payout per partner, which is what the Payouts page lists as a period. A payout created on its own gets a batch of its own, so paying ten partners for the same quarter that way leaves ten separate runs.
Open the batch first when the run covers several partners. Pass `partnerIds` to open every partner's payout in that one call, then fill each one with lines as usual. Each partner still gets their own commission statement.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "https://api.introw.io/api/v1/payout-batches" \
-H "x-api-key: $INTROW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"periodStart": "2026-01-01T00:00:00.000Z",
"periodEnd": "2026-03-31T23:59:59.000Z",
"partnerIds": ["{partnerId}", "{otherPartnerId}"]
}'
```
To add a partner to a run that already exists, create their payout with the batch's id. The batch dates the payout, and a partner already on it keeps the payout they have rather than gaining a second.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "https://api.introw.io/api/v1/payouts" \
-H "x-api-key: $INTROW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"partnerId": "{partnerId}",
"periodStart": "2026-01-01T00:00:00.000Z",
"periodEnd": "2026-03-31T23:59:59.000Z",
"batchId": "{batchId}"
}'
```
Post each commission line against the payout id the create call returned. Send `sourceAmount` alongside `amount` when the commission came off a deal value: the statement then prints the calculation, `EUR 4,200.00 x 10%`, instead of the amount alone.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "https://api.introw.io/api/v1/commission-lines" \
-H "x-api-key: $INTROW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"partnerId": "{partnerId}",
"payoutId": "{payoutId}",
"amount": "420.00",
"sourceAmount": "4200.00",
"currency": "EUR",
"description": "Acme Corp renewal"
}'
```
Render the commission statement PDF and get a link to it. The PDF is rebuilt only when something on it changed, so you can call this after every edit and it stays cheap. The link is signed and expires in an hour; `expiresAt` tells you when.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "https://api.introw.io/api/v1/payouts/{payoutId}/statement" \
-H "x-api-key: $INTROW_API_KEY"
```
You need complete commission billing information and at least one line on the payout, or the call answers `422` with `NO_BILLING_INFO` or `NO_COMMISSION_LINES`. When someone has uploaded their own statement in the app, that PDF is returned untouched and `isUploaded` is true.
## Verify it worked
Your finance system shows one row per commission line for the period, and its totals match the batch **Total** on the Payouts page. Payouts you settled elsewhere read **Paid** in Introw and in the partner portal, with the PO number printed on the statement. A reward booked from a workflow or the API appears as a pending line on the partner, then inside the next batch, with its description on the partner's statement.
## Related
The batch and stages your exports and writes refer to.
Let Introw Pay settle the batch instead of your ERP.
Endpoints, stages and request examples.
Full configuration options.
# Request a partner invoice
Source: https://docs.introw.io/features/commissions/payouts/guides/request-a-partner-invoice
Follow the invoice-first payout path - generate a commission statement, request a partner's invoice, and collect it for approval before you pay.
Many programs on manual invoicing cannot pay a partner until they have the partner's invoice on file. (On Introw Pay the consolidated invoice replaces per-partner invoices, so this step is not needed.) Requesting one in Introw generates the commission statement, moves the payout to pending the partner's invoice, and emails the partner to upload it, so the paperwork is gathered in a single clear step instead of a back-and-forth email thread. Reach for this when invoice collection is a required gate before payment in your payout cycle.
## What you'll achieve
A payout sitting at **Pending Partner Invoice** with the partner notified and a statement generated, ready to continue to payment as soon as their invoice arrives, with finance holding the documentation it needs.
## Before you start
You need write access to payouts.
The partner should have a payout in the current batch with approved commission to invoice against.
Your commission billing info should be set so the generated statement is complete and tells the partner what to put on their invoice.
## Steps
Go to [Payouts](https://app.introw.io/commission?section=payouts), open the batch, and open the partner's payout. You can also request invoices for several partners at once from the batch view.
Choose **Request partner invoice**, then confirm with **Request invoice**. This generates the commission statement, moves the payout to **Pending Partner Invoice**, and emails the partner asking them to upload their invoice. The statement reflects your commission billing info, so the partner knows exactly what amount and details to invoice for.
Check the payout now reads **Pending Partner Invoice**. The partner uploads their invoice from the portal (they see **Upload invoice** on their payout), or simply replies to the statement email with the invoice attached. Once it is attached the payout moves to **Pending payment** on its own and your team is emailed, so you can continue toward **Paid**.
## Verify it worked
The payout shows **Pending Partner Invoice**, the partner has received the request email with the statement attached, and a statement is available on the payout. When the partner uploads or replies with their invoice, it appears on the payout at **Pending payment**, ready for you to pay and mark paid.
## Related
Continue the payout through to paid once the invoice arrives.
Set the billing info that appears on statements.
Full configuration options.
# Run a payout cycle
Source: https://docs.introw.io/features/commissions/payouts/guides/run-a-payout-cycle
Run a payout cycle from a new batch of earned commission to partners marked paid, generating and sharing partner statements at each stage, and hand the payment itself to Introw Pay or your finance stack.
A payout cycle is what turns earned commission into money in partners' accounts. This guide runs the whole job: create a batch for a period, watch each partner's payout move through its stages, generate statements, handle the lines that should be declined or held, and get every payout to paid so finance has a clean trail and partners can see they have been settled. Reach for it on every pay run, whether you trigger it manually or it is created on a schedule. The payment itself is either one **Pay now** on [Introw Pay](/features/commissions/introw-pay/guides/pay-partners-with-introw-pay) or a **Mark as paid** after your finance stack has paid.
## What you'll achieve
A payout batch taken end to end: per-partner payouts built from earned lines, statements produced for partners' records, exceptions declined or postponed, and each payout advanced to **Paid**, so the partner sees their commission as paid in the portal and your finance records reconcile.
## Before you start
You need write access to payouts.
A line is batched as soon as it is earned, shown as **Expected**; there is no separate approval on a line. Decline or postpone what should not pay before you batch, or from inside the batch.
Your commission billing info should be set so statements are complete.
## Steps
### Phase 1 - Create the payout batch
Go to [Payouts](https://app.introw.io/commission?section=payouts). The list groups batches into **All**, **Upcoming**, **Paid**, and **Declined** so you can see what is in flight versus settled.
Choose **Create payout** to open the **Create new payout** dialog, then define the run:
* **Select period** - the date range the batch covers. Earned lines not yet on a payout whose date falls in this period are eligible, plus any earned backlog from before it, so set it to the cycle you are paying (for example last month or last quarter). The dialog proposes the period your payout schedule implies.
* Partner scope - leave the default **All partners** to include everyone with eligible commission, or apply a **segment** filter to pay a specific group. The table previews each partner and their commission total.
* Selection - tick the partners to include; the footer shows how many are selected and the running **Total**.
Choose **Create payout** to build the batch. Introw attaches each partner's eligible lines into a per-partner payout inside the batch, at **Draft**.
### Phase 2 - Move payouts through their stages
Open the batch to see each partner's payout and its stage. The typical path is **Draft**, **Pending Partner Invoice**, **Pending payment**, **Paid**; teams that add an internal gate use **Pending approval** and **Approved** before sending, and **Scheduled** appears while funds are about to land. Exceptions show as **Declined**, **Postponed**, **Blocked**, or **Failed**. Partners see nothing while a payout is in **Draft**. From the first stage after it, including **Pending approval** and **Approved**, the partner can see the payout. The stage tells you what each payout is waiting on; you advance it as the real-world steps complete, or Introw Pay advances it for you.
Produce the documentation partners and finance need. Use **Request partner invoice** on a payout (or in bulk) to generate a commission statement, move the payout to **Pending Partner Invoice**, and email the partner to upload their invoice. You can also produce the statement and **Send to partner** directly, or **Download** and **Regenerate** it from the partner panel. Statements use your commission billing info, so they double as the partner's earnings breakdown.
Clean up anything that should not pay in this run. From a partner's payout panel you can **Decline** a line with a reason, **Restore** one declined in error, or **Postpone to next cycle** to hold a valid line back without voiding it (then **Unpostpone** when it is ready). Whole partner payouts can likewise be declined, postponed, and restored. This keeps the batch paying only what should be paid now.
### Phase 3 - Pay, and mark payouts paid
If your payout method is **Introw Pay**, choose **Pay now** on the batch. Introw Pay issues one invoice to your company for every ready partner; when you pay it, each partner is paid in their own currency and their payout advances to **Paid** on its own. Partners who have not finished their payout setup stay in the batch for the next run. The full run is in [Pay a payout cycle with Introw Pay](/features/commissions/introw-pay/guides/pay-partners-with-introw-pay); skip the remaining steps in this phase.
As you settle each payout, record the supporting detail. Enter the **PO number** where your finance process needs one, and make sure any requested partner invoice has been received and attached.
Once your finance team has paid a partner, advance the payout to its final stage with **Mark as paid**, or let your ERP do it through the API. The payout reads **Paid**, and the partner sees it as paid in the portal. If you ever need to reverse a mistake, **Mark as unpaid** returns it for correction.
### Scheduled batches
If you set a non-manual **Payout schedule** in settings (every month, every quarter, or every fiscal quarter), Introw creates the payout batches for you when each period closes, applying your minimum payout amount, rather than you starting each one. You still review, document, and pay each batch using the same stages above. See [Configure commission and payout settings](/features/commissions/settings/guides/configure-commission-payout-settings) to set the cadence.
## Verify it worked
The batch shows its per-partner payouts at **Paid**, the batch moves into the **Paid** tab, and the **Total paid** figure on the commission dashboard reflects the run. Each partner sees their payout marked paid in the portal with a statement available, and your finance records reconcile to the documented amounts and PO numbers.
## Related
Settle the whole batch with one invoice.
Collect an invoice before you pay, the invoice-first variant.
Approve and clean lines before batching.
Set the schedule, minimum, and billing info.
Full configuration options.
# Payouts
Source: https://docs.introw.io/features/commissions/payouts/index
Turn earned commission into partner payouts: one payout per partner per period, with a statement, tracked from draft to paid, whether Introw Pay settles the batch or your finance stack does.
> Payouts turn earned commission lines into money in partners' hands: one payout per partner per period, moved through clear stages to paid, with a statement partners can read in the portal. Introw Pay settles the whole batch from one invoice, or your finance stack pays and marks it paid.
## The problem it solves
Paying partners from spreadsheets is slow, opaque, and error-prone:
| Without Introw | With Introw |
| - | - |
| Payments are assembled by hand | Earned lines batch themselves |
| Approval is ad hoc | Clear, auditable stages |
| Partners chase you for status | They track it in the portal |
| Statements are manual | Generated with the payout |
| Paying means hundreds of transfers | One invoice, or your own stack |
## Impact
Late and unexplained payments are the most common reason a partner quietly stops selling. Visible stages and a statement they can read keep the relationship boring, which is the goal.
for your business
* **Cost to run**
Partner ops runs batching, review, statements and payment end to end, with no engineering anywhere in it
* **No new tool**
Partners track what is upcoming and what is paid in the portal, or by asking an AI assistant; finance pays from Introw Pay or its own system
for your partners
* **Self-serve**
Forecasted, expected, upcoming and paid, all visible without emailing anyone to ask
* **Enabled**
They upload an invoice and set a PO where you ask for one, so their finance team is not blocked
* **Efficient**
One statement per payout, so their books reconcile without a reconstruction exercise
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - payouts run end to end
* **Finance** - an auditable trail
* **Partners** - what is coming, and when
## How it works
A payout groups a partner's earned commission lines for a period into one amount to be paid. A batch holds one payout per partner.
Batches are created on your schedule, every month, every quarter or every fiscal quarter, or by hand for a period you choose. You review each partner's payout, decline or postpone what should not pay, and move it through clear stages from draft to paid. Along the way Introw generates the statement, you can request the partner's invoice and record a purchase order number, and partners are notified at the moments that matter to them.
How the money moves is your choice. With [Introw Pay](/features/commissions/introw-pay), **Pay now** turns the batch into one consolidated invoice to your company and Introw Pay sends every partner their share, in their own currency, and marks the payouts paid. With manual invoicing, your finance stack pays from a CSV export or through the API and marks each payout paid in Introw, so partners see the same status either way.
Partners are not left guessing. They see their forecasted, expected, upcoming, and paid amounts in the portal, can upload an invoice and set a PO when asked, and can ask an AI assistant where a payout stands. Finance gets a documented, auditable trail, and the same payout data is available through the API for downstream systems.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
batch["Batch earned lines"] --> review["Review and approve"]
review --> settle["Introw Pay or your finance stack"]
settle --> paid["Paid"]
paid --> statement["Statement partners see"]
```
## Run it from your AI assistant
* Show my most recent payouts and their stage.
* What commission is due to be paid out next month, and to whom?
* How much has been paid to Acme year to date?
* Which payouts are still in review?
## Going deeper
Setup, configuration, and all how-to guides.
Read payouts, write status back, book commission lines.
**Works with**
Payouts batch the earned lines.
Settle a whole batch from one invoice.
Reconcile payouts to invoices.
Pay each partner in their currency.
# Payouts
Source: https://docs.introw.io/features/commissions/payouts/technical/index
Create payout batches in Introw, review each partner's payout, request invoices, move payouts through their stages to paid, and settle the batch with Introw Pay or your own finance stack.
## Where it lives
Payouts sit under **Commission**, at [Payouts](https://app.introw.io/commission?section=payouts). Each row is one batch for a pay period; the tabs filter batches into **All**, **Upcoming**, **Paid** and **Declined**, and the metric cards above them show **Forecasted**, **Expected**, **Upcoming payouts**, **In review**, **Total paid** and **Declined** commission.
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Write access to payouts | To create a batch and advance it | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Earned commission lines | Only lines at **Expected** are batched | [Commission lines](/features/commissions/commission-lines/guides/review-and-adjust-commission-lines) |
| Commission billing info | Statements and invoices are generated from it | [Payout settings](/features/commissions/settings/guides/configure-commission-payout-settings) |
| A payout method | Introw Pay, or manual invoicing | [Activate Introw Pay](/features/commissions/introw-pay/guides/activate-introw-pay) |
## How it works
A payout batch holds one payout per partner, and each partner's payout holds their earned
commission lines for the period. A line is earned, shown as **Expected**, once its record meets the
plan's conditions; it needs no separate approval to be batched. You review at the payout instead:
open a partner's payout, decline lines with a reason, postpone lines to the next cycle, or hold the
whole payout.
Batches are created for you when your **Payout schedule** is every month, every quarter or every
fiscal quarter, covering the period that just closed and applying your minimum payout amount. On a
manual schedule you choose **Create payout**, pick the period, and Introw attaches each partner's
eligible lines, including any backlog from earlier periods.
Along the way you can **Request partner invoice**, which generates the statement and emails the
partner with it attached, record **PO number**s, write a **Statement note** that prints on the
statement PDF, and mark payouts paid. Partners upload their invoice and set a PO from the portal,
or reply to the statement email with the invoice attached.
How a payout gets paid depends on your payout method. With [Introw Pay](/features/commissions/introw-pay/technical), **Pay now** on the batch issues one invoice to your company and Introw Pay pays every ready partner and advances their payouts to **Paid** on its own. With manual invoicing, your team pays outside Introw and chooses **Mark as paid**, or your finance system does the same through the API.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
plans["Commission plans"] -->|"earned lines"| batch["Payout batch"]
batch --> review["Review, decline, postpone"]
review -->|"Pay now"| introwPay["Introw Pay"]
review -->|"Mark as paid or API"| finance["Your finance stack"]
introwPay --> portal["Partner portal: status and statement"]
finance --> portal
```
### The stages a payout moves through
Worth knowing in full, because a payout that will not budge is almost always sitting in one of the
later ones. A payout is visible to the partner as soon as it leaves **Draft**, including in **Pending approval**,
**Approved** and **Blocked**; only **Draft** stays on your side.
| Stage | Means |
| - | - |
| **Draft** | Built, not sent; you prepare lines, PO and statement |
| **Pending approval** | Waiting on an internal decision |
| **Approved** | Cleared internally, not yet sent |
| **Pending Partner Invoice** | Sent to the partner; they can see it and upload an invoice |
| **Pending payment** | Approved and being paid; payment checks in progress |
| **Scheduled** | Funds are about to land for this partner |
| **Paid** | Money out, statement final |
| **Postponed** | Moved to a later period, deliberately |
| **Declined** | Rejected for this batch, deliberately |
| **Blocked** | Payment cannot proceed until a problem is resolved |
| **Failed** | The payment did not complete |
Comments your team leaves on a payout while it is in **Draft** stay internal. Once the payout has left **Draft**, a comment is visible to the partner unless you mark it internal.
Uploading an invoice on a **Draft** or **Pending Partner Invoice** payout moves it to **Pending payment** automatically. A statement is generated the first time a payout reaches any paying stage, and regenerated whenever the lines, the PO number or the statement note change.
### What the commission statement shows
The statement is the document the partner invoices you against, so it opens with who to bill.
Your logo sits top left, under it the title and the period the payout covers, and beside it an
**Invoice to** block carrying your commission billing info: your company, its address and its VAT
number, or the registration number when you have no VAT one. The **PO Number** prints under it once
you set one. A **From** block under the period names the partner: the legal name, address, country and
one tax number from the business details they saved when they set up payouts, or the partner's name
alone when they saved none. A statement is regenerated once when the partner saves or edits one of
these details, and the finance email is not printed.
Then one row per commission line: the deal or the description on the left, the calculation in the
middle, the commission on the right. A line that was earned on a deal value prints that calculation
in full, `EUR 4,200.00 x 10%`, so the partner can check the number rather than take it. The rate is
read back out of the line's own two figures, so a line prints what it actually paid whether it came
from a plan, a file import, a manual adjustment or the API. A fixed reward has no proportion to
show and prints its amount alone, and so does a line carrying no source revenue. **Amount to be
invoiced** closes the table, and your statement note prints under it.
Declined and postponed lines are left off, so the statement always adds up to what you are paying
this period.
### Using your own statement instead
**Upload your own** on the statement's menu, or **Replace with your own** once one exists, files
your PDF as the payout's statement. Introw then serves that file everywhere the generated one went,
to the partner portal and the invoice request included, and stops regenerating it. Pick **Use the
generated statement** to go back to the rendered one. Both need write access to payouts.
### The statement note
Free text you write per payout, printed below the commission table on the statement PDF under a
**Note** label. Up to 2000 characters. Set it on the payout in **Statement note**, or through the API
as `metadata` on `PATCH /api/v1/payouts/{id}`. Partners read it on the statement; they cannot edit it.
A note that opens with its own heading, such as `# Appendix`, prints that heading in place of the
label. A payout without a note prints no label and no empty space.
Line breaks are kept, so remittance references, bank details or a contact address each sit on their
own line, and the note is read as Markdown: `#`, `##` and `###` headings, `-` bullets and `1.`
numbered lists, `*bold*` or `**bold**`, and `[label](https://example.com)` links, which stay
clickable in the PDF.
A `#` heading prints at the size of the statement's own title, and the two levels under it step down
towards body size.
There is no italic face on the statement, so one asterisk and two both print bold.
Anything that is not one of those prints exactly as you typed it.
### What partners see in the Commissions section
Partners follow their payouts in the **Commission** section of your portal, which you add to an
experience from the **Smart sections** in the section picker. The section opens on four totals,
**Forecasted**, **Expected**, **Upcoming payouts** and **Total paid**, each of which lists the lines
behind it when clicked, and a table with one row per payout. Clicking a payout opens its detail,
with one row per commission item.
You decide which columns both tables show and what they are called. In the experience builder, the
section carries a **Configure** button above the table, visible to anyone who can edit experiences,
and it opens a side panel with two lists:
* **Payouts table** decides the columns partners see per payout: **Amount**, **Owner**, **Period**,
**Status**, **PO Number**, **Invoice link** and **Commission statement**.
* **Payout details** decides the columns partners see per commission item when they open a payout:
**Commission item**, **Close date**, **Amount**, **Commission** and **Plan**.
In each list you can **rename** a column by typing over its label, **remove** it with the bin icon,
**reorder** it by dragging its handle, and bring a removed one back with **Add column**. Hover the
info icon beside a label to see its original name. **Commission item** always stays first in the
payout details, because it names each row and carries its menu and the **Total** line; you can rename
it but not remove or move it. The payouts table needs at least one column before **Save** is
available. The choice is saved on that section, so two experiences, or two sections on one
experience, can show partners different columns. Publish the experience to put it in front of
partners.
A section you have never configured shows every column in the order above. That includes
**Commission statement**, which gives every payout a **Download statement** link. It renders the
statement from the payout's current lines at the moment the partner clicks, so the file they get is
never older than the payout, and a payout with no commission items on it answers **No statement
yet** instead of an empty PDF. Hiding a column only changes what the table shows; it is not a
permission.
Partner contacts who only see the records they collaborate on, because **See all shared records** is
off on their [segment](/features/partners/segments/technical), get a narrower view. Their payout
list and payout detail only carry the lines from their own deals, and the statement and invoice
columns read `-` for them, since both documents cover the whole partner. Lines with no deal behind
them, such as manual adjustments, stay visible to them. An AI assistant answering that contact reads
the same narrowed view.
When you pay with [Introw Pay](/features/commissions/introw-pay/technical), add the **Payout setup**
section beside it, so partners can set up and check how they get paid in one place. See
[Choose what partners see in the Commissions section](/features/commissions/payouts/guides/choose-what-partners-see-in-the-commissions-section).
### Building a payout over the API
A payout can be assembled end to end without opening Introw: `POST /api/v1/payouts` opens one for a
partner and a period, `POST /api/v1/commission-lines` attaches each line to it, and
`POST /api/v1/payouts/{id}/statement` renders the statement PDF and returns a signed link to it.
A payout covers one partner, and the batch is the run around them, which is what the Payouts page
lists as a period. A payout created on its own opens a batch of its own, so a run that covers
several partners starts at `POST /api/v1/payout-batches` instead: it opens the period once and a
draft payout for every partner you name. Pass that batch id when you add a partner to a run that
already exists.
All four need the **commissions:write** scope. See
[Feed your finance stack from Introw](/features/commissions/payouts/guides/export-commission-data-to-your-finance-stack).
## How-to guides
* 
[**Choose what partners see in the Commissions section**](/features/commissions/payouts/guides/choose-what-partners-see-in-the-commissions-section)
Add the Commission section to a portal experience, choose which payout and commission item columns partners see and what they are called, add the Payout setup section on Introw Pay, and publish.
* [**Feed your finance stack from Introw**](/features/commissions/payouts/guides/export-commission-data-to-your-finance-stack)
Get commission and payout data into your ERP or accounting tool as CSV or through the API, write payment status back, and book one-off rewards from workflows or the API so they join the next payout.
* [**Request a partner invoice**](/features/commissions/payouts/guides/request-a-partner-invoice)
Follow the invoice-first payout path - generate a commission statement, request a partner's invoice, and collect it for approval before you pay.
* [**Run a payout cycle**](/features/commissions/payouts/guides/run-a-payout-cycle)
Run a payout cycle from a new batch of earned commission to partners marked paid, generating and sharing partner statements at each stage, and hand the payment itself to Introw Pay or your finance stack.
## Troubleshooting
Only lines at **Expected** are batched, so a line at **Potential** is not on any payout until its record qualifies. A payout cannot always be deleted depending on its stage, so decline or postpone it instead where that applies. Statements use your commission billing info, so set that before generating them. Once Introw Pay has paid a payout, **Mark as unpaid** is unavailable.
They had no earned lines for the period, or their balance was below the minimum payout amount and rolled forward.
Your commission billing info is not fully set.
Its stage prevents deletion. Decline or postpone it instead.
On Introw Pay, the partner's bank rejected the payment or the invoice was only partially paid. See [Introw Pay troubleshooting](/features/commissions/introw-pay/technical#troubleshooting).
# Configure commission and payout settings
Source: https://docs.introw.io/features/commissions/settings/guides/configure-commission-payout-settings
Configure commission and payout settings - the payout method, payout schedule, minimum amount, billing details, and the currency and fiscal year every calculation uses.
Before you run payouts, a handful of settings decide how and when partners get paid and what their statements say. This guide configures them end to end: the payout method that decides who moves the money, the payout schedule that sets the rhythm, the minimum amount that avoids tiny payments, the company billing info printed on statements, and the currency and fiscal year that commission amounts and schedules depend on. Set these once and every payout cycle runs predictably on top of them.
## What you'll achieve
A fully configured commissions program: a payout method your finance team has chosen, payouts that run on a cadence partners can rely on, balances below your minimum roll forward instead of generating trivial payments, statements carry complete and invoice-ready company details, and amounts and fiscal-quarter timing use the right currency and fiscal year.
## Before you start
You need admin access to commission settings and company settings.
Have your company name, address, finance email, and tax or company registration numbers ready for the statement billing info.
## Watch it
## Steps
### Phase 1 - Choose the method, schedule and minimum
Go to [Payout Settings](https://app.introw.io/commission?section=settings). Under **How will payments be sent to partner?**, pick who moves the money:
* **Manual invoicing** - Introw emails partners their statement and invoice instructions. Your team pays outside Introw, from a CSV export or through the API, and marks payouts paid.
* **[Introw Pay](/features/commissions/introw-pay)** - you pay one consolidated invoice per cycle and Introw Pay distributes it to every partner, with verification performed per partner. It is included in every plan, with a percentage fee on the transactions Introw Pay processes. See [Activate Introw Pay](/features/commissions/introw-pay/guides/activate-introw-pay) for the extra checks it needs.
Start with manual invoicing if finance has not decided yet; you can switch later without touching plans or existing payouts.
Set **Payout schedule** to the rhythm your program pays on:
* **Every month** or **Every quarter** - a batch is created when each calendar period closes, covering that period.
* **Every fiscal quarter** - align payouts to your fiscal calendar instead of the calendar year (this relies on your fiscal year start, set later).
* **Manual** - no automatic batches; you create each payout yourself when you are ready.
A non-manual schedule lets Introw create payout batches automatically on the chosen cadence, so payments happen on time without someone remembering to start them.
When the schedule is not manual, **Minimum payout amount** is required and must be above zero, so small balances are not paid until they are worth the admin:
* **Minimum payout amount** - the threshold a balance must reach before it is paid. Balances below it roll forward to a later cycle.
* Basis - choose **Per partner** to apply the minimum to each partner's own balance, or **Organisation total** to apply it across the program.
The minimum is hidden and does not apply when the schedule is **Manual**. Choose **Save** in the page header; the confirmation reads **Payout settings saved**.
### Phase 2 - Set the currency and fiscal year
Go to [Company settings](https://app.introw.io/settings/company) and confirm the values commissions depend on:
* **Company currency** - your default currency, used for batch totals and the minimum payout amount. Introw Pay needs it to be EUR or USD, and issues its consolidated invoice in US dollars for now.
* **Fiscal year start date** - when your fiscal year begins. This drives the **Every fiscal quarter** schedule and the year-to-date analytics on plans, so a wrong start date misaligns fiscal-quarter payouts.
### Phase 3 - Set the commission billing info
Go to [Billing info](https://app.introw.io/settings/company/billing-info) (the **Billing Info** tab in company settings). These details appear on every generated commission statement and tell partners what to put on their invoices.
Fill in the billing fields so statements are complete and invoice-ready:
* **Company Name** - your legal entity name as it should appear on statements.
* **Address Line 1** and **Address Line 2** - your billing address.
* **Postal Code**, **City**, and **Country Code** - the rest of the address.
* **Finance Email Address** - the contact partners use for billing questions.
* **Company Number** and **VAT Number** - your registration and tax numbers, needed for partners to invoice you correctly. Introw validates the VAT number when you save.
Choose **Save**. Incomplete details produce incomplete statements, so fill in everything your partners need to raise a valid invoice.
## Verify it worked
Payout settings show your chosen method, schedule and minimum, and on a non-manual schedule Introw begins creating batches on that cadence. On Introw Pay the Commission area gains a **Payments** tab. Company settings show the right currency and fiscal year start, and a generated commission statement displays your complete billing details, ready for a partner to invoice against.
## Related
Use these settings to run and pay a batch.
The extra checks Introw Pay needs before the first run.
Generate a statement that uses this billing info.
Full configuration options.
# Settings
Source: https://docs.introw.io/features/commissions/settings/index
Run partner commissions predictably: choose Introw Pay or manual invoicing as the payout method, set the payout schedule, minimum amounts, currency, fiscal year, and the billing details used on statements and invoices.
> Commission Settings make the whole program run on autopilot the way you want: choose whether Introw Pay or your own finance stack pays partners, how often payouts happen, hold small balances until they are worth paying, and set the billing details that appear on every statement and invoice.
## The problem it solves
Inconsistent payout rules create confusion and extra work:
| Without Introw | With Introw |
| - | - |
| Who pays partners is a debate | One payout method, set once |
| Payout timing is ad hoc | A schedule you set once |
| Tiny balances clog it up | A minimum rolls them forward |
| Statements lack the details | Your billing info on each one |
| Currency and periods are unclear | Aligned to your fiscal year |
## Impact
Predictability is the whole point. A partner who knows payouts run on the first of the quarter stops asking, and starts planning around it.
for your business
* **Cost to run**
The rules are set once and every cycle follows them, so nobody re-decides the cadence each month
* **Trustworthy**
Statements carry your real billing details, and minimums keep the run free of trivial payments
for your partners
* **Self-serve**
They know when payouts run, so nobody has to ask when the next one is
* **Enabled**
A statement carrying the right billing details is one their finance team can process
* **Efficient**
Small balances roll forward instead of arriving as payments not worth banking
[A day in the life of your partners](/days-in-the-life)
* **Partner Operations** - the rules set once
* **Finance** - billing details and minimums
## How it works
Commission Settings define how your payout program behaves by default. You choose the payout
method: Introw Pay, which settles every partner from one consolidated invoice, or manual invoicing,
where Introw emails statements and your team pays outside Introw. You choose a payout schedule,
monthly, quarterly, fiscal quarterly, or manual, so payouts happen on a predictable cadence. You set a minimum payout amount so tiny balances roll forward instead of generating
trivial payments. And you set the company billing information that appears on the statements
partners receive and on the invoice Introw Pay issues to you.
These settings, together with your organisation's currency and fiscal year, keep the commission
program consistent run after run. Once configured, your team spends its time reviewing and paying
rather than re-deciding the rules each cycle.
Commission Settings turn one-off decisions into standing rules. Configure the payout method,
schedule, minimums, and billing details once, and every payout cycle follows them. The program runs predictably, and
your team focuses on review and payment.
## Run it from your AI assistant
* How is commission calculated for referrals versus resale?
* What currency are our commissions reported in?
* What rate tiers and installments does each active plan use?
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Switch the payout method to Introw Pay.
Defaults every plan inherits.
Set how and when payouts run.
Define the currencies partners are paid in.
# Settings
Source: https://docs.introw.io/features/commissions/settings/technical/index
Configure the payout method (Introw Pay or manual invoicing), the payout schedule, minimum amounts, currency, fiscal year, and the billing info used on statements and invoices in Introw.
## Where it lives
Settings sits under **Commission**, at [Payout Settings](https://app.introw.io/commission?section=settings). Currency, fiscal year and billing info live in [Company settings](https://app.introw.io/settings/company).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Write access to commissions | Payout method, cadence and minimum live there | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Admin access to company settings | Currency, fiscal year and billing info | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
## How it works
Commission behavior is controlled in a few places. **Payout Settings** decides how partners are paid, when batches are created, and the minimum a balance must reach. Your company settings define the currency and fiscal year that payouts and plan analytics use. Your billing info, also in company settings, prints on the statements partners receive and, on Introw Pay, on the consolidated invoice Introw issues to you.
When the payout schedule is not manual, Introw creates payout batches on the chosen cadence for the period that just closed, and the minimum holds small balances back until they are worth paying.
## Settings & configuration
### Payout method
**How will payments be sent to partner?** offers two options:
* **Manual invoicing** - Introw emails partners their statement and invoice instructions. Your team can still edit payouts, pay outside Introw, and mark them as paid.
* **[Introw Pay](/features/commissions/introw-pay)** - you send a single payment to Introw, and Introw Pay distributes it to all your partners automatically, with verification performed per partner. It is included in every plan, with a percentage fee on the transactions Introw Pay processes; it stays locked until it is switched on for your account.
### Payout schedule
**Payout schedule** sets when batches are created: **Every month**, **Every quarter**, **Every fiscal quarter**, or **Manual**. On a non-manual schedule, Introw creates the batch when the period closes, covering that month, quarter or fiscal quarter. **Manual** means you create every batch yourself with **Create payout**; the dialog still proposes a period for you. **Every fiscal quarter** depends on your fiscal year start.
### Minimum payout amount
Shown for every schedule except **Manual**, and required to be above zero to save. **Minimum payout amount** is the balance a payout must exceed before it is created; smaller balances roll forward to a later cycle. **Per partner** applies it to each partner's own balance; **Organisation total** applies it to the whole batch, so either everyone is paid or the cycle is skipped. The amount is in your company currency.
### Currency and fiscal year
Set **Company currency** at [Company settings](https://app.introw.io/settings/company); it is the currency of batch totals, the minimum, and your Introw Pay invoice. Introw Pay currently issues invoices in **EUR** and **USD**. Set **Fiscal year start date** on the same page; it drives the **Every fiscal quarter** schedule and the year-to-date figures on plans.
### Commission billing info
Set your company details at [Billing info](https://app.introw.io/settings/company/billing-info): **Company Name**, **Address Line 1**, **Address Line 2**, **Postal Code**, **City**, **Country**, **Finance Email Address**, **Company Number** and **VAT Number**. They print on every partner statement and tell partners what to put on their invoices. Introw validates the VAT number when you save. Until billing info is complete, statements cannot be generated and **Request partner invoice**, **Mark as paid** and **Pay now** are blocked.
## How-to guides
* 
[**Configure commission and payout settings**](/features/commissions/settings/guides/configure-commission-payout-settings)
Configure commission and payout settings - the payout method, payout schedule, minimum amount, billing details, and the currency and fiscal year every calculation uses.
## Troubleshooting
The minimum payout amount is hidden and does not apply when the schedule is **Manual**, and must be above zero on any other schedule. Fiscal-quarter schedules depend on your fiscal year start being set correctly. Statements and invoices rely on complete billing info.
The schedule is set to **Manual**.
Enter a minimum payout amount greater than zero, or switch the schedule to **Manual**.
The fiscal year start is not set correctly.
Commission billing info is incomplete.
# Connect a form to your CRM
Source: https://docs.introw.io/features/forms/crm-automations/guides/connect-a-form-to-your-crm
Map fields to CRM properties, control how submissions create or update records, attribute them to the partner, and prefill from known data.
> For partner ops or a CRM admin turning partner submissions into clean, attributed CRM records.
A form only pays off when its data lands in the CRM correctly, with no re-keying and no duplicates. This guide wires a form to your CRM end to end: map each field to a property, decide whether a submission creates or updates records and how it fills each property, tie every record back to the submitting partner, and prefill known data so partners confirm instead of retype. It works with HubSpot and Salesforce, with the CRM-specific differences called out where they matter.
## What you'll achieve
A form whose submissions write straight into your CRM the way you intend - creating or updating the right objects, filling properties without clobbering good data, attributed to the correct partner, and prefilled from a known record when the form is opened in context. Partner-attached pipeline and reporting stay accurate without manual cleanup.
## Before you start
A CRM integration (HubSpot or Salesforce) must be connected and synced. Without it, the mapping controls do not appear.
The form should already have its fields (see [Build and publish a form](/features/forms/form-builder/guides/build-and-publish-a-form)).
Decide which CRM objects each submission should affect and which properties matter, so you map deliberately.
## Watch it
## Steps
### Map fields to CRM properties
Go to [Forms](https://app.introw.io/forms), open the form on the **Form builder** tab, and select a field. In its **CRM Mapping** section, choose the CRM object the field belongs to and the property its value should write to. A mapped field carries the property's name and type, so the submitted value goes to exactly the right place. Map every field whose answer belongs in the CRM; leave purely informational fields unmapped.
### Configure what each submission writes
Open the **Automation** tab. The column beside the form lists everything a submission does, in four groups: **Submission**, **Review**, **Notifications** and **Records written**. Every CRM record the form writes is an entry under **Records written**, such as **Company**, **Contact** and **Deal**, with a count of the fields it maps. Choose **Add automation** at the bottom to add one for another object, and select an entry to open it.
The automation opens on **Which `
Under **Match on these fields**, choose the form fields that identify an existing record, so a submission updates the right one instead of creating a duplicate. It appears on company, contact and custom object automations. A deal automation has no picker, because a deal matches through the company and contact the same form writes. With none set, Introw uses standard matching: name plus domain or website for companies, email for contacts, and every form-mapped field for a custom object. A fixed value under **Default values** never counts as a match field, so setting one does not stop a custom object from matching. When nothing on the form can identify an existing record, the automation says so, because every submission then creates a new one, or, with **Match only**, writes nothing.
Inside the automation, configure values in two places:
* **Form fields** - pair a **CRM property** with a **Form field**, so the submitted value fills it.
* **Default values** - set a fixed **Value** for a CRM property regardless of what the partner submits. Use this for constants like the pipeline, the stage, a deal-name pattern, the owner or, on Salesforce, the **Record Type**.
For each row, set the **Write mode**:
* **Fill in if not known** - only writes when the property is empty, so you add missing data without touching existing values. This is the safe default for updates.
* **Overwrite** - always replaces the current value. Use it only when the form is the authoritative source for that property.
Below your own default values, locked rows show what Introw fills itself when the form is submitted, such as the link to the partner behind the submission. Hover a row to see what it points at, or map the same property yourself to override it.
### Attribute submissions to the partner
In the automation's **Partner links** block, keep **Submitting partner** on and pick the methods Introw uses to link the record to them, such as **Partner Attribution**. The methods are the ones you already defined on your CRM connection, so there is no per-form wiring. This is what keeps partner-sourced pipeline attributed in the CRM rather than landing as orphaned records.
Share the form with a **Partner link** so submissions are related to that partner, or capture the partner with a partner picker field. Without a known partner, attribution has nothing to write.
### Prefill from a known CRM record
When a form is opened with a CRM record's context - for example from a CRM embed on that record - its mapped fields prefill with the record's current values. Partners then confirm or correct known data instead of retyping it, which speeds up submission and keeps values consistent. Prefill relies entirely on the field mapping from the first phase, so any field you want pre-populated must be mapped to a property.
### Create a partner from a submission (optional)
For forms that onboard brand-new partners (a partner application, for example), choose **Add automation** and add **Partner automation** to create a partner directly from a submission. In its panel you map the **Partner name** and **Partner domain** from form fields, optionally set the new partner's **Tier**, **Phase**, and **Partner manager**, choose the portal **Experience** and **Partner portal access** (**Restricted to invited users** or **Restricted to partner domain**), and optionally turn on **Auto-invite submitter** with a **Welcome message** so the submitter is invited automatically. Note that adding this automation turns off channel-conflict analysis on the form, since the submission is creating a partner rather than registering against an existing one.
### CRM-specific differences
On HubSpot, a CRM object automation has an **Association labels** section, so created records are linked with the right labeled association (for example which company a contact belongs to). Leave **Use default association label** on unless your HubSpot setup uses specific labeled associations.
On Salesforce, pick the Salesforce object each automation targets and map fields to the matching Salesforce fields. The create/update, write-mode, attribution, and deduplication behavior is the same; only the object and field names differ by CRM.
## Verify it worked
Submit a test through a partner link. In your CRM, the expected records are created or updated with the right values, existing data is preserved where you chose fill-if-empty, no duplicate is created for a matching record, and each record is attributed to the submitting partner. Opening the form from a record's context shows its fields prefilled.
## Related
Create the form and fields you map here.
Review and approve submissions before they act.
Full configuration options.
# CRM Automations
Source: https://docs.introw.io/features/forms/crm-automations/index
On submit, Introw forms map fields to CRM properties, attribute to the partner, match existing records to prevent duplicates, and enrich with partner data.
> A form is only as good as what it does with the answer. Introw's CRM automations turn an accepted submission into the right CRM records - mapped, attributed, and deduplicated - without anyone re-keying. The result flips the usual worry about partner-submitted data: instead of a pile of duplicates, Introw matches what already exists and enriches it.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Someone re-keys the submission | It writes the CRM record |
| Partner data brings duplicates | It matches and updates instead |
| Existing records get clobbered | Gaps filled, nothing overwritten |
| Attribution is wired per form | Configured once, reused by all |
## Impact
Partners stop submitting when nothing seems to happen with what they send. A submission that becomes a real CRM record their vendor acts on is what keeps the pipe full.
for your business
* **In your CRM**
A company, contact, lead, deal, ticket or custom object, written with the attribution you already defined
* **Cost to run**
Mapping, match keys and write modes are configured per form by partner ops, with no engineering
* **AI, not admin**
Matching feeds channel-conflict detection, and AI can validate a submission before it writes anything
for your partners
* **Self-serve**
Their answers identify them automatically, so there is no account matching for anyone to do by hand
* **Enabled**
What they submit enriches the record your sales team already owns, which is why it gets used
* **Efficient**
They submit once and it exists everywhere, rather than being re-entered and diverging
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Operations** - mapping, attribution, match rules
* **RevOps** - duplicate policy and write modes
## See it work
* 
**Add an automation**
Each form carries its own automations on the Automation tab.
* 
**Link to the CRM**
Auto-link to the CRM, then add company and contact automations.
* 
**Set the write mode**
Starting values, and whether they fill gaps or overwrite.
## How it works
When a submission is accepted, its automation runs a full sequence against your CRM, all configured no-code per form:
* **Field mapping** - each form field maps to a CRM property on the object you choose (company, contact, lead, deal, ticket, or a custom object), writing the submitted value or a fixed value.
* **Auto-attribution** - Introw attaches the partner to the created or updated record using the **attribution method you already defined** on Object Linking. That can be a property, a HubSpot association, a Salesforce lookup, or a relation-table row. You configure attribution once; every form reuses it. See [how to attribute deals to partners](/features/integrations/crm/attribution).
* **Default identity fields** - standard submitter fields (email, first and last name, company) map out of the box, so a partner is identified and their company and contact resolved without custom wiring.
* **Deduplicate, don't duplicate** - before creating anything, Introw looks for the existing record and **updates it instead of making a copy**. It matches a company by name and domain, a contact by email, a deal by its account and contacts. RevOps can tune the exact match keys per object.
* **Enrich the match** - when it finds an existing record, Introw fills the gaps from the submission without clobbering what is already there. The partner's answers become a **second-party enrichment source** for records your sales team already owns.
The flip worth naming: normally a form is where CRM data goes to rot, because someone retypes what the CRM already knows and gets it slightly wrong. Here the form is where the CRM gets cleaner. Prefilled fields come from the live record, so the partner confirms rather than retypes. Mapped answers write straight back to the properties that drive reporting. And an automation can create the follow-up work the moment the answer lands. The partner does less and your data ends up better than before they submitted.
That is why partner-submitted data does not frighten RevOps here. A submission matches the existing company, contact and deal and updates them, so a form never spawns a second copy of a record you already have. On a match the partner's answers fill missing fields - fill-if-empty by default - which makes every submission second-party enrichment rather than noise. You choose the match keys, which fields write, and whether each fills-if-empty or overwrites, so the automation obeys your data model. And when a submission matches an existing *deal*, that is [channel conflict](/features/ai/channel-conflict): Introw flags it for review instead of silently writing.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
submit["Accepted submission"] --> match["Match existing record"]
match --> decide["Update and enrich, or create if new"]
decide --> attribute["Attribute to the partner"]
attribute --> crm["Clean, attributed CRM record"]
```
## Run it from your AI assistant
* When Acme submits a lead, does it update the existing company or create a new one?
* Which fields does the deal-registration form write back to the CRM?
## Going deeper
Configure mapping, attribution, matching, enrichment, and approval.
Integration surface and code.
**Works with**
Automations are configured per form.
Runs on every submission, from any channel.
Writes back using your attribution method.
Matching screens submissions against existing pipeline.
# CRM Automations
Source: https://docs.introw.io/features/forms/crm-automations/technical/index
Configure what a form does on submit: map fields to CRM properties, attribute to the partner, match records to avoid duplicates, and enrich fill-if-empty.
## Where it lives
CRM Automations sits under **Portal**, at [Forms](https://app.introw.io/forms).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| A connected CRM | Automations write into it | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
| Write access to forms | Automations are form config | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| The objects and properties you target | You map onto what exists | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
## How it works
Mapping happens in two linked places. In the form builder, each field can be mapped to a CRM
object and property, so the submitted value knows where it belongs. In the form's Automation
tab, CRM object automations decide what happens on submit: which object is created or updated,
how each property is filled, and how the record is attributed to the partner.
Two things run automatically on top of mapping. First, Introw **matches an existing record** before it creates one, so a submission updates the company, contact, or deal you already have instead of duplicating it. Second, it **attributes** the record to the partner using the method you configured on [Object Linking](/features/integrations/crm/attribution) - no per-form attribution wiring. A submission that matches an existing deal is treated as [channel conflict](/features/ai/channel-conflict) and held for review rather than written blind.
Forms can also prefill mapped fields from an existing CRM record when opened with that record's
context, so partners confirm known data instead of retyping it.
## Settings & configuration
Mapping is configured in the form builder and the form's Automation tab.
### Field-level mapping
In a field's settings, map it to a CRM object and property. The field then carries the property
name and type so its value writes to the right place.
A field mapped to a picklist also inherits that picklist's **options**, live from the CRM, so the
values partners choose are always ones the CRM accepts. You can limit which of them this form
offers by unchecking options in the field's configuration: an opt-out list, so options added in the
CRM later still appear automatically. See
[Dropdown options](/features/forms/form-builder/technical#dropdown-options).
### CRM object automations
In the Automation tab, add a CRM object automation for each object a submission should affect.
Configure how each property is set, either from a form field or a fixed value, and the write
behavior, such as filling only if empty or overwriting.
A few properties need a word:
* **Record Type** (Salesforce) - set it under **Default values** to pick the record type the record is created with. **All pipelines** leaves it to the connected user's default record type.
* **Lookups to another record from the same form** - under **Default values**, a lookup can be set **From the Contact automation** (named after the other automation's record), so a deal points at the contact another automation on this form creates. Introw runs the automations in the order those links need, and warns when two automations point at each other.
* **Account ID** (company lookups) - a property that points at a company or account, such as Salesforce `AccountId`, offers **Submitting partner account ID** under **Default values** instead of a list of live CRM accounts. On submit Introw writes that partner's own company record ID.
* **Partner contact** - a property that points at a contact offers **Partner contact** under **Default values**. On submit Introw writes the contact of the person who submitted the form. It never writes a contact that sits on a different account than the submitting partner's, and leaves the property empty when no contact qualifies, so your CRM's own lookup filter does not reject the record.
* **Stage fields** - a stage property offers the stages of the pipeline you chose, and shows **Select pipeline first** until you choose one. On a HubSpot custom object with a pipeline, the stage offers that object's own stages. Salesforce stage and status fields never wait on a pipeline or record type.
### Create versus update
Automations control whether a submission creates a new record, updates an existing one, or skips
creation. When a partner selects an existing CRM object in a field, you can choose whether to
still create a new record. A partner can clear a picked record with the X on the picker, or by clicking the selected row again, and a record that opened the form from a call-to-action does not refill a picker they cleared. On a required field, an empty picker fails as **Field is required**.
### Matching and deduplication
Before creating, Introw looks for the record that already exists so a form never spawns a duplicate: a **company** matches on name and domain (including the domain of the submitter's email), a **contact** on its email addresses, and a **deal** on its associated account and contacts within a recent window. When a match is found, Introw updates that record instead. You can tune the match keys per object under **Match on these fields**, so the identity rule fits your data model. Companies, contacts and custom objects get that picker; a deal has none, since it matches through its company and contact. A custom object with no saved match fields matches on the properties the form maps, and fixed **Default values** are left out of that comparison, so a constant such as an owner never makes a matching record look new.
### Identify the submitter
Standard submitter fields - email, first and last name, company - map out of the box, so Introw resolves who submitted and links their contact and company without custom setup. This is what lets attribution and matching work from a plain form.
### Enrichment as a second-party source
Because matched records are updated with **fill-if-empty** by default, the partner's answers fill the gaps you are missing without touching values a rep already set. That turns every submission into a clean second-party enrichment of the records you own, rather than a source of conflicting duplicates.
### Write behavior and safety
Each mapped property carries a write mode, and Introw defaults to the safe one:
* **Fill in if not known** (the default) - Introw re-reads the live CRM value and writes only when it is blank, so it never overwrites a value a rep already entered.
* **Overwrite** - always set the value, for the few fields you want a submission to be authoritative on.
Empty or unmapped values are skipped rather than written, so a submission can never blank out a field. And only fields you have marked **editable** can be written from Introw at all - the same allowlist governs writes from a form, the partner portal, and an AI agent, so a field you did not expose is never touched.
### When records are written
A submission that needs no review is accepted on submit, and its CRM automation runs straight after, in the background.
The partner sees the confirmation screen right away instead of waiting on the CRM, and a pipeline section in their portal adds the new record by itself a few seconds later, without a reload.
Your team's submission notification goes out once the records exist, and a CRM write that fails reaches your team as a submission error instead.
A submission held at an approval gate writes when it is accepted.
### Partner attribution
Created or updated records are attributed to the submitting partner using the **method you already defined** on Object Linking - a property, a HubSpot association, a Salesforce lookup, or a relation-table row - so you never wire attribution per form. A partner chosen in a partner-select field can be attributed as a secondary partner the same way. See [how to attribute deals to partners](/features/integrations/crm/attribution).
The automation's **Partner links** block is where that lands per form, and **Default values** shows the result rather than hiding it: the attribution property, and any lookup your CRM will not create the record without, sit there as locked rows you can hover to see what they point at. Map the same property yourself to override one.
When a default value you set already sends the attribution, Introw skips its own write for it, and **Partner links** says so: ` is set as a default value, so it is not listed as a partner link.`
### Prefill
When a form is opened with a CRM record's context, mapped fields can prefill from that record so
partners confirm rather than retype.
A CRM object field's filters bind the partner too.
A field limited to one pipeline only offers records in that pipeline, a prefilled record outside the filters is dropped, and the submit checks the choice again.
A partner whose record fell out of the filters meanwhile reads: `One of the records you selected is no longer available on this form. Refresh the page and pick again.`
The same rule applies over the [forms API](/features/developer/api/technical), which refuses such a submission.
## How-to guides
* 
[**Connect a form to your CRM**](/features/forms/crm-automations/guides/connect-a-form-to-your-crm)
Map fields to CRM properties, control how submissions create or update records, attribute them to the partner, and prefill from known data.
## Troubleshooting
Mapping depends on a connected CRM integration, so connect HubSpot or Salesforce first. Write behavior matters: overwrite can replace existing CRM values, so use fill-if-empty when you only want to add missing data. Attribution requires the right mappings, or records may sync without being tied to the partner.
The field is not mapped, or no CRM automation targets that object.
The write behavior was set to overwrite instead of fill-if-empty.
The attribution mappings are missing or incomplete.
A form field, or another automation that a **From the … automation** default points at, no longer exists, usually because someone deleted it. Introw highlights the rows to fix: **Remap or remove the highlighted rows in Form fields**, or in **Default values**. Until you do, those rows write nothing.
# Build and publish a form
Source: https://docs.introw.io/features/forms/form-builder/guides/build-and-publish-a-form
Create a no-code partner form in Introw: add and configure fields, set the confirmation screen, and publish it via link, embed, portal, or the API.
> For partner ops or partner marketing standing up a new way to collect structured partner input.
Every partner motion that captures input - deal registration, referrals, MDF requests, onboarding, event signups - runs on a form. This guide takes you from an empty form all the way to a live one partners can fill in, covering every field type, the confirmation a partner sees after submitting, and the four ways to deliver the form. Build it once here and reuse the same form across links, your portal, an embed, and the API.
## What you'll achieve
A published, branded form with the exact fields you need, a clear confirmation screen or redirect, and a way for partners to reach it - a general link, a partner-specific link, a section in a partner portal, an embed on your own website, or an API call from your own systems. Submissions flow straight into your **Submissions** inbox.
## Before you start
You need write access to forms.
Know the information each submission must capture and, if relevant, which CRM objects it should feed, so you pick the right field types as you build.
Embedding the form on your own website needs a verified custom domain. A general or partner link and a portal section work without one.
## Watch it
## Steps
### Create the form
Go to [Forms](https://app.introw.io/forms) and create a form. Give it a clear, purpose-led name (for example "Deal registration" or "MDF request") - the name is how you and your team find it later and what partners see at the top of the form. The form opens on the **Form builder** tab, where you add fields and lay out the page. Forms automatically use your portal branding, so the header, colors, and button already match your portal and there is nothing extra to style.
### Build the fields
On the **Form builder** tab, use **Add to form** to insert each input, or type `/` in the body to reach the same menu. Choose the type that matches the data you want, so submissions come in structured rather than as free text:
* **Input field** - a single-line text box for short answers like a name or reference number.
* **Text area** - a multi-line box for longer notes or context.
* **File upload** - lets a partner attach documents such as proof of certification, an invoice, or a signed agreement. Use this whenever you need an artifact, not just text.
* **Checkbox** - a single tick box, ideal for consent or terms acceptance (it defaults to a terms-and-conditions label you can rewrite).
* **CRM Object** - a picker that lets the partner select an existing record from your CRM (for example a deal or company), so the submission attaches to the right object. Partners can clear their pick with the X on the picker.
* **Quote Selector** - shows quotes from a selected deal, for motions where the partner picks a quote.
* A partner picker (added as **Distributor** or **Reseller**) - lets the submitter choose the partner the submission relates to, which you can use for attribution.
* **Batch Upload** - lets a partner submit many records at once by CSV. For that whole job, see [Bulk upload multiple records](/features/forms/sharing-submitting/guides/bulk-upload-multiple-records).
A form is not only fields. The same menu adds content blocks that make a long form easier to complete:
* **Subtitle** headings, a **Columns layout**, and **Image** break the form into readable sections.
* **Videos** embed a **YouTube**, **Loom**, **Vimeo**, or **Vidyard** clip straight into the form, with **Embed other** for any other provider. Paste the share URL and it renders inline. Use one to explain what a deal registration needs before the partner starts filling it in, or to walk through the fields of an application form, so the explanation sits with the form instead of in an email nobody opens.
Select a field to open its settings on the right, then set:
* **Label** - the question or prompt the partner reads. Keep it specific so answers are consistent; you can enable **Label (supports bold, underline, links)** for richer formatting.
* Placeholder - the greyed-out example text inside the input that hints at the expected format.
* **Make this field required** - turn this on for any field a submission cannot be without. Required fields block submission until filled, which is what keeps your data complete.
* **CRM Mapping** - optionally link the field to a CRM object and property so its value writes straight to your CRM with no re-keying. This is optional here; the full create/update behavior is covered in [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm).
Specialized fields add their own settings: a **CRM Object** field has **CRM Object Configuration** (its **Object Type**, **Label Property**, and **Filters** for which records appear), and a partner picker has **Partner Filters** (which partners show in the dropdown) and **Attribution Configuration**.
When a field is mapped to a CRM picklist, its options are synced live from your CRM, so you never maintain a second list. Under **Options (n/m shown)**, uncheck the values this form should not offer - internal-only lead sources, stages partners have no business setting, regions this form does not cover. **Select all** and **Clear all** reset the list.
This is opt-out on purpose: everything is shown unless you hide it, so a new option your team adds in the CRM shows up on the form automatically rather than quietly going missing. You keep the CRM as the source of the list and still give partners a short, relevant set of choices.
Prefer hiding options here over building a separate unmapped dropdown with typed-in **preset options**. A preset list is yours to maintain forever and drifts from the CRM the moment someone adds a value; a limited CRM list cannot drift.
Arrange fields top to bottom in the order you want partners to complete them, and drop in **Subtitle** headings or a **Columns layout** to group related questions. A clear, well-sectioned form is finished more often than a long unbroken list. The submit button reads **Submit** by default.
### Set the confirmation
Open the **Automation** tab and select **Submission confirmation** - this controls the moment right after a partner submits, which is what reassures them it worked. Pick one behavior:
* **End screen** - show a thank-you message inside the form. Use this when the submission is the end of the journey; personalize the wording so the partner knows what happens next.
* **Redirect to URL** - send the partner to another page after submitting. Choose this to route them onward (for example to a resource or scheduling page), and enter the destination in the **Redirect URL** field.
If you set nothing, partners see a generic thank-you screen by default, so configure this whenever the next step matters.
### Share and publish
Choose **Share form** in the editor. The dialog has a **Link** tab, an **Embed** tab, and an **API** tab, covering the four delivery options below. A banner notes that submissions from the link and the embed are secured with reCAPTCHA to keep out spam - this is automatic, with nothing to configure.
On the **Link** tab, copy one of:
* **General link** - works for anyone you send it to. Introw attributes the submission on a best-effort basis, so use this for broad or unknown audiences.
* **Partner link** - tied to a specific partner, so every submission through it is automatically related to that partner. Use this whenever you want clean attribution without asking the partner to identify themselves.
Send the copied link by email or chat.
To collect input where partners already are, add the form as a section in a portal experience. Go to [Experience builder](https://app.introw.io/templates), open the experience, add a form section in the stage you want, and pick this form. Partners then submit in context as part of the portal rather than chasing a separate link.
On the **Embed** tab, copy the HTML snippet to place the form on your own site. This option needs a verified custom domain; if you have not set one up, the dialog prompts you with **Configure custom domain** first.
Not every submission needs a person at a form. On the **API** tab, copy the cURL snippet: it already carries this form's id and every field id, and the **Fields** table below marks which ones are required. Your own product, an internal tool, a script, or an agent can then submit this form from anywhere, running the same automations and approval flow. Full setup is in [Submit a form via the API](/features/forms/sharing-submitting/guides/submit-a-form-via-the-api).
## Verify it worked
The form appears on [Forms](https://app.introw.io/forms) and opens correctly from each link you shared. Submit a test: required fields block until filled, the confirmation behaves as you set it (end screen or redirect), and the submission lands in your [Submissions](https://app.introw.io/submissions) inbox - attributed to the partner when you used a partner link.
## What your partners experience
After you publish it, partners open the form from the portal (or your shared link), fill it in, and submit. Where you added an approval step, they can see where their submission stands - pending, accepted, declined, or returned for changes - and resubmit if you return it. So the form you build here is not just intake for you; it is a status a partner can track themselves without emailing for an update.
## Related
Let partners submit many records in one form.
Write submissions back to your CRM, attributed to the partner.
Review, approve, and notify on what comes in.
Full configuration options.
# Partner form templates & use cases
Source: https://docs.introw.io/features/forms/form-builder/guides/partner-form-templates
Partner form templates: deal registration, lead capture, support, MDF requests, partner applications, purchase orders, events, and feedback.
> For partner ops deciding what to build first. Introw forms are one engine behind many partner motions, so most of what you need is a recipe, not a new tool. This gallery shows the common partner forms, the fields each needs, and the CRM automation that turns a submission into a clean record, with a link to the full guide for each.
A form is never just a form: on submit it runs a CRM automation that maps fields to your objects, attributes the record to the partner, matches existing records so it enriches instead of duplicating, and routes through the approval you set. That is why the same builder produces a deal registration, a support request, an MDF claim, or a partner application. Pick the recipe closest to your need and start from its guide; the pattern is the same underneath.
## What you'll achieve
A clear starting point for whichever partner form you need, and an understanding of the automation that makes each one land as attributed, deduplicated CRM data rather than a row in a form silo.
## Before you start
Each recipe below assumes you can add fields and map them to your CRM. If you are new to the builder, start with [Build and publish a form](./build-and-publish-a-form) and [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm), then come back and pick a recipe.
## Pick a form to build
**Goal:** let a partner register a deal so it is credited to them and screened for overlap before it reaches your pipeline.
**Key fields:** end-customer company and contact, deal name, amount, expected close, and a partner picker (or a partner-specific link) for attribution.
**The automation that makes it work:** creates the opportunity, account, and contact in your CRM, attributes them to the partner, and runs channel-conflict screening so a registration is only credited once.
**Start here:** [Deal Registration](/features/deal-registration).
**Goal:** let a partner pass you a referral that lands attributed, even before it is qualified.
**Key fields:** prospect company and contact, a short context note, and partner attribution.
**The automation that makes it work:** creates an attributed lead (and, when partner-qualified, the opportunity, account, and contact), matching existing records so referrals enrich your CRM instead of duplicating it.
**Start here:** [Lead Sharing](/features/referrals/lead-sharing) and [Ways to refer a deal](/features/referrals/lead-sharing/guides/ways-to-refer).
**Goal:** a self-serve application that turns an applicant into a partner in one step.
**Key fields:** company details, primary contact, and any qualifying questions you screen on.
**The automation that makes it work:** creates the partner in Introw, links the company and contact records in your CRM, and invites the applicant to their portal, so onboarding starts the moment they are accepted. This is the one recipe with a partner-creation automation, which is why it has its own guide.
**Start here:** [Set up a partner application form](./set-up-a-partner-application-form).
**Goal:** run the marketing-development-fund lifecycle - request funds, claim spend, and report outcomes - as a sequence of forms.
**Key fields:** activity name and type (a picklist), requested amount, dates, and supporting detail; later stages capture proof of spend and results.
**The automation that makes it work:** each stage is a form with its own approval gate, tied to a fund budget so allocations, claims, and ROI reconcile against it.
**Start here:** [MDF](/features/mdf).
**Goal:** give partners a structured way to raise a support request instead of an unstructured email.
**Key fields:** subject, description, priority (a picklist), and the related company or deal.
**The automation that makes it work:** creates a ticket in your CRM attributed to the partner, so it enters the same queue your team already works.
**Start here:** [Build and publish a form](./build-and-publish-a-form), then map the fields to your ticket object in [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm).
**Goal:** capture PO or quote details tied to a specific deal.
**Key fields:** the related deal (a CRM object picker), line-item or amount detail, and any reference numbers.
**The automation that makes it work:** attaches the details to the deal in your CRM so quoting and fulfilment stay on the same record.
**Start here:** [Quotes](/features/cpq/quotes).
**Goal:** collect partner sign-ups for an event, webinar, or program.
**Key fields:** attendee name and email, company, and any session or preference choices (picklists).
**The automation that makes it work:** creates or updates the contact and records the registration, attributed to the partner who drove it.
**Start here:** [Build and publish a form](./build-and-publish-a-form).
**Goal:** hear from partners with a lightweight satisfaction or feedback form.
**Key fields:** a score or rating, a comment, and the partner (via a partner-specific link).
**The automation that makes it work:** stores the response against the partner so you can track sentiment over time.
**Start here:** [Build and publish a form](./build-and-publish-a-form).
**Goal:** let a partner submit a whole list - leads, end customers, or assets - in one pass rather than one entry at a time.
**Key fields:** the same per-record fields as the single-entry form, plus a batch upload field.
**The automation that makes it work:** each CSV row runs through the form's automation like an individual submission, validated against your picklists and rules before it lands.
**Start here:** [Bulk upload multiple records](/features/forms/sharing-submitting/guides/bulk-upload-multiple-records).
## Verify it worked
Whichever recipe you build, submit a test entry and confirm it lands in [Submissions](https://app.introw.io/submissions) and creates or updates the expected record in your CRM, attributed to the partner.
## Related
The builder basics behind every recipe.
Map fields, attribute, and match records for any form.
Get any of these forms in front of partners.
The full walkthrough for the application recipe.
# Set up a partner application form
Source: https://docs.introw.io/features/forms/form-builder/guides/set-up-a-partner-application-form
Turn a form into a self-serve partner application that auto-creates the partner, links company and contact records in your CRM, and invites the portal.
> For partner ops or partner marketing who want a self-serve on-ramp that recruits partners and sets them up without manual data entry.
A partner application form is how new partners join your program on their own. This guide takes the whole job end to end: build (or open) the application form, add the **Partner automation** action so a submission creates a fully populated partner in Introw, link company and contact records back to your CRM, assign each applicant a starting tier, phase, manager, and portal experience, and optionally invite them to their portal automatically. Set it up once and every accepted application becomes a real, attributed partner with a linked CRM record, no CRM workflow required.
## What you'll achieve
A published application form that, on each submission, creates the partner in Introw, links a company and contact in your CRM, applies your default tier, phase, manager, and experience, and (optionally) emails the applicant a portal invitation. You can also surface the form on your portal login page and add a human review step before anyone is created.
## Before you start
To auto-create linked company and contact records, a CRM must be connected. See [Connect HubSpot](/features/integrations/crm/guides/connect-hubspot) or [Connect Salesforce](/features/integrations/crm/guides/connect-salesforce). The partner is still created in Introw without a CRM, you just skip the CRM linking.
Assigning a portal **Experience** in the automation is what lets you auto-invite applicants. See [Build and publish a portal experience](/features/portal/experiences/guides/build-and-publish-a-portal-experience).
Decide the tier, lifecycle phase, and partner manager every new applicant should start with, so onboarding and attribution are correct from day one.
## Watch it
## Steps
### Build the application form
Go to [Forms](https://app.introw.io/forms) and open an existing partner application form, or create a new one. This form is what applicants fill in, so include the fields you need to qualify and create a partner, such as company name, website, and the applicant's contact details.
A partner application form includes a terms and conditions checkbox by default, so applicants explicitly agree before they are created. Two things make it work for you:
* **Link to your terms** - in the field label, replace the placeholder URL with the link to your own terms and conditions page so applicants can read them before agreeing.
* **Record acceptance in your CRM (optional)** - map the checkbox to a CRM property in the automation later, so you keep a clean compliance record of who accepted and when. Map it to a boolean property to record acceptance and, if you like, a date/time property to capture the moment.
If terms acceptance is not relevant for your program, remove the field.
### Add the Partner automation
Open the form's **Automation** tab (the second tab of the form editor), select **Add automation**, and choose **Partner automation**. This is the action that turns a submission into a real partner, everything below is configured inside it.
At the top of the **Partner automation** block, **Enrich Partner** matches each submission against existing partners using the form fields provided and enriches the match instead of creating a duplicate. This keeps partner data accurate and attribution clean. There is nothing to switch on, it is how the action behaves.
Under **Auto-link to CRM**, select **Add** for each record type you want created and linked in your CRM:
* **Company automation** - creates the partner company in your CRM and enables deal attribution, so you always know which partner sourced each record.
* **Contact automation** - saves the applicant as a contact in your CRM, linked to the partner company.
Both are optional but recommended for a fully linked setup. After adding each, use **Configure** to map which form fields fill which CRM properties.
### Populate and set up the partner
Under **Form fields**, map each form field to the matching partner property. At minimum map **Partner name** to your company-name field; **Partner domain** is optional. For each mapping, set a **Write Mode**:
* **Fill in if not known** - only writes when the property is empty, so you never overwrite existing data. This is the safe default for enrichment.
* **Overwrite** - always replaces the current value with the submission.
Under **Partner setup**, define fixed values applied to every partner this form creates, so applicants start correctly placed:
* **Tier** - the tier a new applicant starts in.
* **Phase** - the lifecycle stage, for example a "Potential partner" phase, so the applicant enters your funnel at the right point.
* **Partner manager** - the team member made responsible for the partner from the start.
Each also has a **Write Mode** so you control whether these overwrite an enriched partner's existing values.
### Give access and go live
Under **Portal settings**, choose the **Experience** every new partner should land in, so their portal is ready on day one. Set **Partner portal access** to control who can open it: **Restricted to invited users** (only the people you invite) or **Restricted to partner domain** (anyone on the partner's email domain).
Turn on **Auto-invite submitter** to email the applicant a portal invitation once their application is processed. Add an optional **Welcome message** that appears in the invitation email, and use **Preview email** to see exactly what the partner will receive before going live. Auto-invite requires an assigned experience.
By default every application is processed automatically. If your program has a vetting step, enable approval on the form so submissions land in your approval queue first: no partner and no CRM records are created until you approve. See [Run a submission approval workflow](/features/forms/submissions-approvals/guides/run-a-submission-approval-workflow).
Save your changes and publish the form. From now on, every accepted application instantly creates a fully populated partner in Introw and the linked records in your CRM.
### Put it in front of applicants
Anyone who reaches your partner portal without an account is a potential applicant, so the login page is the one place the form has to be.
Go to [Portal settings](https://app.introw.io/settings/portal) and open the **Become a partner** tab, beside **Login**, **Verification** and **No Access**. Pick your application form, then write the two lines a visitor reads: **Prompt text**, the question above the link, which defaults to "Don't have a partner account?", and **Link text**, the link itself, such as "Become a partner". Save the portal settings.
The link sits under the sign-in box, and only for someone who has no portal access yet, so partners who already have a portal never see an invitation to apply again. Opening it launches the form in a dialog on the login page, prefilled with the email address they just typed, so applying never means leaving your portal or waiting for a link.
The same form has a general link, an embed for your website, and an API endpoint, so a partner page, a campaign or your own product can feed the same application. See [Ways to submit a form](/features/forms/sharing-submitting/guides/ways-to-submit-a-form).
## Verify it worked
Submit a test application. A new partner appears in Introw enriched with the mapped fields and your default tier, phase, and manager; the linked company and contact show up in your CRM; and, if you enabled it, the applicant receives the portal invitation email for the experience you assigned. With approval enabled, the submission instead waits in your approval queue and nothing is created until you approve it.
Open your portal login page in a private window to confirm the **Become a partner** link is there and opens the form.
## Related
Create the form and its fields before wiring the automation.
Map form fields to CRM properties and attribute submissions.
Add a human review step before partners are created.
Full configuration options.
# Show fields conditionally
Source: https://docs.introw.io/features/forms/form-builder/guides/show-fields-conditionally
Build one form that adapts: fields that appear only when they are relevant, questions that become mandatory only when they apply, and whole sections that unfold from a single answer.
A form that asks everyone everything is the fastest way to lose a submission.
The usual escape is to split it into four near-identical forms, which then drift apart and multiply the CRM mapping you have to maintain.
Conditional fields let you keep one form and let it adapt: each field can carry rules about when it appears, so a partner sees the three questions their case needs and never the twelve it does not.
This guide builds those rules, including the pattern most people come looking for, a field that is mandatory only in one case.
## What you'll achieve
One form whose questions follow the answers.
A reason field that appears only for the outcome that needs explaining and is required the moment it appears, a whole block of follow-up questions that unfolds from a single choice, and a cascade that collapses cleanly when the partner changes their mind.
The same rules apply in the portal, in the validation that runs on submit, and in the CSV batch-upload path, so a hidden question is never submitted and never written to your CRM.
## Before you start
Conditions point at other fields on the same form, so add the fields first and wire the rules second. See [Build and publish a form](/features/forms/form-builder/guides/build-and-publish-a-form).
Every rule needs a field to read. Dropdowns and checkboxes make the best drivers because their values are a fixed set. Free text works but ages badly: a rule on typed text breaks the day someone types it differently.
## Steps
### Plan the branches before you build them
Write down the two or three real cases the form covers and, for each, the questions only that case needs. This is the whole design. A form with one driver field and three short branches reads well; a form where nine fields each carry their own unrelated rule reads like a puzzle, and nobody can tell what it does six months later.
Mark a question required only when you cannot act on the submission without it. Required is enforced only while a field is visible, so you can be strict inside a branch without punishing the partners that branch does not apply to.
### Make a field appear only when it is relevant
Go to [Forms](https://app.introw.io/forms), open your form and its builder, and select the field that should not always show. The rules live on the field that appears, not on the field that drives it, which is worth remembering when you go looking for them later.
Add a condition and point it at another field on the form, then choose how to compare its value. A field with no conditions is always visible, so the first condition you add is what makes it conditional.
The operators are the same ones Introw uses everywhere: equals, does not equal, contains, does not contain, starts with, ends with, greater than, less than, is any of, is none of, and is unknown. **Is any of** is the one to reach for when several answers should reveal the same field, because it keeps one rule where you would otherwise write three.
Add further conditions and join them with **and** or **or**, and nest groups when a rule genuinely needs both, such as an amount over a threshold in either of two regions. Keep the nesting shallow: if you cannot read the rule aloud, the partner will not be able to predict the form either.
For a multi-select field, a rule is tested against each selected value, so a condition on one option keeps matching after the partner picks a second one.
A field with conditions shows a **Conditional** pill in the builder. Use it to read the branching at a glance and to spot the field that was supposed to be conditional and never got its rule.
### Make a question mandatory only in the case that needs it
There is no separate conditionally-required setting, and this is the part worth internalising: **required is only enforced while the field is visible**. Mark the field required, then give it the visibility condition for the case it belongs to. Outside that case the field is not on screen and not enforced; inside it, the partner cannot submit without it.
The classic shape is an outcome and its explanation. Show a reason field when the outcome field equals the outcome that needs explaining, mark it required, and the reason becomes unavoidable exactly when it matters.
When you need one of two answers but do not care which, give the second field the condition "the first field is unknown" and mark the second required. Answering the first hides the second; leaving the first empty makes the second mandatory. One of the two always gets answered, and the partner never sees both demanded at once.
### Unfold a whole section from one answer
Lead with the dropdown or checkbox that decides the case, so the partner makes one choice and the form shapes itself around it rather than reshuffling as they scroll.
Apply the identical condition to each follow-up question and they appear and disappear together as a block. Headings and other content blocks are not fields and carry no rules, so keep a heading that belongs to one branch short, or word it so it reads sensibly whichever branch is open.
Point a third field at the second field's answer and you get a cascade: outcome, then reason, then sub-reason. Conditions chain and collapse together, so flipping the first answer hides everything below it in one step instead of leaving a stale sub-question on screen off a value the partner can no longer see.
### Check it the way a partner will meet it
Open the form as a partner sees it and walk every case you planned. Watch for the two failures that matter: a question that should have appeared and did not, and a required question stranded in a branch nobody reaches.
Open a branch, leave its required field empty, and submit. The submission is refused, because the same rules run in the validation on submit rather than only in the browser.
If this form accepts CSV batch upload, the same rules apply there too, so a row that does not open a branch is not asked for that branch's columns. See [Share and submit a form](/features/forms/sharing-submitting).
## Verify it worked
Submit the form once per case and open the submissions inbox.
* Each submission carries only the fields its branch actually showed. A hidden field is never submitted, never validated, and never written to your CRM, so your reports are not full of blank columns from branches nobody opened.
* The required field inside a branch is filled on every submission that opened it.
* Your CRM records carry the branch's answers on the properties you mapped, and nothing on the properties belonging to branches that stayed closed.
Conditional visibility is a relevance feature, not an access-control or security one.
It decides which questions are worth asking; it is not a way to hide sensitive content from a partner who has the form's link.
What a partner is allowed to see and do is governed by [segments and permissions](/features/partners/segments/technical).
## Limits & gotchas
* **Rules point at fields, so deleting a field breaks the rules that read it.** A condition whose field no longer exists stops matching, which hides the field that depended on it. If a question disappears after an edit, check whether its driver field was removed or replaced.
* **A malformed rule fails open.** A condition Introw cannot read is ignored rather than applied, so a field is shown rather than silently hidden. Broken rules cost you a stray question, never a lost answer.
* **Keep the driver's options stable.** A rule matches a value, so renaming the option a rule depends on means revisiting the rule.
## Related
These rules put to work on a shared deal, behind a button that hides itself.
Where the answers land, and the write modes that decide whether they stick.
The form itself, end to end.
Full configuration options.
# Test a form before partners see it
Source: https://docs.introw.io/features/forms/form-builder/guides/test-a-form-before-partners-see-it
Submit a form the way a partner will, confirm the CRM record and notifications it produces, walk every outcome, and clean up the test without leaving records behind.
> For anyone about to hand a form to partners who wants to see it work first.
A form is the only part of a partner program where a silent failure is invisible until a partner is already annoyed.
It renders fine, it accepts a submission, and the record writes nowhere because one field is not mapped or a CRM validation rule rejected the value.
The fix is five minutes of dry run, once, before anyone external sees it.
This guide is that dry run, including the cleanup, so the test does not leave a fake deal in your pipeline.
## What you'll achieve
One test submission taken all the way through: the form as a partner sees it, the submission in your inbox, the record in your CRM with the right owner and the right partner attributed, the notifications that fired, every outcome exercised, and both the test submission and its CRM record removed afterwards.
## Before you start
Test after the CRM automation is configured, not before.
A form with no automation will pass this test and still be useless.
See [Build and publish a form](./build-and-publish-a-form) and [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm).
Use an internal partner record, or a real partner you have an actual relationship with, not your largest one.
You are about to create and delete a record attributed to them.
See [Create a partner manually](/features/partners/partner-management/guides/create-a-partner-manually).
## Steps
### Submit it the way a partner will
Go to [Forms](https://app.introw.io/forms), open the form and choose **Share form**.
On the **Link** tab there are two links, and the difference matters for the test.
* **General link** is anonymous. Nobody is attributed, and the submitter has to type their own details.
* **Partner link** is scoped to one partner you select. The submission arrives already attributed to them, and the standard submitter fields resolve their contact and company on their own.
Test with the **Partner link**, because that is what a real partner uses from their portal, and attribution is most of what you are testing.
If you plan to share the form publicly, test the general link too: it exercises a genuinely different path.
Open the link in a private window or a different browser, so you see it as an outside visitor rather than as a signed-in admin.
Check the obvious things while you are there: does the form explain itself, is the field count something a partner will actually finish, and does every required field deserve to be required.
A field you cannot justify out loud is a field to cut, since every one of them costs you submissions.
Fill it as a partner would and submit.
Then submit a second time on purpose badly: leave a conditionally required field blank, put a value in a picklist-backed field that is not one of your CRM's options, and use a date or amount format your CRM is fussy about.
You are looking for two behaviours.
A validation error the partner can act on is the good outcome.
A submission that lands in **Error** means it reached Introw but your CRM refused to write it, which is almost always a required property or a validation rule on the object.
Better to find that now than on a partner's first registration.
### Follow it all the way through
Go to [Submissions](https://app.introw.io/submissions) and find it.
Check the status is the one your configuration implies: **Pending** if you set an approval gate, **Auto accepted** if you did not, or **Accepted** once you approve it.
Check the partner column names your test partner rather than being empty, since an unattributed submission cannot be bulk accepted and will not credit anyone.
This is the step people skip and the one that catches real problems.
Open the record the submission created and check it field by field:
* Every field the partner filled arrived, in the right property, in a usable format.
* The record is on the object and pipeline you intended, at the stage you intended.
* The owner is the person who should be working it, not whoever the CRM defaults to.
* The name follows your convention rather than reading as an ID.
* The partner is attributed by whichever method you configured, so reporting and commissions will resolve.
See [Configure partner deal owner and name](/features/deal-registration/registration/guides/configure-partner-deal-owner-and-name) and [Configure deal attribution](/features/co-selling/shared-pipelines/guides/configure-deal-attribution).
A form nobody is alerted about is a form that waits.
Confirm the on-submit alert reached your team, including the partnership-manager fallback if no team member could be resolved, and that it arrived on the channel you expect rather than only by email.
See [Configure the chat integration](/features/integrations/chat/guides/configure-the-chat-integration).
### Exercise every outcome
Return the test submission with a specific comment, then reopen the form as the partner.
Their previous answers should be prefilled and your comment shown with them, and their edit should update the same submission rather than creating a second one.
This is the outcome worth rehearsing, because a returned submission with a vague comment is the one that never comes back.
Decline it and confirm the partner receives your decline message rather than a bare status change.
Then use **Reopen** at the top of the declined submission and confirm it returns to **Pending** and re-enters the approval gate from the first step.
Accept it only when you are done, because accepting is the one outcome you cannot undo.
It runs the CRM automations and tells the partner yes.
See [Choose how submissions get approved](/features/forms/submissions-approvals/guides/choose-an-approval-model).
### Clean up properly
Select it in the inbox and choose **Delete**.
This permanently removes the submission and tells no partner anything, which is exactly what you want for a test.
It is not a decline, and it cannot be undone.
Deleting the submission does not delete the record it created in your CRM.
That record is real, it is in someone's pipeline, and it will show up in a forecast if you leave it.
Delete it in your CRM as a second, deliberate step.
This is the step that gets forgotten. A test deal registration that was accepted leaves a live deal attributed to a real partner, which can also flow into commission calculations. Delete it in the CRM before you move on.
## Verify it worked
You have seen the form render as an outsider, one submission arrive attributed to the right partner, one clean record in your CRM with the right owner and name, an alert reach your team, and a return arrive back with the partner's prior answers intact.
Nothing is left in the inbox and nothing is left in the pipeline.
Do this again after any change to the form's fields or its CRM automation.
It is the cheapest test in the product and the only one that covers the whole path.
## Related
The build this test verifies.
The mapping most test failures come back to.
What each outcome does to the partner.
Full configuration options.
# Form Builder
Source: https://docs.introw.io/features/forms/form-builder/index
Build no-code, on-brand partner forms in minutes and put them in front of partners through share links, website embeds, and portal sections in Introw.
> The Form Builder lets your team create on-brand forms without code and deliver them anywhere partners are: a share link, an embed, or a section in the portal.
## The problem it solves
Collecting partner information usually means messy spreadsheets and email back-and-forth:
| Without Introw | With Introw |
| - | - |
| Building a form needs engineering | Your team builds it themselves |
| Forms look off-brand | They inherit your portal branding |
| Partners cannot reach the form | A link, an embed or a section |
| Input arrives unstructured | Defined fields, every time |
## Impact
Partners judge you on the first form they fill in. One that looks like your product, asks only what it needs and offers their own records to pick from is a small thing they remember.
for your business
* **Cost to run**
Anyone on your team assembles fields, layout and branding, so a new field never waits on engineering
* **Live in days**
A form is built, branded and collecting in minutes, not after a design and development cycle
for your partners
* **Self-serve**
They fill it in with no CRM seat, and pickers offer them your real CRM records to choose from
* **Enabled**
Required fields, instructions and headings tell them what good looks like as they type
* **Efficient**
A quote selector or an object picker, instead of retyping something you already have
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Operations** - forms without engineering
* **Partner Marketing** - on-brand forms in journeys
* **Partners** - a form that is quick to finish
## See it work
* 
**What the partner fills in**
The finished form, opened where they already are and already knowing who they are.
* 
**Create the form**
Start from the builder and name it.
* 
**Add the fields**
Text, uploads, checkboxes, CRM pickers, quote selectors.
* 
**Map to the CRM**
Each field carries its own label, rules and CRM mapping.
* 
**Decide the ending**
A confirmation, an end screen, or a redirect of your own.
## How it works
The Form Builder is a no-code editor for the forms partners fill in. You add the fields you
need, from text and file uploads to CRM object pickers, set which are required, and lay them out
with headings, columns, and instructions. Forms inherit your portal branding, so they look like
your product without extra design work.
Once built, a form goes wherever partners work. Share a general or partner-specific link, embed
it on a page, or drop it into a portal experience as a section. Partners submit without a CRM
seat, and the structured data flows into your review and CRM-sync workflows. Because anyone on
your team can build a form, capturing new partner information never waits on engineering.
The Form Builder turns partner data capture into a self-serve, on-brand workflow. Build the
form, choose the fields, and deliver it wherever partners are. Structured submissions flow
straight into review and CRM sync, with no engineering and no messy spreadsheets.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
build["Build the form"] --> deliver["Deliver where partners are"]
deliver --> submit["Partner submits"]
submit --> sync["Review and CRM sync"]
```
## Run it from your AI assistant
* Which forms can I submit for Acme?
* Start a project submission form for Acme and tell me which fields are required.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Share and submit the built form through every channel.
Submissions run through approval.
Map fields to CRM properties.
Embed a form in the portal.
# Form Builder
Source: https://docs.introw.io/features/forms/form-builder/technical/index
Create partner forms in Introw: add and configure fields, set the confirmation screen, and share via link or embed the form for partners to submit.
## Where it lives
Forms are their own area, at [Forms](https://app.introw.io/forms). Each form is built on a canvas of fields and content blocks, then shared by link, embed, portal or API.
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Write access to forms | To build and publish a form | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A portal domain | Only the embed route needs one | A subdomain, or a [Custom domain](/features/portal/custom-domains/guides/connect-a-custom-domain) |
Link, portal and API sharing work without a domain.
## How it works
Forms are managed under **Forms**. You create a form, then build it in an editor with three
tabs: **Form builder** for the fields and layout, **Automation** for what happens on submit, and
**Workflow** for a visual view of the submission flow. Forms inherit your organisation's portal
branding, so the header, colors, and button match your portal.
A form reaches partners through a share link, an embed, or a section in a portal experience.
General links work for anyone, while partner-specific links tie a submission to a known partner.
Embedding a form requires a portal domain (a subdomain or verified custom domain).
## Settings & configuration
Forms are built at [Forms](https://app.introw.io/forms) and edited at
`/forms/{org}/{formId}/edit`.
### Fields
Add fields from the **Add to form** menu, or by typing `/` in the form body. Field types include
text input, text area, file upload, checkbox, partner select, CRM object, quote selector, and
batch (CSV) upload. For each field you set a label, placeholder, and whether it is required, plus
any CRM mapping.
A field's handle menu has **Duplicate**, which adds a copy of the field right below it with its configuration kept, so a second address or contact block does not start from scratch.
#### How many fields to ask for, and which ones to require
The most common form problem is not a missing capability, it is a form nobody finishes. Two rules keep
it honest.
**Ask only for what you cannot get another way.** Every field a partner has to type is a field you
could have resolved, defaulted or inferred instead. Before adding one, check whether it is already
available:
* **The submitter and their company** resolve on their own when the partner arrives through their own portal or through the partner-specific link from the **Share form** dialog. Asking a partner to type their own name and company is the clearest signal a form was never tested.
* **Anything on the partner record** is already yours. Region, tier, manager and program type do not need asking; they are on the partner and can be written by the automation rather than by the partner.
* **Anything your team decides** does not belong on a partner's form. Owner, stage, source and internal classifications are set by the CRM automation.
**Require a field only when a submission is genuinely unusable without it.** A required field that a
partner cannot answer confidently is where they abandon the form, and a nice-to-have that is required
costs you the whole submission rather than the field. Where a field only matters in some cases, make it
conditionally required instead of always required, so it is enforced exactly when it applies (see
[Conditional fields](#conditional-fields)).
A practical target for a deal registration is four to six fields the partner types. Anything beyond
that should be earning its place, and each one is worth checking against the two rules above.
### Content blocks
The same menu adds blocks that are not inputs: **Subtitle** headings, a **Columns layout**,
**Image**, and **Videos**. A video block embeds **YouTube**, **Loom**, **Vimeo**, or **Vidyard**
from its share URL, with **Embed other** for any other provider, so an explainer can sit inside
the form rather than alongside it.
### Dropdown options
A field mapped to a CRM picklist gets its options **live from your CRM**, so you never re-type or
maintain a second list. Introw adds one control on top of that: you can limit which of those options
the form offers.
The limiting is **exclusion-based**. Every synced option is checked by default, and you uncheck the ones
this form should not show. That direction matters: because you are opting options *out* rather than
picking them *in*, an option your team adds in the CRM later appears on the form automatically instead
of silently going missing. You get both halves - your CRM stays the source of the list, and partners only
see the subset that makes sense for them.
The field's configuration shows **Options (n/m shown)** with a checkbox per option, plus **Select all**
and **Clear all**. A value you hid is remembered even if it later disappears from the CRM, so it stays
hidden if it comes back. Unmapped dropdown fields work differently: they carry your own **preset
options**, typed on the field.
On the form itself, a multi-select dropdown carries **Select all** at the top of its list, so a
partner picking most of a long list ticks one box instead of twenty. Typing in the search narrows
the control to **Select all matching**, which takes only the options on screen, so searching
`EMEA` and selecting all picks the EMEA options and leaves the rest alone.
### Conditional fields
Any field can be shown only when other answers on the same form match a rule. Open the field and add
one or more **visibility conditions**; each condition points at another field on the form and compares
its value. A field with no conditions is always visible, and a field that has them shows a
**Conditional** pill in the builder so you can see the branching at a glance.
Conditions use the same operator set as the rest of Introw: equals, does not equal, contains, does not
contain, starts with, ends with, greater/less than, is any of, is none of, and is unknown. Group them
with **and** / **or**, and nest the groups when a rule needs both. A multi-select field is compared per
selected value, so a rule on one option keeps matching after a second option is picked.
Conditions chain. Hiding a field also hides anything that depended on its answer, so a
stage -> reason -> sub-reason cascade collapses in one step rather than leaving orphaned questions on
screen.
**Required follows visibility.** A field marked required is only enforced while it is visible, which is
what makes the two most-asked patterns work:
| Pattern | How to build it |
| - | - |
| Conditionally mandatory | Mark the field required and give it a visibility condition. It is only required when the condition matches (State is required only when Country is US). |
| Required A **or** B | Give B the condition "A is unknown" and mark B required. Answering A hides B; leaving A empty makes B mandatory. |
| Conditional section | Put a checkbox or dropdown first, then give every follow-up question the same condition, so a whole block of questions appears together. |
The same rules run in three places: the form as the partner sees it, the validation that runs on submit,
and the CSV batch-upload path. A hidden field is never submitted, never validated, and never written to
the CRM.
### Helper text
Each field takes an optional **description**. It renders as an info icon next to the label, so you can
explain what a field means or how the value is used without adding a paragraph to the form body.
### Validation
Two layers of validation run before a submission is accepted.
**Your CRM's own rules.** For every field mapped to a CRM property, Introw reads that property's
validation rules from HubSpot or Salesforce and applies them at submit time - number ranges and the
constraints the CRM enforces on its own writes. Submissions that would be rejected by the CRM are caught
in the form instead of failing later, and the message names the property that blocked it.
**Introw's own rules.** Required fields, field types (a number field only accepts numbers, a date field
only a date), and the visibility rules above. Date and date-time fields do not need a CRM mapping - an
unmapped date field is a plain question with a date picker.
### Layout
Structure the form with headings, lists, columns, tables, images, and call-to-action links so it
reads clearly.
### Confirmation
In the automation tab, set the submission confirmation: show an end screen or redirect partners
to a URL after they submit.
### Sharing and embedding
Use **Share form** to get a general link or a partner-specific link, or to embed the form.
Embedding requires a portal domain. You can also add the form to a portal experience as a
section.
### Branding
Forms automatically use your portal branding, so there is no separate per-form branding to set.
## How-to guides
* 
[**Build and publish a form**](/features/forms/form-builder/guides/build-and-publish-a-form)
Create a no-code partner form in Introw: add and configure fields, set the confirmation screen, and publish it via link, embed, portal, or the API.
* [**Partner form templates & use cases**](/features/forms/form-builder/guides/partner-form-templates)
Partner form templates: deal registration, lead capture, support, MDF requests, partner applications, purchase orders, events, and feedback.
* 
[**Set up a partner application form**](/features/forms/form-builder/guides/set-up-a-partner-application-form)
Turn a form into a self-serve partner application that auto-creates the partner, links company and contact records in your CRM, and invites the portal.
* [**Show fields conditionally**](/features/forms/form-builder/guides/show-fields-conditionally)
Build one form that adapts: fields that appear only when they are relevant, questions that become mandatory only when they apply, and whole sections that unfold from a single answer.
* [**Test a form before partners see it**](/features/forms/form-builder/guides/test-a-form-before-partners-see-it)
Submit a form the way a partner will, confirm the CRM record and notifications it produces, walk every outcome, and clean up the test without leaving records behind.
## Troubleshooting
Embedding a form requires a portal domain (subdomain or verified custom domain). Batch (CSV) upload has a per-submission row limit, so very large imports must be split. Forms use your portal branding, so update branding centrally rather than per form.
Set up a portal domain first.
Use the partner link from the share dialog, not the general link.
Confirm it is marked required in the field settings.
# Forms
Source: https://docs.introw.io/features/forms/index
No-code partner forms that capture structured input and run CRM automations on submit: map fields, attribute to partners, dedupe, enrich, and approve.
> Forms are the engine behind much of Introw. A no-code form captures structured input from a partner, and on submit its CRM automation does the real work: it maps to your objects, attributes the record to the partner, matches what already exists so it enriches instead of duplicating, and routes through the approval you set. Deal registration, lead sharing, MDF, partner applications, purchase orders - they are all forms underneath, which is why partner input lands as clean, attributed CRM data instead of duplicates in a form silo.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Partner input lands in a silo | It lands in your CRM |
| Partner data brings duplicates | It matches and enriches instead |
| Approvals stall for days | AI clears the routine ones |
| A new field needs engineering | Partner ops adds it themselves |
## Impact
Every partner interaction that matters is a form: registering a deal, asking for funds, applying to the program. Making those quick and answerable is most of what a partner means by easy to work with.
for your business
* **In your CRM**
Every submission maps to CRM objects and properties and is attributed to the partner, so nothing is re-keyed
* **AI, not admin**
AI reviews routine submissions against your instructions and clears the obvious ones, keeping humans on judgment calls
* **Cost to run**
Forms, mappings and approval flows are all no-code, so a new automation never waits on a release
for your partners
* **Self-serve**
They submit from a link, the portal, email, Slack, Teams, an assistant, or a CSV of a thousand rows
* **Enabled**
The same form takes a deal registration, an MDF request or an application, so there is one thing to learn
* **Efficient**
Validation happens before they submit, so a request comes back approved rather than returned
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Operations** - forms, mappings and approvals, no code
* **Partner Marketing** - forms inside portals and journeys
* **RevOps** - clean, attributed CRM data
* **Partners** - submit from wherever they are
## How this area works
Forms are not a side feature: they are the intake layer the rest of Introw runs on. Deal registration, lead sharing, MDF requests and claims, onboarding steps, course enrollment, feedback and partner applications are all forms. That is why one set of field types, conditional logic, approval chains and CRM mappings covers every one of them. Build the mechanics once and every motion inherits them.
A submission is not just stored - it runs an automation that lands attributed, deduplicated CRM data.
**Where this sits in a setup.** Forms are core, not optional: they are how a partner sends you anything. The [referral](/tracks/referral), [reseller](/tracks/reseller) and [co-sell](/tracks/co-sell) tracks each build theirs before the portal is published.
* 
[**Form Builder**](./form-builder)
Fields, layout and branding, with no code.
[How to · 4 guides](./form-builder/technical)
* 
[**Sharing & Submitting**](./sharing-submitting)
Link, embed, portal, chat, assistant, CSV, or API.
[How to · 3 guides](./sharing-submitting/technical)
* 
[**Submissions & Approvals**](./submissions-approvals)
One inbox, with approval gates and AI review.
[How to · 2 guides](./submissions-approvals/technical)
* 
[**CRM Automations**](./crm-automations)
Map, attribute, match and enrich on accept.
[How to · 1 guide](./crm-automations/technical)
Whenever you need structured input from a partner, a form captures it - and a form is four things working together:
* **A no-code builder** - assemble fields (text, uploads, partner and CRM-object pickers, quote selectors, checkboxes, CSV batch upload) and brand it. Partners fill it in with no CRM seat.
* **Every way to submit** - deliver the form by share link, embed, or portal section. Partners can also submit from email, Slack, Teams, or an AI assistant, and whole lists go through a bulk CSV upload. Your own systems or an agent can submit it over the API. Every channel feeds the same form.
* **A submissions inbox with approval** - every submission lands in one place to accept, decline, or return, behind optional **multi-step human approval** and an **AI review** that clears routine cases automatically.
* **A CRM automation** - on accept, the submission becomes CRM records. Fields map to properties and the record is attributed to the partner by your defined method. Existing records are matched and enriched rather than duplicated, and channel conflict is flagged.
Because that automation is the real payload, forms are not a side tool - they are the mechanism a large part of Introw runs on. The same platform captures a deal registration, a shared lead, an MDF project and its claims, a partner application, or a purchase order. Each one lands as a clean, attributed record in your CRM.
Register partner deals with attribution and channel-conflict screening.
Partners share referrals that land attributed in your CRM.
Every step of the MDF lifecycle is a form with its own approval.
A self-serve application that creates the partner and invites them.
Capture PO and quote details tied to the deal.
Reconcile conversions that feed affiliate commission.
## Run it from your AI assistant
* Submit a co-marketing request form for Acme.
* Show all pending form submissions across every form.
* Approve Globex's submission and notify them.
# Bulk upload multiple records
Source: https://docs.introw.io/features/forms/sharing-submitting/guides/bulk-upload-multiple-records
Let partners submit many records at once with a CSV bulk upload: a template, picklists and validation on every row, and a preview that blocks bad data.
> For partner ops collecting batches of records - lists of leads, end customers, deals, or assets - from partners who work in a spreadsheet, not one entry at a time.
Sometimes the unit of work is a whole list, not a single record. A batch upload field lets a partner hand over many rows in one CSV, and each row flows into your CRM exactly like a single submission would: mapped, attributed, deduplicated, and routed through the same approval. The difference is scale, and the safeguards that come with it. Partners download a template that already knows your fields and your allowed values, and a preview validates every row before anything is submitted, so a spreadsheet full of typos never becomes a CRM full of bad data.
## What you'll achieve
A form with a batch upload field where a partner downloads a ready-made CSV template, fills in up to 1000 rows, and uploads them in one pass. Before submission, a preview validates every row against the same rules a single submission obeys - required fields, picklist options, and the validation rules on your mapped CRM properties - and highlights any cell that fails. The partner can only submit once every row is clean, and each row then lands as its own created or updated CRM record, attributed to the partner.
## Before you start
You need edit access to forms.
Batch upload reuses the form's CRM automation, so each row needs somewhere to land. Map the per-record fields to your CRM objects and properties first, in [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm). The template columns, the allowed picklist values, and the validation rules all come from that mapping.
## Watch it
## Steps
### Add and configure the batch upload field
Go to [Forms](https://app.introw.io/forms) and open the form partners will submit records to, on its **Form builder** tab. Use an existing form or build one first (see [Build and publish a form](/features/forms/form-builder/guides/build-and-publish-a-form)).
Use **Add field** and choose **Batch Upload**. This replaces single-entry inputs with one control that accepts a CSV of many rows, so a partner submits a list instead of one record at a time. One batch field per form is enough: the template is built from the form's other fields, and those fields define every column.
Open **Batch Upload Settings** for the field. These four labels are what the partner sees, so make them action-led:
* **Label** - the title on the upload card. Name the thing being uploaded, for example "Upload your leads" or "Upload end customers".
* **Subtext** - the helper line under the label. Use it to set expectations on format and size. The default notes a CSV upload with a maximum of 1000 rows; keep that limit visible so partners split larger lists themselves.
* **Download Template** - the label for the action that hands the partner the ready-made CSV. Leave it recognizable so partners always start from the template rather than an empty sheet.
* **Upload Data** - the label for the action where the partner picks their completed CSV file.
On the **Automation** tab, confirm every per-record field maps to the right CRM object and property, and set the write behavior (create new, or match and update) exactly as you would for a single submission. This is the same create/update, attribution, and duplicate-matching model described in [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm). It is also what makes the template and the validation smart: mapped picklist properties become dropdown columns with fixed options, and any validation rules on those properties apply to every row.
File upload fields are the one thing a CSV can't carry, so they are left out of the template and ignored on a batch. If a per-record field must include a file, collect it through a single submission instead.
### The template partners download
The template is the contract between you and the partner. It is generated from the form's fields the moment the partner chooses **Download Template**, so it always matches the current form, and it is self-documenting:
* **One column per field, in form order.** Every field becomes a column headed by its exact label. Because two fields can legitimately share a label (a company email and a contact email), columns are matched to fields by position, so duplicate headers never collapse onto one field.
* **Required columns are flagged.** Each required field's example cell is prefixed with `[Required]`, so the partner can see at a glance which columns cannot be left blank.
* **Picklist columns spell out their allowed values.** This is the important part. For a field mapped to a CRM picklist (a dropdown or multi-select property), a pipeline stage, or a partner picker, the example cell lists the actual allowed values, for example `One of: Gold | Silver | Bronze`. A multi-select field reads `Any of (separate multiple with ;): ...` so the partner knows to separate several values with a semicolon. Long option lists are truncated to the first ten with a `+N more` hint. Partners no longer guess your labels: the vocabulary is shared in the template itself.
Tell partners to fill in the template rather than build a sheet from scratch, and to replace the example cells with real values, keeping the exact allowed values for picklist columns. Everything downstream keys off these columns.
### What the partner sees when they upload
The partner opens the form, opens the batch upload card, chooses **Upload Data**, and picks their file. Introw reads it in the browser and immediately opens a preview - nothing is submitted yet.
The preview shows the file name, the row count, and a table of the rows to be submitted, then validates every row before anything is sent. Validation runs the same three checks a single submission passes, cell by cell:
* **Required values must be present.** A required column left empty is flagged.
* **Picklist values must be allowed.** Every value in a dropdown, multi-select, pipeline-stage, or partner column must be one of that column's allowed options (matched case-insensitively; multi-select values split on `;`). A value that isn't in the set is rejected, and the message lists what is allowed. The options shared in the template are enforced on the batch, not merely suggested.
* **Validation rules must pass.** The full set of rules your form applies on a single submission runs on every row too: number and date formats, email format, and any validation rules configured on the mapped CRM properties. A row that would have been blocked in the single-entry form is blocked here for the same reason.
Offending cells are highlighted in red with the reason on hover, and a summary reports how many rows have invalid values. The **Submit** button stays disabled while any row is invalid or a required column is missing entirely, so a partner cannot push a partly-broken list through. When everything checks out, the preview turns green and confirms all rows are ready. The partner fixes the highlighted cells in their sheet, re-uploads, and submits once the preview is clean.
On a clean file, the partner submits and sees a confirmation that the records were received. Large lists must be split: a file over the 1000-row limit, an empty file, or a non-CSV file is rejected up front with a clear message rather than partly imported.
### What happens after submit
Each row becomes its own submission and flows through the form's automation exactly like a single entry: fields map to your CRM objects and properties, the record is attributed to the partner, existing records are matched and enriched instead of duplicated, and the batch runs through the same approval you configured (auto-accepted, or held for human or AI review, per row).
Introw re-validates every row on the server as it processes the batch, so the browser preview is a fast first pass, not the only gate. On the server, picklist entries are canonicalized to the values your CRM stores (a partner can type the label they saw, and it resolves correctly), and any row that still fails validation is skipped and reported rather than written, so a bad row can never quietly land as malformed CRM data. Rows are processed in chunks, so a large batch lands steadily without overwhelming your CRM.
## Verify it worked
Upload a test CSV that mixes clean rows with a couple of deliberate mistakes: a made-up picklist value and a blank required cell. The preview should highlight exactly those cells and keep **Submit** disabled. Fix them, re-upload, and submit. Each row then appears as its own created or updated record in your CRM, attributed to the partner, and the batch shows in your [Submissions](https://app.introw.io/submissions) inbox under **Form submissions**.
## Related
Every other channel a partner can submit through: link, embed, email, Slack, Teams, AI, or the API.
Map each record to the right CRM object, and set the picklists and rules the batch enforces.
Create the form and its fields first.
Review and approve what a batch brings in.
# Submit a form via the API
Source: https://docs.introw.io/features/forms/sharing-submitting/guides/submit-a-form-via-the-api
Submit any Introw form from your own systems: fetch its schema for field ids and picklists, post with a scoped API key, and run the same automations.
> Some submissions should never require a human to open a form. A partner's own portal writes a deal into your system, an internal tool has the lead already, a script backfills 400 registrations, an agent has just gathered the details. The API makes those a first-class submission: same automation, same attribution, same approval queue as a partner filling in the form by hand.
This guide takes you from a form you already built to your first API submission, and shows you where the ids come from so you never have to guess them.
## What you'll achieve
Any of your systems able to submit an Introw form over HTTP, from anywhere, with no browser and no portal login. The submission is attributed to the right partner, runs through the form's CRM automation, and, when the form has an approval step, waits in your submissions inbox exactly like a portal submission.
## Before you start
The API submits an existing form, it does not define one. Build it in [Build and publish a form](/features/forms/form-builder/guides/build-and-publish-a-form) and map its automation in [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm).
Every plan includes API access with a monthly allowance of [API credits](/general/api-credits). One submission spends one credit, and the allowance resets on the first of the month.
Create an API key with the **Forms - Write** permission and copy the secret once. Add **Forms - Read** too if you want to fetch the form's schema from code (see the next section). See [Create and manage API keys](/features/developer/api/guides/create-and-manage-api-keys).
## Watch it
## Steps
### Get the form id and its field ids
You have two ways to discover a form's fields: fetch its schema from the API (recommended when your code needs to react to form changes), or copy them out of the Share dialog (fine for a one-off script).
#### Option A: fetch the schema from the API
Open [Forms](https://app.introw.io/forms), open the form, and copy the form id from its URL or from **Share form → API**.
Use a key with the `forms:read` scope (or `forms:write`), and call `GET /api/v1/forms/{formId}/schema` to read the field ids.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl "https://api.introw.io/api/v1/forms/$FORM_ID/schema" \
-H "x-api-key: $INTROW_API_KEY"
```
The response lists every submittable field with its `id` (the key to use in the submission's `fields` map), `label`, `isRequired`, `dataType` (what value shape to send: `STRING`, `NUMBER`, `EMAIL`, `DATE`, `DROPDOWN`, `PARTNER_SELECT`, and so on), and, for `DROPDOWN`, `DROPDOWN_MULTI`, and `PARTNER_SELECT`, the resolved `options` you can send as `value`. Field ids are opaque strings like `qkzv8h2m4t6r1yc9pd3sxf70` and stable across form edits. The full value-shape table is in [Form submissions](/general/forms-overview#what-to-send-per-field).
The Share dialog spells out this call for the form you are looking at, so you can copy the exact path:
The schema is resolved live, so don't cache it indefinitely. Re-fetch it whenever the form's fields might have changed, or whenever a picklist behind a `DROPDOWN` has been synced from the CRM. Both change what a valid submission looks like.
Do not hand-write field ids from labels. Read them from the schema (or the Share dialog), and re-check them whenever the form changes.
#### Option B: copy from the Share dialog
Go to [Forms](https://app.introw.io/forms), open the form, and select **Share form**.
Select **API**. This tab turns the form into a request: it shows the endpoint, the header to authenticate with, and a runnable cURL snippet already carrying this form's id and every one of its field ids. **Manage API keys** links straight to where you create the key.
Below the snippet, the **Fields** table lists each field's **id**, its **label**, and whether it is **required**, the same information the schema endpoint returns. Each id has a copy button. The note under the table points at `GET /api/v1/forms/{formId}/schema` for the same list in code, with value types and allowed dropdown values.
Pick a partner on the **Link** tab before switching back, and the snippet comes back with that partner's `partnerId` already filled in. Handy for testing against a real partner.
### Post your first submission
Select **Copy cURL**, then set `INTROW_API_KEY` to the key you created. Swap the placeholder values for real ones.
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "https://api.introw.io/api/v1/forms/$FORM_ID/submissions" \
-H "x-api-key: $INTROW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"email": "jamie@partner.example",
"partnerId": "ptn_01HVK6Y8Z8Q7J8J8J8J8J8J8J8",
"fields": {
"qkzv8h2m4t6r1yc9pd3sxf70": "Globex Corporation",
"b3n7wq1k5rt9x2ycp8ds4hf6": "45000"
}
}'
```
Send `partnerId` whenever your system knows which partner it is acting for. It takes the Introw partner id **or** the partner's CRM external id, so pass whichever you already store; an unknown value comes back as `404` instead of quietly landing unattributed. With only `email`, Introw resolves the submitter and applies the form's identification automations. With neither, the submission is accepted but unattributed, just like a general share link.
A `201` returns the submission id and its status. `AUTO_ACCEPTED` means the form has no approval step and the automation has already run. `PENDING` means it is waiting in your inbox for review. Keep the returned `id` if you want to comment on the submission later.
### Link the partner's own CRM records
When the submitting partner runs their own CRM and you have the record ids, attach them so both sides point at the same deal:
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"partnerObjects": [
{ "objectType": "deal", "objectId": "9840193344" }
]
}
```
## Verify it worked
Open [Submissions](https://app.introw.io/submissions). The submission appears under **Form submissions** with the partner you attributed it to, indistinguishable from a portal submission apart from its source. If the form auto-accepts, the mapped record already exists in your CRM. If it has an approval step, the submission sits as **Pending** and your reviewers are notified as usual.
## Limits & gotchas
Keep the call server-side: it authenticates with a secret key, and the reCAPTCHA that protects the public link and embed does not apply here. Unknown keys in `fields` are ignored, but a missing required field returns `422`. A `404` on the form itself usually means the form has no CRM automation configured yet, not that the id is wrong.
* **120 requests per minute per key.** Every response carries `x-ratelimit-remaining-minute`; over the limit you get `429`. For a backfill, submit sequentially with a small delay and retry after the minute rolls over.
* **One request per submission.** A batch upload field is the portal's bulk-CSV control and carries no value over the API, so loop instead. See [Bulk upload multiple records](./bulk-upload-multiple-records) for the partner-facing path.
* **Picklist labels are tolerated.** `"Qualified to buy"` resolves to `qualifiedtobuy` case-insensitively, and a `PARTNER_SELECT` field accepts a partner name, but send `value` when you have it. A value matching no option is passed through as sent.
* **Nothing is deduplicated by the API.** Keep the returned submission id against your source record so a retried run does not submit twice.
## Troubleshooting
* **`403 Forbidden`** - the key is valid but lacks `forms:write`, or the submitter is not allowed to process quotes on this form.
* **`404 FORM_NOT_FOUND`** - the id is wrong, or the form has no automation configured.
* **`404 PARTNER_NOT_FOUND`** - `partnerId` matched neither an Introw id nor a CRM external id.
* **`422 VALIDATION_ERROR`** - a value failed the form's own validation, or a required field was missing. Re-check the **Fields** table.
* **`422 MDF_FUND_EXPIRED`** - the marketing fund behind this form is no longer active.
* **`429 RATE_LIMIT_EXCEEDED`** - more than 120 requests in the current minute on this key.
* **The submission arrived unattributed** - you sent neither `partnerId` nor a resolvable `email`.
## Related
The full reference: value shapes, attribution, statuses, errors, rate limits, and code samples.
Every other channel the same form is reachable through.
Create the scoped key this guide uses.
# Ways to submit a form
Source: https://docs.introw.io/features/forms/sharing-submitting/guides/ways-to-submit-a-form
Every way a partner can submit an Introw form: share link, website embed, your portal login page, email, Slack, Teams, AI assistant, bulk CSV upload, or API from your own systems.
> Every step between a partner's intent and the data landing in your CRM costs you submissions. Build the form once, then let partners submit through whichever entry point fits how they work: a link, an embed, email, Slack, Teams, an AI assistant, a bulk CSV, or a call from their own systems. Every channel feeds the same form and the same CRM automation, so the submission always lands attributed and clean.
You build one form, with its CRM automation, attribution, and duplicate checks, and then expose it through as many channels as you like. This guide covers each one. Pick the channels where your partners already are; you don't need all of them. Deal registration, lead sharing, and MDF have their own channel guides that reuse these same routes for those specific motions.
## What you'll achieve
The same form reachable through every channel your partners use, so participation no longer depends on a portal login. Each submission, wherever it started, runs through the form's automation and lands attributed to the right partner in your CRM.
## Before you start
Batch upload is a plan feature. If the option is missing from the share dialog, it is not on your plan yet - check what yours includes at [introw.io/pricing](https://introw.io/pricing).
A published form with its CRM automation, attribution, and duplicate checks should already exist, and every channel below feeds it. Build it in [Build and publish a form](/features/forms/form-builder/guides/build-and-publish-a-form) and map it in [Connect a form to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm).
## Choose a channel
The lowest-friction way to submit is a link the partner opens and fills in anywhere. A **partner-specific link** attributes every submission to that partner automatically, so credit is never in question; a **general link** is open to anyone and arrives unattributed. Prefer the partner link whenever you send the form to a known partner.
In [Forms](https://app.introw.io/forms), open your form and choose **Share form**.
On the **Link** area, copy the **General link** to share with anyone, or the **Partner link** to attribute every submission to a specific partner.
Drop the link into an email, a portal message, or a Slack channel - anywhere your partners already are.
Some partners and prospects arrive on your own pages. Embedding the form there captures submissions in context, with your branding. Where the page is partner-specific, use an attributed embed so each submission credits the right partner. Embedding requires a custom domain; without one, share the link instead.
In the **Share form** dialog, switch to the **Embed** tab and copy the generated snippet. The embedded form resizes to fit as it grows or shrinks, including the confirmation after submit, so your page never shows a scrollbar inside the form or a gap below it. A snippet copied before this resizing arrived is a plain frame with a fixed height; copy it again to get the resizing one.
Add the snippet to the page where you want partners to submit, such as a partner landing page or a website footer.
Everyone who reaches your partner portal without an account is already at the door, so put the form on the login page itself. This is how a partner application form recruits: a visitor applies without leaving the portal, and nobody has to hand them a link first.
Go to [Portal settings](https://app.introw.io/settings/portal) and open the **Become a partner** tab, beside **Login**, **Verification** and **No Access**. Select the form, then set **Prompt text**, the question above the link, and **Link text**, the link itself.
The link shows under the sign-in box, and only to a visitor with no portal access yet, so existing partners never see it. It opens the form in a dialog on the login page, prefilled with the email address they just typed.
For the whole setup, see [Set up a partner application form](/features/forms/form-builder/guides/set-up-a-partner-application-form).
A partner often has the details mid email thread. Letting them forward that email captures the submission, with the AI agent reading it and filling in the form so it still lands attributed and CRM-ready. The [AI agent](/features/ai/partner-support) must be enabled for your program.
If your partners live in Slack, bringing the Introw agent into the channel lets them submit in the same place they already talk to your team: they give the agent the details in a message and it submits the form for them. Connect your workspace first, see [Connect Slack](/features/integrations/chat/guides/connect-slack).
Same as Slack, for Teams-first partners. Connect your tenant first, see [Connect Microsoft Teams](/features/integrations/chat/guides/connect-microsoft-teams).
When a partner already works in an AI assistant, the lowest-friction path is to just ask it. An assistant connected to Introw over MCP fills in the form and submits it, attributed to the partner, without switching tools. See [Connect an MCP client](/features/developer/mcp/guides/connect-an-mcp-client) and, for partners running their own assistant, [Partner Connect](/features/partner-connect).
When a partner has a whole list rather than a single record, a batch upload field takes up to 1000 rows from one CSV. Partners download a template that already lists your allowed values, and a preview validates every row before submission. See [Bulk upload multiple records](./bulk-upload-multiple-records).
Sometimes no human should be filling in a form at all: a large partner's own portal already holds the deal, an internal tool has the lead, a script is backfilling history, or an agent has just gathered the details. The API submits the same form directly, attributed to the partner you name, and runs the same automation and approval flow. Get the form id and field ids from the **API** tab of the **Share form** dialog. See [Submit a form via the API](./submit-a-form-via-the-api).
## Verify it worked
Use whichever channel you set up to submit a test entry, then confirm it appears in [Submissions](https://app.introw.io/submissions) under **Form submissions**, attributed to the right partner, with the matching record synced to your CRM.
## Related
Submit a whole list at once from a validated CSV.
Set up the automation, attribution, and checks every channel feeds.
Let your own systems or an agent submit the form directly.
The same channels, applied to the referral motion.
Let assistants submit through Introw's MCP server.
# Sharing & submitting
Source: https://docs.introw.io/features/forms/sharing-submitting/index
Every way an Introw form reaches partners and returns attributed, CRM-ready submissions: share links, website embeds, email, Slack, Teams, AI, CSV, API.
> A form is only as good as the partners who actually fill it in. Sharing & Submitting is every way a form gets to a partner and back: a link, an embed, an email, a Slack or Teams message, an AI assistant, a bulk CSV upload, or a call from your own systems. Every channel feeds the same form, so the submission always lands attributed and CRM-ready, wherever the partner started.
## The problem it solves
Most partner data never arrives because the form is one more place partners have to go:
| Without Introw | With Introw |
| - | - |
| Partners will not log in for a form | They submit from where they are |
| A form with no submissions is waste | Every channel feeds one form |
| A long list, one row at a time | One CSV of up to 1000 rows |
| Big partners want system-to-system | The same form over the API |
## Impact
The form is not the product, the submission is. Being reachable in the channel a partner already has open is the whole difference between a form you built and data you actually have.
for your business
* **No new tool**
Link, embed, portal, email, Slack, Teams, an AI assistant, a CSV or the API, all into one form
* **Live in days**
Switching on a channel is a setting, so submissions start arriving in days rather than quarters
for your partners
* **Self-serve**
Templates, bulk upload and pre-submit validation let them get it right without a round trip
* **Enabled**
They start where the deal came up, in chat or their inbox, not in a tool they had to remember
* **Efficient**
One CSV instead of a hundred submissions, and their own systems can submit on their behalf
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Operations** - the channels to switch on
* **Partner Marketing** - forms in sites and journeys
* **Partners** - one record or a whole list
* **Developers** - intake over the API
## See it work
* 
**One at a time, from the portal**
The form opens where the partner already is, already knowing who they are.
* 
**Allow a batch**
A Batch Upload field turns one form into a list intake.
* 
**Take the CSV**
Partners hand over a whole book of business in one file.
* 
**Validate before it lands**
Required values, picklists and rules are checked row by row.
* 
**Or system to system**
The same form is callable over the API, with its own key.
## How it works
Once a form is built, you deliver it through whatever channel fits how your partners work. Send a general or partner-specific link, embed it on your own site, or drop it into a portal experience. Partners can also submit straight from email, Slack, Teams, or an AI assistant that fills the form for them. When a partner has a whole list rather than a single record, a batch upload lets them submit up to 1000 rows from one CSV. And when the submission should not involve a human at all, your own product, an internal tool, or an agent can submit the form over the API.
Every one of these routes feeds the same form and the same CRM automation, so it does not matter where a partner starts. The submission is attributed to the right partner, checked, and turned into clean CRM records the same way each time. Meeting partners where they already work, instead of forcing them into a portal, is what turns a form from a thing you built into submissions you actually receive.
Sharing & Submitting turns a built form into submissions you receive. Publish it through the channels your partners already live in, add a bulk path for lists, and let every route converge on the same attributed, CRM-synced record. Adoption stops being a portal-login problem and becomes a question of which channels you switch on.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
form["One form"] --> channels["Link, embed, email, Slack, Teams, AI, bulk CSV, API"]
channels --> submit["Partner submits where they work"]
submit --> record["Attributed, CRM-ready record"]
```
## Run it from your AI assistant
* Which forms can I submit for Acme, and what are the ways to submit them?
* Share the deal registration form with Globex as a partner-specific link.
* Submit a batch of leads for Acme from a CSV.
## Going deeper
Setup, channels, and all how-to guides.
Integration surface and code.
**Works with**
Build the form once, then share it through every channel.
Each submission maps and syncs to the CRM on the way in.
Every submission lands in one inbox to review.
Partners submit by email, Slack, Teams, or AI and the agent fills the form.
# Sharing & submitting
Source: https://docs.introw.io/features/forms/sharing-submitting/technical/index
Set up how partners reach and submit your forms with share links, embeds, off-portal channels like email, Slack, and Teams, bulk CSV upload, and the API.
## Where it lives
Sharing & submitting sits under **Portal**, at [Forms](https://app.introw.io/forms).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| A published form, CRM-mapped | Submissions need somewhere to land | [Map it to your CRM](/features/forms/crm-automations/guides/connect-a-form-to-your-crm) |
| A custom domain, to embed | Only for embedding on your pages | [Custom domain](/features/portal/custom-domains/guides/connect-a-custom-domain) |
| The AI agent and a chat app | Only for chat and assistant sends | [Launch the agent](/features/ai/partner-support/guides/launch-the-partner-support-agent) |
| An API key, Forms - Write | Only for API submissions | [API keys](/features/developer/api/guides/create-and-manage-api-keys) |
Every plan includes API access with a monthly API credit allowance, so there is no add-on to enable.
## How it works
A form in Introw has one definition and one CRM automation, and many ways in. You build the form once, then decide how partners reach it: copy a link, embed it, place it in a portal experience, turn on off-portal channels, or expose a bulk upload for lists. Whichever route a partner takes, the submission runs through the same automation, so it is attributed and synced to your CRM identically every time.
Two ideas are worth holding onto. First, a **general link** is open to anyone, while a **partner-specific link** stamps every submission with that partner's attribution automatically. Second, the channels are not separate forms: they are entry points onto one form, so you configure the form and its automation once and switch channels on or off freely.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
form["Form + CRM automation"] --> link["Share link / embed"]
form --> channel["Email / Slack / Teams / AI"]
form --> bulk["Bulk CSV upload"]
form --> api["API"]
link --> crm["Attributed CRM record"]
channel --> crm
bulk --> crm
api --> crm
```
## Settings & configuration
### Share form dialog
Open a form and choose **Share form** to get its entry points.
**General link** is the open link anyone can open and submit. Use it for broad, unattributed capture (a public sign-up, an event form).
**Partner link** is a partner-specific link that credits every submission to the chosen partner. Prefer it over the general link whenever you send a form to a known partner, so attribution is never in question.
**Embed** provides the code to drop the form onto your own site under your branding, on the **Embed** tab. The snippet resizes the form to its content, including after submit. Embedding requires a custom domain; until one is set, the tab points you to **Configure custom domain** and you should share the link instead.
**API** turns the form into a request. The tab gives you a runnable cURL snippet already carrying this form's id and every field id, plus a **Fields** table listing each field's id, label, and whether it is required. Field ids are opaque generated strings, so never type them from labels: read them here, or fetch them from `GET /api/v1/forms/{formId}/schema`, which the note under the table links to. Pick a partner in the dialog before copying and the snippet comes back with that partner's `partnerId` pre-filled. API submissions run the same automations and acceptance flow as portal submissions, from any system, with no browser and no portal login. The tab is available on every plan; each submission spends one [API credit](/general/api-credits) from your monthly allowance. Full setup is in [Submit a form via the API](../guides/submit-a-form-via-the-api), and the complete contract is in [Form submissions](/general/forms-overview).
### Off-portal channels
Partners can also submit without opening the form at all. With the AI agent enabled and the matching integration connected, a partner can forward an email, message the agent in Slack or Microsoft Teams, or ask a connected AI assistant, and the agent fills in and submits the same form. These channels are covered end to end in [Ways to submit a form](../guides/ways-to-submit-a-form).
### Batch upload
For lists rather than single records, add a **Batch Upload** field to the form. Its **Batch Upload Settings** control the four labels a partner sees (the upload **Label** and **Subtext**, the **Download Template** action, and the **Upload Data** action), and the field accepts a CSV of up to 1000 rows. The downloaded template is built from the form's fields, so it lists your allowed picklist values and marks required columns, and a preview validates every row before submission. Full setup is in [Bulk upload multiple records](../guides/bulk-upload-multiple-records).
## How-to guides
* 
[**Bulk upload multiple records**](/features/forms/sharing-submitting/guides/bulk-upload-multiple-records)
Let partners submit many records at once with a CSV bulk upload: a template, picklists and validation on every row, and a preview that blocks bad data.
* 
[**Submit a form via the API**](/features/forms/sharing-submitting/guides/submit-a-form-via-the-api)
Submit any Introw form from your own systems: fetch its schema for field ids and picklists, post with a scoped API key, and run the same automations.
* [**Ways to submit a form**](/features/forms/sharing-submitting/guides/ways-to-submit-a-form)
Every way a partner can submit an Introw form: share link, website embed, your portal login page, email, Slack, Teams, AI assistant, bulk CSV upload, or API from your own systems.
## Troubleshooting
A batch upload takes at most 1000 rows per file; larger lists must be split. A general link is open to anyone with the URL and its submissions are unattributed unless you use a partner-specific link. Embedding needs a custom domain. Off-portal (email, Slack, Teams, AI) submissions depend on the AI agent and the relevant integration being enabled. API submissions spend one [API credit](/general/api-credits) each from your monthly allowance and authenticate with a secret key rather than the reCAPTCHA that guards the link and embed, and adding or removing fields changes which field ids a valid payload carries, so re-fetch the schema after editing a form.
It likely came through the general link. Send the partner-specific link instead, or pass `partnerId` on the API call.
The snippet on the page predates auto-resizing. Copy it again from the **Embed** tab and replace the old one.
Configure a custom domain first, then re-open the **Embed** tab.
Confirm the AI agent is enabled and the Slack or Teams integration is connected for your program.
This month's API credit allowance is spent; it resets on the first of the month.
A required field was missing or a value failed the form's validation. Re-check the ids in the **Fields** table.
# Choose how submissions get approved
Source: https://docs.introw.io/features/forms/submissions-approvals/guides/choose-an-approval-model
Decide who signs off on partner form submissions, what accept, decline and return each do, and what the partner sees at every step.
> For partner ops and partner managers deciding how a registration, referral or request gets signed off before it counts.
[Run a submission approval workflow](./run-a-submission-approval-workflow) shows you where the controls are.
This guide is the decision in front of that: how many approvers a submission really needs, who they should be, and what each outcome does to the partner on the other end.
Getting it wrong in either direction is expensive.
Too loose and unqualified deals land in your pipeline with a partner already told yes.
Too tight and partners wait days for an answer, which is the fastest way to teach them not to register the next one.
## What you'll achieve
An approval model you can defend: the right number of steps, the right approver on each one, outcome messages that tell a partner what to do next, and a clear view of what this model can and cannot express, so you find out here rather than three weeks into a rollout.
## Before you start
Approval is a business decision before it is a setting.
Write down who is accountable for saying yes to this form: a named person, whoever manages that partner, or anyone on the team.
That answer maps directly onto the options below.
Two of the four approver options resolve per partner rather than to a fixed person, and both need ownership set on the partner record.
See [Wire partner ownership](/features/partners/team/guides/wire-partner-ownership) and [Set up partner team roles](/features/access/team-management/guides/set-up-partner-team-roles).
## Steps
### Decide how much of a gate you need
A submission with no gate is accepted the moment it arrives, and its CRM automations run immediately.
That is the right answer more often than teams expect: a referral you would never turn down, an event registration, a support request.
Add a gate only where a wrong yes costs you something, because every gate you add is latency a partner feels.
On the form's **Automation** tab, **Approval gate** under **Review** is what holds submissions as **Pending** instead.
Switching it on lands the review on **AI Assisted** and seeds a first step set to **Anyone**, so the gate starts permissive and you tighten it from there.
Steps run in order, and each step carries exactly one approver. Your options:
* **Anyone** - any team member in your organisation can approve. Use it when speed matters more than who signs, and for the first step of a queue your ops team works together.
* **A specific team member** - one named person. Precise, and the only option that stalls when they are on holiday, so keep it for genuinely personal sign-off.
* **A partner team role** - resolves per partner to whoever holds that role on the submitting partner. This is how one form serves a hundred partners without a hundred rules.
* **Fund owner** - on MDF forms only, resolves to the owners of the fund the request is routed to. See [Set up an MDF program](/features/mdf/funds-allocation/guides/set-up-an-mdf-program).
The two dynamic options are what make a gate scale.
A step set to a partner team role reads as "the person responsible for this partner" rather than a name, so onboarding a new partner manager changes nothing about the form.
A second step is worth its latency when the second approver is deciding something the first cannot: a discount beyond policy, a fund commitment, a strategic account.
It is not worth it when the second approver is just double-checking the first.
Chain the steps in the order the decision actually travels, since each one must approve before the next is asked.
Removing the last step switches the gate off entirely, which is the quickest way back to auto-acceptance.
On a high-volume, rule-based form, most submissions are decided by criteria you can write down.
One question on the gate sets how much of that Introw AI owns: **Manual**, **AI Assisted** while you learn what its verdicts look like, then **Autonomous AI (Agentic)** once they hold up.
Describe the policy under **Guidance for Introw AI** in plain language, or generate a first draft from the form's own fields and edit it.
On **Autonomous AI** it accepts, declines or returns on its own only above the confidence you set, and everything below it still reaches a human.
This is the one lever that shortens the queue without loosening the rules, and it is why a two-step gate is survivable at volume.
See [AI approvals](/features/ai/approvals/technical).
### Know what each outcome does
Every submission sits in exactly one state, and the state decides what can still happen to it.
| Status | What it means | Can it still be edited? |
| - | - | - |
| **Pending** | Waiting on an approver step, or on AI that was not confident enough | Yes |
| **Accepted** | Approved. CRM automations have run and the partner has been told | No |
| **Auto accepted** | Accepted without a human, either with no gate or by AI above its threshold | No |
| **Declined** | Rejected, with your decline message sent | No, but it can be reopened |
| **Returned** | Sent back to the partner for more information | Yes, by the partner |
| **Error** | Something failed on the way to your CRM, usually a validation rule | Yes |
An **Error** is not a decision.
It means the submission could not be written, so treat it as work rather than an outcome: fix the value it tripped on and resubmit.
They read very differently to a partner, and only one of them is reversible on your side.
* **Decline** ends it with your decline message. If circumstances change, **Reopen** at the top of a declined submission sends it back to **Pending**, where it re-enters the gate from the first step and AI validation runs again.
* **Return** keeps it alive and hands it back. Use it whenever the answer is "not like this" rather than "no".
Return is per submission by design, because it asks one partner for something specific.
A bulk decision can only accept or decline.
Set the **Accept** and **Decline** messages on the form so every partner gets a reason rather than a status change, and edit them per submission when a case deserves it.
A decline that explains what would have qualified is the difference between a partner registering again and a partner giving up.
An accepted submission cannot be un-accepted, because accepting is what created the record in your CRM and told the partner yes.
If you accept one in error, correct the record in your CRM and use **Return** to ask the partner for a corrected submission.
On forms where a wrong yes is costly, that is the argument for a gate rather than for an undo.
### Show the partner where their submission stands
Partners chase you for status because nothing shows it to them.
Add the **Form submissions** section to the portal experience from the **Forms** group in the section picker.
It lists that partner's own submissions with a **Status** column, so "where is my registration" answers itself.
See [Every section you can add to a portal](/features/portal/experiences/guides/every-portal-section).
A partner who reopens the form finds their previous answers already filled in and your reviewer's return comment shown alongside them, and their edit resubmits the same submission rather than creating a second one.
That is why **Return** does not fragment your inbox, and why a returned submission is worth a specific comment: the comment is the instruction they act on.
Outcome emails are org-level, not per-form.
On [Default settings](https://app.introw.io/settings/segments/default), open the **Notifications** tab and give **Form submission accepted**, **Form submission declined** and **Form submission returned** their recipients under the **Submissions** group.
See [Control who gets notified](/features/engagement/notifications/guides/control-who-gets-notified).
## What this model cannot express
Worth knowing before you design around it, because each of these has a route that gets you most of the way.
| What teams ask for | Where it stands | What to do instead |
| - | - | - |
| Two approvers on one step, either of whom can approve | A step carries one approver | Set the step to **Anyone**, or to a partner team role several people hold |
| Route by a field value, like territory or deal size | Not available | Use a partner team role so routing follows the partner, or split into two forms with their own gates |
| An SLA that auto-accepts after N days | No timers | Use AI validation to clear the routine cases so a queue does not form |
| Accept or decline from Slack or Teams | The chat message links to the submission | Review in Introw; chat gets you there in one click. See [Configure the chat integration](/features/integrations/chat/guides/configure-the-chat-integration) |
| Auto-decline a duplicate or an existing customer | The AI flags and recommends, a reviewer decides | Shape what it screens with channel-conflict filters and context. See [Catch and resolve channel conflict](/features/ai/channel-conflict/guides/catch-and-resolve-channel-conflict) |
| Accept a registration from a partner not yet in your CRM | It will not auto-accept | Put an application form in front, which creates the partner and their CRM records first. See [Set up a partner application form](/features/forms/form-builder/guides/set-up-a-partner-application-form) |
## Verify it worked
Submit a test through the form and follow it end to end.
It should arrive as **Pending** (or **Auto accepted** if AI cleared it), name the approver you expect on its current step, and change status as each step signs off.
Decline it and confirm the partner receives your decline message and that **Reopen** puts it back to **Pending**.
Return a second test and confirm the partner's form comes back prefilled with the return comment attached.
See [Test a form before partners see it](/features/forms/form-builder/guides/test-a-form-before-partners-see-it).
## Related
Where every control in this guide lives.
Review by the columns you decide on.
The same model applied to deal registration.
Full configuration options.
# Customize the submissions inbox
Source: https://docs.introw.io/features/forms/submissions-approvals/guides/customize-the-submissions-inbox
Customize the submissions inbox in Introw: choose the columns you review form submissions by, including custom fields and mapped CRM properties.
> For partner ops who triage submissions at a glance instead of opening each one.
The right columns make review fast. Surfacing the fields you actually decide on - including custom fields and CRM data - lets you scan and act on a queue without opening every submission, which keeps the inbox moving. This is a quick, one-time setup that pays off on every review session.
## What you'll achieve
A **Submissions** inbox that shows the columns most useful to your review - status, partner, the dates you track, and any custom or CRM fields you decide by - so you can prioritize and triage at a glance.
## Before you start
You need access to the **Submissions** inbox.
Decide which fields drive your triage (deal value, region, a qualifying field) so you know which columns to add.
## Watch it
## Steps
Go to [Submissions](https://app.introw.io/submissions). By default the inbox shows core columns such as the form, partner, dates, status, and who submitted.
Choose **Configure** to open the column configuration. This is where you decide which properties appear as columns across every submission in the inbox.
Add the columns you review by and remove the ones you do not need:
* Core fields - form, partner, the submitted and accepted dates, status, and submitter - keep the ones that drive your triage.
* Custom and CRM fields - add fields captured by the form or synced from your CRM, so values like deal size or region show inline. These are the columns that let you decide without opening a submission.
Order them so the most important sits left, where you read first.
Save so the inbox shows your chosen columns for every submission going forward.
## Verify it worked
The inbox shows your chosen columns - including any custom or CRM fields - for every submission, so you can triage and prioritize without opening each one.
## Related
Review and resolve the submissions you triage.
Surface CRM data in the inbox columns.
Full configuration options.
# Run a submission approval workflow
Source: https://docs.introw.io/features/forms/submissions-approvals/guides/run-a-submission-approval-workflow
Set up a form submission approval workflow with steps and AI validation, notify the right reviewers, and process every submission to a clear outcome.
> For partner ops and partner managers who need every submission reviewed, signed off by the right people, and answered.
Some submissions cannot be accepted on the spot - they need sign-off, the right people alerted, and the partner told what happened. This guide builds that whole loop: an approval gate with ordered steps, optional AI that clears the routine cases, notifications to your team and the partner, and the day-to-day review where you accept, decline, return, or reopen each submission. The result is consistent, auditable handling instead of submissions waiting on whoever happens to notice them.
## What you'll achieve
A form where every submission routes through the approvers you choose, AI optionally handles confident cases on its own, your team is alerted on submit, and partners receive a clear outcome - all reviewed from one **Submissions** inbox. Nothing stalls unseen and nothing is rubber-stamped.
## Before you start
You need access to the **Submissions** inbox and write access to the form you configure.
Decide who must approve (specific team members, partner team roles, or anyone) and who should be alerted when a submission arrives.
## Steps
### Set up the approval gate
Go to [Forms](https://app.introw.io/forms), open the form, and on the **Automation** tab select **Approval gate**. Turn on the switch so submissions are held as pending until they are approved, rather than accepted automatically. Switching it on lands on **AI Assisted** and adds a first step set to **Anyone**, so you tighten it from there. Use a gate whenever a submission needs a human (or AI) decision before it counts.
Under **Approval steps**, choose **Add approval step** for each level of sign-off. Steps run in order: each must approve before the next is asked, which is how you model a two-stage review (for example a reviewer then a manager). For each step:
* Name the step so approvers understand its purpose.
* Pick the approvers - specific team members, a partner team role, or **Anyone** in your organisation. If you add no steps at all, any team member can approve, so add steps when you need specific sign-off.
Set the **Accept** and **Decline** messages partners receive, so each outcome guides them on what happens next instead of being a bare status change. You can still edit these per submission at review time.
### Let AI clear the routine cases (optional)
Under **How much of the review should Introw AI own?**, pick a card. **Manual** sends every submission to your approvers with no AI. **AI Assisted** has Introw AI pre-check and recommend while your approvers decide. **Autonomous AI (Agentic)** lets it decide when it is confident and escalates the rest. AI review is what collapses approval time on high-volume, rule-based forms.
Under **Guidance for Introw AI**, enter the policy it should apply: what to accept, decline, or return. Use **Generate with AI** to draft guidance from the form's fields, then refine them to your risk tolerance and must-have criteria (for example, decline submissions missing timeline details, return ones without target-account fit).
On **Autonomous AI (Agentic)**, one slider sets the threshold between **More cautious** and **More autonomous**. Above it, Introw AI accepts, declines, or returns the submission itself; below it, the submission still goes to your approval steps. Start with **AI Assisted** or a cautious threshold, watch the results, then loosen it as you build trust.
### Notify the right people
Still on the **Automation** tab, open **Notify your team**. Pick the partner team roles to email on submit, and use **Add partnership manager fallback** so an alert still goes out when no team member can be determined. Add anyone else who should know with **Add recipient**. This is what keeps response time short - a submission no one is told about waits.
Partner emails for outcomes are managed centrally, not on the form. Go to [Default settings](https://app.introw.io/settings/segments/default), open the **Notifications** tab, and under the **Submissions** group give **Form submission accepted**, **Form submission declined**, and **Form submission returned** their recipients, so partners are automatically told when their submission is resolved.
Each event takes one value rather than an on/off switch: **All partners**, **Collaborating only**, or **Disabled**. Outcome emails go to the person who submitted, so **All partners** is the setting that answers them. To vary it for one audience, override the event on that segment's own **Notifications** tab.
[Notification settings](https://app.introw.io/settings/notifications) is the report on what your program sent, not the place to change it. Recipients are set on the default and per segment.
### Review and resolve submissions
Go to [Submissions](https://app.introw.io/submissions) to see incoming submissions with their status - **Pending**, **Accepted**, **Auto accepted**, **Declined**, or **Returned** - alongside the form, partner, and submitter.
Open a pending submission to see its full detail and act:
* **Accept** - approve it; the partner is notified and any CRM automations run.
* **Decline** - reject it with your decline message.
* **Return** - send it back asking for more information; the partner can edit and resubmit.
Add a note so the partner understands the outcome. Where an approval gate has multiple steps, the submission advances only as each approver signs off.
If an answer is wrong, edit the submission instead of returning it. On a form with an approval gate, saving keeps it in review, and when you approve the current step the **Accept** dialog opens so you can finish straight away. On a form without a gate, saving resubmits it as **Auto accepted** and the corrected values go to your CRM. Editing an **Error** submission is the retry. Accept, Decline and Return only show to the approvers of the current step.
When a run of submissions gets the same decision - a distributor's weekly order forms, a backlog after a campaign - handle them together instead of one at a time. Select them with the checkbox on each row (the checkbox in the selection bar takes every row loaded in the table, so filter or search first to scope the batch), then choose **Accept** or **Decline**.
One dialog covers the batch: write the **Message to partners** once, prefilled with the form's accept or decline message, and every partner in it gets that message. Each submission still runs its own automations and notifications, and on a form with an approval gate your bulk accept counts as your approval on the current step rather than skipping the gate.
Introw processes only what qualifies and tells you what it skipped - anything not pending, and for **Accept**, anything with no partner linked yet. Handle those individually. **Return** is deliberately per submission, since it asks one partner for something specific.
A decline is not final. Open a **declined** submission and choose **Reopen** at the top of the submission to send it back to **Pending** for another decision - it re-enters the approval gate from the first step, and AI validation runs again if enabled. Add a note explaining why, then review it to a fresh outcome. Use this when something changes after you declined.
## Verify it worked
Submit a test: it arrives as **Pending** (or **Auto accepted** if AI cleared it), your team receives the on-submit alert, and stepping it through approval changes its status. When you accept, decline, or return it, the partner receives the matching email and the inbox reflects the new status. Returned submissions reappear once the partner resubmits.
## Related
Review by the columns you care about.
Create the form this workflow reviews.
Full configuration options.
# Submissions & Approvals
Source: https://docs.introw.io/features/forms/submissions-approvals/index
Every partner form submission in one inbox: review, approve through gates you define, and let AI handle routine cases with automated validation in Introw.
> Submissions & Approvals gives every form submission a home: one inbox to review, accept, decline, or return, with optional approval gates and AI that clears the routine cases so your team handles only the judgment calls.
## The problem it solves
Manual review of partner submissions is slow, inconsistent, and easy to drop:
| Without Introw | With Introw |
| - | - |
| Submissions scatter across inboxes | One place to review them |
| Approvals stall for days | AI clears the routine ones |
| Review is inconsistent | Accept, decline or return |
| A backlog is cleared one by one | Accept a whole batch at once |
## Impact
How fast you answer a registration is the clearest signal a partner gets about how much you want their business. Seconds instead of days is the whole game.
for your business
* **Cost to run**
Review and multi-step approval flows are configured rather than built, so adding an approver is a setting
* **AI, not admin**
AI reviews routine submissions against your instructions, collapsing approval from days to seconds
for your partners
* **Self-serve**
They get a clear answer, and a returned submission says what to add rather than just failing
* **Enabled**
A declined submission can be reopened, so a changed circumstance does not mean starting again
* **Efficient**
The routine cases come back in seconds, which is what makes registering worth doing at all
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Operations** - one inbox and the gates
* **VP Partnerships** - fast, auditable approvals
* **Partners** - an answer, quickly
## See it work
* 
**One inbox**
Every submission, with who sent it and where it stands.
* 
**Review your way**
Pick the columns your team actually decides on.
## How it works
Every form submission lands in one inbox where your team can review it and accept, decline, or
return it for more information. You see who submitted, which partner it belongs to, and its
status at a glance, and you can tailor the columns you review by. No submission falls through the
cracks, and partners get a clear answer. A decline is not final: if circumstances change, you can
reopen a declined submission and send it back into review.
Volume does not have to mean volume of clicks. Where a run of submissions deserves the same answer,
select them and accept or decline the whole batch with one message to the partners behind it - each
submission still runs its own CRM automations, notifications, and approval steps.
For workflows that need sign-off, you add an approval gate, including multi-step approvers, so a
submission is only accepted once the right people agree. AI can review routine submissions
against your instructions and auto-handle the obvious ones, collapsing approval time from days to
seconds while keeping humans in the loop where judgment matters.
Submissions & Approvals turns review into a fast, consistent workflow. Submissions land in one
inbox, gates route the ones that need sign-off, and AI handles the routine majority. Your team
spends its time on the decisions that actually need a human.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
submit["Submission"] --> inbox["One inbox"]
inbox --> gate["Approval gate or AI"]
gate --> decision["Decision"]
```
## Run it from your AI assistant
* Show all pending submissions across every form.
* Approve Acme's submission and notify them.
* Return Globex's registration for missing fields.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Submissions from every channel land here to review.
Approvals are configured per form.
Approve registrations submitted via forms.
Route approvals to the partner's manager.
# Submissions & Approvals
Source: https://docs.introw.io/features/forms/submissions-approvals/technical/index
Review partner form submissions, configure approval gates and AI validation, customize the inbox columns, and set reviewer notifications in Introw.
## Where it lives
Submissions & Approvals sits under **Submissions**, at [Submissions](https://app.introw.io/submissions).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Access to submissions | The inbox is where you decide | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Approvers defined, for multi-step | Only for staged approval | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
## How it works
Submissions land in the **Submissions** inbox. Each submission holds one of six statuses and shows
the form, partner, submitter, and dates. From a submission you can accept, decline, return for more
information, or reopen it.
| Status | What it means | Still editable? |
| - | - | - |
| **Pending** | Waiting on an approver step, or on AI that was not confident enough | Yes |
| **Accepted** | Approved: CRM automations have run and the partner has been told | No |
| **Auto accepted** | Accepted with no human, either with no gate or by AI above its threshold | No |
| **Declined** | Rejected, with your decline message sent | No, but it can be reopened |
| **Returned** | Sent back to the partner for more information | Yes, by the partner |
| **Error** | The write to your CRM failed, almost always a required property or a validation rule | Yes |
**Error is not a decision.** It means the submission reached Introw but your CRM refused the record, so
treat it as work rather than an outcome. **Accepted is final**: an accepted submission cannot be
un-accepted, because accepting is what created the CRM record and told the partner yes. Correct the
record in your CRM and use **Return** to ask for a corrected submission.
**Reading an Error.** Open the submission and the object that failed carries a red **Could not create**
panel with the reason in plain language, rewritten from your CRM's own refusal so it names what
happened rather than a status code. A submission that failed on several objects reports each one
against its own object. Where the cause is the submitted data, a required property left empty or a
value your CRM validates, the panel says **Edit the submitted fields to retry** and the automation
runs again on your correction. Where the cause is a permission, fix it in your CRM first: Introw does
not retry a permission refusal, because the same call fails the same way every time. Once the cause
is fixed in your CRM, you can also accept an Error submission again, from the **Accept** dialog or by
sending the message the channel conflict chat drafts for you: either one reruns the CRM create, sends
the acceptance email and marks the submission Accepted. The chat replies before the CRM create
finishes, so if it fails again the chat still says the submission was accepted: the red panel and the
**Submission error** email are where the new failure shows. See
[Every CRM error Introw logs](/features/integrations/crm/guides/every-crm-error-introw-logs).
**Someone has to be told.** Introw emails a **Submission error** notification to the internal
recipients configured under **Notify your team** on that form's **Automation** tab, and to nobody
else. A form with no recipients there sends no error email, so its failed submissions wait in the
inbox until someone looks. Configure recipients on every form that writes to your CRM.
Approval behavior is set per form in the form's Automation tab. You can require an approval gate
with one or more approver steps, and optionally enable AI validation that reviews a submission
against instructions and, if you allow it, auto-executes when it is confident enough. Org-level
notifications control which emails go out on submit and on each outcome.
## Settings & configuration
The inbox is at [Submissions](https://app.introw.io/submissions); approval gates are set per form
in the Automation tab.
### Reviewing submissions
Open a submission to see its details and act on it: accept, decline, or return. Returned
submissions can be edited and resubmitted by the partner. A declined submission can be reopened
from the top of the submission, which returns it to pending for another decision - it re-enters
the approval gate from the first step and re-runs AI validation if enabled.
### Editing a submission
You can correct the answers on a **Pending** or **Error** submission. What the save does depends on the form:
* **No approval gate (auto-accept form).** The edit is resubmitted on the spot: the submission becomes **Auto accepted** and the corrected values go to your CRM now. Partners do not get a second "form submitted" email.
* **Approval gate, and you approve the current step.** The submission stays in review and the **Accept** dialog opens right away, so you can finish the review in one go.
* **Approval gate, and you do not approve the current step.** The submission stays **Pending** and the confirmation says it is still waiting for review.
* **An Error submission.** Editing is the retry. The approval cycle restarts, so the submission has to be accepted again, unless the form auto-accepts.
**Accept**, **Decline** and **Return** show only to the approvers of the current step, so a team member who is not in that step no longer sees buttons Introw would refuse.
### Inbox columns
Use the configure option to choose the columns shown in the inbox, including custom and CRM
fields, so you review by what matters to you.
### Bulk accept, decline, and delete
Select submissions with the checkbox on the left of each row. The column headers are replaced by a
bar reading **N selected** with **Accept**, **Decline**, and **Delete**, and the checkbox in that bar
selects every row currently loaded in the table - so filter or search first, then select, when you
want a batch that is scoped to one form or partner.
**Accept** and **Decline** open one dialog for the whole batch with an optional **Message to
partners**. It is prefilled with the form's accept or decline message when the selection has one, and
the same message is sent to every partner in the batch and posted on each submission, so the partner
still gets a reason rather than a bare status change.
Every submission in the batch runs the same path as accepting or declining it on its own: CRM
automations, partner and team notifications, and timeline events. Where the form has an approval
gate, a bulk accept records your approval on the current step (and on any later step you are an
approver for) rather than force-accepting - the submission is accepted once the last step is
satisfied.
Only what qualifies is processed, and the rest is skipped rather than blocking the batch. Introw
reports how many were processed and how many were skipped:
* **Not pending** - already accepted, declined, or returned. Both actions only touch pending submissions.
* **No partner linked** - bulk accept skips a submission Introw could not tie to a partner, since attribution is the point of accepting it. Link the partner, or open the submission and accept it there.
* **Not yours to approve** - you are not an approver on the submission's current step, or you already approved it.
* **An MDF request with no fund** - route it to a fund first, since acceptance is what creates the fund-linked request.
**Accept** and **Decline** are greyed out until the selection holds at least one pending submission
with a partner linked, so a selection of only partnerless or already-decided submissions offers
neither. **Delete** stays available for any selection and permanently removes those submissions: it
is not a decline, no partner is told, and it cannot be undone.
### Approval gate
In a form's **Automation** tab, switch on **Approval gate** to hold submissions as pending rather than
accepting them on arrival. One question then sets how much of the review Introw AI owns: **Manual**
sends every submission to your approvers with no AI, **AI Assisted** has the AI pre-check and recommend
while your approvers decide, and **Autonomous AI** lets it accept, decline or return on its own above
the confidence you set, escalating everything below. Switching the gate on lands on **AI Assisted** and
seeds one step set to **Anyone**, so it starts permissive and you tighten it from there. Steps run in
order: each must approve before the next is asked.
**Each step carries exactly one approver**, chosen from:
| Approver | Resolves to |
| - | - |
| **Anyone** | Any team member in your organisation |
| A **partner team role** | Whoever holds that role on the submitting partner, per submission |
| A **specific team member** | That one person |
| **Fund owner** | The owners of the fund an MDF request is routed to (MDF forms only) |
The two dynamic options are what let one form serve every partner without a rule per partner. Removing
the last step switches the gate off entirely.
**What the model does not express**, since these are the questions it raises most: two approvers on one
step where either may approve, routing by a field value such as territory or deal size, an SLA that
auto-accepts after a number of days, and accepting or declining from Slack or Teams (the chat message
deep-links to the submission instead). See
[Choose how submissions get approved](/features/forms/submissions-approvals/guides/choose-an-approval-model)
for what to do instead in each case.
### What the partner sees
Nothing about the gate is visible to a partner unless you show it, which is why "where is my
registration" is a common question.
* **Their own submissions, with status.** Add the **Form submissions** section to the portal experience, from the **Forms** group in the section picker. It lists that partner's submissions with a **Status** column.
* **A returned submission comes back prefilled.** When a partner reopens the form after a return, their previous answers are already filled in and the reviewer's return comment is shown with them. Their edit resubmits the same submission rather than creating a second one, so a return does not fragment the inbox.
* **Outcome emails are org-level.** Accepted, declined and returned emails are configured on [Default settings](https://app.introw.io/settings/segments/default), on the **Notifications** tab, under the **Submissions** group.
### AI validation
Both AI modes are steered from the same box on the gate. Under **Guidance for Introw AI**, write the
rules a submission has to meet in plain language, or **Generate with AI** a first draft from the
form's own fields and edit it. On **Autonomous AI**, one slider sets the confidence the AI has to
clear before it accepts, declines or returns by itself (it defaults to 90%); anything below that bar
still goes to your approval steps. See [AI Approvals](/features/ai/approvals/technical).
### Notifications
Per-form, set who is informed on submit. Org-level notification settings control partner emails
for accepted, declined, and returned outcomes.
## How-to guides
* [**Choose how submissions get approved**](/features/forms/submissions-approvals/guides/choose-an-approval-model)
Decide who signs off on partner form submissions, what accept, decline and return each do, and what the partner sees at every step.
* 
[**Customize the submissions inbox**](/features/forms/submissions-approvals/guides/customize-the-submissions-inbox)
Customize the submissions inbox in Introw: choose the columns you review form submissions by, including custom fields and mapped CRM properties.
* [**Run a submission approval workflow**](/features/forms/submissions-approvals/guides/run-a-submission-approval-workflow)
Set up a form submission approval workflow with steps and AI validation, notify the right reviewers, and process every submission to a clear outcome.
## Troubleshooting
AI auto-execution only acts when it meets your certainty threshold; less certain cases still route to a human. Returned submissions wait on the partner to resubmit, so track them so they do not stall. The form-submitted notification is managed per form, while outcome notifications are managed at the org level. Spam protection (reCAPTCHA) is applied automatically to public forms, so there is no toggle to enable and nothing to configure. Bulk accept and decline send one shared message to every partner in the batch, so keep batches to submissions that deserve the same answer, and note that **Return** is per submission only - returning asks that partner for something specific.
It is waiting on an approver step, or AI was not confident enough to auto-execute.
The certainty threshold is higher than its confidence, or auto-execution is off.
Check the org-level notification settings for that outcome.
No selected submission is both pending and linked to a partner. Both buttons hinge on that, so a partnerless submission has to be handled from the submission itself.
They were not pending, had no partner linked, were on an approval step you are not an approver for, or were MDF requests not yet routed to a fund. Open those individually to see which.
It selects the rows loaded in the table, not every match behind the filter. Scroll to load more, or narrow the filter and repeat.
# Market Development Funds
Source: https://docs.introw.io/features/mdf/index
Run MDF end to end on your CRM: allocate budgets, collect proposals, approve, gather proof of spend, prove ROI, and reimburse with partner attribution.
> 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?
# Wire partner ownership
Source: https://docs.introw.io/features/partners/team/guides/wire-partner-ownership
Assign your team to a partner with the right roles, then wire ownership through portal contacts, senders, certificate issuers, and form approvals.
## What you'll achieve
Each partner has a clear owner, and that ownership flows automatically into the portal points of contact, the sender and reply-to on partner communications, the issuer on certificates, and form approval routing. Change the assignment and every downstream surface follows, with no per-partner editing.
## Before you start
You need permission to edit a partner and manage its team.
The partner team roles you assign (for example lead partner manager, technical contact) should already exist. See [Team Management](/features/access/team-management/guides/set-up-partner-team-roles).
## Watch it
## Steps
### Assign the team
Go to [Partners](https://app.introw.io/partners), open the partner, and find its **Team** card. This card lists the people from your side who own the relationship.
Add a team member and choose the **partner team role** they hold, such as lead partner manager or technical contact. The role is what downstream surfaces key on (the partnership manager step, for example, resolves to whoever holds the lead role).
Some roles allow only one member, such as a single lead manager. Adding another prompts you to replace the current one. Set the lead deliberately, since the sender, issuer, and approver routing all resolve to the assigned manager.
### Wire the downstream surfaces
In [Experiences](https://app.introw.io/templates), add a partner profile or team section to the experience so the logged-in partner sees their assigned team. The names update automatically as you change the assignment, so you build it once. Preview as a partner, then publish.
On a partner-facing communication, set the sender to the partner's assigned manager rather than a fixed address, so it resolves per partner and replies reach the owner. Set it on [Announcements](https://app.introw.io/announcements) and on partner notifications. Reply-to follows the same assigned manager.
On a certificate, set the **Issued by** field to the team member who should appear as the issuer, such as the partner's assigned manager, so credentials are signed by the right person. Open the certificate in [Certificates](https://app.introw.io/certificates) and save so new awards carry it.
On a form's automation, enable the approval gate and add an approver step set to the **partnership manager**, which resolves to the partner's assigned manager at submission time. Open the form in [Forms](https://app.introw.io/forms), add the step, and save so new submissions route to whoever owns the partner.
## Verify it worked
The partner's **Team** card lists the assigned members with their roles. The portal shows those people as points of contact, a delivered communication shows the assigned manager as sender and reply-to, a new certificate names them as issuer, and a test submission routes its approval to the partner's manager. A partner with no team assigned falls back to org defaults instead.
## Related
Define the roles you assign here.
Use the assigned manager as the email sender.
Manage the rest of the partner's fields.
Full configuration options for partner team ownership.
# Assign a partner's tier
Source: https://docs.introw.io/features/partners/tiers/guides/assign-a-partner-tier
Set a partner's tier on their detail page, or update a whole cohort at once with bulk edit, and have it flow to your CRM when tier sync is on.
## What you'll achieve
Partners assigned to the right tier, individually or in bulk, so the correct benefits apply and, when tier CRM sync is configured, the status is written to your CRM.
## Before you start
Your tier program and its tiers should already exist, and you need write access to partners.
## Watch it
## Steps
Open the partner on [Partners](https://app.introw.io/partners) and set the **Tier** field on their detail page. The tier options come from the program, and each partner holds one tier per program. Use this for a single new partner or a one-off change.
On the partners list, select the partners you want to update, choose the bulk **Edit** action, pick **Tier** as the property, and set the tier for the whole selection together. Use this after a tier review to move a cohort in one pass instead of opening each record.
Save. If tier CRM sync is configured, the assignment is written to the CRM as well, so the tier stays aligned across both systems.
## Verify it worked
Each partner shows the assigned tier on [Partners](https://app.introw.io/partners), and on their CRM record when sync is configured.
## Related
Create the program and its tiers first.
Push tier status to the CRM and keep it in sync.
Change tier and other properties across a cohort.
Full configuration options for tiers.
# Build a tier program
Source: https://docs.introw.io/features/partners/tiers/guides/build-a-tier-program
Create a tier program with ordered tiers, badges, and colors, then fill each tier's requirements and benefits with text, checkbox, and goal items.
## What you'll achieve
A complete tier program: ordered tiers each with a visual identity (name, color, badge, description), and requirements and benefits filled in so partners know what it takes to climb and what they unlock, including measurable goals that show live progress.
## Before you start
You need access to tier settings to create programs and tiers.
Have one badge image per tier ready to upload. Badges are shown small and fitted, never cropped, and partners download them at full size to put on their own site, so a **square PNG with a transparent background at around 512×512** works best. Up to 20 MB per file.
## Watch it
## Steps
### Create the program and tiers
On [Tiers](https://app.introw.io/settings/tiers), choose **Create Program** and name it for the partner type or motion it covers. Each program is independent, so you can run different ladders side by side for different partner types.
In the program editor, choose **Create tier** for each level, such as Bronze, Silver, and Gold. A partner holds exactly one tier per program.
Drag the tiers into sequence from entry level to top. This order is the ladder partners see, so keep it lowest to highest.
### Brand each tier
Open a tier and set what partners see:
* **Name** - the label for the level, such as Gold. Keep it consistent with how you talk about the program.
* **Color** - a color that distinguishes this tier from the others on the ladder at a glance.
* **Badge** - the artwork for the tier. Partners assigned to it can download the badge to display on their site or signature, which markets your program for you. Use a square, transparent PNG around 512×512: in the portal it renders fitted at roughly 32px next to the tier name, and partners get the original file when they download it. The upload box in this editor is wide, so ignore how the preview frames it.
* **Description** - a rich description of what the tier represents, reinforcing its value.
### Define requirements and benefits
In the tier's **requirements** group, add items that explain how to reach the tier. Each item can be:
* **Text** - a plain statement of what is expected.
* **Checkbox** - a yes/no item partners can see as a checklist.
* **Goal** - a measurable target that progress tracks against.
In the **benefits** group, add the perks the tier unlocks using the same text, checkbox, or goal item types, so the value of leveling up is obvious.
For any goal item, set its target so a partner's progress shows against it. A goal with no target shows no progress, so this is what turns a static requirement into a live one.
## Verify it worked
The program appears on [Tiers](https://app.introw.io/settings/tiers) with your tiers in order, each showing its color and badge, and every tier shows its requirements and benefits. Goal items display progress toward their target. The program is ready to assign partners to.
## Related
Place partners on the ladder, individually or in bulk.
Keep tier status aligned with your CRM.
Full configuration options for tiers.
# Tiers
Source: https://docs.introw.io/features/partners/tiers/index
Build tier programs with clear requirements and benefits, show partners how to level up, and keep every partner's tier synced to your CRM.
> Tiers give your program a ladder: every partner can see what their tier unlocks and what it takes to reach the next one, and their status stays in sync with your CRM.
## The problem it solves
Tiering often exists on a slide but not in a way partners can act on:
| Without Introw | With Introw |
| - | - |
| Partners cannot see how to level up | Requirements are published |
| Tier status is invisible elsewhere | It syncs to a CRM property |
| A tier is a label, not a motivator | Goal-based requirements |
| Maintaining tiers is manual | No-code programs, bulk assign |
## Impact
A tier only motivates when a partner can see the rung above and what is on it. Publishing the requirements is what turns a label into something they will work for.
for your business
* **Cost to run**
Partner ops builds programs, tiers, requirements and benefits with no code, and assigns in bulk
* **In your CRM**
Each partner's tier syncs to a CRM property, so sales and ops can act on it without asking
for your partners
* **Self-serve**
They can read what their tier unlocks and exactly what the next one requires
* **Enabled**
A named colour and a downloadable badge they can put in front of their own customers
* **Efficient**
Goal-based requirements track their real progress, so nothing has to be claimed by email
[A day in the life of a reseller](/days-in-the-life/reseller)
* **Partner Operations** - programs and CRM sync
* **Partner Marketing** - a ladder that drives behaviour
* **Partner alliance managers** - what the next tier takes
## See it work
* 
**The partner sees the ladder**
Where they stand, and exactly what the next tier asks for.
* 
**Add the tiers**
As many levels as your program actually has.
* 
**Give each an identity**
A name, a colour, a badge and a description.
* 
**Publish the requirements**
Text, a checklist, or a goal tied to real progress.
* 
**Assign in bulk**
One partner, or a whole selection at once.
## How it works
Tiers let you build one or more tier programs, each a set of levels like Gold,
Silver, and Bronze. For every tier you spell out two things partners care about most:
the **requirements** to reach it and the **benefits** it unlocks. Requirements can be
simple statements, checklist items, or goals tied to real progress, and benefits make
the value of leveling up concrete.
Each tier gets its own identity, with a name, color, and downloadable badge a partner
can show off. Partners are assigned to a tier individually or in bulk, and because
Introw sits on your CRM, a partner's tier syncs to a CRM property, so the rest of your
go-to-market motion can see and act on it. The result is a transparent ladder that
motivates partners to invest more in the relationship.
Tiers turn a tiering policy into a working program. Partner ops builds the levels and
their requirements and benefits once, partners see a clear ladder to climb, and every
partner's tier flows back to the CRM so the whole revenue team works from the same
status. The program motivates partners instead of just labeling them.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
build["Build tiers, requirements, benefits"] --> qualify["Partner meets requirements"]
qualify --> assign["Tier assigned"]
assign --> sync["Synced to CRM"]
```
## Run it from your AI assistant
* List every tier in order with its requirements and benefits.
* How close is Acme to the next tier based on their goal progress?
* Which Silver partners now meet the Gold requirements and should be promoted?
* Promote Acme to Gold and sync the new tier to our CRM.
* Show all partners grouped by tier and country.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Set discounts by tier.
Tiers organize the partner list.
Sync tier to a CRM property.
Move a partner up a tier the moment they earn it.
# Tiers
Source: https://docs.introw.io/features/partners/tiers/technical/index
Create tier programs, define requirements and benefits, assign partners to tiers, and sync tier data back to your CRM automatically in Introw.
## Where it lives
Tiers sits under **Settings**, at [Tiers](https://app.introw.io/settings/tiers).
## Before you start
| You need | Why | Fix it |
| - | - | - |
| Access to tier settings | Programs and tiers are created there | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| Integration settings access | Only to map tiers to a property | [Internal roles](/features/access/team-management/guides/create-an-internal-role) |
| A connected CRM | Only if assignments should sync | [Connect a CRM](/features/integrations/crm/guides/connect-hubspot) |
## How it works
A **tier program** is a container for a set of tiers, and you can run more than one
program for different partner types. Inside a program you create tiers (for example
Gold, Silver, and Bronze) and order them from lowest to highest. Each tier has its own
name, color, and optional badge image, plus two groups partners care about:
**requirements** (what it takes to reach the tier) and **benefits** (what the tier
unlocks).
The items inside those groups can be plain text, checklist items, or goals that track
real progress against a target. A partner is assigned to exactly one tier within a
program, on their own detail page or in bulk from the partners list. When you map a
tier to a CRM property, assignments sync to the CRM, and a tier set in the CRM can flow
back into Introw.
## Settings & configuration
Tier programs are managed under
[Settings, then Tiers](https://app.introw.io/settings/tiers). Each program opens its
own editor.
### Tier programs
**Create tier program** starts a new program with a name (for example a name for a
specific partner type). Each program is independent, so you can run different ladders
side by side. From the program list you can also rename, duplicate, or delete a
program.
### Tiers within a program
**Create tier** adds a level to the open program. A tier has a **name**, a **color**,
an optional **badge**, and a rich **description**. Drag tiers to order them from
entry level to top, since that order is the ladder partners see.
The badge is stored and served as uploaded - no ratio is enforced and no crop step
runs - and every partner-facing surface fits it inside its box rather than cropping:
roughly 32px next to the tier name in the portal, 40px in the tiers list, and full
size in the download dialog, where partners can also copy an `` snippet that
links back to your site. So upload a square, transparent PNG at around 512×512, up to
20 MB. The upload frame in the tier editor is 16:9 and previews with a fill crop,
which is cosmetic: it does not affect the stored file.
**Requirements** and **benefits** are the two groups shown for each tier. Add items to
them as **text** for a plain statement, a **checkbox** for a yes/no item, or a **goal**
that links to a measurable target so progress shows against it. Use requirements to
explain how to reach the tier and benefits to make its value concrete.
#### What a tier states
A tier holds named groups of items - "Requirements", "Benefits", whatever you call them - and each item
is a yes/no, a free-text value, or **a goal**. A goal-backed item is the one that makes the ladder
honest: the tier states the requirement and the partner sees their live progress against it in the same
place, so "what do I need to do to reach Gold" is answered by the portal rather than by an email.
### Assigning partners
A partner's **tier** is set on their detail page or, for many partners at once,
through the bulk edit action on the partners list. Each partner holds one tier per
program.
### CRM sync
**Sync** maps your tiers to a CRM property so a partner's tier is written to the CRM,
and a tier already set in the CRM can be pulled into Introw. Set this up once and tier
status stays aligned across both systems.
### Automate it with a workflow
Tiers sync from your CRM on their own, and a [workflow](/features/automation/workflows/technical) covers the moves your CRM does not decide. **Update partner properties** with **Partner tier** writes the tier from any trigger, so "move them up the moment their contact certifies" or "promote on finishing onboarding" is a rule rather than a quarterly clean-up.
The **Write mode** on that row is the setting to think about: **Overwrite** is right for a promotion, because the point is to move a partner who already has a tier, while **Fill in if not known** is right when your team also sets tiers by hand and should not be overridden. A tier condition on a fork reads the tier the partner has when that step runs, so a chain can check a promotion actually landed.
See [Build your first workflow](/features/automation/workflows/guides/build-your-first-workflow), which is this exact rule end to end.
## How-to guides
* 
[**Assign a partner's tier**](/features/partners/tiers/guides/assign-a-partner-tier)
Set a partner's tier on their detail page, or update a whole cohort at once with bulk edit, and have it flow to your CRM when tier sync is on.
* 
[**Build a tier program**](/features/partners/tiers/guides/build-a-tier-program)
Create a tier program with ordered tiers, badges, and colors, then fill each tier's requirements and benefits with text, checkbox, and goal items.
## Troubleshooting
A partner holds one tier per program. Tier order is the ladder partners see, so keep it lowest to highest. CRM sync needs both tier access and integration access; if the mapping is incomplete, the sync control flags it until every tier is mapped.
The tier mapping is incomplete; finish mapping every tier and run **Sync**.
Drag them into sequence; the order on screen is the order partners see.
The goal is not linked to a measurable target yet; set its target so progress can be tracked.
# Channel Conflict
Source: https://docs.introw.io/features/referrals/channel-conflict/index
Channel conflict screening checks every referred lead against your direct and partner pipeline before crediting, so referrers never lose deals to overlap.
> Nothing kills a referral program faster than a partner referring a deal your direct team already has. Channel conflict screening checks every referral against your pipeline before it credits, so the referrer knows their intro will be recognized and never quietly duplicated.
## The problem it solves
A referral program leaks trust at the point of overlap:
| Without Introw | With Introw |
| - | - |
| A partner refers a deal you have | Overlap is caught before credit |
| Two partners refer one account | The earlier claim is surfaced |
| Duplicates pile up quietly | Matched against pipeline first |
| Disputed credit stops referrals | Handled on facts, up front |
## Impact
A referral is a promise about credit. Screening every intro against your own pipeline before it counts is how you keep that promise, and keeping it is why a referrer sends the second one.
for your business
* **Trustworthy**
Overlaps are caught and resolved on facts, so a referrer's intro is honoured rather than quietly duplicated
* **In your CRM**
Screening runs against the deals already in HubSpot or Salesforce, not a separate referral database
for your partners
* **Self-serve**
They learn where they stand at submission, instead of finding out at payout time
* **Enabled**
Knowing an intro will be screened fairly is what makes referring worth the effort
* **Efficient**
One check up front, rather than an argument about credit months later
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Managers** - clean credit without policing
* **Chief Revenue Officer** - direct and referral kept aligned
* **Referral partners** - an intro that will be honoured
## See it work
* 
**Turn on the screen**
Pick the object to check against, and narrow it with filters.
* 
**On the referral form**
The same screen runs on the form partners refer through.
## How it works
When a partner refers a lead, Introw cross-references your CRM for an existing opportunity on the same account. That covers both cases: the direct team already has it, or another partner referred it first. The check runs before the referral creates records or credits anyone. Overlaps are flagged with the context: who's involved and which claim came first. A clean referral flows through and lands attributed; an overlapping one is surfaced so credit is decided fairly instead of the same deal being double-counted.
This is the same [AI channel-conflict engine](/features/ai/channel-conflict) that runs across every submission motion, applied to the referral flow. What's specific to referrals is what's protected - the referrer's trust that a warm intro will be honored, which is the whole basis of a program that keeps producing.
Screening makes a referral a promise you can keep. The partner refers, Introw checks the lead against your pipeline, and only a conflict-free (or fairly resolved) referral becomes attributed pipeline the referrer will be rewarded for.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
refer["Partner refers"] --> screen["Conflict screen vs. pipeline"]
screen -->|clear| credited["Attributed, credited lead"]
screen -->|overlap| resolve["Flagged for fair resolution"]
```
## Run it from your AI assistant
* Does this referral overlap a deal our direct team already has?
* Has anyone else referred this account before?
* Which shared leads conflict with existing pipeline?
## Going deeper
Configure detection and resolution on the AI channel-conflict page.
Turn on screening for a referral form and work conflicts from the inbox.
**Works with**
The AI engine that detects and resolves conflict.
Every referral is screened before it credits.
Clean attribution protects the reward that pays out.
# Keep referrers updated
Source: https://docs.introw.io/features/referrals/deal-updates/guides/keep-referrers-updated
Set up automated notifications that keep referrers in the loop as their referred deals progress, win, or close - delivered by email and chat.
Referrers stay engaged when they can see their introduction paying off. This guide sets up the full update loop: progress notifications as a referred deal advances, a celebration when it is won, and delivery by email and chat so the news reaches referrers where they work. Progress and wins are two notification types on the same partner-notification machinery, so you configure them together once and they run automatically.
## What you'll achieve
Referrers who automatically hear about their referred deals: a notification when the deal advances through meaningful stages, a closed-won notification when it lands, delivered by email and, where connected, Slack or Teams. No manual status updates, and the program feels alive between referral and reward.
## Before you start
Updates only reach a referrer when the referred deal is attributed to that partner in your CRM. See [Build and share a referral form](/features/referrals/lead-sharing/guides/build-and-share-a-referral-form).
Delivering updates to chat requires a connected Slack or Teams workspace. See [Slack and Teams](/features/integrations/chat).
## Watch it
## Steps
### Turn on the update events
Go to [Default settings](https://app.introw.io/settings/segments/default) and open the **Notifications** tab. These are the org-wide defaults for which events notify partners, and every segment inherits them until it overrides one. The deal-progress machinery is the same partner-notification system covered in [Partner notifications](/features/engagement/notifications); this guide tunes it for referrers.
For the partner audience, turn on the two events that keep referrers informed:
* **Object updates** - notifies the partner when a related object changes in your CRM. This is the workhorse for progress: a stage change on a referred deal counts as an update, so referrers hear about advancement.
* **Deal closed won** - notifies the partner when a related deal is won. This is the single most motivating message in a referral program and the natural lead-in to the reward conversation. It is on by default for partners.
### Tune what counts as progress
A raw object update can fire on any field change, which is noisy. On the deal pipeline embed in the **Experience builder**, open the **Deal updated** notification and configure which properties count: mark the fields that represent real progress (stage, amount, close date) to notify partners and silence fields referrers do not care about. If stage is not watched, advancement will not notify.
On the same embed, open the **Deal won** notification to confirm which closed stages count as won, so the closed-won message fires at the right moment rather than on every closed stage.
### Choose how updates reach referrers
Each event can be delivered by email and, where connected, by Slack or Teams. Choose the mix that fits how your referrers prefer to hear from you: email for a durable record, chat for referrers who rarely open their inbox and respond fastest in the moment. Per-channel setup lives in [Partner notifications](/features/engagement/notifications).
The org defaults apply everywhere, but a specific pipeline embed can override which events notify and which properties are watched. Use this when one referral pipeline needs a different update cadence than the rest.
## Verify it worked
Move a test referred deal to a new stage and confirm the attributed partner receives a progress update by your chosen channels. Then move it to a winning stage and confirm they receive the closed-won notification. If chat is connected, confirm the message also lands in Slack or Teams.
## What your partners experience
With updates configured, the referrer hears about their deal where they already work: a notification when it moves stage or closes, by email, Slack, or Teams, plus the status in their portal. That is the payoff of this setup on the partner side - a referrer who made a warm intro sees it is being worked and knows what they will earn, without chasing your team for a status.
## Related
Attribute referred deals so updates reach the right referrer.
Reward referrers after the win.
The canonical notification machinery and per-channel setup.
Full configuration options.
# Deal Progress Updates
Source: https://docs.introw.io/features/referrals/deal-updates/index
Keep referrers in the loop automatically - when your direct team moves a referred deal forward, the referrer is notified without chasing you for status.
> The fastest way to kill a referral program is silence after the intro. Deal progress updates close that gap: as your team works the referred deal, the referrer is kept informed automatically, so they stay confident and keep sending you deals.
## The problem it solves
The handoff after a referral is where trust erodes:
| Without Introw | With Introw |
| - | - |
| Referrers go dark after the intro | They are notified as it moves |
| Chasing status eats your time | Updates fire on CRM events |
| Ignored partners stop referring | Timely updates keep them warm |
| You over- or under-notify | You pick the events that count |
## Impact
Silence after the intro is what kills a referral program. A partner who hears the deal moved, without asking, is a partner who sends the next one.
for your business
* **No new tool**
The update reaches the referrer by email and chat, so nothing depends on them opening a portal
* **Trustworthy**
The notification fires off the CRM event itself, so what the referrer hears is what actually happened
for your partners
* **Self-serve**
They never have to email for status, because the status comes to them
* **Enabled**
They can answer their own prospect about progress, which is what protects their relationship
* **Efficient**
One notification when something real changes, not a weekly report to read
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Managers** - warm referrers, no status emails
* **Referral partners** - progress, in real time
## See it work
* 
**Open the settings**
Updates are configured per embed, alongside the pipeline.
* 
**Pick the events**
Object updates and closed-won, or just the ones you choose.
## How it works
Once a partner refers a lead and, once it's qualified, your direct team takes over the sale, the
referrer naturally wants to know what happened. Deal progress updates send that status automatically. When a
deal related to a partner is updated or won in your CRM, Introw notifies the partner by email
and chat, based on the events and properties you choose to watch.
The referrer never has to email you for an update, and your team never has to remember to send
one. The result is a referral motion that feels alive to the partner, even though the vendor
is running the actual sale.
Pick the deal events that matter, and Introw keeps referrers informed as your team runs the
sale. Referrers stay confident, your team stays heads-down, and the program keeps producing.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
events["Pick deal events"] --> move["Team moves the deal"]
move --> notify["Referrer notified automatically"]
```
## Run it from your AI assistant
* What's the latest status on the deal I referred into Acme?
* Post a comment on my referred deal asking the rep for next steps.
* Show updates on all the deals I've referred.
## Going deeper
Setup, configuration, and all how-to guides.
Integration surface and code.
**Works with**
Update partners on leads they shared.
Send status updates off-portal.
# Deal Progress Updates
Source: https://docs.introw.io/features/referrals/deal-updates/technical/index
Configure the notifications that keep referrers updated as their referred deals move through your CRM, by email and chat, in Introw.
## Where it lives
Deal Progress Updates is the partner-notification layer, so it lives in two places under **Settings**: [Default settings](https://app.introw.io/settings/segments/default), on its **Notifications** tab, is where you choose which deal events reach referrers, and [Notification settings](https://app.introw.io/settings/notifications) reports what actually went out.
## Before you start
| You need | Why | Fix it |
| - | - | - |
| A connected CRM with attribution | Updates reach the right referrer | [Configure attribution](/features/co-selling/shared-pipelines/guides/configure-deal-attribution) |
| Slack or Teams, for chat updates | Only for the chat channel | [Connect Slack](/features/integrations/chat/guides/connect-slack) or [Teams](/features/integrations/chat/guides/connect-microsoft-teams) |
## How it works
Referrer updates are partner notifications driven by your CRM. When an object related to a
partner is updated or reaches a winning stage, Introw can send that partner an email and a
chat message. You set the defaults for which events notify partners org-wide, and you can
override them per pipeline embed and per segment.
There is no separate "referral autopilot" to configure. Instead you decide which CRM events
count as progress worth telling a referrer about, and which properties to watch for changes,
and Introw handles the delivery.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
update["CRM object update or win"] --> introw["Introw"]
introw --> email["Email"]
introw --> chat["Chat"]
```
## Settings & configuration
Org defaults live on the **Notifications** tab of [Default settings](https://app.introw.io/settings/segments/default), and any audience can
override them on its own segment; per-deal behavior is set on the CRM embed in the **Experience
builder**. Each event takes one recipients value - **All partners**, **Collaborating only**, or
**Disabled** - rather than an on/off switch.
### Object updates
**Object updates** notifies a partner when an object related to them is updated in your CRM.
This is the workhorse for progress: a stage change on a referred deal counts as an update, so
referrers hear about advancement. Keep it on for the partner audience to drive ongoing
updates.
### Deal closed won
**Deal closed won** notifies a partner when a related deal is won. Use it to celebrate the
outcome with the referrer and reinforce that referring pays off. It is on by default for the
partner audience.
### Watched properties
On a deal pipeline embed, the **Notifications** section controls which changes notify partners
and lets you mark individual properties with **Notify change to partners** or **Don't notify
change to partners**. Use this to watch the fields that represent real progress, like stage,
and to silence noisy fields referrers do not care about.
### Delivery channels
Each notification can be delivered by email and, where connected, by Slack or Teams. Choose
the channel mix that fits how your referrers prefer to hear from you.
## How-to guides
* 
[**Keep referrers updated**](/features/referrals/deal-updates/guides/keep-referrers-updated)
Set up automated notifications that keep referrers in the loop as their referred deals progress, win, or close - delivered by email and chat.
## Troubleshooting
Updates only reach a referrer when the referred deal is attributed to that partner in your CRM. Stage changes are delivered through object-update notifications on watched properties, so if stage is not watched, advancement will not notify. Chat delivery requires a connected Slack or Teams workspace.
Confirm the deal is attributed to that partner and that partner notifications are on.
Add the stage field to the embed's watched properties.
Check that Slack or Teams is connected and selected as a channel.
# Referrals
Source: https://docs.introw.io/features/referrals/index
Turn partner introductions into tracked CRM pipeline with off-portal referrals, first-touch attribution, auto status updates, and automated referral fees.
> A referral program lives or dies on friction and trust. Introw lets partners refer a named deal from wherever they already work, keeps them updated automatically as your team runs the sale, and pays referral fees and revenue share without a spreadsheet, so referrers keep referring.
## The problem it solves
| Without Introw | With Introw |
| - | - |
| Referring means logging in | A link, an email, an assistant |
| It goes silent after the intro | Updates arrive as it moves |
| Credit gets disputed | Attribution is set at the source |
| Fees are worked out by hand | Calculated from the closed deal |
## Impact
A referral partner has one question: will my intro be honoured. Answering it with automatic updates and a payout they can trace is what turns one referral into a habit.
for your business
* **In your CRM**
A referral lands as an attributed lead, and once partner-qualified it becomes the opportunity, account and contact your team works
* **No new tool**
Partners refer from a link, your site, their inbox, or an AI assistant, never from a forced portal
* **Trustworthy**
Conflict screening runs before anything credits, and payouts reconcile to the CRM deal that earned them
for your partners
* **Self-serve**
They refer, follow the deal on a shared pipeline and see what they earned, without emailing anyone
* **Enabled**
Automatic progress updates mean they can answer their own prospect about where things stand
* **Efficient**
A few details at the moment they think of it, rather than a form after a login
[A day in the life of a referral partner](/days-in-the-life/referral-partner)
* **Partner Managers** - referrers who stay warm
* **Your own reps** - clean pipeline to work
* **Referral partners** - status and earnings, unasked
## How this area works
Referrals is the motion where a partner makes a warm introduction and your team closes the deal. A referral usually enters as a **lead**: a warm intro to a named prospect. The partner submits it off-portal through a link, an embedded form, an email, or an AI assistant - no login, only a few details. It is attributed to the referring partner from the first touch.
A warm intro becomes tracked pipeline and an automatic reward.
**Where this sits in a setup.** The [referral track](/tracks/referral) is this area end to end, and the [affiliate track](/tracks/affiliate) is the same motion when the reward is per click rather than per introduction.
* 
[**Lead Sharing**](./lead-sharing)
Refer from a link, a site, an inbox or an assistant.
[How to · 2 guides](./lead-sharing/technical)
* 
[**Channel Conflict**](./channel-conflict)
Screened against your pipeline before it credits.
[Read more](./channel-conflict)
* 
[**Shared Pipeline**](/features/co-selling/shared-pipelines)
A live view of the deals they sourced.
[How to · 7 guides](/features/co-selling/shared-pipelines/technical)
* 
[**Deal Progress Updates**](./deal-updates)
The referrer hears as your team moves it.
[How to · 1 guide](./deal-updates/technical)
* 
[**Referral Rewards**](./rewards)
A fee or revenue share, paid on the closed deal.
[How to · 1 guide](./rewards/technical)
Then the referral is treated as **partner-qualified**: the partner marks it qualified, or your team accepts it. Introw goes further and creates the full deal context - the opportunity, its account and the contact. Now it's real, worked pipeline, still attributed. As your direct team moves the opportunity forward, update notifications keep the referrer in the loop, so they never chase you for status. When it closes, referral fees and revenue share are calculated and paid through commission plans tied to partner attribution.
The mechanics build on Introw's forms, notifications, and commissions, framed for the referral motion: low-friction sourcing, automatic follow-through, and trustworthy payout.
## Run it from your AI assistant
* Share a lead for Acme: contact [john@acme.com](mailto:john@acme.com), interested in the enterprise plan.
* Show all shared leads still pending review.
* What reward is owed on the referral that just closed?
# Build and share a referral form
Source: https://docs.introw.io/features/referrals/lead-sharing/guides/build-and-share-a-referral-form
Build a referral form that captures attributed leads, credits the referring partner, and share it as a link, an embed, or an API call from their systems.
A referral program only works once partners have a clean way to hand you a lead and trust that they will get the credit. This guide builds that capture form end to end: the fields partners complete, the automation that turns a submission into an attributed lead - and, when the referral is partner-qualified, the opportunity, its account, and the contact - the partner attribution that ties it to the referrer, the conflict and duplicate checks that protect credit, and the link or embed you hand out. Set it up once and every channel guide (link, email, embed, Slack, Teams, AI, API) plugs into it.
## What you'll achieve
A live referral form that a partner can open from anywhere, fill in with prospect details, and submit. Each submission creates an attributed lead in your CRM, credited to the referring partner from the first touch; once the referral is partner-qualified, that lead becomes the opportunity, its account, and the contact - still attributed. Every submission is checked for conflicts and duplicates before it is accepted. You leave with a shareable link, an embed snippet, and an API request ready to distribute.
## Before you start
A connected CRM is required so the form can create the lead - and, when qualified, the opportunity, account, and contact - and read your pipeline and properties.
Partner attribution should be configured on your CRM connection so every created record can be credited to the referring partner.
Embedding the form on your own website requires a custom domain on your plan. A shareable link works without one.
## Watch it
## Steps
### Build the form
Go to [Forms](https://app.introw.io/forms) and select **Create form**. Give it a clear name like "Refer a deal" so partners and your team recognize it, then open the **Form builder**.
On the **Form builder** tab, use **Add field** to build the questions a partner answers about the prospect. For each field, set:
* **Field type** - what kind of input it is. Use **Input field** for short answers (company name, contact email), **Text area** for context like deal notes, **CRM Object** to let a partner pick an existing record, and **File upload** for attachments. Most referral forms need a handful of input fields plus a notes area.
* **Label** - the question text the partner reads. Keep it plain ("Prospect company", "Contact email") so partners do not hesitate.
* **Placeholder** - example text inside the field that hints at the expected answer.
* **Make this field required** - turn this on for the details you must have to create a usable deal (company, contact, email). Leave optional anything that is nice to have.
* **CRM Mapping** - optionally link the field to a CRM property here so its value flows straight into the record. You can also map fields later in the automation; mapping here seeds that step.
### Turn submissions into CRM records
Open the **Automation** tab and select **Add automation**. A referral should enter as a **lead** - the lowest-friction way for a partner to hand you a warm intro, attributed from the first touch. Add a **Lead automation** and, in **Enrich or create**, turn on **Create a new lead when one is selected** so a fresh, attributed lead is created from each referral.
When the referral is **partner-qualified** - the partner marks it qualified, or your team accepts it - you want the full deal context, not just a lead. Add **Company**, **Contact**, and **Deal automations** as well, so a qualified referral creates the opportunity, its account, and the contact as real, worked pipeline. Introw matches existing records first (see the deduplication step below), so this enriches what you already have instead of duplicating it.
In the **Form fields** section, connect each answer to the right CRM property so the lead - and the opportunity, account, and contact it becomes once qualified - is populated correctly. For each mapping set:
* **CRM Property** - the field on the CRM record that receives the value (for example the deal name or amount).
* **Form Field** - the answer from the form that fills it.
* **Write Mode** - how the value is written. **Fill in if not known** (the default) only sets the property when it is empty, which is safest for enrichment; **Overwrite** always replaces the current value. Use **Add field mapping** for each property you want to set.
Use **Default values** to set properties every referral should carry (a source label, a default pipeline or stage) without asking the partner.
Turn on **Auto-link your partners** so the created records are tied to the referrer, then set the **Submitting Partner** attribution method that records who sent the referral. This is what makes credit automatic: every downstream update notification and reward depends on the referral being attributed here.
### Protect referral credit
Select **Channel Conflict Analysis** in the automation list and enable it. Before a referral creates CRM records, Introw cross-references your CRM for an existing overlapping deal so the same opportunity is not double-credited or claimed twice. Configure:
* **Object** - the record type to check conflicts against, typically the deal pipeline the referral lands in.
* **Filters** - limit the check to deals that match conditions you set, so only relevant pipeline counts as a conflict.
* **Additional context** - a short description of your process that helps the analysis judge borderline cases.
Leave it on for referral forms: a disputed deal is the fastest way to lose a referrer.
On company and contact automations, open **Enrich or create** and review **Deduplication fields**. Introw matches incoming submissions against existing company or contact records on these fields to prevent duplicates and detect conflicts. Keep the suggested defaults (name, email, domain) or pick the fields that best identify a unique account in your CRM.
### Set the partner experience and share
Configure **Submission confirmation** to control what a partner sees after submitting: choose an **End screen** with a thank-you message, or **Redirect to URL** to send them to a page you choose. Then decide review with **Approval Gate**: leave it off (the default) to accept referrals automatically, or enable it when a person should approve submissions before they create CRM records.
Select **Share form** to open the share dialog. On the **Link** tab you get two options:
* **General link** - shareable with anyone; Introw makes a best effort to relate the submission to a partner, but attribution is not guaranteed. Use it for open or web traffic.
* **Partner link** - pick a partner and copy their link; every submission through it is attributed to that partner automatically. Use this whenever you send the form to a known referrer so credit is never in question.
On the **Embed** tab, copy the HTML snippet to place the form on a page you control. Embedding requires a custom domain; without one, share the link instead.
On the **API** tab, copy the cURL snippet. It already carries this form's id and every field id, and the **Fields** table below marks which ones are required. A partner's own portal, your internal tooling, a backfill script, or an agent can then refer from anywhere, with the referral attributed to the partner you name and running the same conflict checks and automation. Full setup is in [Submit a form via the API](/features/forms/sharing-submitting/guides/submit-a-form-via-the-api).
## Verify it worked
Open a partner link yourself and submit a test referral. Confirm it appears in [Submissions](https://app.introw.io/submissions) under **Form submissions**, attributed to the right partner, and that an attributed lead was created in your CRM with the mapped properties filled in. Mark it partner-qualified (or accept it) and confirm the opportunity, its account, and the contact are created and still attributed. To check the safeguards, submit a referral that overlaps an existing deal and confirm it is flagged as a conflict rather than silently creating a duplicate.
## Related
Every channel a partner can refer from - link, embed, email, Slack, Teams, AI, or the API.
Notify referrers as their deals progress.
Pay referrers for the deals they source.
The full conflict-detection setup.
Full configuration options.
# Ways to refer a deal
Source: https://docs.introw.io/features/referrals/lead-sharing/guides/ways-to-refer
Every way partners can refer a deal - link, embed, email, Slack, Teams, AI assistant, or the API - all feeding one attributed referral form.
> Every step between a partner's intent to refer and the lead landing in your CRM costs you referrals. Build the referral form once, then let partners refer through whichever entry point fits how they work - a link, an embed, email, Slack, Teams, their AI assistant, or a call from their own systems. Every channel feeds the same form, so the lead always lands attributed to the referrer.
You build one referral form - with its CRM automation, partner attribution, and conflict and duplicate checks - and then expose it through as many channels as you like. This guide covers each one. Pick the channels where your partners already are; you don't need all of them.
## Before you start
A referral form that captures an attributed lead - and, when partner-qualified, creates the opportunity, account, and contact - should already exist, and every channel below feeds it. Build it in [Build and share a referral form](./build-and-share-a-referral-form), which also sets up attribution and channel-conflict checks.
## Choose a channel
The lowest-friction way for a partner to refer is a link they open and fill in anywhere. A **partner-specific link** attributes every submission to that referrer automatically, so credit is never in question. Prefer the partner link over the general link whenever you send the form to a known referrer.
In [Forms](https://app.introw.io/forms), open your form and open its **Share form** dialog.
On the **Link** tab, copy the general link to share with anyone, or the partner link to attribute every submission to a specific partner.
Drop the link into an email, a portal message, a Slack channel, or anywhere your partners already are. A partner link credits that partner every time they a deal.
Some partners and prospects arrive on your own pages. Embedding the referral form there captures referrals in context, with your branding. Where the page is partner-specific, use an attributed embed so each submission credits the right partner instead of arriving anonymous. Embedding requires a custom domain; without one, share the link instead.
In [Forms](https://app.introw.io/forms), open your form and open its **Share form** dialog.
On the **Embed** tab, copy the generated HTML snippet.
Add the snippet to the page where you want partners to , such as a partner landing page or a website footer.
The snippet includes a hosted `form-embed.js` script that resizes the iframe as the form grows or shrinks, including after submit.
If you already pasted a bare `