E-commerce
July 1, 2026
"Does this sensor work with the base purchased in 2023?" "Can I add this extension after my purchase?" "I received a module that does not connect to my device." These questions arise when the customer does not know if the module matches their version, their setup, or other extensions already in use.
The add-on module support must verify the base product before recommending a SKU, clearly explain what the module adds, and provide a reliable installation process. A module differs from a simple accessory: it expands the capabilities of the main product and may depend on version or combination rules.
The guide #669 details the ADDON-SUP policy, the AO-1 to AO-8 flow, and the ADDON-MAP matrix. It complements the future ADDON bot (#670), which will handle simple compatibility and benefit-related questions.
Summary
Why do add-ons create so many questions?
The customer already owns a base product, such as a smart home hub, a modular device, or an equipment combining software and hardware. Before adding an extension, they need to know if their version is compatible, what the module provides, and how to install it. Without a procedure, the agent may recommend an incompatible SKU or confuse a functional extension with a simple accessory.
The five most common difficulties
Compatibility with the base: the customer does not know the revision or generation of their product.
Unclear benefit: they do not understand what new function the module provides.
Purchase after the main product: they do not know if the extension can be added later.
Combining multiple modules: two extensions may be incompatible or limited by a maximum capacity.
Installation: pairing, connection, or configuration are not sufficiently explained.
Aculogi indicates that structured compatibility data can reduce returns related to poor fitment (Aculogi, compatibility data). ADDON-MAP allows support and merchandising to use the same versioning and combination rules.
Convert over 2,000 customers on average per month with Qstomy.
The world’s 1st Shopify AI dedicated to customer conversion
Empowering 200+ e-commerce merchants
How do you distinguish between a module, an accessory, and an upgrade pack?
Not all complementary products meet the same need. Support must first determine whether the customer is looking for a new capability, a usage accessory, or a complete upgrade.
Which path to use?
#669 ADDON: the complementary product extends the base capabilities and requires a compatibility or installation check.
Accessory #350: the accessory complements usage, like a case or a filter, without modifying the main capabilities.
UPGRBND #663: the customer upgrades to a pack or a higher tier according to an upgrade sequence.
INCOMPAT #483: options in the configurator cannot be selected together.
Bot #670: the bot checks the first criteria and presents the benefits before any potential transfer.
An accessory improves usage. An add-on module adds a function to the base and often depends on its version, other installed modules, and an installation guide.
Which addon_* typologies should be used?
The eight typologies make it possible to distinguish a compatibility question, a request for advice, an installation problem, or an ordering error.
The ADDON typologies
addon_compat: the customer is asking if a module works with their base or revision.
addon_benefit: they want to understand the added features.
addon_which_module: they are asking which module meets their need.
addon_post_purchase: they want to add an extension after purchasing the main product.
addon_stack: they wish to combine multiple modules.
addon_install: they are experiencing a connection, pairing, or configuration issue.
addon_order_link: the module must be associated with the order or account of the main product.
addon_wrong_compat: the customer received a module that does not work with their base.
Use the tags addon, add_on_module, and extension. The BASE-API-CITE rule requires finding the base product before confirming compatibility.
How should the ADDON-MAP matrix be structured?
ADDON-MAP centralizes the relationships between bases, modules, and installation rules. It must be precise enough so that an agent never recommends a module based on a simple sales resemblance.
Essential fields
addon_program_id: identifies the product ecosystem.
base_product_skus: lists the SKUs of the main products.
addon_module_skus: associates the available modules with each base.
module_type: specifies whether it is a sensor, a battery, a rail, a software extension, or another type.
benefit_copy: explains the added capabilities in customer-friendly language.
compat_rules: details required versions and exclusions.
stack_rules: indicates modules that are compatible with each other and any potential limits.
post_purchase_addon_allowed: specifies whether the module can be purchased after the base.
addon_purchase_url: provides the correct purchase link.
install_guide_url: links to the wiring or pairing guide.
order_link_required: indicates whether the original order must be linked.
customer_communication_copy: provides the approved text for the customer journey.
Synchronize this matrix with the base_owned metafield, post-purchase emails, helpdesk macros, and the attachment rate dashboard.
Which ADDON-SUP rules must agents follow?
The six ADDON-SUP rules prevent approximate recommendations and compatibility errors.
ADDON-MAP-GROUNDED: only use the SKUs, benefits, and rules present in the matrix.
BASE-API-CITE: find the base product in the order before responding.
ADDON-SKU-CITE: only recommend a SKU present in addon_module_skus.
COMPAT-CITE: check compat_rules and stack_rules, including already owned modules.
INSTALL-CITE: use install_guide_url for any installation procedure.
ACC350-REROUTE: when dealing with a simple accessory, use guide #350.
Which path should be followed to answer an ADDON question?
The flow AO-1 to AO-8 guarantees that the recommendation starts from the product actually owned by the customer.
AO-1 — Collect: identify the request, the order, and the base model.
AO-2 — Consult ADDON-MAP: check the modules, benefits, combination rules, and installation guide.
AO-3 — Retrieve the base: confirm the SKU and revision in the order or account.
AO-4 — Classify: select compat, benefit, post_purchase, stack, install, or wrong_compat.
AO-5 — Apply rules: use BASE-CITE, ADDON-SKU, COMPAT, INSTALL or redirect to the accessory guide.
AO-6 — Respond: send the macro based on ADDON-MAP and the correct purchase link.
AO-7 — Execute: process a return for incompatibility, a stack exception, or an installation escalation.
AO-8 — Close: apply addon_resolved and record the recommended SKU as well as the conversion.
An addon_which_module request should ideally be resolved in a single interaction, with the compatible module, its benefit, and the purchase link.
Which ADDON macros should I use?
Macros must cite the core product, the exact module, and the compatibility rule.
ADDON-COMPAT-01
"Your core product is [base_product_skus]. The [addon_module_skus] module is [compatible/not compatible] according to the following rule: [compat_rules]. With the modules already installed, here is the combination rule: [stack_rules]."
ADDON-BENEFIT-01
"The [addon_module_skus] module adds the following features: [benefit_copy]. You can purchase it here: [addon_purchase_url]. It can be added after purchasing the base when [post_purchase_addon_allowed] is validated."
ADDON-INSTALL-01
"Here is the installation guide for the [addon_module_skus] module: [install_guide_url]. If the installation requires an assistant, consult the partner installation guide."
ADDON-POSTPURCHASE-01
"We have found your core product in order [order_ref]. Compatible modules are [addon_module_skus]. Post-purchase is [allowed/not allowed]. Here is the corresponding link: [addon_purchase_url]."
Which cases fall under a different pathway?
Some complementary products look like modules but must be handled with a different guide.
Option blocked in a configurator: use INCOMPAT #483 to explain exclusions between options.
Upgrade to a bundle: use UPGRBND #663 when the customer changes tier or bundle.
Generic sales recommendation: the cross-sell #152 guide applies when no specific technical compatibility is required.
Base product out of program: explain that the SKU is not covered and offer the standard compatibility form.
Maximum number of modules reached: use stack_rules to explain the limit and, if it exists, the upgrade alternative.
An add-on module extends the capabilities of the base product. An accessory #350 improves usage without changing its core functions.
Which ADDON KPIs to track?
KPIs must measure both the quality of the recommendations and their business impact.
addon_attach_rate: number of add-ons sold relative to the number of eligible bases.
addon_wrong_compat_rate: share of add-on orders presenting an incompatibility.
addon_post_purchase_convert_rate: share of post-purchase requests that result in an add-on order.
addon_compat_response_sla: share of compatibility responses given after verification of the base.
addon_install_ticket_rate: number of installation tickets relative to add-ons sold.
Aim for an addon_wrong_compat_rate below 5% and an addon_compat_response_sla above 95%.
Which ADDON errors should be avoided?
The following five practices increase returns and reduce customer trust.
Inventing a SKU: only recommend part numbers present in addon_module_skus.
Confirming compatibility without retrieving the base: always apply BASE-API-CITE.
Confusing a module with an accessory: use ACC350-REROUTE when dealing with a case, a filter, or a non-functional add-on.
Ignoring already installed modules: check stack_rules before recommending a new extension.
Improvising the installation: use only install_guide_url and the planned escalation path.
How does Qstomy automate ADDON support?
On Shopify, Qstomy can detect the addon intent, find the base product in the order, and query ADDON-MAP before suggesting a module.
Bot #670 handles simple compatibility and benefit questions. Module errors, complex stacks, and installation issues are transferred to agents who apply guide #669.
Discover AI customer support or request a demo.
Checklist, FAQ, and additional resources
Eight-step ADDON Checklist
Create the ADDON-MAP with bases, modules, benefits, and compatibility rules.
Validate the six ADDON-SUP rules.
Configure the eight addon_* typologies in the helpdesk.
Create the COMPAT, BENEFIT, INSTALL, and POSTPURCHASE macros.
Add the addon_purchase_url link and the module benefit to post-purchase emails.
Synchronize the base_owned metafield with the tools used by agents.
Train agents to distinguish between an ADDON, accessory #350, bundle #663, and incompatible option #483.
Track the attachment rate and compatibility errors in a dashboard.
FAQ
What is the difference with accessory #350?
An accessory complements usage. A module #669 adds a capability and depends on compatibility or combination rules.
What is the difference with UPGRBND #663?
UPGRBND handles an upsell or a bundle. ADDON handles adding a module to an existing base.
Can a module be purchased after the base?
Yes, when post_purchase_addon_allowed is validated in the ADDON-MAP. In this case, use addon_purchase_url.
What is the role of bot #670?
It handles simple compatibility and benefit questions. Complex cases continue to be handled by agents.
Going further
Start by indexing the ecosystems in the ADDON-MAP, verify the purchase links sent after buying the base, and test ADDON-COMPAT-01 with agents.
Enzo
July 1, 2026
