Piso WiFi Voucher Printing Workflow: From Batch Planning to a Clean Batch Log

Voucher printing is a workflow, not just a print job. A batch printed with the wrong terms, a faded code, or no record of what was sold will cause disputes for every code in that batch. A careful workflow prevents most of those disputes: plan the batch, generate it, test one code on the live portal, print carefully, check readability, store the codes safely, distribute them through a record, and track every code until it is sold, used, or voided.

This post covers workflow only. It does not repeat voucher generation types, pricing, or redemption steps in full. For voucher types, how customers buy and redeem codes, and expiry rules, see Piso WiFi Voucher Guide. For admin panel access, see the Admin Login guide. Use this post for the steps between planning a batch and closing it out.

Answer first: Plan the batch on paper, generate it, test one code on the live portal, then print, check every slip, store the codes securely, distribute them through a record, and track every code in the batch log until the batch is closed.

Part of the Piso WiFi Business guide. Same-category guides: Best Location for a Piso WiFi Machine and Piso WiFi Permits and Taxes.

Step 1: Plan the Batch Before You Generate Anything

Start with the batch on paper, before you open the admin panel. A batch plan answers five questions, and every code in the batch shares the same answers unless you deliberately split the batch.

Printer with paper coming out
Print vouchers in a checked batch, then count them before they reach customers. A failed print is a lost code, not a free voucher. Real photo by Anete Lusina on Pexels, free to use. The printer shown is a general printer, not a voucher printer.
  • Who is this batch for: walk in customers, dorm residents, a reseller, or a shop that sells codes for your machine.
  • How many codes: a small batch for a first test, or a larger batch for a known seller, with a clear reason for the size.
  • What terms: the time or data amount, the speed limit if any, and the expiry date, written down so they can be checked against the printed slip later.
  • Which machine: the exact machine name or WiFi name the codes work on, because a code for one machine will not usually work on another.
  • When it expires: the last date a code can be redeemed, and whether the timer starts on purchase or on redemption, confirmed from the voucher guide terms for your platform.

Write the batch plan down with a batch name or number, the date, and the person who planned it. A batch without a name is hard to trace when a customer returns with a disputed code weeks later. If the batch is for a reseller or a dorm, note the seller or dorm name in the plan as well, so distribution can be checked later.

Keep the first batch small. A small batch limits the damage if a term is wrong, a print setting is wrong, or a code format is hard to read. A large batch printed before any test multiplies the same mistake across every slip.

Step 2: Generate in the Admin Panel in General Terms

Generate the batch in the voucher section of your admin panel, following the platform steps for your system. This post does not repeat those steps, because they differ by platform and are covered in the Admin Login guide and the voucher guide.

In general terms, enter the batch terms from your written plan: the time or data amount, the price if your platform asks for it, the speed limit if any, the service type where separate types exist, and the expiry date. Check each field against the written plan before you confirm, because a single wrong field will apply to the whole batch. Generate the batch, then check the batch summary in the panel, including the batch name or number, the code count, and the expiry date, before you print anything.

Do not generate a second batch to fix a first batch error without first dealing with the first batch. If the terms are wrong, void or delete the wrong batch in the panel where your platform allows it, and note the void in the batch log, so no wrong code can be sold by mistake later. Two live batches with similar terms and different expiries are a common source of customer disputes.

Step 3: Test a Sample Code on the Live Portal Before Printing the Full Batch

This step is the most important step in the workflow, and it must happen before the full batch is printed. Pick one sample code from the generated batch and test it exactly as a customer would, on the live portal for the correct machine.

Test the sample code in this order:

  • Join the correct machine network, not a neighbouring network.
  • Open the portal and find the voucher field.
  • Enter the sample code exactly as the panel shows it, including any password where a secured code is used.
  • Confirm, and check that the timer or allowance shown matches the batch plan.
  • Check that the session starts and that a short browse works.

If the sample code fails, or if the timer or allowance does not match the plan, stop. Do not print the batch. Fix the batch terms in the panel, or void the batch and generate a corrected one, then test a new sample code. A printed batch cannot be fixed by a later correction in the panel, because the slips are already in customers’ hands.

If the sample code works, note the sample code, the test time, and the timer or allowance shown in the batch log. That note proves the batch was tested, and it helps you answer a later dispute about whether the batch worked at all. Note that testing a sample code may mark that code as used, depending on your platform. If it does, mark that code as a test code in the log, and do not sell it as a fresh code.

Step 4: Print the Batch

Print only after the sample test passes. Before you print the full batch, check the print settings on a single test slip, not on the whole batch. Check the slip layout, the font size, and the paper size, and confirm that the printed slip shows every label a customer needs: the machine name or WiFi name, the time or data amount, the speed limit if any, and the expiry date, plus whether the timer starts on purchase or on redemption where that is part of your terms.

