SaaS, or Software as a Service, is a delivery model in which a provider operates an application and customers access its capabilities over a network. Customers typically use a browser, mobile application, desktop client, or API without managing the underlying application infrastructure.
Consider a company adopting a hosted customer-support platform. Employees can create queues, assign tickets, and reply to customers without installing the service’s database or deploying its application servers.
That changes the company’s operational responsibilities. It still needs to decide who can access customer information, how tickets enter the system, how records are retained, and what happens when the service is unavailable.
SaaS moves a substantial part of operating software to a provider while leaving the organisation responsible for its own use of the service.
The Provider Operates a Service, Not Just an Installation Package
The provider runs the application and maintains the infrastructure and software layers behind it. Customers configure the capabilities the product exposes rather than administering its complete implementation.
The NIST definition of cloud computing distinguishes SaaS from infrastructure and platform service models. The distinction concerns the capability supplied and the level of control retained by the customer.
| Model | Typical customer responsibility |
|---|---|
| Infrastructure as a Service | Operate applications and operating systems on supplied infrastructure |
| Platform as a Service | Develop and operate applications using a managed application platform |
| Software as a Service | Configure and use a provider-operated application |
These are broad boundaries. Individual services and contracts divide responsibilities differently.
A monthly subscription alone does not make software SaaS. Installed software can also be sold by subscription. SaaS describes delivery and operation; subscription describes one way to charge for it.
Access and Tenant Isolation Are Part of the Service
In the support-platform example, the company has an organisational account, users, roles, and customer records. The provider must ensure that those records remain appropriately separated from other customers’ information.
Many SaaS products use multi-tenant designs, sharing some infrastructure or application components across customers. Others use more isolated deployment arrangements. A customer does not need to infer the exact design from the product’s pricing page.
AWS’s SaaS overview describes hosted applications, common tenant arrangements, and subscription or usage-based delivery. The architecture may vary while the provider remains responsible for operating the service.
The customer still configures its own access. A well-isolated platform can expose information if an administrator grants excessive privileges or creates an overly broad sharing rule. User provisioning, offboarding, service accounts, and permission review remain operational work.
Fast Adoption Still Requires Integration
A support team may be able to create an account immediately. Making the platform part of normal work takes longer.
Incoming email must reach the right queue. Customer identifiers must match the sales system. Historical records may need importing, and automated notifications must reflect the company’s actual process.
- Customer requestA customer initiates an interaction with the service.
- Identity and routingEstablish access and send the request to the appropriate workflow.
- SaaS support platformProcess the request through the hosted application.
- Staff and connected systemsCarry out the work required to resolve the request.
- Customer outcome and recordsRetain the result and the records needed to explain it.
Every connection introduces assumptions about identifiers, permissions, timing, and failure handling. If the customer database is temporarily unavailable, the support team needs to know whether work can continue and how missing information will be reconciled later.
SaaS reduces the need to operate the application’s internals. It does not remove the need to operate the workflow around it.
Updates Transfer Control as Well as Work
Provider-managed updates can reduce the effort of patching and maintaining software. They can also change interfaces, available features, administrative settings, and integration behaviour.
An organisation should understand the service’s change process, especially where it depends on APIs or extensive configuration. Useful provisions may include release notices, versioning policies, a test environment, and a clear route for reporting regressions.
The appropriate level of preparation depends on the consequence of disruption. A change to an optional reporting view differs from a change to the workflow receiving urgent customer requests.
Configuration also evolves over time. New queues, automation rules, and permissions can become difficult to understand without ownership and documentation. The need for evolutive maintenance continues, even when much of the application code belongs to a supplier.
Price the Workflow, Not Only the Seat
SaaS may be priced by user, usage, storage, transaction, feature tier, or a combination. The visible subscription is only part of the adoption cost.
For the support platform, include implementation, migration, integration, administrator time, training, and any required add-ons. Examine how cost changes if the team grows, retains more data, or enables additional automation.
The same applies to capacity. Adding users may be straightforward, but API quotas, processing limits, or contractual restrictions can still constrain the complete workflow.
A useful evaluation compares realistic operating scenarios. A low initial bill provides little guidance if the expected workload requires a different tier.
Recovery and Exit Need Specific Answers
Availability commitments describe part of the service relationship. They do not replace a continuity plan for the business process.
Ask what remains possible during an outage and how the organisation will reconcile work completed elsewhere. Also distinguish provider disaster recovery from recovery of a customer’s accidental deletion or configuration mistake. Those capabilities may have different limits.
Before adoption, inspect an export of representative records. Does it include attachments, relationships, and the history needed to interpret the data? Can another system use it?
These questions connect SaaS to digital sovereignty and supplier dependency. Owning data is more useful when the organisation can retrieve and interpret it within the time available.
SaaS Changes Where Operational Effort Sits
A strong SaaS fit lets an organisation use an application without reproducing the provider’s operating capability. That can free attention for the work the software supports.
The arrangement remains a managed dependency. Access, configuration, connected systems, costs, continuity, and supplier changes need identifiable owners.
The useful evaluation is therefore broader than whether the application has the desired features. It asks whether the organisation can operate its workflow reliably within the service’s capabilities and constraints.
Key Takeaways
- SaaS provides access to a provider-operated application; subscription is only a pricing model.
- Customers retain responsibilities for access, configuration, integrations, and use of their data.
- Adoption costs and capacity limits extend beyond the advertised seat price.
- Assess recovery, data export, and supplier change processes before the service becomes critical.
