Running a Bag Campaign on Two Platforms at Once

Why a bag creator ends up on two platforms

There are three honest reasons a creator runs a bag on two platforms, and one bad one. The first honest reason is audience. Kickstarter and Indiegogo draw overlapping but not identical visitors, and a bag that underperforms with one audience may do considerably better with the other. The second is the funding model. A creator who cannot accept an all-or-nothing outcome may launch on the platform that offers flexible funding, and then use a second platform for a later phase. The third is continuity: one platform offers a post-campaign sales mechanism, and the creator wants the demand that continues after the funding period to keep flowing rather than to disappear at the close date.

The bad reason is the belief that two platforms means twice the money for the same work. It does not. Two platforms mean two sets of page copy that must agree, two fee structures that reduce the production budget differently, two backer lists that have to be reconciled, and two sets of promises that were probably written on different days by someone in a different mood. The operational load is closer to one and a half times than to one time, and the failure modes are specific rather than generic. The most common is not that one campaign fails; it is that both succeed and the creator has not planned for the sum.

That sum is the number to calculate first. If a bag sells 400 units on one platform and 350 on the other, the production requirement is 750 units, and a production plan built for 400 of them will break. This is especially true where colourways are involved, because 750 units spread across four colours may be four separate 500 pc minimums rather than one 750 unit order. The bag MOQ reference for mixed colours sets out how the minimum splits across SKUs, and it is worth reading before you decide how many colours to offer across two pages. The full platform comparison sits in the Indiegogo bag campaign guide.

Simultaneous or sequential: the two models

The first structural decision is whether the two campaigns run at the same time or one after the other, and it is not reversible once the pages are live. In the simultaneous model, both campaigns are open during an overlapping period and the backer chooses where to pledge. In the sequential model, one campaign closes and its results are known before the second opens. The two models produce completely different production situations, and the right choice depends on whether the creator needs information or needs momentum. A simultaneous run captures momentum and cross-promotion. A sequential run captures information.

The simultaneous model has one clear advantage and one clear cost. The advantage is that a single marketing push serves both pages, and a backer who prefers one platform over the other is not lost. The cost is that the production decision has to be made about a total that is still moving, and there is a real temptation to accept the quantity from the page that closes first and then discover the second page contributes more than the plan assumed. Creators in this model should place the bulk order on a pooled quantity with a stated top-up right, so that the second contribution becomes a defined second batch rather than a surprise.

The sequential model is the more conservative and, for a first multi-platform bag, usually the better one. The first campaign establishes real demand by colour and by tier. The second campaign then sells against known demand, and more importantly the production programme has one order date and one quantity. The cost is that the second launch has to be marketed afresh, and that the first campaign's backers may wait longer than the second campaign's backers for the same product. If the two orders are placed separately, each one still faces the 500 pc minimum on its own, which is the principal reason creators in the sequential model pool anyway.

The single specification rule

One document governs both campaigns. Not two documents that were consistent when they were written, but one document that both pages refer to. The specification contains the construction, the material call-outs, the hardware references, the dimensions, the tolerances, the colour references, the print or embroidery artwork references and the packing method, and it carries a version number and a date. When a change is made, the version number changes, and both pages are checked against the new version. This sounds bureaucratic. It is the cheapest insurance available in a multi-platform programme, because the alternative is discovering a discrepancy at first article.

The discrepancies that appear without a single specification are predictable. One page says the bag holds a 16 inch laptop and the other says 15 inch, because the measurement was written before the padding changed. One page shows a black version with silver hardware and the other shows gunmetal, because the trim was upgraded and only one page was updated. One page claims a water-resistant coating and the other does not, because the coating was added after the first page was published and the second page was copied from a draft. None of these are malicious. All of them are expensive, because they become a backer expectation that either cannot be met or can only be met at a cost.

The rule also applies to the physical reference. Alongside the document, there should be one approved and retained sample, and it should be the object that both pages describe. If a second sample is made for photography, or a revised sample is made after a change, the retained reference is updated in the same week, or the document stops being true. For a two-platform programme this discipline scales badly if it is not formalised, because there are two people who can edit two pages and only one of them will remember to check the document. Version control is the entire mechanism. The pre-production sample guide covers what the retained reference should physically be.

Pooling quantity across two platforms

The minimum is 500 pcs per style and per colourway, and it applies to the production order, not to a campaign. This is the single most useful fact in a multi-platform programme, because it means two campaigns can together clear a minimum that neither would clear alone. A bag that sells 280 units on one platform and 240 on the other is a 520 unit product, and as one pooled production order it works. As two separate orders it does not, and each side would face a shortfall of roughly 220 units that has to be absorbed somewhere.

Pooling by colourway is the part that needs care. If the pooled total is 520 units but they are spread across three colours, the pool does not help unless each colour reaches 500. The practical fix is to allocate colours by proportion of demand only after the minimum is met, or to reduce the number of colours offered. A common workable arrangement is one shell colourway with two or three webbing and zip-tape colours, which reads as a range on both pages while consuming one colourway of shell fabric. The reverse arrangement, three shell colours at 170 units each, is the arrangement that fails.

