[VoiceOps] CSR BTN

[Robert Schoneman]

As a customer doing porting from one carrier to another my experience has been the CSR is just a record of everything (phone number, circuit, trunk, etc) on an account or BTN. It's not a verification document, per se. But is often used during porting to verify information if the port order gets rejected by the losing carrier or if the port order is somehow incomplete or fails an initial verification.

All the CSRs I've ever seen were just everything on the BTN and weren't specific to the port order in question. That is, if I was porting 5 numbers from a BTN and there's 100 numbers on the BTN, the CSR would include all 100 numbers regardless of the port order.

I've not seen any consistency with regards to what details are on the CSRs from one carrier to another. Some are quite verbose, and others are little more than a list of numbers.

________________________________
From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Mike Hammett <voiceops at ics-il.net>
Sent: Friday, May 28, 2021 10:51 PM
To: VoiceOps <voiceops at voiceops.org>
Subject: [VoiceOps] CSR BTN

Does a CSR have to have the specific number being ported or just any number on the account?

We're testing a third party network that we'll utilize in the short-term for out-of-area usage.
We ported some of our own numbers to our account at the third party.
The CSRs arrived with the main BTN on the account, not the number being ported.
Our porting person rejected the CSRs because they weren't for the number being ported. Of course she knew what number was being attempted because it was an internal operation, but normally she wouldn't.


It's my thought that the CSR is a customer information verification process. We wouldn't know the number actually being ported until the LSR came. Does the name, address, account number, TN, etc. match an account you have? If so, great.


Where can I find a good resource on the process and what's normally acceptable for rejections?


Of course I said, "Let me verify this before we do anything" and then she replied to the CSRs rejecting.  *sigh* I guess we'll really be testing all scenarios.



-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ics-2Dil.com&d=DwQFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=O9zkNrKbQF1fgs1KTBRWpbNPvZEkJNea930OX6UPkBE&m=aR5JTq8SllMct1kRkYd2qv2GOoPcv9M9LFoAy20REIs&s=ImMHidIuRKsJodab9BGmkKWxVVa-0KwXhVZftefq3MQ&e=>



Midwest Internet Exchange
http://www.midwest-ix.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.midwest-2Dix.com&d=DwQFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=O9zkNrKbQF1fgs1KTBRWpbNPvZEkJNea930OX6UPkBE&m=aR5JTq8SllMct1kRkYd2qv2GOoPcv9M9LFoAy20REIs&s=xr8izRMQ6mfH9a90W1aHPbgdH8NAZI9JsmyPlsion90&e=>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20210529/14c331e0/attachment-0001.htm>