A glowing three-layer description template machine fed by spreadsheet data, sending matching listing cards along light rails to five marketplace logo pedestals, with a mismatched card filtered out.
← All posts

November 10, 2026

Offer Description Templates for Multi-Marketplace Game Sellers: Variables, Delivery Notes, and Per-Marketplace Rules

Titles and prices get most of the attention, but the description is where buyers confirm what they are getting, and where sellers quietly create disputes. When you list the same stock on Eldorado, G2G, iGVault, Racoon, and GameBoost, hand-written descriptions drift fast. This guide shows how to build a variable-driven description template system that stays accurate, reads naturally, and survives bulk restocks.

Why Descriptions Break at Scale

When you list ten offers by hand, you write each description fresh. When you restock two hundred accounts or item bundles, you copy, paste, and tweak. That is where the errors start:

  • A description says "EU server" but the row was NA.
  • A delivery note promises "instant delivery" on an offer you actually fulfil manually.
  • An old season's rank text survives into this season's listings.
  • One marketplace gets the detailed version and another gets a stub.

Buyers read descriptions as promises. If the description and the delivered product do not match, you get disputes, refunds, and returned stock. The fix is not writing better prose. It is treating the description as structured data plus a small set of reviewed templates.

The Three-Layer Description Model

Split every description into three layers so you only edit each kind of text in one place.

Layer 1: Fixed blocks (written once)

These are the parts that never change per listing:

  • Your delivery process in plain language.
  • What happens if the buyer has a problem and how to reach you through the marketplace's own messaging.
  • General reminders, such as checking the server before ordering.

Keep fixed blocks short. Long boilerplate buries the details buyers actually care about.

Layer 2: Variable blocks (filled from your data)

These come from columns in your restock sheet. Instead of typing "Level 60, EU, Gold rank", your template says Level {level}, {region}, {rank} and the value is pulled from the row. This is the same discipline as normalizing account attributes before listing: if the underlying value is clean, the description is clean.

Layer 3: Marketplace-specific blocks (written per channel)

Some marketplaces want a short description, some give you more room, and each has its own conventions and rules. Keep a small override block per marketplace rather than maintaining five entirely separate templates.

Build a Variable Dictionary First

Before writing any template, list the variables you will use and where each value comes from. A simple dictionary prevents the most common mistake: two columns that mean the same thing.

VariableExample valueSourceUsed in
{game}Example RPGRestock sheetAll offer types
{region}EUNormalized columnAccounts, currency
{rank_or_level}Level 60Normalized columnAccounts
{platform}PCNormalized columnAccounts, items
{unit_label}per 1M goldUnit mappingCurrency
{delivery_method}Manual, in-game tradeSeller settingAll
{delivery_window}Within 30 minutes onlineSeller settingAll
{season_tag}Season 4Reviewed each seasonAccounts

Two rules keep this dictionary useful:

  1. One variable, one meaning. Do not have both {server} and {region} unless they are genuinely different fields.
  2. Every variable has an owner column. If a value is not in your data, it does not belong in a template. Free-typed text belongs in an optional notes field, not in the structure.

Template Patterns by Offer Type

Game accounts

Account descriptions need to be specific and verifiable. A solid structure:

  1. One-line summary: game, region, platform, level or rank.
  2. A short bullet list of what is included (only things you have confirmed on that specific account).
  3. What is not included or any known limitations.
  4. Delivery method and window.
  5. Fixed support line.

The "not included" line is underrated. Stating limitations up front lowers dispute rates more than any amount of positive wording.

Game currency

Currency descriptions should be short and unit-focused. State the unit, the minimum order, the delivery method, and any requirements on the buyer's side (such as character name or server). If your unit sizes differ between channels, make sure {unit_label} is consistent with the price shown; mismatches here are a classic source of confusion, covered in our post on currency unit and price-per-unit mapping.

Items and bundles

For items, list quantity, quality or tier, and whether stock is delivered in one trade or several. If you sell variable quantities, avoid hardcoding a number in the description; use {quantity} from the row.

