Service Scope

1. Overview

Why the service is workflow based

FlowOps AI is an operational service, not a general-purpose allocation of prompts, APIs or development hours. Each implementation is organised around an approved business process so the trigger, data, decisions, human controls and expected result are understood before work begins.

An approved scope protects both parties: the client knows what will be operated and supported, while FlowOps can test, monitor and improve a defined process without silently expanding it into unrelated systems or departments.

2. Workflow definition

The contractual operating unit

A workflow is a predefined business process with a clearly defined trigger, input sources, processing steps, approval points, outputs and completion criteria.

Trigger

The event that starts the process.

Input

The approved sources, messages or records used.

Processing

The agreed checks, actions and AI-assisted steps.

Approval

Where a person reviews or authorises an action.

Output

The draft, notification, record or report produced.

Completion

The condition that closes the process or schedules the next step.

Example: lead processing

1. 1Lead received
2. 2AI analysis
3. 3Missing information identified
4. 4Draft prepared
5. 5Human approval
6. 6Google Sheet updated
7. 7Follow-up scheduled

3. Scope classification

New workflow or optimisation?

Optimisation of an existing workflow is included within the package allowance. Expansion of its operating scope is not automatically included.

4. Pilot Framework

A controlled route from discovery to live service

Every pilot is a separate written engagement. It may be paid or discounted, but is not automatically free and does not automatically activate a subscription.

Pilot start

The approved start date after scope, access and controls are ready.

Pilot end

The written end date or agreed completion event.

Approved workflows

The exact processes included in the pilot.

Data sources

The authorised inboxes, forms, registers and systems used.

Users

The named or approved user group and access boundaries.

Success criteria

The measurable operational results used to review the pilot.

Human Review

The points where an authorised person checks or approves output.

Pilot close

Acceptance, findings, unresolved items and final status are recorded.

Live transition

A separate written go-live decision and service agreement are required.

Data retention

Export, retention and deletion steps are agreed for the pilot data.

5. Package boundaries

Detailed package scope

6. Client-specific scope

Client Order Form

Every client receives a written Order Form or Statement of Work defining the approved workflows, integrations, users, usage assumptions, acceptance criteria and exclusions. Where the signed Order Form contains explicit client-specific scope terms, those terms govern that scope subject to applicable law, the Terms and any separate data processing addendum.

The Order Form records the actual workflow limits and project details. A new requirement is added only after an approved written change request or a new proposal. If personal data is processed on the client’s behalf, the parties assess whether a DPA is required before activation. This public Service Scope remains the general operating framework; the signed client-specific agreement records the concrete project.

7. Change control

How requested changes are handled

1. Client submits the requestDescribe the issue, desired result and affected workflow.
2. FlowOps classifies itBug, optimisation or scope extension.
3. Applicable routeA bug is corrected; optimisation uses the package allowance; scope extension receives a proposal.
4. Written approvalMaterial scope, fee or timetable changes are agreed before work starts.
5. Development and verificationThe approved change is implemented, tested and released through the agreed process.

8. Support

Operational help within the approved scope

Support covers questions, incidents and reasonable guidance relating to approved live workflows. It does not automatically include new workflows, integrations, training programmes, data correction, third-party administration or out-of-hours availability.

These are indicative operating targets, not guaranteed service levels. The applicable support hours, timezone and holiday calendar must be confirmed in the Order Form. A signed service level agreement may set different commitments.

9. Responsibilities

A shared implementation duty

10. AI and human review

Business-critical action is not autonomous by default

AI-generated drafts, summaries, classifications, reports, document suggestions and operational recommendations are decision-support outputs. They must be reviewed by an authorised person before external communication, professional reliance, financial action, legal action, clinical action or another business-critical decision where human approval is required by the agreed workflow.

• FlowOps AI does not replace legal, financial, medical, engineering or other professional advice.
• AI output may be inaccurate or incomplete.
• The client is responsible for appointing an appropriate authorised reviewer.
• An automatic external action is permitted only under a separate written scope with approved controls.
• Business-critical action requires human approval by default.

11. External costs

Third-party services are scoped separately

Third-party services and usage charges are not automatically included unless the written proposal expressly says so. This may include OpenAI or other AI-provider usage, Google Workspace, Microsoft services, CRM licences, email delivery, messaging, storage, hosting, portal access, mapping, document processing and other external provider costs.

• Expected costs are disclosed in the proposal where reasonably possible.
• A new paid service requires client approval before it is added.
• A provider price change may require a revised quotation.
• FlowOps does not control third-party pricing, taxes, currency movements or provider fees.
• The client may pay for its own subscriptions directly.
• The proposal identifies which external costs are included and which are excluded.

12. Fair use

Normal business use within the approved scope

The service is designed for normal business use within the approved package, workflows and usage assumptions.

Fair use does not include

• Automated scraping.
• Credential sharing outside the approved users.
• Deliberate attempts to bypass limits or security controls.
• Denial-of-service behaviour.
• Excessive automated requests unrelated to the approved workflow.
• Unusually high processing volumes not disclosed during discovery.
• Bulk use outside the agreed business process.
• Unlawful, harmful or abusive use.
• Use that creates material third-party cost or operational load beyond the agreed scope.

If usage materially exceeds the agreed assumptions

1. FlowOps reviews the activity.
2. The client is contacted.
3. Technical or commercial options are discussed.
4. A revised package, usage allowance or written proposal may be required.
5. An urgent protective restriction may be applied only where necessary to protect security, service availability, third parties or legal compliance.

Fair use is not a hidden penalty or an unlimited unilateral right. It is an operating safeguard tied to the workflows and usage assumptions approved in writing.

13. Early client programme

Founding Partner Pilot Programme

A limited number of early clients may receive reduced pilot setup pricing in exchange for structured feedback and separately agreed permission to use anonymised results. Each pilot has written workflows, controls, duration and success criteria. It does not activate a subscription automatically, and live service requires separate written acceptance.

14. Document hierarchy

Each document has a defined responsibility

• The pricing pages provide a commercial summary.
• The Service Scope describes the general operating boundaries of each package.
• The Terms of Service govern the general contractual relationship.
• The signed Order Form or Statement of Work defines the client-specific workflows, integrations, limits, charges, acceptance criteria and exclusions.
• A separate DPA governs processing matters within its scope.
• An approved Change Request records later scope, fee, control or timetable changes.

Where documents appear inconsistent, mandatory law prevails; a signed DPA governs processing matters within its scope; explicit client-specific terms govern the agreed scope; the Terms govern the general contractual relationship; this Service Scope governs package operations; and the pricing pages remain a commercial summary.