Print in a quiet moment, not during a rush, because a print jam halfway through a batch can duplicate codes, skip codes, or mix slips from two batches. Print the batch in one run where you can, and keep the printed slips in batch order. If the printer jams, stop, check which codes printed cleanly and which did not, and reprint only the damaged or missing slips after checking the panel record, rather than reprinting the whole batch and creating duplicates.

Use paper and ink that survive handling. A slip that fades in a pocket, smudges in rain, or tears at the code is a dispute waiting to happen. If slips will be carried in a bag, sold outdoors, or stored for weeks, use sturdier paper or a protective sleeve, and test one slip by folding it and carrying it for a day before you print a large batch for outdoor sale.

Step 5: Check Print Quality and Code Readability

After printing, check every slip, not just the first one. This check takes minutes for a small batch and saves hours of disputes later. Check each slip for:

  • Code readability: every character is clear, with no faded, smudged, or cut off characters.
  • Confusable characters: check characters that look alike, such as the letter O and the number 0, the letter I and the number 1, and the letter S and the number 5, and confirm they print distinctly. If two characters look identical in your print font, change the font or the print size before you sell the batch.
  • Complete labels: machine name, time or data amount, speed limit if any, and expiry date are all present and correct on every slip.
  • Matching terms: the printed terms match the batch plan and the panel summary, with no slip from an older batch mixed in.
  • No duplicates: no code appears twice in the batch. If a duplicate is found, stop selling that batch until the panel record is checked and the duplicate is resolved.

Set aside any slip that fails this check. Do not sell a slip you cannot read yourself, because a customer will not read it better. Handle failed slips under the damaged code process below, not by guessing the code or by selling it at a discount.

Step 6: Store Codes Securely

Store unredeemed voucher slips like cash, because an unsecured code can be used by anyone who finds it. Keep the batch in a locked drawer, a safe, or another locked place that only the owner and trusted sellers can open. Do not leave a batch on a counter, in an unlocked box, or in a bag that leaves the shop with no record.

Store the batch log with the batch, or in a separate secure place where it can be found quickly during a dispute. If the log is stored with the batch and the batch is stolen, the thief gains both the codes and the record, so consider keeping the log separately from the slips for larger batches. For a small shop batch, a locked drawer for slips and a notebook or file for the log, kept in different places, is a reasonable split.

Count the batch when it goes into storage, and count it again when it comes out for sale. If the count differs, check the log before you sell any more codes from that batch, because a missing slip may have been sold without a record, or taken without payment.

Step 7: Distribute to Sellers or Dorms Through a Record

Do not hand a stack of codes to a seller or a dorm manager without a record. Distribution without a record makes it impossible to tell whether a missing code was sold, lost, or stolen, and it makes settlement with the seller a guess.

For each distribution, record in the batch log:

  • The date of distribution.
  • The seller or dorm name.
  • The codes given, by range or by list, depending on how your platform numbers codes.
  • The number of codes given.
  • The amount the seller owes, or the settlement terms, where a reseller arrangement exists.
  • The name of the person who handed the codes over and the person who received them.

Ask the seller to count the codes on receipt and to sign or confirm the count, even in a simple notebook. That confirmation protects both sides: the seller cannot be blamed for a short count they did not receive, and the owner cannot be blamed for a short count the seller already accepted.

Give sellers only the codes they can sell before expiry, not a whole batch for a slow seller. A seller holding expired codes at the end of the period creates void work and disputes, while a smaller, more frequent distribution keeps codes fresh and records simple. For dorm distribution, give the dorm manager a clear note of the expiry date and the machine name, so residents are not sold a code that expired before they could use it.

Step 8: Track Sold, Unsold, and Expired Codes in a Batch Log

Track every code in the batch until the batch is closed. A code is in one of four states: unsold, sold, redeemed, or voided. A code that is sold but not yet redeemed is still live, and a code that is unsold but past expiry is not live, even if the slip still exists. The batch log is how you tell those states apart.

Update the log at least once a day for an active batch, and at least once a week for a slow batch. Record sales as they happen, not from memory at the end of the week, because memory mixes batches. Reconcile the log against the panel reports for your platform, where those reports are available, and against cash collected, so voucher sales and coin sales are counted separately.

Close a batch only when every code is accounted for: sold and redeemed, sold and expired, unsold and voided, or damaged and voided. Keep the closed log, because a customer may return weeks later with an old slip and a dispute, and the log is your answer.

Batch Log Template

Copy this template for each batch, and keep one log per batch. Do not mix two batches in one log, because expiry dates and terms will differ.

Batch name or number:
Batch date:
Machine name or WiFi name:
Time or data amount:
Speed limit, if any:
Expiry date:
Timer starts on purchase or on redemption:
Total codes in batch:
Sample code tested on live portal, with test date and result:
Distributed to, with dates and counts:
Closed date, when every code is accounted for:

Code or code rangeStatus: unsold, sold, redeemed, or voidedDate sold, if soldSold by or distributed toDate redeemed or voided, if knownNotes

For a large batch, one row per code range with the same status is acceptable, provided the range is exact and any single code that changes status gets its own row. For a small batch, one row per code is clearer and worth the extra lines.

