New SIM Rules, Spam Deadlines, Complaint Deadlines — Handled On Time.
Your Team Approves Every Step.
For private and public-sector mobile operators, large broadband providers, and the system integrators who deliver their programmes. GUARDIAN clears SIM KYC exception queues, runs spam and complaint deadlines, works out outage credits and explains partner bills — inside your own cloud in India, beside the systems you already have. Nothing goes out without your team's approval.
Fair Cancellations. Complaints Resolved in Time. Every Telecare User Protected.
With the Evidence to Show It.
For mobile and converged operators, MVNOs and MVNEs, altnets and ISPs, and their system integrators. GUARDIAN adds governed AI workflows beside your BSS and contact centre — cancellation assurance, complaint and ADR deadlines, telecare checks before the PSTN switch-off, and wholesale invoice reconciliation — running in your UK environment, with your team approving every regulated step.
Built by People Who Have Run Telecom IT
You already have big vendors. We don't ask you to replace any of them. We bring a small, governed AI layer that works beside them — designed by people who have lived your month-end, your migrations and your regulator's letters.
Years in telecom IT across CRM, BSS, billing, CDR reconciliation, digital channels and MVNO integration — including Virgin Mobile (now part of VMO2), Telefónica O2 and Lebara.
Senior experience with major telecom brands including Sky and Lebara.
See Where GUARDIAN Fits Beside Your Systems
Keep your billing, CRM and KYC systems. GUARDIAN collects totals and exceptions from them, does the matching, drafting and deadline-watching, and waits for your team to approve.
See Where GUARDIAN Fits Beside Your BSS
Your BSS and contact centre stay the systems of record. GUARDIAN picks up events, gathers what's missing, and writes back approved outcomes — with a person on every regulated decision.
Which one is your business?
Choose one. In Step 2, the problems that match your business get a ✓. Step 3 shows how GUARDIAN connects to what you already use.
Problems every telecom back office knows
Pick a problem. Each one shows a real-life example, how GUARDIAN helps step by step, where your team decides, and what happens in unusual cases.
New SIM rules: thousands of activations stuck, and every one needs a person to sort it out.
Under the new SIM rules, a customer's details must match, nobody may hold more than 9 SIMs, and every new connection is checked live against DoT's system. At Sampark (our made-up operator), about 2,000 activations a week now get stuck. A shop owner in Guntur calls about a customer who was turned away. A company asks why 40 employee SIMs are "pending". Kavitha's KYC team handles all of it by phone and spreadsheet.
New to this? The background in plain words
Every SIM in India must be linked to a verified person. The operator checks identity at the shop (now with live fingerprint or face checks), makes sure nobody holds too many SIMs and — under the new rules — checks each new connection against DoT's central system. Most activations pass. The ones that don't — a name mismatch, a person over the SIM limit, a business SIM for an employee — become "exceptions" that people must sort out by hand.
Sound familiar?
- Hundreds of cases stuck at "pending verification"
- Customers sent back to the shop again and again
- Business SIM lists kept in spreadsheets
- Good customers disconnected by mistake
Why it matters
- New rules, close deadline. The Telecommunications (User Identification) Rules 2026 were notified on 21 August 2026; the live DoT check is reported due by 30 November 2026.
- Wrong disconnections lose good customers and bring complaints.
- Every decision must be on record for audit.
Where a person decides: your KYC officer decides every case. Fingerprint and face checks, Aadhaar e-KYC and DoT checks stay in your own licensed systems — GUARDIAN never touches them.
A simple example — one stuck activation
- Anil buys a SIM in Guntur. The name typed at the shop doesn't match his ID, so activation stops.
- GUARDIAN receives the exception from your KYC system — no fingerprints, no ID images — with names tokenised.
- It sends Anil a WhatsApp message in Telugu, on the other number he gave at the shop: what to bring, and store timings.
- Anil returns; the shop corrects the details in your KYC system. Kavitha sees a complete case and approves.
- The case closes, with every step recorded.
Made-up example.
What happens when… — the situations we've planned for
- Customer cut off after a DoT list check says it is a mistake — an appeal file is prepared; your team decides, following the DoT process.
- An employee with a company SIM leaves — the SIM is flagged for your re-assignment process.
- SIM transfer to a legal heir — the document checklist is sent; biometrics of both people are arranged in store.
- Customer has no Aadhaar — the other KYC route is explained, step by step.
What we need from you to start: exception reports from your KYC / activation system · your KYC policy · approved WhatsApp message templates in the languages you need.
What we'd measure in your pilot: age of open cases, repeat shop visits, appeals about wrongful disconnection, audit findings.
For your IT person — how it connects
- GUARDIAN receives exception events only. It never receives fingerprints, face images or Aadhaar e-KYC data, and never calls DoT's platform itself; biometric capture happens only in your licensed channel.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- WhatsApp through the official WhatsApp Business Platform (via a BSP); RCS through RBM aggregators. Messages GUARDIAN starts use approved templates; customers can type "agent" at any time.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
Spam complaints: five days to act — and now some steps must happen in hours.
Monday morning: 340 spam complaints came in over the weekend — through the app, by SMS to 1909 and through customer care. Sixty of them are about one business using many different numbers. The rules say act within 5 days. Under TRAI's September 2026 changes, a misused sender name (a "header") must be suspended within 6 hours, and a suspected spammer shared with other operators within 2 hours. Today Ravi's team matches complaints to senders in Excel.
New to this? The background in plain words
Businesses that send promotional or service SMS and calls must register their sender names ("headers") and message templates on a shared ledger system called DLT. When customers report spam, the operator must find who sent it, count complaints against that sender, and act — warn, suspend or disconnect — within TRAI's deadlines. Businesses can appeal.
Sound familiar?
- Complaints matched to senders by hand
- Deadlines counted on a calendar
- Genuine businesses angry when their header is blocked
- Penalty notices from TRAI
Why it matters
- Some deadlines are now hours, not days — TRAI's September 2026 changes are phased in over 30–90 days.
- Consistent action protects genuine businesses as well as customers; repeated failures carry graded penalties (₹2, 5 and 10 lakh).
- About 25 lakh spam complaints were made in India in 2025.
Where a person decides: a person approves every suspension and every notice to a business. Spam detection in your network stays yours — GUARDIAN runs the complaint and action process around it.
A simple example — one busy weekend
- 340 complaints arrive. GUARDIAN groups 60 of them under one business that used 14 different numbers.
- That business has crossed TRAI's mark of 5 complaints in 10 days, so the deadlines start.
- GUARDIAN prepares the suspension and a notice to the business, with the evidence attached.
- Ravi approves within the hour; your team applies it in your DLT system.
- Two days later the business appeals. The full file is ready for the appeal officer.
Made-up example.
What happens when… — the situations we've planned for
- A genuine business is flagged (for example, a bank's OTP header) — sent at once to a person for review.
- Complaints about correctly used 140 or 1600 numbers — handled as customer preferences, not as spam.
- One sender using many numbers — grouped by the business, not just by the number.
- Complaint made after the 7-day limit — recorded and marked as outside the limit.
What we need from you to start: complaint feeds (app, 1909, care) · sender and header records from your DLT platform · your escalation rules.
What we'd measure in your pilot: actions within 2 hours / 6 hours / 5 days, penalties received, appeals upheld.
For your IT person — how it connects
- GUARDIAN reads complaint and DLT records through exports or APIs. It does not do network-level call or SMS spam detection.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
One customer complains three ways. Which deadline is running?
Lakshmi in Vijayawada says her bill is ₹340 more than her plan. She tells the WhatsApp bot, then calls customer care, then sends an email. Today that may become three separate records — or none, if it is logged as a "query". TRAI's rules give a billing complaint 4 weeks to be resolved, 1 week to apply any credit, and 39 days for an appeal to be decided.
New to this? The background in plain words
TRAI's rules give each kind of complaint a deadline, and a customer who isn't satisfied can appeal to the operator's appellate authority. The deadline starts when the complaint is made — on any channel. A complaint on WhatsApp counts just as much as one to the call centre.
Sound familiar?
- Complaints logged as "queries" and never counted
- The same customer in three places
- Deadlines tracked in someone's head
- Appeals with no file ready
Why it matters
- TRAI's service-quality rules (in force since 1 October 2024) set these deadlines, with penalties of ₹1–10 lakh.
- One complaint should mean one record, however the customer contacts you.
- Quick, clear answers keep customers.
Where a person decides: your agent or manager approves every reply and every credit. If the customer asks for a person, they get one straight away.
What happens when… — the situations we've planned for
- Complaint hidden inside a sales chat — flagged for an agent to confirm — not logged automatically.
- Customer says "I want to talk to a person" — handed over at once.
- Charge from a third-party service on the bill — case opened; your routing rules decide who owns it.
- Customer has already appealed — the full file is put together; nothing is sent without approval.
What we need from you to start: your complaint categories and deadlines · reply templates · access to bills and plans (read-only).
What we'd measure in your pilot: complaints resolved inside the deadline, credits applied within 1 week, appeals, repeat complaints.
For your IT person — how it connects
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- WhatsApp through the official WhatsApp Business Platform (via a BSP); RCS through RBM aggregators. Messages GUARDIAN starts use approved templates; customers can type "agent" at any time.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
A 30-hour outage in one district. Every affected customer must get their credit within a week.
A cable cut in Krishna district takes the network down for 30 hours. TRAI's rules say that after an outage of more than 24 hours in a district, postpaid customers get a rent rebate and prepaid customers get extra validity — within one week. But which customers were affected? The network team, billing team and care team each have part of the answer.
New to this? The background in plain words
Network tools know when and where a site or cable failed. Billing knows which customers have which plans. Customer care knows who complained. To credit the right customers, all three must be joined up — by area, by time and by plan.
Sound familiar?
- Affected customers found with manual queries
- Some customers missed, some credited twice
- Credits keyed in by hand
- Complaints about missing credits
Why it matters
- One week is short, and a district is large.
- Every customer credited once — not missed, not paid twice.
- Customers notice — and complain.
Where a person decides: your finance team approves every credit batch before it is posted to billing.
What happens when… — the situations we've planned for
- Customer changed plan during the outage — the plan active at each moment is used.
- Two outages overlap for the same customer — credited once, as the rule says — not twice.
- Outage caused by a natural disaster — shown to the approver with the reason, for your decision.
- Customer already credited by an agent — found and netted off.
What we need from you to start: outage records (area and time) · which customers are served from where · your credit rules.
What we'd measure in your pilot: credits posted within 1 week, missed or double credits, complaints about credits.
For your IT person — how it connects
- Credits are written to billing only after approval, through your billing API or a batch file.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
Roaming and wholesale bills from partners: every difference explained before the dispute window closes.
Sampark is a made-up Indian mobile operator for this example. Its customers use their phones abroad, and the foreign networks bill Sampark through a clearing house. This month one partner's statement says US$412,000. Sampark's own records say US$398,000. Priya in the wholesale team has 30 days to dispute the US$14,000 difference. She pastes the statement into Excel and starts matching, line by line. The same work repeats for wholesale capacity bought from other carriers.
New to this? The background in plain words
When a customer uses their phone abroad, the foreign network carries the calls and data and later bills the home operator. Records of that usage (TAP files, now moving to a newer format called BCE) pass through a clearing house, and the operators settle every month. Each side counts usage with its own systems, so the totals rarely match exactly. Differences can be disputed — but only within a fixed number of days. The same happens with wholesale capacity bought from other carriers.
Sound familiar?
- The same difference explained again every month
- Disputes raised after the window has closed
- Usage records and statement lines that never quite match
- Auditors asking "where is the evidence?"
Why it matters
- Unexplained money is lost money. Industry surveys have put billing leakage at around 2–3% of revenue.
- Dispute windows are short. Miss one and you pay the full bill.
- Records must be kept for two years, and subscriber data must stay in India.
Where a person decides: your wholesale manager and your finance team both approve every dispute before it goes to the partner. Small differences below your agreed limit are recorded, not disputed — unless you choose to.
A simple example — one roaming partner, one month
- Partner statement: US$412,000. Sampark's own records: US$398,000. Difference: US$14,000.
- US$6,500: a new rate that started on the 15th was charged for the whole month.
- US$4,000: the same usage records appear twice.
- US$2,300: Sampark's own records arrived late — the partner was right, and these are carried into next month, not counted twice.
- US$1,200: no clear reason yet — shown to Priya with the records behind it.
- Priya and finance approve a dispute for US$10,500, with evidence.
Made-up company and figures, for illustration only.
What happens when… — the situations we've planned for
- Statement is a scanned PDF — read inside the Data Privacy Shield; any unclear lines are shown to the analyst.
- Rate changed in the middle of the month — both rates are applied, and the split is shown.
- Records arrive after month-end — carried into next month's check — never counted twice.
- Currency or tax differences — shown separately from usage differences.
- Wholesale capacity from another carrier — the same check runs on that carrier's monthly bill.
What we need from you to start: one month's partner statement (roaming, wholesale or host network) · your own usage records from billing or the data warehouse · the contract rates · your dispute rules and limits.
What we'd measure in your pilot: days to close the month, % of the difference explained, disputes raised inside the window, credit notes received.
For your IT person — how it connects
- GUARDIAN works on usage totals and exceptions exported from your mediation, billing or data warehouse — not on the raw CDR stream.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- Scanned statements are read (OCR) inside the Data Privacy Shield; low-confidence lines go to a person.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
"Show me my data." "Delete my data." — answered on time, with proof, and without deleting what the law says you must keep.
Under India's data protection law, from May 2027 customers can ask what personal data you hold about them, ask you to correct it, or ask you to erase it — and complaints must be answered within 90 days. Suresh, a Sampark customer who has moved to another operator, asks on WhatsApp for his data to be deleted. His details sit in CRM, billing, care chats and KYC files. But the law also says call records must be kept for two years. Today nobody could say exactly what was deleted, what was kept, and why.
New to this? The background in plain words
Customers have rights over their personal data: to see it, correct it and have it erased when it is no longer needed. Operators must answer these requests, but they must also keep some records by law — for example call records for two years. The hard part is finding every copy, erasing what can be erased, and keeping — safely locked — what cannot.
Sound familiar?
- Requests arriving by WhatsApp, email and in stores
- Each system searched by hand
- Worry about deleting something the law says to keep
- No proof that every copy is gone
Why it matters
- New rights from May 2027 under the Digital Personal Data Protection Act.
- Telecom records have legal retention periods — erasure must respect them.
- Customers trust operators that handle their data clearly.
Where a person decides: your Data Protection Officer approves every response, and your CISO also approves every erasure. Records you must keep by law are locked, not deleted — and come back for approval when their time is up.
How one-click erasure works, in simple words
- GUARDIAN locks each customer's personal data with a key that belongs only to that customer.
- Rules written with your DPO decide, record by record, what can be erased now and what the law says to keep.
- After your DPO and CISO approve, one click destroys the customer's key. Every copy of their data in GUARDIAN — including backups — becomes unreadable for ever.
- Records the law requires, like call records for two years, are locked under a separate hold and erased when the period ends, again with approval.
- Other systems, like billing, erase through their own process. GUARDIAN raises those tasks and tracks them to the end.
Example uses a made-up operator.
What happens when… — the situations we've planned for
- Customer can't be verified — no personal data is shared; the request is recorded.
- A family member asks for someone else — their authority is checked first.
- An open billing dispute — those records are kept until the dispute closes.
- Customer changes their mind — recorded; nothing is destroyed.
What we need from you to start: your retention rules (with your DPO and legal team) · connected systems list · who approves.
What we'd measure in your pilot: requests answered within the deadline, systems covered, erasure certificates issued, complaints about data requests.
For your IT person — how it connects
- One master key per person, held in your HSM on a Sovereign Node. Key destruction is logged and needs both DPO and CISO approval in the Multi-Consensus HITL Gate.
- Retention and erasure rules run on Open Policy Agent (OPA), versioned with your DPO.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
Every new TRAI voucher rule turns into a big catalogue project.
TRAI's September 2026 change says: for each bundled plan of 30 days or less, offer a voice-and-SMS-only voucher, with at least one that renews on the same date each month, priced roughly in proportion. Sampark (our made-up operator) has 180 live plans. Which ones need a new voucher? Today the regulatory team reads the rule, product writes it up, IT changes the catalogue — all by email.
New to this? The background in plain words
A "voucher" is a recharge plan: an amount of calls, SMS and data for a number of days. TRAI sets rules on which vouchers operators must offer and how validity works. All plans live in a product catalogue that feeds billing, the app and shops — so one rule can mean changing many plans.
Sound familiar?
- Every rule change handled by email and spreadsheet
- Old plans forgotten
- Changes made at the last minute
- Different wording in different places
Why it matters
- Better to find gaps yourself, before customers or TRAI do.
- Rules keep coming: voice-and-SMS vouchers in December 2024, and more in September 2026.
- Each change touches the catalogue, billing and customer messages.
Where a person decides: your regulatory and product teams agree how to read each rule, and approve every change before it is raised.
What happens when… — the situations we've planned for
- The team disagrees on what the rule means — no change is raised until it is agreed.
- Old plans closed to new customers but still live — checked separately.
- A tariff filing is needed — a draft is prepared for your regulatory team to file.
What we need from you to start: a catalogue export or API · the rule text · your change-request process.
What we'd measure in your pilot: days from rule to compliant catalogue, gaps found after launch, regulatory findings.
For your IT person — how it connects
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
"Why did my data finish early?" — answered on WhatsApp in minutes, with a person one tap away.
Meena asks on WhatsApp why her data finished five days early. Today she waits in a call queue, or a bot sends her in circles. With GUARDIAN she gets a clear answer from her own account and your approved information: on Sunday she used 3 GB, about three times her usual day — and it shows her how to check usage and set an alert. If she types "agent", a person takes over — with the whole conversation in front of them.
New to this? The background in plain words
Most customer questions are simple, and the answer is already in the customer's account: their plan, usage and last recharge. WhatsApp lets operators answer in the customer's own chat. The hard part is doing it safely — checking it's really the customer, never guessing, and handing over to a person at the right moment.
Sound familiar?
- Long queues for simple questions
- Bots that go round in circles
- Agents asking for the same details again
- The same question asked again and again
Why it matters
- Care is one of the biggest costs in telecoms.
- WhatsApp is where your customers already are.
- Customers must always be able to reach a person.
Where a person decides: a person handles anything that needs a decision — refunds, complaints, disputes — and any customer who asks for one.
What happens when… — the situations we've planned for
- Customer wants to cancel — sent straight to a person; never blocked.
- Message sounds like fraud or a SIM-swap worry — sent to your fraud team at once.
- Customer not verified — only general information is given.
What we need from you to start: your WhatsApp Business number · approved answers and templates · read-only access to bills, plans and orders.
What we'd measure in your pilot: questions answered without a call, repeat contacts, hand-over time, satisfaction, complaints about the bot.
For your IT person — how it connects
- WhatsApp through the official WhatsApp Business Platform (via a BSP); RCS through RBM aggregators. Messages GUARDIAN starts use approved templates; customers can type "agent" at any time.
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
A security incident at 2 a.m. The first report to DoT is due by 8 a.m.
At 2 a.m. the security team finds suspicious access to a customer database. The Telecom Cyber Security Rules say report to DoT within 6 hours, and send a detailed report within 24 hours. CERT-In also wants a report within 6 hours. Facts are changing by the minute, and each report has its own form.
New to this? The background in plain words
Telecom networks are critical infrastructure, so security incidents must be reported fast. Each operator has a Chief Telecommunication Security Officer who reports to DoT; CERT-In also needs a report. The reports must agree with each other, and logs must be kept in India.
Sound familiar?
- Facts spread across chat groups
- Each form filled in by hand
- Different facts in different reports
- Timings pieced together afterwards
Why it matters
- The first deadline is only 6 hours.
- Several reports start at once — DoT, CERT-In, and from May 2027 the Data Protection Board.
- Consistent facts build trust with regulators.
Where a person decides: your Chief Telecommunication Security Officer (or DPO) decides what is reportable and approves every report. Your staff submit it — GUARDIAN holds no regulator passwords.
What happens when… — the situations we've planned for
- Officer decides it is not reportable — the decision and the reason are recorded.
- Facts change — updated drafts show exactly what changed.
- Incident affects India and the UK — each country's deadlines run from their own start.
What we need from you to start: your incident process · report formats · who approves what.
What we'd measure in your pilot: time to first report, reports on time, differences found between reports.
For your IT person — how it connects
- GUARDIAN drafts reports only; submission is by your staff through each regulator's channel.
- India: a Sovereign Node in your Indian cloud region or data centre, or GUARDIAN SaaS in an Indian cloud region. Subscriber data and logs stay in India (CERT-In: logs kept 180 days).
Words used on this page — in simple terms
How GUARDIAN connects to your business
Runs Inside Your Cloud, in India — Beside Your BSS.
Which best describes your business?
Choose yours. In Step 2, the problems that apply to you are marked ✓ — and Step 3 shows how GUARDIAN connects to the systems you already use.
The problems GUARDIAN solves for operators and providers
Pick a problem to see a worked example, how GUARDIAN handles it, where your team stays in control, and what happens in the awkward cases.
Show that every cancellation is handled fairly — across every site and every supplier.
Beacon Mobile is an MVNO with 1.2 million customers — a fictional name for this example. It uses two outsourced contact centres. Sarah calls to cancel. The agent makes an offer; she declines twice; the call ends without a cancellation. She calls again the next week. Nobody meant harm, but this is the pattern Ofcom looks for. In July 2026 it issued a record £28m fine under the cancellation rule, finding that over a million callers had had to repeat their requests and that quality checks on outsourced centres were weak.
New to this? The background in plain words
Customers who want to leave are often put through to a retention team, which may make offers. What it may not do is make leaving hard — for example, by making people ask again and again. Many operators use outsourced contact centres, so they need evidence that every site handles cancellations fairly.
Sound familiar?
- Customers calling several times to cancel
- QA samples a tiny fraction of calls
- Outsourced sites reporting on their own quality
- Cancellation complaints reaching ADR
Why it matters
- General Condition C1.8 says cancelling must not be made difficult.
- Retention practice has close regulatory attention in 2026.
- Outsourced sites are where evidence is hardest to see — and where it helps most.
Where a person decides: retention offers stay with your team, and a QA reviewer decides on every flag. GUARDIAN never blocks or delays a cancellation.
A worked example — one customer, two calls
- Sarah says "I want to cancel" on her first call. GUARDIAN recognises the intent and opens a case with a timer.
- The call ends without a cancellation. The case stays open.
- A week later Sarah calls again. GUARDIAN links the two calls and flags a repeat request.
- A QA reviewer looks at both calls and decides: fair handling, or something to coach.
- Each month, compliance sees repeat-request rates by site and supplier.
Fictional example.
What happens when… — the situations we've planned for
- Customer asks about cancelling but wants options — recorded as an enquiry — not forced into a cancellation.
- Cancelling inside a minimum term — early termination charges explained accurately; still actioned if the customer asks.
- Cancelling because of a fault — linked to the complaint and compensation workflows.
- Vulnerable customer — routed to specialist handling.
What we need from you to start: call transcripts or speech-analytics output · chat and email · your cancellation process and QA rules.
What we'd measure in your pilot: repeat cancellation contacts, time to action, QA flags confirmed, cancellation complaints.
For your IT person — how it connects
- GUARDIAN works from transcripts supplied by your contact-centre platform; it does not record calls itself.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
Six weeks to ADR since 8 April — every complaint on the right deadline.
David complains in a web chat that his broadband drops every evening. He mentions it again on a call, then emails. Since 8 April 2026, a customer can take an unresolved complaint to ADR (the Communications Ombudsman or CISAS) after 6 weeks instead of 8. If the chat was logged as a "query", nobody knows the deadline has started.
New to this? The background in plain words
Ofcom requires every provider to follow a complaints code. If a complaint isn't resolved within six weeks, or the provider issues a "deadlock letter", the customer can take it to an independent ombudsman (ADR). The deadline counts from the first complaint, on any channel.
Sound familiar?
- Complaints recorded as "queries"
- Deadlock letters written by hand
- ADR cases you didn't see coming
- Case notes spread across systems
Why it matters
- General Condition C4 sets how complaints are handled — and Ofcom checks how they are recorded and closed.
- About 700,000 customers a year were still unresolved at 6 weeks (Ofcom estimate).
- Satisfaction with complaint handling is only around 58–61% (Ofcom, 2025).
Where a person decides: your agent or manager approves every response and every deadlock letter. Anyone who asks for a person gets one straight away.
What happens when… — the situations we've planned for
- Complaint hidden in a sales or care chat — flagged for an agent to confirm — not logged automatically.
- Customer asks for a person — handed over at once.
- Vulnerable customer — flagged for specialist handling.
- Customer already at ADR — the file is assembled; nothing is sent without approval.
What we need from you to start: your complaints code · letter templates · CRM or ticketing access.
What we'd measure in your pilot: complaints resolved before 6 weeks, missed deadlines, re-opened complaints, satisfaction.
For your IT person — how it connects
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- WhatsApp through the official WhatsApp Business Platform (via a BSP); RCS through RBM aggregators. Messages GUARDIAN starts use approved templates; customers can type "agent" at any time.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
Find and confirm every telecare user before their line moves to digital.
Mrs Patel's landline is due to move from analogue to digital next month. Her personal alarm depends on it. The only clue is a note from 2019 in the CRM — and the migration team works from a list of lines, not people. The analogue network (PSTN) closes on 31 January 2027, and about 1.8 million people use telecare devices.
New to this? The background in plain words
Telecare devices — personal alarms, fall detectors — often dial out over an analogue landline. When a line moves to digital, some devices stop working unless they are replaced or tested. Providers must find these customers first, but their records rarely say "telecare" clearly.
Sound familiar?
- Vulnerability flags incomplete and scattered
- Migration planned from line lists
- Emergency reconnections after migration
- Third-party lists in different formats
Why it matters
- Customers' safety can depend on an alarm working.
- Ofcom has made telecare protection a priority, including enforcement action in December 2025.
- The Fixed Telecoms Modernisation Charter (March 2026) commits providers to identify vulnerable users first.
Where a person decides: a person confirms every possible telecare or vulnerable customer. GUARDIAN never labels someone vulnerable by itself — it only surfaces candidates.
A worked example — one line in next month's batch
- Next month's migration list includes Mrs Patel's line.
- GUARDIAN finds a 2019 CRM note mentioning a "pendant alarm", and no broadband order on the line.
- It surfaces her as a possible telecare user, with those reasons.
- Your vulnerability team calls her, confirms the alarm and arranges a tested solution.
- Only then is the line cleared for migration.
Fictional example.
What happens when… — the situations we've planned for
- Customer doesn't respond — migration is held, not forced; your escalation path applies.
- Device already works on a digital line — confirmed and recorded.
- Data shared by a local authority — used only under the agreed data-sharing terms.
- Customer declines to be recorded as vulnerable — respected and recorded.
What we need from you to start: your migration line list · CRM notes and order history · any agreed third-party lists · your vulnerability policy.
What we'd measure in your pilot: candidates found vs confirmed, migrations held, incidents after migration.
For your IT person — how it connects
- Special-category data is handled under your DPIA and data-sharing agreements; access is limited to named roles.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
How much of your wholesale invoice do you still check by spreadsheet?
Beacon Mobile (our fictional MVNO) receives its host network's monthly invoice: £2.41m. Its own usage records say £2.36m. The dispute window is 30 days. James in finance exports usage from billing, pastes the invoice into Excel and starts matching.
New to this? The background in plain words
An MVNO has no network of its own. It rents capacity from a host network and pays a monthly wholesale invoice based on the host's count of its customers' usage. The MVNO also counts usage in its own systems. The two rarely match exactly — different rules, time zones, rounding, late or duplicate records — and differences can be disputed only within a fixed window.
Sound familiar?
- The same variance explained every month
- Disputes raised after the window
- Invoice lines that never quite match usage
- Auditors asking for evidence
Why it matters
- Revenue-assurance surveys have put billing leakage at around 2–3% of revenue.
- MVNOs are about 24% of UK mobile in 2026, forecast to reach ~30% by 2031 — more settlement relationships every year.
- Roaming is moving from TAP to BCE — another format to reconcile.
Where a person decides: your wholesale lead and finance both approve every dispute. Variances under your contractual threshold are logged, not disputed, unless you choose to.
A worked example — Beacon Mobile, one month
- Host invoice £2.41m; Beacon's records £2.36m; variance £50k.
- £21k: a mid-month rate change applied to the whole month.
- £14k: duplicate usage records.
- £9k: Beacon's own records arrived late — the host was right; carried into next month.
- £6k: not yet explained — shown to James with the underlying records.
- James and the wholesale lead approve a £35k dispute with evidence.
Fictional company and figures, for illustration only.
What happens when… — the situations we've planned for
- Scanned PDF invoice — read inside the Data Privacy Shield; low-confidence lines shown to the analyst.
- Mid-month tariff change — both periods applied, split shown.
- Late usage records — carried into next month — never counted twice.
- Currency or tax differences on roaming — shown separately.
What we need from you to start: one month's invoice · usage totals from billing or your data warehouse · contract rates · dispute rules.
What we'd measure in your pilot: days to close the month, % of variance explained, disputes inside the window, credit notes received.
For your IT person — how it connects
- GUARDIAN works on usage totals and exceptions exported from your mediation, billing or data warehouse — not on the raw CDR stream.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
Turn failed One Touch Switch matches into completed switches — first time.
A customer joining Wessex Fibre — a fictional altnet with 60,000 customers — asks to switch from their old provider. Wessex sends a One Touch Switch match request; it fails because the address is written differently. The customer gives up, or is billed by both providers. After a year of One Touch Switch (live since 12 September 2024), only about 67–68% of daily match requests were succeeding.
New to this? The background in plain words
When a broadband or landline customer switches, the new provider sends a "match" request through a central hub (TOTSCo) to find the customer's service at the old provider. If the name, address or account number doesn't match closely enough, the request fails. For mobile, customers text PAC or STAC to get a switching code.
Sound familiar?
- Failed matches checked by hand
- Switches that quietly stall
- Billing that carries on after a switch
- Customers stuck between providers
Why it matters
- Lost customers and wasted acquisition spend.
- Compensation for delays and complaints.
- Mobile ports should complete within one working day.
Where a person decides: an agent approves every corrected match before it's resent.
What happens when… — the situations we've planned for
- Switching only part of a bundle — handled service by service.
- Possible switch without consent (slamming) — sent to your fraud and complaints teams.
- Losing provider doesn't respond — escalated through the industry process.
- Mobile port delayed beyond one working day — compensation rules checked.
What we need from you to start: failure messages from your One Touch Switch integration · order and billing access.
What we'd measure in your pilot: match success rate, days stuck, post-switch billing complaints.
For your IT person — how it connects
- GUARDIAN is not a TOTSCo hub member; it reads failure messages from your own One Touch Switch integration.
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
A missed engineer visit and four extra days without broadband — is the credit right, and on time?
An engineer misses Wednesday's appointment at a Wessex Fibre customer's home, and the repair then takes four extra days. If you've signed up to Ofcom's voluntary automatic compensation scheme, from April 2026 that is £32.31 for the missed appointment plus £10.34 a day for the delayed repair: £73.67. Field, network and billing each hold part of the picture.
New to this? The background in plain words
Under Ofcom's voluntary scheme, most large providers pay customers automatically when repairs are slow, engineers miss appointments or new services start late. Amounts depend on days and on rates set each April. Working them out needs field, network and billing data together.
Sound familiar?
- Credits worked out with manual queries
- Some customers missed, some paid twice
- Batch jobs after every major incident
- Complaints about missing credits
Why it matters
- Providers paid about £63m in automatic compensation in 2024.
- Rates rise with inflation each April.
- Missed credits become complaints and audit findings.
Where a person decides: finance approves every compensation batch before it is posted to billing.
What happens when… — the situations we've planned for
- Customer changed plan during the event — the product in force at each moment is used.
- Two overlapping events — paid once per rule, not twice.
- Already credited by an agent — found and netted off.
What we need from you to start: fault, appointment and provisioning events · your compensation rules · billing access.
What we'd measure in your pilot: credits on time, missed or duplicate credits, compensation complaints.
For your IT person — how it connects
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
Subject access and erasure requests answered within the month — with proof of what was erased, what was kept, and why.
A former Beacon Mobile customer emails asking for a copy of her data and then for it to be erased. Under UK GDPR you have one month. Her data sits in CRM, billing, contact-centre recordings and chat logs, and some records — billing for tax, an open complaint — must be kept for now. Today the DPO's team searches each system by hand and can't easily prove every copy is gone.
New to this? The background in plain words
Under UK GDPR people can ask for a copy of their data (a subject access request) or for it to be erased. Providers have one month to respond. Some records must still be kept — for tax, disputes or other legal reasons — so erasure has to be selective and provable.
Sound familiar?
- Requests by email, chat, post and phone
- Manual searches across systems
- Uncertainty over what must be kept
- No single proof of erasure
Why it matters
- One month to respond under UK GDPR (extendable by two months for complex requests).
- Clear, complete answers avoid complaints to the ICO.
- Retention duties — tax, disputes, lawful requirements — must be respected.
Where a person decides: your DPO approves every response and your CISO co-approves every erasure. Records under a legal hold are restricted, then erased when the hold ends — again with approval.
How one-click erasure works
- Each person's data in GUARDIAN is protected by a key unique to that person.
- Policies agreed with your DPO decide, record by record, what can be erased and what must be kept.
- After DPO and CISO approval, destroying the key makes every copy of that person's data in GUARDIAN — including backups — permanently unreadable.
- Held records stay restricted until their retention ends, then return for approval.
- Systems outside GUARDIAN erase through their own processes; GUARDIAN raises and tracks those tasks.
Fictional example.
What happens when… — the situations we've planned for
- Requester can't be verified — no data released; request logged.
- Request made on someone's behalf — authority checked first.
- Open complaint or dispute — related records kept until it closes.
- Request withdrawn — recorded; nothing destroyed.
What we need from you to start: your retention schedule · connected systems · approvers.
What we'd measure in your pilot: requests answered within one month, systems covered, erasure certificates, ICO complaints.
For your IT person — how it connects
- One master key per person in your HSM; destruction logged and dual-approved (DPO + CISO) in the Multi-Consensus HITL Gate.
- Policies run on Open Policy Agent (OPA).
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
Every price rise in pounds and pence. Every notice on time.
Since 17 January 2025, any price rise in a new consumer contract must be set out in pounds and pence at the point of sale — no inflation-linked or percentage rises. End-of-contract notices are due 10–40 days before a contract ends, and out-of-contract customers get an annual best-tariff notice. Your catalogue has hundreds of live and legacy plans, and notice schedules run in several systems.
New to this? The background in plain words
Every plan in a provider's catalogue has a price, a contract term and rules for price changes. Ofcom's rules say how price rises must be shown and when customers must be told their contract is ending. Legacy plans no longer on sale still have customers — and still need to comply.
Sound familiar?
- Rules handled by email and spreadsheet
- Legacy plans forgotten
- Notice campaigns re-run
- Inconsistent wording across channels
Why it matters
- Better to find gaps yourself, before customers or Ofcom do.
- Notices must go out on time, with the right wording.
- Clear, consistent wording across channels builds trust.
Where a person decides: your regulatory and product teams agree how each rule is read, and approve every change and notice.
What happens when… — the situations we've planned for
- Interpretation disputed internally — no change raised until agreed.
- Legacy plans closed to new customers — checked separately.
- Notice undeliverable — flagged for another channel.
What we need from you to start: catalogue export or API · notice schedules · the rule text.
What we'd measure in your pilot: days from rule to compliant catalogue, notice timeliness, regulatory findings.
For your IT person — how it connects
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
Answers in minutes on RCS or WhatsApp — and a person whenever the customer wants one.
A Beacon Mobile customer asks why this month's bill is £6 higher. On RCS she gets a clear answer from her own account: a roaming day in France. When she asks about leaving, she's passed straight to a person, with the conversation attached. On 25 September 2026 Ofcom warned that AI must be transparent and must not become a "gatekeeper" to human support.
New to this? The background in plain words
Many questions — "why is my bill higher?" — can be answered from the customer's own account. RCS is a richer form of text messaging built into phones; WhatsApp is widely used too. Ofcom expects AI in customer service to be transparent and to let customers reach a person.
Sound familiar?
- Queues for simple questions
- Bots with no clear way to a person
- Agents re-asking for details
- Complaints about chatbots
Why it matters
- Care is a major cost for every operator.
- Ofcom expects AI in care to be transparent, with a clear route to people.
- Messaging channels must resist impersonation under the Fraud Charter.
Where a person decides: your team handles refunds, complaints, cancellations and anything the customer wants a person for.
What happens when… — the situations we've planned for
- Customer wants to cancel — straight to a person — never obstructed.
- Scam or SIM-swap worry — to your fraud team at once.
- Signs of vulnerability — specialist handling.
- Not verified — general information only.
What we need from you to start: RCS agent or WhatsApp number · approved answers · read-only billing and order access.
What we'd measure in your pilot: contacts resolved without a call, repeat contacts, hand-over time, satisfaction, bot complaints.
For your IT person — how it connects
- WhatsApp through the official WhatsApp Business Platform (via a BSP); RCS through RBM aggregators. Messages GUARDIAN starts use approved templates; customers can type "agent" at any time.
- Reads and writes through TM Forum Open APIs where your stack offers them — TMF620 catalogue, TMF621 trouble ticket, TMF622 ordering, TMF629 customer, TMF678 bill — otherwise through database views or SFTP files.
- Phone numbers (MSISDN), IMSI, ICCID and IMEI are tokenised with prefix-preserving Format-Preserving Encryption (NIST SP 800-38G, FF1): country code, operator prefix and MCC-MNC stay readable so routing and rating logic still work, and check digits are recomputed. On a Sovereign Node the keys stay in your own HSM.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
One incident, several regulators, several deadlines.
A security compromise affects customer data. Ofcom must be told about security compromises with a significant effect, and the ICO about personal data breaches within 72 hours. Facts change hour by hour, and each report has its own format.
New to this? The background in plain words
Providers must tell Ofcom about security compromises with a significant effect, and the ICO about personal data breaches within 72 hours. Incidents move fast, and several teams contribute facts.
Sound familiar?
- Facts in chat rooms and spreadsheets
- Forms filled by hand
- Different facts in different reports
- Timings reconstructed afterwards
Why it matters
- 72 hours to the ICO for a personal data breach.
- The Telecoms Security Code (revised July 2026) expects controlled, monitored processes.
- Consistent reports build regulator trust.
Where a person decides: your CISO or DPO decides what is reportable and approves each report; your staff submit it.
What happens when… — the situations we've planned for
- Not reportable — decision and reason recorded.
- Facts change — updated drafts show what changed.
- Incident spans the UK and India — each country's deadlines count from their own start.
What we need from you to start: incident process · report formats · approvers.
What we'd measure in your pilot: time to first report, reports on time, inconsistencies found.
For your IT person — how it connects
- Drafts only; no regulator credentials are held by GUARDIAN.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
A four-month MVNO launch, tracked in spreadsheets and slide decks.
A new brand is launching an MVNO with an enabler (MVNE) and a host network. UK enablers report launches in about four months. CRM, rating, billing, number ranges, porting and eSIM supply all have to work together, and evidence comes from three companies. Every week the programme manager collects status by email.
New to this? The background in plain words
An MVNO launch connects a new brand's systems — often run by an enabler (MVNE) — to a host network: numbers, SIMs and eSIMs, porting, rating and billing. Dozens of tests must pass, and three or more companies sign off.
Sound familiar?
- Checklists in spreadsheets
- Test evidence lost in email
- Go-live dates that slip
- Day-one billing disputes
Why it matters
- Delays cost the brand, the enabler and the host.
- Cut-over surprises become wholesale disputes.
- New entrants — including fintech brands — expect speed.
Where a person decides: the steering group decides go or no-go; each approver is recorded.
What happens when… — the situations we've planned for
- Conflicting evidence — shown side by side.
- Scope change — checklist versioned.
- Invoice dry run fails — linked to the wholesale reconciliation before go-live.
What we need from you to start: integration plan · test cases · sign-off owners.
What we'd measure in your pilot: milestones met, post-launch defects, first-month wholesale disputes.
For your IT person — how it connects
- Evidence stored with source and time; go / no-go through the multi-person Approval Gate.
- UK: a Sovereign Node in your UK environment, or UK-region SaaS. You control and monitor all GUARDIAN access, in line with the Telecommunications Security Code of Practice.
Terms used on this page
How GUARDIAN connects to your business
A Sovereign Node in Your UK Environment — Under Your Access Controls.
Pick a Template. Connect It. Teach It Your Rules.
Every problem on this page comes as a designed workflow template for mobile operators, broadband providers and their partners, set up with you in a pilot. You do not start from a blank page: choose one, give it your name, connect your systems and upload your own rules. Your team approves every important step.
- ChoosePick a template for your problem
- RenameGive it your own name
- ConnectLink your systems through NEXUS
- Set the startA new record, a file, a message or a time
- TeachUpload your rules, letters and FAQs to its expert
- TestRun it on your past cases
- ShadowIt runs on real work; your team checks every step
- LiveSteps go automatic only once your team agrees they are right
Every template has its own expert: the SME Agent
Each workflow step can ask its SME Agent (subject-matter expert) a question, such as "which documents does our policy accept here?". It answers from your material only, and always shows where the answer came from.
If it is not sure, it says so, and the step waits for your team. A step moves on by itself only when the rules are met and the confidence is high enough. Important decisions always go to a person.
- Current rulesRegulations and deadlines, kept up to date by Guideazy, with the date each rule starts
- Your policiesYour SOPs, limits and ways of working
- Your letters and formsThe wording and formats you already use
- Your historyPast tickets, customers and orders, read from your systems with personal details hidden
- Your team's decisionsWhat your approvers agreed or changed, so it learns your way
- Nothing sharedEach customer's expert is separate. The AI works on tokenised data, not real names or numbers.
Roaming & Wholesale Settlement Check
Puts a partner's statement beside your own usage totals, explains each difference by cause with evidence, and prepares a dispute pack for approval before the window closes.
What it needs
- Connects to
- Partner statement, Data warehouse / billing, Contract rates
- Your team approves
- Wholesale analyst, Finance
- Its expert learns from
- Partner contracts (rates, windows, dispute process), Past dispute letters
- Where there is no API
- GUARDIAN prepares the work; your team completes that step by hand, and it is recorded.
Complaint Deadlines & Appeals
Links every contact about the same issue into one case, starts the right regulatory deadline from the first contact, drafts replies and deadlock / appeal files for approval.
What it needs
- Connects to
- Channels (WhatsApp, RCS, email, chat), CRM / ticketing
- Your team approves
- Agent, Complaints manager
- Its expert learns from
- Complaints code / SOP, Reply and letter templates, Product and tariff FAQs
Outage & Service-Failure Credits
Takes a qualifying outage or service failure, finds the affected customers, calculates each credit from the plan in force, nets off duplicates and prepares one batch for finance.
What it needs
- Connects to
- Network / service assurance (NOC), Customer-to-area map, Billing (read)
- Your team approves
- Billing operations, Finance
- Its expert learns from
- Credit and compensation policy, Customer notification wording
Tariff, Catalogue & Notice Checks
Turns each new pricing or voucher rule into checks, runs them across live and legacy plans and notice schedules, and raises approved change requests.
What it needs
- Connects to
- Product catalogue
- Your team approves
- Regulatory, Product
- Its expert learns from
- Regulation texts and internal interpretations, Catalogue naming conventions
WhatsApp & RCS Care with a Person on Request
Answers bill, plan and usage questions from the customer's own account and approved content, and hands over to a person whenever asked or needed.
What it needs
- Connects to
- WhatsApp / RCS, Billing / usage (read-only), Knowledge base
- Your team approves
- Agent
- Its expert learns from
- FAQ and policy documents, Tariff sheets, Tone-of-voice guide
SIM KYC Exception Handling
Handles activations that fail a KYC, SIM-cap or DoT check: tells the customer or shop what is missing, gathers non-biometric documents, and builds a complete case for the KYC officer.
What it needs
- Connects to
- KYC / activation platform
- Your team approves
- KYC officer, KYC head
- Its expert learns from
- Your KYC policy and exception-handling SOP, List of acceptable documents per exception type, FAQs your stores and care teams answer about KYC and 1 more
Spam (UCC) Complaint Actions
Groups spam complaints by the business behind them, tracks TRAI deadlines, and prepares suspensions, notices and appeal files for your regulatory officer.
What it needs
- Connects to
- Complaint systems (1909 / app / care), DLT platform
- Your team approves
- Regulatory officer, Head of regulatory
- Its expert learns from
- Your UCC handling SOP, Notice and appeal letter formats, List of critical / protected headers and 1 more
- Where there is no API
- GUARDIAN prepares the work; your team completes that step by hand, and it is recorded.
Cancellation Handling Assurance (Ofcom C1.8)
Recognises cancellation intent in every channel, times each request to completion, and flags possible obstruction for QA review by site and supplier.
What it needs
- Connects to
- Contact-centre platform, CRM
- Your team approves
- QA reviewer
- Its expert learns from
- Cancellation policy and scripts, QA scorecard
Telecare Checks Before Landline Migration
Surfaces possible telecare or vulnerable customers in each migration batch, with reasons, for a person to confirm before any line moves.
What it needs
- Connects to
- Migration programme, CRM
- Your team approves
- Vulnerability team
- Its expert learns from
- Vulnerable customer policy, Contact scripts
Switching Exceptions (One Touch Switch, PAC/STAC)
Diagnoses failed and stuck switches from your own switching integration, proposes corrections for approval, and checks billing stops after the switch.
What it needs
- Connects to
- Your One Touch Switch integration, CRM / orders, Billing
- Your team approves
- Agent
- Its expert learns from
- Switching process guide
Security & Data Incident Reports
Starts every reporting deadline that applies, keeps one fact timeline, drafts each regulator's report for your security officer to approve; staff submit.
What it needs
- Connects to
- SIEM / ticketing, Incident form
- Your team approves
- CTSO (India) / CISO, DPO
- Its expert learns from
- Incident response plan, Regulator report formats
MVNO Launch Readiness
Keeps the launch checklist and evidence from every party in one place, chases gaps, and prepares the go / no-go pack for the steering group.
What it needs
- Connects to
- Integration plan, Evidence uploads / email
- Your team approves
- Steering group
- Its expert learns from
- Integration plan and test strategy
Customer Data Requests & One-Click Erasure
Verifies the customer, lists the data held, applies retention rules with Open Policy Agent, and after DPO and CISO approval erases the person's data in GUARDIAN by destroying their master key.
What it needs
- Connects to
- Request channels
- Your team approves
- DPO, CISO
- Its expert learns from
- Your privacy notice and data-retention schedule, DSAR / grievance SOP, Response letter templates
13 templates. Each one is fully designed and documented for our engineering team. We set it up with you in a pilot, and it starts in shadow mode before any step runs on its own. Some steps, like final approvals, never run on their own.
What GUARDIAN Prepares — and What Always Stays With You
Telecoms is licensed, regulated and security-critical. So GUARDIAN does the routine work and stops for a person at every decision.
Fair Questions. Straight Answers.
Operators are right to be careful with new suppliers. These are the questions we expect.
GUARDIAN Gets It Ready. Your Team Says Yes.
Here's what an approval looks like. Some decisions need more than one person — a partner dispute needs wholesale and finance — and the gate records each of them. If approvers need to talk it through, they can start a video call from the same screen.
After approval, your team applies the suspension in your DLT system. Made-up example.
Nobody is labelled vulnerable, or migrated, without a person deciding. Example only.
Where We Stand — Honestly
Operators will ask, so here it is plainly. We use "in preparation" and "planned" until a certificate is issued.
✓ Today
- UK GDPR — self-assessed, with our own DPIA pack for each engagement
- Tokenisation of telecom identifiers (NIST SP 800-38G) before any AI model
- Private, open-weight AI models — no public AI services
- Approval Gate — UK patent-pending GB2615329.6
◐ In preparation (from October 2026)
- Cyber Essentials Plus (UK)
- Independent penetration test, repeated for each major release
- Security questionnaire pack for operator assessments
○ Planned
- ISO/IEC 27001
- India: CERT-In-empanelled security audit before our first production deployment in India
- India's DPDP Act duties from May 2027 — built into the India workflows
Three Ways to Work With Us — Pick What Suits You
- GUARDIAN inside your own cloud account or data centre — in India for Indian operators, in the UK for UK operators
- Encryption keys in your own HSM
- Private AI models on your infrastructure
- You control and monitor all access
- Hosted by us in an Indian or UK cloud region
- A separate, protected space for your business
- Same tokenisation and Approval Gate
- India-region environment being set up — dates confirmed before any pilot
- Your SI deploys and runs GUARDIAN in your environment
- White-label option
- Joint pre-sales and engineering support from us
- Fits your existing procurement route
Telecom engagements are priced per engagement, starting with a scoped pilot on one workflow. Talk to us about yours.
What a pilot looks like
You don't have to change anything big at once. Start with one workflow, on your own data, then decide.
New Rules Handled On Time. Partner Bills Explained. A Person on Every Decision.
Fair Cancellations. Complaints on Time. Every Telecare User Protected.
We're looking for our first telecom design partners in India and the UK. Show us one real case and we'll walk you through how GUARDIAN handles it.
GUARDIAN never performs biometric checks, never logs in to regulator portals and never makes a regulated decision — your team approves every step.