Per-Marketplace Differences to Plan For

Marketplace rules and field limits change, so check each platform's current seller guidelines before finalizing templates. These are the categories worth comparing, not fixed facts:

ConsiderationWhat to checkTemplate impact
Description lengthIs there a character cap or a short summary field?Create a short and a long variant of your fixed block
FormattingAre line breaks, bullets, or emphasis supported?Use plain line breaks as the safe default
Delivery fieldsIs delivery time a dedicated field or free text?Avoid repeating it inconsistently in both places
Required attributesWhich fields are mandatory vs. optional?Map them in your sheet so they are never blank
Policy limitsRules about external contact or off-platform paymentKeep these out of every template, everywhere

When you map columns in Sellerbot, handle these differences at the mapping and channel level instead of rewriting each description by hand. See how Sellerbot handles multiple platforms and the feature overview for what the panel covers.

What Never Belongs in a Description

Some content creates risk on every marketplace:

  • Credentials or anything that exposes the account before the sale.
  • Off-platform contact details or payment instructions. Most marketplaces restrict this, and it can put your seller account at risk.
  • Claims you cannot back up such as "never banned" or "guaranteed rare drops" unless you can truly stand behind them.
  • Stale event text. If a season, event, or patch has passed, remove it. This ties directly into patch day and season reset handling.

Put a short "banned phrases" list next to your templates. Before any bulk upload, search the filled-in descriptions for those phrases.

A Pre-Upload Description QA Pass

Templates reduce errors but do not remove them. Before a bulk restock, run a quick pass on a sample:

  1. Unresolved placeholders. Search for { and } in the generated descriptions. Any hit means a variable had no value.
  2. Blank-value artifacts. Look for phrases like "Level , EU" or "Rank: " that signal an empty field.
  3. Cross-check three rows. Pick the first, a middle, and the last row; compare the description against the source row.
  4. Compare channels. Open the same item on two marketplaces and confirm the facts match, even if the wording differs.
  5. Season and date check. Confirm {season_tag} is current.

This fits naturally into your bulk restock prep checklist, and you can use the preview to see how the panel looks before committing to a workflow.

Version Your Templates

Treat template changes like small releases:

  • Give each template a version label, such as acct-desc-v3, kept in your own notes or sheet.
  • Write one line on what changed and why (for example, "added limitations line after refund spike").
  • When you change a template, decide whether existing live listings need updating or only new ones. Usually, only listings with factual errors justify an immediate edit.

Versioning also helps with diagnosis. If disputes rise after a template change, you will know where to look.

Connect Descriptions to Your Delivery Reality

The most valuable question to ask of any template is: can I do exactly what this says, every time?

  • If your delivery window is "within 30 minutes online," be sure that is true during your normal hours.
  • If you offer instant delivery on some offers and manual on others, use two delivery blocks and choose by offer type, not by memory.
  • If stock sells on another marketplace and you have to cancel, make sure your sold-stock sync process is working so descriptions do not advertise inventory you no longer have.

A description that is slightly less impressive but always true will outperform an aggressive one that creates disputes.

A Simple Rollout Plan

  1. Write your variable dictionary and clean the underlying columns.
  2. Draft one template per offer type with the three-layer model.
  3. Add a short marketplace override for each channel you use.
  4. Test on a small batch of listings, then review the results on every marketplace.
  5. Run the QA pass before each bulk upload.
  6. Review disputes monthly and tweak the template, not individual listings.

If you are scaling up your seller operation, check the plans to see which setup fits your volume, and browse the blog for related workflow guides.

Key Takeaways

  • Treat descriptions as structured data: fixed blocks, variable blocks, and marketplace overrides.
  • Build a variable dictionary so every value has one meaning and one source column.
  • State limitations clearly; it reduces disputes.
  • Keep credentials, off-platform contact, and unverifiable claims out of every template.
  • QA for unresolved placeholders and stale season text before every bulk upload.
  • Version your templates so you can trace problems back to a change.