Bulk order or one top-up at a time?
If the same team needs airtime every Friday, approve the list once and send the top-ups together. If a driver runs out mid-shift, deal with that request as it comes in. Before moving more orders into a batch, measure staff time and check whether you can trace an order that gets stuck.
| Work pattern | Start with |
|---|---|
| Same team funded every Friday | A reviewed batch with one owner and one release time |
| Single driver needs urgent airtime mid-shift | An approved individual exception |
| Orders are often corrected immediately before sending | Improve the recipient list before increasing batch size |
| Repeated top-ups must trigger immediately from an application | Assess an integration after documenting the manual process |
By Freepaid · Published
Calculate staff time from the whole process
Suppose a team approves 60 top-ups every Friday. Each individual top-up takes 75 seconds to enter and confirm, giving 75 minutes for data entry and confirmation. Assume four records need another three minutes of follow-up each. The run then takes 87 minutes before any work shared by both methods.
A trial bulk run takes 18 minutes to prepare the list, 12 minutes for independent review, five minutes to release it and six minutes to check the result. Three lines need three minutes each of follow-up. Total staff time is 50 minutes. On these illustrative assumptions, batching saves 37 minutes per run. Time your own run, including how long a prepared batch sits waiting for approval.
| Step | Individual process | Batch process |
|---|---|---|
| Prepare, review and release | 75 min | 35 min |
| Check batch result | Included in per-order confirmation | 6 min |
| Follow up exceptions | 12 min | 9 min |
| Total in the example | 87 min | 50 min |
Separate preparation from sending
Name the person who prepares the list and the person who approves its release. Before approval, compare the count and total against the source request. Check that every row has the intended recipient, amount and product, and investigate duplicate entries. Two rows for the same number can be legitimate when they cover different purposes. Have the preparer explain the second row and make that reason visible to the reviewer.
Once the batch is sent, save the confirmation and references used by the ordering system. Keep the submitted list as the evidence for the run. If the provider returns partial results, compare the response line by line against the original submission. Record confirmed, failed and unknown statuses separately. Investigate unknown rows using their original references before deciding how to address them.
Define the exception route
Decide who can approve an urgent top-up and how much they can approve. Ask for a short reason on each request. If the individual request relates to someone already on the current batch, check the outcome of that person's existing row before sending another order. Use the same end-of-day register for both methods so finance can account for every recharge.
Try the two processes over comparable runs. Record how long recipients wait, how much staff time each run consumes, and how many corrections and support calls follow. Batching makes more sense when the work can wait for the next cut-off and the team has a reliable list. Keep the individual route open for the cases where waiting would interrupt work. Freepaid bulk airtime · SIMcloud