Onboarding

The TOTSCO process involves several stages. Once you get on the pre-production platform you can send and receive messsages to other CPs on the pre-production platform. It is usually a good idea to talk to the CP first, but some CPs are happy for you to send mesages at any time (including A&A).

Once you think you are ready, TOTSCO will pair you with another CP and arrange a call with them and you and go through some simple tests. They actually want you to do a lot of messages as well, but that can be a script of a few hundred match requests if necessary.

The idea is that this shows you are ready to go live. It is not a comprehensive test by any means.

Platforms

You need to either be able to switch your system between platforms or handle more than one platform. Handling more than one platform is a good idea. You can make your dev system talk to the TOTSCO pre-production platform both ways. You can make a system which talks to NOTSCO both ways. And finally you have a live system that talks to/from TOTSCO live platform and your live customer database and interactions. Obviously your test systems will want to avoid sending messages to real customers or ceasing real services.

It makes a lot of sense to keep a dev systrem that talks to TOTSCO pre-production, it allows you to carry out tests if something comes up later before changes are made live. Sorry I have to say this!

One trick on your dev/test platform is to direct messages based on the CP identity, a simple trick is to set up NOTSCO to be TEST. Then your dev system can have code to route any message to TEST to NOTSO and other messages to TOTSCO pre-production platform. It makes testing using pre-production and NOTSCO simple.

NOTSCO can help

The NOTSCO system handles and generates all of these message types, and you can do tests. The Scorecard can confirm what you have managed.

There are also a lot of ways to test your error checking, sending invalid messages, and sending errors to check how you handle them.

Are you ready?

You need to be able to send and receive all of the types of message. This means the SwitchMatch messages (Request, Confirmation, and Failure), and the same for SwitchOrder, SwitchOrderUpdate, SwitchOrderCancellation, and SwitchOrderTrigger. You also need to handle a messageDeliveryFailure.

This is a lot to test on the call, 16 message types, sent and received to your buddy CP, so 30 messages total. If your system is ready it can be done quite quickly.

Not just messages

There is more to it than just sending and receiving 16 messages, sorry.

To handle switching away from you...

• You need to be able to handle a match request. This means finding the service in your cutsomer database, checking the status (valid, already ceased, already switched, etc), checking if any termination charge or minimum term to tell your customer about, and if there are related services (like a phone line) that will also cease. Assuming no problems you need to be able to allocate a switch order reference, and notify your customer. You have to do this quickly and automatically 24/7.
• Do check the matching rules carefully - things like address matching rules, and surname checking with unicode characters for accented letters match against non accented versions, and letters like ß matching ss, etc.
• If not matched, or other errors, you have to report failure. Basically you will need to have tested for every error case and be able to report every error code. We don't try and test all of these, but we'll want to test a confirmation, and failure, and possibly some other error codes. This also has to be done quickly and automaticlly 24/7.
• You need to be able to keep track of the switch order, handle the switch order message, and update, and cancellation messages.
• You need to be able to handle the trigger, ceasing your service and correctly charging your customer to the trigger date.
• You also need to be able to handle a switch order timing out, and other errors.

To handle switching to you...

• You need your order process to handle switching, e.g. your web ordering and/or customer service systems, need to be able to make a match request. This includes handling all the errors, and possibly asking for more information such as an account number or circuit ID. If all goes well you get a switch order reference.
• You have to check your customer got the notice from their existing provider, and confirm they have authority to go ahead, and then do a switch order.
• You need to have your own ordering system to provide your service, or migrate over the existing service if that is how you work.
• You have to be able to handle changes and delays for expected install date and send an update message.
• You have to be able to handle a cancellation, cancelling your service provision and sending a cancellation message.
• You have to be able to send a prompt and correct trigger message when your service is provided, and bill from that trigger date.
• In all of this, you also have to be able to handle possible error replies.

You also need staff trained on the process both ways, and ways to handle exceptions and errors that may crop up.

A&A can help.

Yes, we can be a buddy CP, but some steps to it, sorry.

• Use NOTSCO, even if you did not in your development, it will help find issues you may have missed. Fill the score card for all the message types (without errors).
• Make sure you are actually ready - as I say above, it is not just about the messages. It is important to have all the processes behind them.
• Once you are ready and have done that testing, then contact us or ask TOTSCO to contact us.
• We'll want to go through some tests on pre-production platform, to/from you, without errors. We want to check you seem to have not just messages, but the underlying processes in place.
• Basically, we're not trying to spend a lot of time hand holding. If you can get through NOSTCO using your ordering processes, the call with TOSTCO should be quick and easy.
• Once the call is done, we can do the several hundred messages on a script if TOTSCO insist on it. It just shows your system can handle messages reliably.

Obviously for this, you'll need to provide us with a test surname, address, account, circuit for a match, and we'll provide you the same. Ideally this is test data only, but if you do check your real customer database, we'll only use what you provide for these tests.