Operational and Technical Support

  • Updated

In this section of the user guide, we will walk you through all aspects of operational and technical support within io.network. As a principal member there are nine key activities to take into consideration;

  1. Raising an issue or query to io
  2. Receiving / Managing an underlying client’s issue or query
  3. Escalating an underlying client’s issue to io
  4. Reviewing issue / query updates
  5. Invoicing process - Underlying client
  6. Invoicing process - Principal Member
  7. Support FAQs & Training Video Guides
  8. Disaster recovery process
  9. Best practices

Please note – Process documentation will only show the interactions you are either involved in performing or where IO / Underlying clients are interacting with you

6.1 Raising a query or issue to IO

When you are wanting to raise an issue or query directly to IO as a principal member, please following the below process;

 

Process Ref.

Process Step

1 There are two routes for you to raise an issue or query with io;
  1. Visit our website, click contact us in the top right corner and choose from the "Help & Support";
  2. Choose the "Support" button within the io.network web-dashboard.
2 Once chosen, click "submit a request" in the top right corner of the screen
3 Then choose "Principal Member" from the topic dropdown
4 Add your email address and click "you" from the who is facing the issue dropdown
5 Once chosen, complete the rest of the form
6 Once complete, click submit
7 Once submitted, you will receive an acknowledgement confirmation

Please Note - Please add as much detail within the message area and attachments as possible. This will allow us to diagnose the issue or query within requiring any further information

Please Note - Once we receive the form, we will keep you updated through the process via notification

 

6.2 Receiving / Managing a query or issue from the Underlying Clients

How you want to receive and manage your underlying clients’ queries or issues is totally up to you. We advise you to link into your current support network and structure for this element. 

 

Screenshot_2023-04-26_at_2.42.28_PM.png

 

6.3 Escalating an Underlying Clients query or issue to IO

When you are wanting to escalate an issue or query to IO that your underlying client is dealing with, please following the below process;

 

6.3a Process to resolve or escalate

Process Ref.

Process Step

1

There are two routes for you to raise an issue or query with io;

  1. Visit our website, click contact us in the top right corner and choose from the "Help & Support";
  2. Choose the "Support" button within the io.network web-dashboard.
2 Once chosen, click "submit a request" in the top right corner of the screen
3 Then choose "Principal Member" from the topic dropdown
4 Add your email address and click "my client is having an issue" from the who is facing the issue dropdown
5 Once chosen, complete the rest of the form
6 Once complete, click submit
7 Once submitted, you will receive an acknowledgement confirmation
Please Note - Please add as much detail within the message area and attachments as possible. This will allow us to diagnose the issue or query within requiring any further information
Please Note - Once we receive the form, we will keep you updated through the process via notification

 

6.3b Type of issues to resolve or escalate

Responsibilities between IO  & Principal Member

io Escalation Principal Member to resolve
• Technical system issue • General question / query
• Transaction issues on the network or vault • Issues with minting or burning
• Transaction failures • Withdrawing or depositing issues

 

6.4 Reviewing issue / query updates 

When you are wanting to review your open or closed tickets, please following the below process;

 

Process Ref.

Process Step

1 Visit our support webpage, click “existing requests” in the middle of the page
2 If you are not signed in, please sign up with your full name and company email
3

Once logged in, you will be able to see the following:

  • Your requests (raised by you)
  • Requests you are CC'd in
  • Organization requests (raised from your business)
4 To review further ticket information, click onto the ticket to see communications, status, requester, etc.

Please Note - The company email you sign up with must be the same as what you logged when raising an issue ticket.

           - If not, you will not see the support tickets

 

6.5 Invoicing Process - Underlying Client

Below is the documented process across the invoicing end to end journey from io, to you as a principal member and then onto your underlying clients.  

6.5a Invoicing - Procedure

Process Ref. Process Step Owner Duration Aligned SLA
Standard Process
1.1

io.finnet collates all UC's monthly invoices for each PM and share via email

• If the client start during the month, the 1st month will be pro-rata and then all clients are set on the same billing cycle

io.finnet   SLA 1 Start
1.2 Principal member receives monthly invoices for all their underlying clients vault/s Principal Member    
1.3 Principal member deducts billing amount from underlying clients standard accounts

Principal

Member

   
1.4 Share invoice with each individual underlying client

Principal

Member

   
1.5 Underlying client receives monthly invoice for vault/s Underlying Client    
io.finnet payment
1.6 Invoice paid before the 30 day deadline?
  • If Yes - Follow Step 1.6
  • If no - Follow Step 1.7

