Master this essential documentation concept
Value-Added Reseller - a company that purchases a vendor's product, enhances it with additional features or services, and resells it to end customers.
Value-Added Reseller - a company that purchases a vendor's product, enhances it with additional features or services, and resells it to end customers.
When your team works with value-added resellers, a significant amount of institutional knowledge gets captured in video format — partner onboarding calls, product walkthrough recordings, channel enablement sessions, and vendor briefings. These recordings hold critical details about how each VAR enhances your product, what services they bundle, and how they position the solution to end customers.
The challenge is that video is a poor format for the kind of quick-reference lookups your team actually needs day-to-day. When a support engineer needs to confirm what a specific VAR includes in their implementation package, or when a new account manager wants to understand a reseller's unique value proposition, scrubbing through a 45-minute onboarding recording is not a practical workflow. Knowledge stays locked inside those files, effectively invisible.
Converting your VAR-related recordings into structured documentation changes how that knowledge circulates. A partner enablement call becomes a searchable article covering that reseller's added features and service scope. A vendor briefing becomes a reference page your whole team can query by reseller name, product line, or region — without sitting through the original recording.
If your team manages multiple VAR relationships and relies on recorded calls to preserve that context, see how video-to-documentation workflows can make that knowledge accessible.
A VAR reselling Microsoft 365 adds custom onboarding scripts, a branded helpdesk portal, and compliance reporting tools, but has no documentation explaining what differentiates their bundle from buying M365 directly from Microsoft — causing sales reps to struggle answering 'why not just buy from Microsoft?'
VAR-specific solution documentation clearly maps the vendor's base product against the VAR's added-value layers (custom integrations, SLA-backed support, migration services), giving sales and customers a precise comparison.
["Create a 'Base Product vs. VAR Bundle' comparison table listing Microsoft 365 native features alongside the VAR's additions (e.g., 24/7 helpdesk, automated compliance reports, onboarding wizard).", 'Document each value-added service with its own one-pager: service description, how it integrates with M365, and the business problem it solves for SMBs.', "Publish a VAR Solution Architecture diagram showing data flow from Microsoft's cloud through the VAR's management layer to the end customer's environment.", "Add a customer FAQ section addressing 'Why buy through us?' with quantified benefits such as '4-hour response SLA vs. Microsoft's 24-hour standard support.'"]
Sales cycles shorten by reducing objections at the differentiation stage, and onboarding time drops because customers arrive with clear expectations of what they purchased.
A VAR that bundles Palo Alto firewall hardware with its own network assessment service and managed SOC monitoring has no unified technical documentation — field engineers rely on Palo Alto's generic docs, missing the VAR-specific configuration baselines and escalation procedures.
A VAR technical documentation suite separates vendor documentation from VAR-layer procedures, giving engineers a single source of truth for deployment, configuration standards, and escalation paths specific to the VAR's managed offering.
['Audit existing Palo Alto documentation and tag sections that apply unchanged versus sections requiring VAR-specific overrides (e.g., custom security policy templates, SIEM integration steps).', "Write a 'VAR Deployment Runbook' covering pre-sales network assessment checklist, standard firewall baseline configuration, and integration steps for the VAR's SOC monitoring platform.", 'Create an escalation matrix document defining Tier 1 (VAR helpdesk), Tier 2 (VAR network engineers), and Tier 3 (Palo Alto TAC) with contact details, ticket templates, and SLA thresholds.', 'Version-control all VAR docs in a Git repository tied to Palo Alto firmware release cycles so engineers always know which runbook version aligns with the deployed hardware.']
Field engineers reduce firewall deployment time and escalation errors drop because the boundary between VAR responsibility and vendor responsibility is explicitly documented.
A VAR reselling SAP Business One with custom manufacturing modules and a proprietary data migration tool onboards new customers using a mix of SAP's generic user guides and informal email threads — resulting in customers calling support for tasks that should be self-service.
A structured VAR onboarding documentation portal guides end customers through the complete journey: from data migration using the VAR's tool, through VAR-customized SAP workflows, to daily operations — without referencing SAP's standard documentation for features the VAR has modified.
['Map the customer onboarding journey into phases: Data Migration, System Configuration, User Training, and Go-Live Checklist — each phase documented with VAR-specific steps and screenshots of the customized SAP interface.', "Write a Data Migration Guide for the VAR's proprietary migration tool, including field mapping templates, validation rules, and rollback procedures specific to manufacturing data.", "Create role-based quick-start guides (Warehouse Manager, Finance Controller, System Admin) that reflect the VAR's custom menu layouts and approval workflows, not SAP's default UI.", "Publish the portal in the VAR's branded customer portal with a feedback widget so support tickets can be converted directly into documentation improvements."]
First-month support ticket volume for onboarding issues decreases significantly, and customer satisfaction scores improve because users can self-serve through VAR-specific workflows.
A VAR offering a managed AWS environment with custom security hardening, cost optimization tooling, and HIPAA compliance configuration has no documentation clarifying the shared responsibility model — customers and auditors cannot determine which controls are AWS's, which are the VAR's, and which remain the customer's obligation.
A VAR Shared Responsibility Matrix document extends AWS's standard shared responsibility model with a third layer explicitly defining what the VAR manages, automates, or guarantees, giving compliance teams and auditors a precise control ownership map.
["Start with AWS's published shared responsibility model and add a 'VAR-Managed Layer' column listing each control the VAR handles (e.g., OS patching, GuardDuty alerting, monthly cost reports, HIPAA audit logging).", 'Write a VAR Security Controls Addendum documenting the specific AWS Config rules, IAM policies, and CloudTrail configurations the VAR deploys as part of the managed package.', 'Create a Customer Responsibility Checklist for controls that remain with the end customer (e.g., application-level data classification, user access reviews), with instructions for how to fulfill each in the VAR-managed environment.', "Attach the Shared Responsibility Matrix as an exhibit to the VAR's Managed Services Agreement and update it with each new compliance framework the VAR certifies against."]
HIPAA and SOC 2 audit preparation time is reduced because auditors have a pre-mapped control ownership document, and customer disputes about incident responsibility decrease.
End customers and internal teams frequently confuse what comes from the vendor versus what the VAR has built or configured, leading to misdirected support calls and unrealistic expectations. Every document should make this boundary explicit using visual markers, separate sections, or comparison tables. This prevents customers from contacting the vendor for issues the VAR owns, and vice versa.
VARs add integrations, scripts, and customizations on top of vendor products that can break when the vendor releases updates. Without documented version compatibility, field engineers deploy mismatched components and customers experience silent failures. A living compatibility matrix prevents this by explicitly stating which VAR bundle version is validated against which vendor product version.
When issues arise in a VAR-delivered solution, both customers and VAR support staff often waste time debating whether the problem is in the vendor's product or the VAR's customization layer. A documented, tiered escalation path with clear handoff criteria eliminates this ambiguity and sets customer expectations for response times at each tier.
VARs frequently rebrand vendor portals, customize dashboards, or configure default settings that make the vendor's standard documentation misleading or confusing for end customers. Using vendor-provided screenshots in customer-facing docs creates a trust gap when the customer's actual screen looks different. VAR documentation must use screenshots and workflows from the customer's real, deployed environment.
Without a formal record of what the VAR has customized, integrated, or configured for a specific customer, both the VAR's delivery team and the customer lose visibility into the solution's architecture over time — especially during staff turnover or contract renewals. A Solution Design Document (SDD) serves as the authoritative record of the VAR's value-added work for each engagement.
Join thousands of teams creating outstanding documentation
Start Free Trial