ActiveManage Docs ← Back to activemanage.co.uk

Vendor Applications

How Vendor Applications Work

In a marketplace, a vendor is a third-party seller who lists products or services on your platform. Vendor applications are the gating workflow that lets aspiring sellers apply, get vetted, and become active vendors with the right permissions and payout setup.

Vendor application form with company info, contact details, tax/VAT number, payout bank details, sample listings, and a Submit button at the bottom

The Standard Flow

  1. Discovery: Visitor clicks “Sell on our platform”.
  2. Apply: Application form captures business name, contact, tax info, bank details, sample products and any platform-specific requirements.
  3. Review: Application enters a queue. Admins review against your criteria (verified business, products in scope, no policy violations).
  4. Decision: Approved → vendor account created with seller permissions, payout configured. Declined → polite email with feedback. More info needed → request from applicant.
  5. Onboarding: Approved vendor lands in the seller dashboard with a guided checklist.

Vetting Criteria

  • Verified business registration (Companies House for UK, equivalents elsewhere).
  • Valid tax/VAT number where applicable.
  • Sample listings meeting platform quality bar.
  • No prior policy violations or chargebacks on related accounts.
  • Optional: KYC/AML check via Stripe Connect or equivalent.

Worked Examples

  • Open consumer marketplace: Lightweight application, automated approval where Stripe Connect KYC passes.
  • Curated artisan marketplace: Manual review by editorial team, looking at sample products and brand fit.
  • B2B wholesale platform: Document upload (trade licence, certifications), 5–10 day review.
  • Regulated industry: KYC + manual compliance review + sample listings + reference checks.

Vendor Approval Workflow

The approval workflow is what your admins use day-to-day to process vendor applications. Designing it well keeps throughput high while maintaining quality.

Application queue with rows showing applicant name, date submitted, status (pending/in-review/needs-info/approved/declined), assigned reviewer, age in days, and quick-action buttons

The Queue View

The pending applications page is a sortable, filterable list. Useful filters:

  • By status (pending, in review, needs info).
  • By age (longer than 5 days is a service-level risk).
  • By assigned reviewer.
  • By application source (organic, referred, ad campaign).

Per-Application View

Click an application to see all submitted data, attached documents, KYC results (if integrated), sample listings, and a notes field. Buttons: Approve, Decline, Request more info, Reassign.

Approval Side-Effects

When you click Approve:

  • A new vendor account is provisioned.
  • The applicant's user is added to the Vendor security group.
  • Welcome email with login link is sent.
  • Stripe Connect onboarding link generated (if payouts via Connect).
  • Audit log records who approved and when.

Decline Reasons and Reapplication

Define common decline reasons in Site Settings → eCommerce → Vendor Applications → Reasons. Each reason can be linked to a template paragraph in the decline email. Optionally allow reapplication after N days for less-severe reasons.

Worked Examples

  • Same-day approvals: Automate where KYC passes and product samples score above threshold; manual queue only for edge cases.
  • Curated marketplace: Editorial reviews each application in a 30-minute slot; tags applications with brand-fit notes.
  • High-volume B2B: Tier-based — small applications auto-approved, larger ones routed to senior reviewers.
  • Compliance-heavy: Two-stage — compliance officer approves, then commercial team approves.

Vendor Decline Email Template

The decline email is one of the most-read emails your platform sends — applicants want clear explanation and (if possible) a path forward. A well-written template balances honesty with respect.

Email template editor showing the Vendor Decline template with subject 'Update on your vendor application', personalised greeting, reason placeholder, possible-next-steps section, and signature

Structure

  1. Personal greeting using the applicant's name.
  2. Acknowledgement that you appreciate their time and interest.
  3. Decision statement — clear, not buried.
  4. Reason — specific enough to be useful, vague enough to not invite gaming.
  5. Next steps — “you may reapply after addressing X” or “feel free to contact us”.
  6. Sign-off — human name, not a generic “The Team”.

Editing

  1. Open Architect Panel → Email Templates.
  2. Find vendor_application_decline.
  3. Customise. The body supports a {{declineReason}} token that maps to the reason picked at decline time.
  4. Optionally write reason-specific templates (e.g. vendor_decline_kyc, vendor_decline_quality) for clearer guidance.

Example Templates

  • Generic decline: “Thanks for your interest. After reviewing your application, we're unable to approve it at this time. You may reapply in 6 months.”
  • Quality decline: “Your product samples didn't meet our quality bar. Specific feedback: [...]. We'd love to see you reapply once you've addressed this.”
  • KYC decline: “We weren't able to verify your business information through our standard checks. Please reach out to support if you'd like guidance on what to supply.”
  • Out-of-scope decline: “Your products fall outside the categories we currently support. We'll keep your contact details on file and reach out when we expand.”
Tip: Never lie in a decline email. Vague-but-honest beats specific-but-misleading every time. Applicants who feel respected become future customers, partners or hires.