There is a second benefit to pooling that has nothing to do with the minimum. A larger single order buys a larger fabric lot, and a larger fabric lot reduces the risk of shade variation between the portion of the run that serves one platform's backers and the portion that serves the other's. Where two platforms are served by two separate dye lots of the same nominal colour, the difference is visible when two backers compare bags. It is also visible in photographs, and on a multi-platform campaign there are two audiences who can post photographs in the same thread.

Colourway allocation across two audiences

The two audiences do not want identical ranges, and treating them as identical wastes a real opportunity. A bag that performs well on one platform may sell a different colour mix on the other, and the practical method is to offer the same product with different default presentation rather than different products. The default presentation on each page is the colour shown in the hero image, the order the colours appear in the reward selector, and the language used to describe them. Those three can differ without any difference in what is produced.

What should not differ is the set of colours that can actually be made. A page that offers four colours when only two are in the production plan creates a reconciliation problem at the moment the backer selects. The safeguard is a colour matrix held in the specification: each listed colour, its reference, the minimum it requires, and whether it is confirmed for this run. Colours that are unconfirmed should be marked as stretch goals with a stated unlock quantity that is itself above the minimum, not as options that were added because the page looked thin. A stretch colour that does not unlock costs nothing. A colour offered at the wrong minimum costs the difference.

Allocation also has a physical side. When the goods are packed, they are usually packed by colour, and a two-platform fulfiment operation that packs by colour and then sorts by platform does the sort twice. Packing by platform allocation at the point of packing, using a printed allocation table derived from the two backer lists, does it once. This is a small operation that saves a surprising amount of time at 750 units, and it is the kind of thing worth raising with a fulfilment partner before the goods arrive rather than after. For the tier and colour economics, see the bag MOQ calculator.

Money timing: fees and payout schedules

The two platforms do not remove the same money, and they do not release it on the same schedule, and both facts belong in the cash plan before the production deposit is due. Platform fees on Kickstarter are typically around 5 percent of funds raised, and payment processing typically adds a further 3 to 5 percent depending on the method and the backer's location. Indiegogo's figures typically fall in a similar range for platform fee and processing, with the exact split depending on the campaign type and the payment route. These figures change, and every creator should check current platform terms before building a budget, because the published percentages are not stable over time and the treatment of taxes and international cards varies.

The timing matters more than the percentage. A production programme on T/T 30/70 requires a 30 percent deposit before bulk begins and the 70 percent balance before shipment, so the cash need is front-loaded relative to the revenue. On a two-platform run, the money arrives in two tranches that are not necessarily aligned with that shape, and the gap has to be planned. The practical discipline is to treat the deposit as the earliest date, work back from it to the earliest date at which both tranches are expected, and hold a contingency for the case where one tranche is later than planned. A campaign that raises enough but receives it in the wrong order still cannot place the order.

The third money issue is currency and cross-border receiving. A bag campaign sells internationally on both platforms, and the funds that arrive may be net of withholding, conversion or regional processing that differs between them. For production this matters because the deposit is due in a single currency on a single date. The practical move is to ask the production partner to quote and invoice in one currency, so the exposure sits in one place, and to model the deposit on the lower of the two expected receipts rather than the sum. Conservative modelling of the deposit is unglamorous and prevents a stalled order.

One AQL across two lots

If both platforms are served from one production order, there is one inspection and one standard, and the standard is AQL 2.5 to ISO 2859-1. The complication arrives when the two platforms are served from two lots, either because the second campaign was larger than expected or because a top-up was needed. In that case two inspections happen, and the risk is that they are held to different standards or conducted by different people with different tolerances. The fix is to specify the same AQL, the same defect classification and the same inspection level for both, and to record the results on one register.

A defect register shared across two lots is more useful than it sounds. A single register accumulates the defect types, the rates and the dispositions across the whole programme, and it makes a drift visible. If the first lot passes with a 1.2 percent major rate and the second shows 2.8 percent, that is a signal about the second lot, and it is only visible if both results are in the same document. Where the two results are recorded separately, on two platforms, by two coordinators, each result looks acceptable on its own and the drift goes unnoticed until backers compare notes.

The classification should also be shared. Minor, major and critical are not cosmetic labels; they determine what happens to a unit. A common two-platform failure is a major being treated as a minor on one lot because the coordinator wanted to clear the shipment, and the follow-on is that one platform's backers receive units the other platform's backers would have rejected. Define the three classes in the specification once, with one or two concrete examples of each, and use them on both lots. The AQL 2.5 reference for bag campaigns sets out how the sampling plan works in practice.

Two backer lists, one warehouse

Fulfilment is where a two-platform programme either holds together or visibly comes apart. Each platform produces a backer list with its own fields, its own export format, its own treatment of add-ons and its own way of recording shipping addresses and survey responses. Reconciling them into one pick list is a real task, and it is a task that should be rehearsed with a sample of 20 records before the goods arrive, not attempted with 750 on the day. The reconciliation needs one key, and the key should be the SKU: one SKU per physical variant, used identically on both platforms.

