When SaaS is enough, and when forward-deployed work is different

Companies often discuss AI modernisation as a tooling decision.

The harder decision is what kind of change the organisation needs.

A standard workflow may need a well-designed SaaS product. Existing systems may need reliable operation from a managed service provider. A defined experience or integration may need an agency. An uncertain organisational problem may need consulting. A cross-system operating problem may need a platform and a team working close to the business.

These routes can overlap, but they are not substitutes. Each makes a different promise about standardisation, ownership, implementation, and what remains after the engagement.

Begin with the problem, not the vendor category

The same request can conceal several different needs.

“We need better supplier visibility” might mean:

• standardise supplier records in an existing procurement product;
• clean and reconcile supplier identities across finance and logistics systems;
• redesign qualification ownership and approval;
• build a comparison interface for one buying team;
• connect evidence, decisions, and next actions across several systems;
• provide ongoing operational support for the resulting workflow.

Each version points to a different delivery model.

The choice becomes clearer when the organisation can answer:

• Is the workflow standard across many companies or specific to this business?
• Does one existing product category already own the process?
• Is the main problem software access, operational reliability, specialist execution, organisational diagnosis, or a connected operating model?
• How fragmented and inconsistent is the data?
• Which teams and decisions cross system boundaries?
• Who will own the workflow after implementation?
• Is the desired result a recommendation, a deliverable, an operating service, or durable software?

The route should follow those answers.

SaaS is strong when standardisation creates value

The National Institute of Standards and Technology defines Software as a Service as access to provider applications running on cloud infrastructure, with the provider managing the underlying infrastructure and the customer having limited control over it ^{1NIST SP 800-145, The NIST Definition of Cloud Computing}.

That arrangement is valuable. The customer receives a maintained product, a repeatable operating model, upgrades, documentation, and a roadmap without building the underlying software.

SaaS is usually the right choice when:

• the workflow is common and well understood;
• the product's data model fits the business closely enough;
• standardisation is more valuable than preserving local variation;
• integrations are available and stable;
• the organisation is willing to adopt the product's operating assumptions;
• implementation speed and maintainability matter more than exact workflow fit.

Payroll, accounting, email, ticketing, document management, CRM, project tracking, and many other functional workflows benefit from this model.

The tradeoff is not that SaaS is generic or inflexible. Mature products can be highly configurable. The tradeoff is that the product still needs a stable model that works across many customers. When the business outcome depends on relationships the product does not represent, users either adapt the work, create workarounds, or add another layer.

Managed services solve an operating-ownership problem

A managed service provider takes ongoing responsibility for an agreed service. The work may include infrastructure, security operations, support, monitoring, administration, backup, compliance support, or operation of particular applications.

This model is useful when the organisation needs reliable coverage, specialist capacity, or defined service levels more than a new operating model.

Managed services are usually a good fit when:

• the systems and responsibilities are already understood;
• the main need is continuous operation and support;
• the organisation wants external capacity under a clear service boundary;
• performance can be described through incidents, availability, response, controls, or service levels.

The limitation appears when the underlying workflow itself is the problem. Keeping several systems operational does not necessarily reconcile their data, redesign the decision, or make cross-system context easier for users.

Agencies are strong around defined outputs

Agencies organise specialist craft around a brief. The output may be a site, interface, prototype, automation, integration, content system, campaign, or digital service.

This is a strong model when the organisation can define the result and needs specialist execution to deliver it.

Agency work is usually a good fit when:

• the desired artifact or experience is clear;
• the project can be bounded;
• the client can provide decisions and feedback;
• long-term ownership and maintenance are agreed;
• success can be evaluated against the brief.

The tradeoff is continuity. A successful deliverable may still depend on the client's data model, permissions, operational ownership, and integration architecture. If those foundations are outside the brief, the artifact can be well executed without changing the underlying operating problem.

Consultants help when the problem is not yet clear

Consulting is valuable when leaders need diagnosis, strategy, process design, governance, procurement support, programme management, or organisational alignment.

The organisation may not yet know which workflow matters, why an initiative is failing, how decision rights should change, or what should be built. Advice, facilitation, analysis, and change leadership can be the right first intervention.

Consulting is usually a good fit when:

• the problem needs framing before implementation;
• several stakeholders need alignment;
• operating or governance choices remain open;
• the organisation needs independent expertise;
• a roadmap or decision is the intended output.

The tradeoff is the transition from advice to operation. Recommendations create value only when the organisation can translate them into owned processes, data changes, interfaces, controls, training, and working systems.

A platform provides reusable foundations

A platform is a system-building layer rather than one fixed workflow.

It can provide reusable capabilities for:

• identity and access;
• connectors and approved-source indexing;
• data models and ontologies;
• provenance and audit;
• retrieval and search;
• workflow states and queues;
• interface components;
• automation and controlled write paths;
• review, approval, and escalation.

The value of a platform is composition. A new workflow does not need to rebuild authentication, permissions, provenance, deployment, and control from the beginning.

