You are moving your existing contact center to Amazon Connect. You have read that it is best to forward your current numbers to a new number claimed in Connect for your initial go-live before porting the numbers. That way, if there is a problem with your migration, you can roll back cleanly by pointing the number back at the legacy IVR.
The challenge is, you want to be able to use your existing phone numbers as the outbound caller id when your agents dial out.
When setting the outbound number for each queue, you find that you can only select from numbers you’ve either claimed or ported to Connect.
You search on and discover that when building the outbound flow, you can use the Call Phone Number block to dynamically set the outbound number.
This is great because you want to use a different number depending on the customer’s area code you are calling. But again, you are only able to select from numbers already in your Connect instance.
Your search continues and you find an article detailing how to dynamically set the call ID phone number based on the customer’s phone number of a given call. You build the Lambda and add the numbers you want to use to a Dynamo table, but when you test it, you discover that if you use a value that is not one of your Connect numbers, the caller ID on your test calls shows “Unidentified” with no phone number 😖
The missing piece is that AWS must turn on ‘Call Spoofing,’ or as it’s internally called ‘Custom Caller ID.’ You can do this with a Support Case.
Here is an example of the text you can use when creating these Support Case:
Please enable call spoofing/custom caller ID for Connect instance arn:aws:connect:region:123456789100:instance/abcdefg-123456789
for the following numbers:
+1 800-555-1234 (Invoice Attachment 1, page 3)
+1 800-555-4321 (Invoice Attachment 1, page 5)
+1 800-555-6789 (Invoice Attachment 2, page 4)
Proof of ownership for these numbers is attached.
We are interested in presenting the carrier-level numbers to our customers when dialing out.
I understand that this is a request that must be forwarded to the Connect Service Team.
Please let us know what, if any, additional information is required.
The attachment with proof of ownership of the numbers is a requirement. AWS does not want to enable bad actors to impersonate numbers they do not own. The bill you provide should show that the name of AWS account is the same as that of the company paying the monthly bill for those numbers. And the specific phone number will need to be included in the invoice/report. If your bill does not show an itemized list of the number you want to spoof, you’ll need to contact them to get some form of proof.
This feature is not well documented and is not widely understood even by the team responding to support tickets. Even when providing a request with the above level of specificity, the support agent will sometimes reply with documentation for the Call Phone Number block.
When this happens, this is how you can respond:
Thank you. The Call Phone Number block only allows you to use phone numbers associated with the Connect instance. We wish to use numbers that are:
- currently owned
- in operation with another carrier
- will be ported eventually, but forwarded initially per Connect best practices
For this to work, we need Custom Caller ID turned on. Without it, the Call Number Block looks like my first attachment. However, in an instance with it turned on, the block has an additional option, like my second attachment.
The wait time for getting Call Spoofing turned on in Connect depends on how many numbers you are requesting and whether you need an additional round of communication with the Support Team. Two to seven days has been my experience.
Using Amazon Connect’s Custom Caller ID feature will enable the porting process to occur after you’ve initially forwarded numbers, gone live, and confirmed that everything is working.
Additionally, it is easier to time a forward than a phone number port.
Letting your current carrier know about your port too late can lead to missing your intended go-live date because the legacy provider took longer than anticipated.
Worse, you may face a surprise go-live when your new system is not yet completely built and tested if your legacy telephony provider executes the number transfer early without communicating the timeline to you and AWS. In either case, you will wish you’d taken the extra steps to forward first.
Need help getting Call Spoofing turned on in Connect? Contact us.