The second fulfilment decision is whether the two platforms' goods are held together or separately. Holding them together is cheaper and simpler, and it allows a shortage on one side to be covered by the other. Holding them separately protects against a shortage becoming a cross-platform problem, and it makes the reporting cleaner. For a two-platform bag campaign with a single production order, holding together is usually correct, with allocation recorded against each list rather than physically separated. The exception is where one platform's demand continues after the other's closes, in which case a reserve for the continuing side may be worth holding.

Shipping profiles differ by platform because the audiences differ, and this affects carton planning more than most creators expect. If one audience is predominantly in one region and the other is spread across several, the practical packing unit changes: one side may be efficiently shipped in consolidated cartons to a regional hub, while the other needs individual parcels. Deciding this after the goods are packed means re-packing. The backer shipping cost guide covers how to price the two profiles into the tiers before launch, which is where the decision belongs.

Where the two pages drift apart

Drift is the characteristic failure of a two-platform programme, and it has a recognisable pattern. It begins when one page is edited and the other is not. The edit is usually small and reasonable: a delivery month is updated on one page, a feature is clarified on the other, a photograph is replaced on one because the light was better. Individually these are improvements. Collectively they produce two products that share a name, and the reconciliation happens when a backer reads both, which on an overlapping audience they will.

• Dates. One page promises an earlier month than the other. Reconcile against the production calendar, not against optimism.
• Dimensions. Capacity claims written before the final pattern was cut. Reconcile against the retained sample, not the prototype.
• Materials. A fabric or hardware upgrade recorded on one page only. Reconcile against the specification version.
• Colours. A colour offered on one page that is not in the production plan. Reconcile against the colour matrix.
• Add-ons. An add-on sold on one platform that has no SKU on the other. Reconcile against one shared SKU list.

The practical control is a standing comparison. Once a week while both pages are live, and once on the day each closes, put the two pages side by side and read the reward descriptions, the specifications, the delivery months and the shipping terms line by line. It takes 20 minutes and it catches most of what matters. The alternative control is to have one person own both pages and forbid edits that are not recorded in the specification, which is better and harder to sustain when the two campaigns are marketed by two different people.

Re-orders after both campaigns close

When both campaigns close, the question is what happens to continued demand, and on a two-platform programme the answer is usually that one platform continues and the other does not. That asymmetry is an argument for a decision rather than a default. If the continuing side will generate a few orders a month, those orders are not a production run, and treating them as one produces a re-order with a 35 to 50 day lead time to fill five units. Consolidating them into a quarterly re-order of 500 pcs is usually the better shape, with the intervening orders served from reserve stock.

The reserve is the second decision, and it should be sized deliberately rather than left as a remainder. A reasonable planning figure is 5 to 10 percent of the total campaign quantity held back as reserve, covering replacements, damage in transit, address failures and the early continuing demand before the first re-order lands. On a 750 unit programme that is 38 to 75 units, which is one carton and a small holding cost, and it is far cheaper than a re-order placed to satisfy a replacement request. The reserve also absorbs the units that fail inspection and that would otherwise create a shortfall at the end of the pick.

The third decision is about continuity of the file. A re-order is only reproducible if the specification, the pattern and the retained reference still exist and are still the current version. On a two-platform programme there is a real risk that the version used for the second lot differs from the version used for the first, and the re-order then reproduces whichever one is handed over. Record which version each lot was built to, and re-order against the approved one. For continuity planning across platforms, the cross-platform sampling guide covers the file discipline in more detail.

A two-platform production calendar

The calendar below assumes a sequential model with pooled production, which is the arrangement we would recommend for a first two-platform bag. It runs from twelve weeks before the first campaign opens to the point the second campaign's backers are served, and each stage has a trigger rather than a fixed date. A calendar with fixed dates breaks the first time a date moves; a calendar with triggers survives it.

1. Week minus 12. Freeze the specification at version 1 and agree the colour matrix with confirmed and stretch colours.
2. Week minus 10. Sample. Allow 6 to 10 working days, or 12 to 15 for complex constructions, and retain the approved reference.
3. Week minus 2. Launch the first campaign with the retained reference as the photographed object on the page.
4. Close of campaign 1. Reconcile demand by colour and by tier. Place the pooled bulk slot with a top-up right for campaign 2.
5. Campaign 2 period. Market against known demand. Run the weekly two-page comparison without fail.
6. Close of campaign 2. Confirm the top-up quantity and release bulk, starting the 35 to 50 day window.
7. During production. One inspection at AQL 2.5 to ISO 2859-1, recorded on one register for both lots.
8. After packing. Reconcile the two backer lists to one pick list with one shared SKU key, rehearsed first on 20 records.
9. After dispatch. Hold 5 to 10 percent as reserve and set a quarterly re-order review for the continuing platform.

Two things in that sequence do most of the work. The pooled bulk slot with a top-up right means the second campaign is a defined contribution to a known order rather than a separate decision made under time pressure, and the shared SKU key means the two backer lists reconcile into one list instead of being merged by hand at the worst possible moment. Neither is difficult. Both are the kind of thing that is obvious in hindsight and skipped in advance, which is why a calendar with triggers is worth more than a calendar with dates.

Frequently Asked Questions

People Also Ask