A platform becomes relevant when several workflows share foundations but cannot be reduced to one standard application category. The platform does not remove the need to understand the business. It provides the reusable structure through which that understanding can become software.

Forward-deployed work starts close to the operation

Forward-deployed work combines a platform or technical foundation with people who learn from the operating environment and shape the implementation with users.

The important distinction is not the job title. It is the feedback loop.

The team begins with a business outcome, observes how the work happens, audits the approved data, maps authority and exceptions, builds the connected model, tests an interface or workflow with real users, and refines it from corrections.

This model is useful when:

• the workflow carries the organisation's own operating language and judgment;
• relevant data is fragmented or inconsistent across systems;
• the decision crosses teams and sources;
• edge cases are material to the outcome;
• users need role-specific interfaces;
• adoption requires changes to habits, review, and ownership;
• the implementation should become durable software rather than remain a series of manual interventions.

The forward-deployed model is not justified merely because a workflow is complicated. Some complexity should be removed. Some local variation should be standardised. Some problems are better solved by configuring an existing product.

It becomes justified when understanding and representing the specific operation is part of the product value.

Why AI increases the need for operating fit

Traditional automation works best when the state and next step are known. IBM describes workflow automation as using software to execute part or all of a process ^{2IBM, What is workflow automation?}.

AI can help with less structured work, but it still needs operating context:

• which customer, order, supplier, project, asset, or case is involved;
• which source is authoritative;
• which evidence is current;
• what uncertainty or conflict remains;
• who owns the decision;
• what the system may read, prepare, update, or send;
• when human review is required.

Anthropic's guidance distinguishes predefined workflows from agents that choose more of their own process, and recommends using the simplest effective pattern before adding autonomy ^{3Anthropic, Building effective agents}.

That principle changes implementation. Before adding an agent, the organisation may need to audit and reconcile data, define a business ontology, design narrow tools, establish review paths, and train users. A generic interface cannot supply missing authority or resolve conflicting product identity by itself.

The operating model around the AI is therefore part of the system, not a service wrapped around a finished model.

The engagement should leave durable capability

Forward-deployed work can fail by becoming bespoke work without a stable foundation.

Warning signs include:

• every client request becomes a separate code path;
• important logic remains in one consultant's memory;
• data mappings have no owner or provenance;
• the client cannot understand how the workflow works;
• user corrections do not improve the system;
• the implementation relies indefinitely on manual intervention;
• the vendor and client have unclear responsibility for operation and change.

A healthy engagement separates reusable foundations from specific operating design.

Reusable foundations may include access control, connectors, indexing, provenance, workflow primitives, audit, interface components, and deployment infrastructure.

Specific design may include the client's business outcome, ontology, source mappings, state definitions, permissions, exception rules, operating cadence, user interface, and training.

The client-specific work should make the platform more capable without pretending every organisation uses the same terminology or process.

Compare what each model leaves behind

The categories are easier to compare by their durable output:

Real engagements can combine these models. A company may use SaaS systems of record, an MSP for infrastructure, consultants for governance, an agency for a customer experience, and a forward-deployed platform for a cross-system operating workflow.

The useful question is which model owns each outcome and handoff.

Cost structure follows the kind of work

These routes have different commercial structures because the customer is buying different things.

SaaS commonly charges for access or usage. Managed services commonly charge for continuing coverage and service levels. Agency and consulting work is often scoped around deliverables, time, or programme responsibility.

A forward-deployed engagement may include:

• paid discovery or setup;
• scoped implementation or embedded engineering;
• ongoing managed support and improvement;
• third-party AI, cloud, licence, or transaction costs where applicable.

Exact pricing follows scoping because integrations, data condition, security, user acceptance testing, workflow complexity, and support needs change the work materially.

This does not make the commercial model unknowable. It means the scope should connect cost to a defined business outcome, implementation boundary, responsibilities, and success criteria instead of using a generic public figure that conceals the actual work.

How to choose

Choose SaaS when the workflow is standard and adopting the product model creates more value than preserving local variation.

Choose a managed service when the main problem is reliable operation and coverage.

Choose an agency when the output is defined and specialist execution is the constraint.

Choose consulting when diagnosis, alignment, governance, or change design needs to come before implementation.

Choose a platform when several systems or workflows need reusable technical and governance foundations.

Consider forward-deployed work when the business outcome depends on specific data, cross-system relationships, domain language, edge cases, role-specific interfaces, and continuing adoption.

Whichever route is chosen, governance remains an operating responsibility. NIST's AI Risk Management Framework treats risk as contextual and managed across the lifecycle, while ISO/IEC 42001 describes a continuing management system for responsible AI use (NIST AI RMF).

The buying decision is not a hierarchy from simple to sophisticated. It is a question of fit. The strongest option is the least elaborate model that can achieve the outcome and leave the organisation able to operate what comes next.

Sources

1. NIST SP 800-145, The NIST Definition of Cloud Computing
2. IBM, What is workflow automation?
3. Anthropic, Building effective agents
4. NIST AI Risk Management Framework
5. ISO/IEC 42001 AI management systems