Principal

Member

   
1.7 Pays io.finnet billable amount into dedicated account upon receipt

Principal Member

  SLA 1 Finish

Invoice Chaser

1.8 Enter invoice chaser process (internal io.finnet process)

io.finnet

   

 

6.5b Invoicing - SLA’s

 

SLA Ref. SLA Description Process Step Start & End Duration Aligned SLA
1 Time taken from io.finnet sharing monthly invoices to principal member, until payment has been received 1.1 - 1.6 30 calendar days

io.finnet & Principal

Member

 

6.6 Invoicing Process - Principal Member

Below is the documented process across the invoicing end to end journey from io, to you as a principal member and then onto your underlying clients.  

 

6.6a Invoicing Procedure

Process Ref. Process Step Owner Duration Aligned SLA

Standard Process

1.1

lo.finnet collates quarterly invoices for each principal member and share via email

• If the client start during the month, the invoice will be pro-rata

io.finnet   SLA 1 Start
1.2 PM receives quarterly invoices for io.network

Principal

Member

   
1.3 30 days deadline starts          

Principal

Member

   

io.finnet payment

1.4

Invoice paid before the 30 day deadline?

  • If Yes - Follow Step 1.5
  • If no - Follow Step 1.6

io.finnet

   
1.5

Pays io.finnet billable amount into dedicated account upon receipt

Principal

Member

  SLA 1 Finish
Invoice Chaser
1.6

Enter invoice chaser process  (internal io.finnet process)

io.finnet    

 

6.6b Invoicing SLA’s

SLA Ref. SLA Description Process Step Start & End Duration Aligned SLA
1 Time taken from io.finnet sharing monthly invoices to principal member, until payment has been received 1.1 - 1.5 30 calendar days

io.finnet & Principal

Member

 

6.7 Support FAQs and Training Video Guides

  1. For all io.network and io.vault FAQ’s please use the following link - Online FAQ’s
  2. For io.network and io.vault training videos please use the following link - Training Videos

Please note - you must be logged in to see the io.network / io.vault FAQs and user guides. It is very easy to sign up or login with your full name and company email

6.8 io.vault Disaster Recovery Process

6.8a Background

io.vault implements a backup and recovery process for each vault in an organization. The recovery process uses a unique 24-word phrase for each signing device (generated upon initial sign-in on every new device) to encrypt copies of the secret shares that are held locally on the device. 

When initially creating a vault, consideration should be made in balancing security vs redundancy in the number of shares and signers for a vault. 

 

There are two routes;

  • If a users’ signing device is lost / misplaced and there are enough available shares to reach the vault threshold using other devices, then a reshare request can be created to issue new shares to a new user device;
  • If there are not enough shares available, the disaster recovery process will be necessary.

6.8b Responsibility

Each user is responsible for downloading and storing an up-to-date encrypted device back-up file and for the safe-keeping of their 24-word secret phrase in an offline and physically secure location (advice is for this location to be cloud based).

 

6.8c Process to recover access

Process Ref.

Process Step

1 Members of the signing party with devices containing enough secret shares to reach the vault threshold must obtain their corresponding up-to-date encrypted back-up files and device specific 24-word secret phrases
2 The organization should then use a publicly available, open-source script published on github on a secure offline computer to generate, for the first time, a valid private key for the desired vault
3 Follow step by step guide direction from github

Please Note - This process must be used when funds cannot be withdrawn from a vault due to the inability to generate a signed transaction. This can occur for example, by a critical software malfunction, a malicious DDOS attack, a permanent service shutdown, or a critical loss of user secret shares.

 

6.9 io.network - Operational Best Practices

Below are some best practices we strongly recommend all users and clients using the io.network and io.vault products to implement;

Business Area

Best Practise Detail

Test Transactions

Always perform two test transactions when creating a new vault:

  • First, verify that the deposit address displayed is valid by making a test deposit and confirming receipt;

  • Finally, ownership of the vault and underlying public addresses should be verified by performing a test withdrawal.

Redundancy of Users/devices 

Create vaults with redundancy of users and their devices in mind to avoid requiring implementation of the disaster recovery process for instances of a single user losing a signing device

Backing up Devices

Ensure all users are consistently and frequently backing up their device to the cloud

At a minimum, each user device should be backed up each time it participates in creation of a new vault or a vault re-share as these processes result in new shares being created locally on the devices

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.