Last month Bavardio wrote up 34,280 calls for ISP teams, which is a lot of notes nobody had to type. Mia takes the nights and weekends, so you serve more customers with the team you already have.
Guides and field notes
How to check billing before you switch systems, and how to show network status so the person on the phone can act on it.
Product videos
Last month Bavardio wrote up 34,280 calls for ISP teams, which is a lot of notes nobody had to type. Mia takes the nights and weekends, so you serve more customers with the team you already have.
A subscriber calls at 2:14 AM. Mia picks up on the first ring and already knows about the outage. Four in five of her calls come after hours, which is the shift nobody wants to staff.
Your rep sees the call, the account and the customer's radio on one screen, and AI suggests the next step. The problem gets fixed while the customer is still on the line, and nobody rolls a truck for it.
From the field
A practical sequence for mapping billing rules, comparing invoices, reviewing exceptions, and planning cutover.
Read itWhy the source and freshness of a status matter, and how to make gaps in visibility easier to understand.
Read itBefore a new system bills anyone, two things need to exist: a written definition of what it should produce, and a review that surfaces every difference before a customer is charged.
An invoice is the result of several decisions: which services are active, the dates being billed, when a service changed, how an adjustment should apply, and which tax configuration is required. Before comparing output, document the rules that produce it.
Choose people who understand the billing process and the exceptions handled by the team. Agree on which source records matter and who can resolve questions about them. This gives the migration a practical reference point when two systems produce different results.
A typical account is useful, but it does not describe the entire business. Include accounts with the variations your team actually handles: mid-cycle changes, multiple services, credits, overdue balances, different payment methods, and the relevant tax situations.
Define the population you are testing and keep a record of why it was chosen. A result from one sample should be described as a result from that sample.
Before evaluating a calculation, check the information used to calculate it. A missing service date, an unmapped adjustment, or an account relationship can create a difference even when the calculation itself is working as designed.
Review identifiers, dates, services, balances, and the relationships between records. Keep historical invoices distinguishable from newly generated output. That makes it easier to investigate whether a difference comes from the transfer of information or from the billing rules.
Totals tell you that something is off. The line items, periods, quantities, adjustments and taxes tell you why.
Use a comparison format the billing team can read. Show the original or expected value, the new value, and the difference. Keep enough context to identify the account and billing period without forcing reviewers to assemble the information again.
A mismatch may reflect a mapping problem, an incorrect rule, missing information, or an intentional change to the billing process. Reviewers need a place to record the explanation and the action required.
Useful exception fields include the account, the affected line or rule, the observed difference, the owner, and the decision. Keep unresolved questions visible. Agree on which issues must be corrected and which intentional differences need explicit approval.
A percentage alone is not an acceptance criterion. Review the types of remaining exceptions, their impact, and the checks required for the population moving into the new workflow.
The approval process should state who signs off, what they are approving, and the scope covered. It should also explain how the team will handle records outside that scope. This makes the decision understandable to billing, operations, and the people responsible for the cutover.
The transition plan should identify which system owns billing for each account, when that responsibility changes, and how the team will monitor the first live activity. Document communication, escalation, and the recovery options available for the workflow.
Include a review after the first cycle. Write down what happened, what needed attention, and which decisions belong in the documented process.
Bring your billing rules, a few tricky accounts, and the questions your team wants answered.
Discuss your migrationA green dot is only useful if the person looking at it knows what was checked, by what, and how long ago.
The person looking at a status may be troubleshooting a customer call, reviewing an incident, or deciding whether a technician needs to visit. The display should answer that question.
A radio that answers a ping can still be giving the subscriber a bad connection, and a failed check can mean the monitoring lost sight of the device, with the device itself fine. Label what the indicator actually measures.
Show what the system checked. Reachability, signal quality, an integration response, and application behavior are different observations. The right description helps the reader understand what can reasonably be concluded.
The label should be useful to the audience. An operations engineer may need the specific check. A service representative may need a plain-language explanation and a link to more detail. Both should be able to trace the information to its source.
Operational information can become outdated. A last-known healthy observation from an earlier period should be distinguishable from a recent successful check.
Include the time of the observation when it matters to the workflow. If the data is delayed or a new check failed, make that context visible. The team can then decide whether another check is needed before acting.
Sometimes the system does not know the current state. Say so on the screen.
An unknown or stale state should explain what is missing and, where possible, what the team can do next. A label, timestamp, and short explanation are usually more informative than color alone. Consistent states also help people scan the page without guessing how to interpret an unusual result.
When relationships are mapped, equipment information becomes more useful to customer-facing teams. A site, device, or link can be associated with the services and accounts that depend on it.
Keep the relationship visible enough to inspect. The team should understand which customers are associated with an issue and where that association comes from. This is especially useful when deciding who needs an update or which service request belongs with an existing incident.
The NOC wants diagnostics. Support wants the incident and what to tell the customer. Dispatch wants the reason for the truck roll and what has already been tried.
Design the handoff around that next action. Show each team the details it needs in the workspace it already uses, and keep the source one click away.
Ask the people using the dashboard to explain what they think each state means. If they interpret the same indicator differently, the design needs clarification.
Use representative situations: a recent successful check, a failed observation, a delayed integration, and a customer report without a confirmed equipment issue. If two people read the same screen and would do different things, the screen is not done.
Walk us through how your team uses equipment information today and where it gets stuck.
Explore network operationsWe will show you how Bavardio handles it, using your own examples.