When reviewing GPS customer billing, relate each subscription to its date, payments and sent notices before deciding whom to contact. In Plaspy's My customers section, the list ordered by expiry provides a starting point. What happens next depends on the evidence: checking a pending payment, clarifying the service being renewed or speaking to a customer who still needs to make a payment.
At the start of the morning, you may have unanswered chats and a list of past-due subscriptions. The latest message attracts attention, but simply reversing the order and calling every red row is not enough either. Two cases with the same status may need different responses. Understanding that difference lets you begin a conversation with specific information.
A useful review ends with a task that somebody can carry out and check again. Its duration depends on the size of the customer base, the quality of the records and the open cases. It does not need to promise a fifteen-minute turnaround to bring order to everyday work.
The date locates a case without explaining its whole history
Plaspy's subscription list is ordered by expiry and can be filtered by status. It includes the customer, service description, items, price per period and date. Those details help identify the renewal being examined. A date without an identified service leaves too much room for misunderstanding what the customer is expected to renew.
Active means that Paid until is today or a future date. Past due means that date has passed and grace days remain. Suspended follows the end of grace without payment, while Cancelled reflects a cancellation that someone performed. These categories describe different commercial situations. They are not labels for the customer's intentions or an automatic assessment of their reliability as a payer.
Grace deserves attention because it affects the next operational deadline. If it ends without payment, the subscription is suspended. When the subscription is configured to extend linked Plaspy devices, the suspension affects their operation on the platform at the end of the last grace day. Understanding that consequence requires knowing the applicable configuration. A past-due row does not establish that all its devices have already stopped working on the platform.
An old date alone does not identify the outstanding task either. A recorded payment may await confirmation, a date may have been entered incorrectly, or the service may be disputed. The list locates the situation; its records and the relevant conversation help explain it. Giving the status that additional meaning requires examining the case rather than supplying assumptions about what must have happened.
Plaspy checks expiry dates hourly using the account's time zone. That reference matters when colleagues view the same service from different locations. Before communicating a deadline, the team needs to be discussing the same day and subscription. The list provides a common basis, while deciding the particular priority still requires commercial judgement informed by the customer's situation.
Two past-due subscriptions may need different responses
Imagine two hypothetical cases. Both show Past due, and their grace periods require attention. In the first, a colleague has recorded a bank transfer through a method that leaves the payment awaiting confirmation. In the second, no payment has been confirmed and the reminder shows a sending failure. Matching statuses do not make those cases the same conversation.
The first calls for an internal check of an identified transaction. The second requires understanding the attempted contact and how to continue the renewal discussion. Beginning both with “you still haven't paid” overlooks an important difference: one already has a record for the team to investigate. Neither case permits treating funds as received without the relevant verification.
In Payments, the Only pending filter brings together records awaiting confirmation. Their details connect a payment to its customer and subscription, including the transaction information and supporting document when applicable. An attached file helps investigate the operation. Its presence does not require you to conclude that the payment is confirmed simply because somebody uploaded it.
Confirmation belongs to someone with permission to update payments who has completed the appropriate check. While a payment is pending, it does not renew the subscription. Confirming it applies the documented renewal and generates the corresponding notice. That dependency makes reviewing pending payments a task with a commercial consequence, rather than an exercise in making a list look tidier.
It may therefore make sense to examine a pending transaction nearing a service-continuity consequence before repeating a payment request to the customer. This is a proposed way to organize work, rather than a priority calculated by Plaspy. The decision depends on the case and available information, including the requirements for confirming the transaction correctly.
If the examination does not support confirmation, the task remains open and needs a precise explanation. “Transfer under review” communicates something different from “payment received.” Keeping that distinction helps colleagues coordinate and respond to the customer without requesting another payment merely to resolve an administrative uncertainty that is still being investigated.
A sent notice provides evidence about the sending attempt
The second example leads to Sent notifications. This section shows emails, SMS and WhatsApp messages associated with customers, as well as template tests. You can examine the date, recipient, channel, type and result. Those details help identify the attempt related to the renewal instead of assuming that any recent message was the particular notice you are looking for.
Sent and Failed describe the saved sending result. A failure has a reason to investigate: missing contact information, the daily SMS limit being reached, or an unprepared WhatsApp option, for example. The issue requires its appropriate correction. Repeating the same commercial request does not supply a missing telephone number or complete a configuration that is still needed.
Imagine finding a Failed SMS and a Sent email for the same renewal. A view restricted to failures reveals the SMS problem while excluding the email result. Those two records do not represent two different customers either. Checking the recipient, date and type connects each attempt to the right case and restores the context of the channels used. You can then explain which attempt failed and which send is recorded, without extending one channel's failure to every contact attempt or treating the sent email as evidence that the recipient read it.
One limitation is especially useful when preparing a conversation: Plaspy retains the sending result, rather than the message text. That record does not let you reread an earlier notification word for word there. Equally, a Sent result alone does not establish that the recipient read and understood the renewal. Distinguish the recorded attempt from what you actually know through the customer's response.
Filters affect what you see as well. The default date range covers the last thirty days, and you can select the customer, channel and result. If an expected notice is missing, examine the scope of the search before concluding that no contact ever occurred. An absence in a filtered view first describes that view, rather than every possible part of the customer's history.
The guide also explains that a failed reminder is not retried. Correcting customer information allows the next reminder, but does not retrospectively turn the earlier attempt into a successful send. That matters when a current case needs attention. The responsible person must decide how to continue through the appropriate channels without assuming that a resend has already taken place.
With that context, the conversation can begin by clarifying the service and checking the contact information. There is no reason to accuse someone of ignoring a notice whose recorded result shows a failure. Reviewing that evidence helps you formulate a response consistent with the available facts, while respecting the applicable agreements and communication preferences.
Follow-up needs an identified service and a responsible person
One customer can have several subscriptions, and those subscriptions need not share the same situation. Consider a business with two services: one remains active while another needs renewal. A broad statement such as “your account is overdue” can hide the difference. The subscription description helps make the conversation about the particular service you are examining.
That precision also matters when a customer sends a payment reference without explaining which renewal it concerns. Before treating it as resolution of every service, connect it to the corresponding record. The purpose of the review is to give each case an identifiable basis. Customer and subscription records make that basis easier to find, without replacing verification of the transaction itself.
The person responsible for the next action does not always have to be the person answering the chat. One colleague may be authorized to view information while another can confirm payments. User groups distinguish those capabilities. The standard Collections group registers, confirms and voids payments; Support can consult customers, subscriptions and sent notifications. Specific privileges determine what each subuser can actually do.
This division is useful when an outstanding renewal coincides with a technical incident. A past-due subscription does not independently prove a tracker fault. An active one does not establish the absence of a communication, installation or configuration problem either. Understanding why a device is missing from the map requires examining its technical situation alongside the relevant commercial context.
You can therefore maintain two related tasks without turning one into a diagnosis of the other. Collections examines the payment or expiry issue; the support representative investigates the device incident within their remit. This does not promise that both matters will be resolved together. It avoids communicating a single cause before that cause has been checked.
For someone returning to the case later, identifying the service and responsible colleague clarifies what remains outstanding. Follow-up can use your usual practices and appropriate notes. What matters is that consulting a record is not mistaken for confirming a transaction, and that a technical-support conversation does not automatically close a commercial renewal that remains unresolved.
Leaving a list does not always mean a payment was collected
After a review, it is natural to want fewer past-due cases. However, a row disappearing from a filter does not independently establish that payment arrived. Paid until can change through a transaction, but someone with the relevant permission can also edit that date. A cancellation or a different filter likewise changes what you are currently viewing.
When explaining what was resolved, retain the reason for the change. If a payment was confirmed, its record provides the reference. If an incorrect date was corrected, that correction is the explanation. Either action may be appropriate in its context, but they represent different commercial events and should not both be counted indiscriminately as paid renewals.
Return to the two hypothetical cases. The first advances when the transaction can be checked and the responsible person applies the appropriate action. The second may improve because valid contact information and a conversation about the service now exist. Obtaining useful information is progress even when there is no confirmed payment yet. The review should recognize that progress without inflating its results.
Distinguishing an assigned task from a finished task matters too. Recording who should check a transfer gives the task an owner within the team; it does not prove the check has happened. Sharing a subscription's link can facilitate payment without establishing receipt. Follow-up needs to return to the evidence supporting the particular result you are communicating.
This makes the next review easier to continue without starting from scratch. You can return to the identified service and ask what new evidence has appeared since the previous observation. The process need not become an endless sequence of calls. It helps distinguish a customer's outstanding decision, an internal check and missing information needed to move the case forward.
A short review should leave a decision that can be checked
The time a review reasonably takes depends on your operation. A small, well-maintained customer base creates a different workload from several renewals with pending payments and information to correct. Reserving regular time can help identify cases. It does not guarantee completion within fifteen minutes, prevent every suspension or ensure that every customer pays.
The useful outcome is more specific: knowing which subscription needs attention, why it needs attention and who can perform the next action. Begin with one case and check whether another colleague understands its situation from the references you retained. If they must search several chats to discover which service was discussed, the follow-up still lacks important context.
My customers has access conditions. The main account's menu is available from fifty licensed devices, combining standard and professional licenses. Saving is enabled from one hundred. Between those levels there is a preview without saving, and the free version is excluded. The My customers guide explains those requirements and access for subusers.
Record quality remains decisive. An incorrect date, an ambiguous description or a payment associated with the wrong service can misdirect the review. Examining those details is part of the work. The tool brings references and actions together; the team needs to use them consistently with what happened and with the service agreement, rather than treating the list as independent proof of every underlying event.
The cover is illustrative and does not show actual customer accounts or current deadlines. To organize this review within your team, contact Plaspy with how you record renewals and who reviews pending payments . That information makes it possible to identify what you need to consult and who can take each case forward.
