Figuring out SaaS licencing and SLA's

Overview: Buyers be they B2B or B2C will want to understand you licensing, probably cost, and level of service.  Keep it simple, keep it understandable, make sure you cover what availability, performance, actions users can use you service for are all clearly outlined in you Service Level Agreement (SLA).

Licensing pricing options:  Pay per use one-off, yearly, pay per user monthly or annual, pay per consumption e.g. stripe.  

SLA:

• Availability 99.9 or better is good, it really depends on what you are offering but there are often penalties for missing availability SLA.  If I build a pretty standard SaaS application that utilises App Services, APIM (standard, premium geo loaded has a higher SLA) and Azure SQL, I can't make a 99.9% SLA excluding AAD and any patching, or application caused downtime.  At a SaaS product level providing an actual 99.999% (5 nines) SLA is not as easy as the marketing and legal stakeholders might assume.

It becomes easier to offer 99.9+% SLA's if you as a company assume the risk.  i.e it's unlikely all the downtime will occur and affect you sequentially so offering money back is absolutely possible.  Also most SaaS companies require clients to claim, it is not monitored and automatically applied to your bill.

• Support - phone, bot, email and max time to respond and time to resolve.  
• B2B Monitoring - Good idea to monitor you SaaS provider and not just take their word for it.  Technically, monitor availability of individual services (web sites or API's), it also good to know when items outside of your control (with the SaaS vendor) are unavailable in internal support.  Examples: page load times, login times, you are looking for availability and speed.   How much of the service is down, how much does this affect end customers.   You may want to use a 3rd party tool or write your own as a last resort to monitoring.  When relying on 3rd parties to provide services ensure you do a hazard risk assessment.  Plan for when things happen, how will you respond, adjust.

SaaS Onboarding & Payment collections

SaaS Customer Experience

SLA vs SLO vs SLI:

• SLA (Servcie Level Agreement - contractual agreement SaaS company makes with the customer.
• SLO  (Service Level Objective) - Goal availability (and acceptable performance) of the microservice or application.  Measurement goal.
• SLI (Service Level Indicator) - checks if SLO is achieved.  Actual Measurement.

As part of High Availability and scalability, it is a good idea to know how many instances and how autogrowth is setup, here is an example for Azure App Services.

Scale Out (CPU or Memory) - Matrix Threshold (Avg): 70, Duration:  5 Min, Cool down Time:  5 Min, Increase Count: 1

Scale In   (CPU or Memory) - Matrix Threshold (Avg): 40, Duration: 30 Min, Cool down Time: 10 Min, Decrease Count: 1

Power Apps - MicrosoftTeams.CreateATeam() connector method not working

Problem:  I am provisioning a new team inside my tenant using Power Apps.  The code throws an error and I can't get the TeamId, however, the Team is being created.

Hypothesis:  The call creates the team and using the Monitoring Tool inside Power Apps I can see the call is working.  The issue appears to be when Power Apps reads the response.

Possible Resolutions:  

1. Use Power Automate and fire from the Power App
2. Create a custom Postman Collection using the Teams Graph API