Handling Damaged or Unreadable Codes

A damaged code is a slip that cannot be read reliably, whether from a print fault, water, tearing, or fading. Handle it in this order, and do not guess.

First, keep the damaged slip. The operator may need its serial number, batch details, or partial code to check the panel record. A slip thrown away is much harder to trace.

Second, check the panel record for that batch, using the batch name or number and any readable part of the code. Confirm whether the code was already redeemed, already voided, or still live and unsold.

Third, if the code is still live and unsold, void it in the panel where your platform allows it, and mark it as voided for damage in the batch log. Then, if a replacement is due, generate or assign a replacement code from a fresh batch or a corrected batch, and log the replacement separately, so the damaged code and the replacement code are not confused.

Fourth, if the code was already sold and the customer brings the damaged slip, check the purchase record, the batch log, and the panel redemption record before deciding on a replacement. If the code was already redeemed, explain that the code is used, using the panel record as evidence. If the code was sold but never redeemed and is now unreadable through no fault of the customer, a replacement is the fair outcome where your platform allows it, and the damaged code should be voided so it cannot be used twice.

Do not try to guess a damaged character repeatedly on the portal, because repeated failed attempts can lock a code on some systems. One careful check of the panel record is better than several guesses on the live portal.

Voiding Expired Codes

Voiding means marking a code as no longer valid in the panel and in the batch log, so it cannot be redeemed after expiry. Void expired codes promptly, at the end of the expiry period, rather than leaving them live in the log.

To void a batch of expired codes:

  • List every unsold code in the batch that has passed its expiry date.
  • List every sold but unredeemed code that has passed its expiry date, separately, because those customers may return with a complaint.
  • Void each code in the panel where your platform allows it, or mark it as expired in the log where the panel voids it automatically on expiry, and note which method applied.
  • Mark each code as voided for expiry in the batch log, with the void date.
  • Remove expired slips from the sale stock, so no expired slip can be sold by mistake. Keep the voided slips or a note of them until the batch is closed, in case a customer returns with one.

If a customer returns with an expired code, check the log and the panel record, explain the expiry date printed on the slip, and do not promise a replacement as a matter of course. A replacement for an expired code is an owner decision, not a customer right, and it should be logged as a goodwill replacement if given, with the expired code marked as voided, so the same code cannot be replaced twice.

Workflow Mistakes to Avoid

  • Printing a full batch before testing a sample code on the live portal.
  • Printing without checking every slip for readability and complete labels.
  • Mixing slips from two batches, so terms and expiry dates no longer match the log.
  • Handing codes to a seller or dorm without a distribution record and a receipt count.
  • Tracking sales from memory at the end of the week, instead of in the log as they happen.
  • Selling a damaged slip, or guessing a damaged character on the portal.
  • Leaving expired slips in sale stock, where they can be sold by mistake.
  • Closing a batch with codes unaccounted for, so a later dispute has no record to check.

Frequently Asked Questions About Piso WiFi Voucher Printing Workflow

How many codes should I print in my first batch?

Print a small batch first. A small batch limits the damage if a term, a print setting, or a code format is wrong, and it gives you a full workflow test, from generation to sale to log, before a larger batch multiplies any mistake. Increase the batch size only after the small batch sold and tracked cleanly.

Must I really test a sample code before printing the full batch?

Yes. A sample test on the live portal is the only check that proves the batch terms, the machine name, and the code format all work together for a real customer. A panel summary alone does not prove that the portal accepts the code, and a printed batch cannot be corrected once slips are sold.

What should I do if the printer jams halfway through a batch?

Stop, check which codes printed cleanly and which did not, and reprint only the damaged or missing slips after checking the panel record. Do not reprint the whole batch without checking, because that creates duplicate slips for codes that already printed cleanly.

Can a seller or dorm manager keep unsold codes after expiry?

No, not for sale. Collect or account for unsold codes at expiry, void them in the panel and the log, and remove them from sale stock. A seller holding expired codes creates void work and risks selling an expired slip by mistake.

What is the difference between a damaged code and an expired code in the log?

A damaged code is unreadable but may still be live, so it is voided for damage and possibly replaced. An expired code has passed its expiry date, so it is voided for expiry and is not normally replaced, unless the owner decides on a goodwill replacement and logs it as such. The log must show which reason applied, because the customer conversation is different in each case.

How long should I keep a closed batch log?

Keep it at least until well after the last expiry date in the batch, because a customer may return with an old slip after expiry. A closed log with every code accounted for is your record for that dispute, and it also shows which batches, sellers, and terms worked well for the next batch plan.

For voucher types, buying, redemption, and expiry rules in full, go to Piso WiFi Voucher Guide. For admin panel access in full, go to the Admin Login guide. For rate strategy and voucher pack pricing, go to the Rates pillar. For business costs, income factors, and daily routine, go to the Business guide. For portal and code problems, go to the Troubleshooting guide.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *