> For the complete documentation index, see [llms.txt](https://vendorspace.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vendorspace.gitbook.io/docs/vendors/vendor-pipeline.md). # Vendor pipeline The vendor pipeline gives you a clear view of where every vendor stands for each of your events. From the moment you add a vendor to an event, they move through a series of stages that reflect the real-world booking process -- from initial contact all the way to being fully set up for event day. *** ## Pipeline Stages Every vendor assigned to an event moves through these six main stages: | Stage | What it means | | ----------------------- | ------------------------------------------------------------------------------------------------ | | **Lead** | Initial contact. The vendor has been added to the event, but no action has been taken yet. | | **Waitlist** | The vendor is on a waiting list for the event. They will be moved to Offer when a spot opens up. | | **Offer** | You have presented the vendor with an offer and their portal link has been shared. | | **Paid** | The vendor has completed their payment through Stripe. | | **Onboarding Sent** | An onboarding form has been sent to the vendor to collect additional details. | | **Onboarding Complete** | The vendor has completed onboarding and is fully set up for the event. | ### Terminal Stages In addition to the main pipeline, vendors can be moved to these terminal stages: | Stage | What it means | | ------------ | ------------------------------------------------------------- | | **Rejected** | The vendor has been declined or removed from the event. | | **Archived** | The vendor relationship has been archived for record-keeping. | Vendors in terminal stages are hidden from the default pipeline view but can still be found using the stage filter. *** ## How Stages Work ### Tracked per event Pipeline stages are tracked **independently for each event**. A single vendor can be at different stages across different events. For example, the same vendor might be **Paid** for your summer market and still a **Lead** for your fall event. This means you always have an accurate picture of where things stand for each event, even if a vendor participates in several. ### Automatic transitions Some stage changes happen automatically when you or the vendor takes an action: * **Creating an offer** for a vendor moves them to **Offer** and sends them a portal link (if the offer email is enabled) * **Vendor completes payment** through Stripe moves them to **Paid** and sends a payment confirmation (if enabled) * **Approving an application** can auto-create a company, link them to the event, and generate an offer if a product was selected ### Email notifications at each stage Automatic emails are sent at certain stage transitions. You can control these per event in your [event settings](/docs/events/event-settings.md): * **Lead to Waitlist:** Waitlist notification (if enabled) * **Lead/Waitlist to Offer:** Offer email with portal link * **Offer to Paid:** Payment confirmation email * **Application approved:** Approval notification * **Application declined:** Decline notification ### Manual transitions You can also change a vendor's stage manually at any time. This is useful when: * A vendor confirms participation over the phone or email and you want to move them to **Offer** * You need to move a vendor back to an earlier stage * A vendor pays outside of Stripe and you want to mark them as **Paid** manually * You need to reject or archive a vendor To change a stage manually, click on a vendor row to open the quick panel, then use the stage selector. *** ## Pipeline View The Vendors page offers three view modes: * **By Event** -- Vendors grouped under each event with stage, booth, and payment details * **Full List** -- All vendors in a flat list with expandable event rows * **Pipeline** -- A drag-and-drop Kanban board where you can move vendors between stages by dragging their cards The Pipeline view shows all six main stages as columns. Drag a vendor card from one column to another to change their stage. Vendors in terminal stages (Rejected, Archived) are excluded from the Kanban board. *** ## Using the Pipeline to Stay Organized The pipeline is designed to help you see your entire vendor operation at a glance. Here are a few ways to get the most out of it: * **Filter your vendor list by stage** to quickly see who still needs an offer, who hasn't paid yet, or who hasn't completed onboarding. * **Use the Pipeline view** to drag vendors between stages and manage your entire operation visually. * **Check the pipeline before sending reminders.** A quick look at who is still in **Offer** tells you exactly which vendors need a nudge to complete their payment. * **Click any vendor row** to open the quick panel with actions, form submission data, and stage controls. > **Tip:** Don't worry about moving vendors through every stage in order. If a vendor pays immediately after you add them, Vendor Space will jump them straight to **Paid** automatically. The pipeline reflects what actually happened, not a rigid checklist. *** ## Pipeline at a Glance Here is the typical flow a vendor follows from start to finish: ``` Lead --> Waitlist --> Offer --> Paid --> Onboarding Sent --> Onboarding Complete ``` Not every vendor will pass through every stage. Some may skip **Offer** if you go straight to manual payment tracking, and some may not need onboarding at all. The pipeline adapts to however you run your events. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://vendorspace.gitbook.io/docs/vendors/vendor-pipeline.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.