Service model

Initial implementation, ongoing operation and continuing improvement are different kinds of work.

A clear engagement names each responsibility rather than hiding all three behind “managed.” This page explains the model without inventing prices, service levels or ownership clauses.

01 · Initial implementation

Turn an existing foundation into an installation your people can use.

Discovery establishes the records, roles, rules, integrations, migration needs and acceptance examples. Delivery selects standard capabilities, configures the installation and implements only the bespoke differences that matter.

Inputs: Business examples, current systems, approved access, provider decisions and subject-matter review.
Outputs: Configured software, scoped bespoke changes, migration/integration evidence, release identity and operating guides.
Acceptance: Agreed examples work in the selected environment and known exceptions are recorded.

02 · Ongoing operation

Keep the agreed system boundary useful and observable.

Operation can include release management, monitoring, investigation, maintenance and support—but only as stated in the engagement. Client-owned providers, accounts and decisions do not silently become delivery-team obligations.

Incident

Observed behavior is inconsistent with the accepted system. Investigate from logs, records, configuration and release identity.

Operating question

Use the applicable guide and installation-specific notes before treating uncertainty as a defect.

External dependency

Record the provider state and owner; do not promise control over an unbound third party.

03 · Improvement capacity

Reserve a practical path for the next valuable change.

Improvement work is prioritized against capacity agreed for the relationship. A request is framed, classified as configuration/integration/bespoke work, validated, released and documented. “Continual” means a durable capability to change—not unlimited work or an unstated delivery deadline.

Follow a change through the evidence path

What shapes an engagement

Cost and cadence follow the work, not a fabricated tier table.

Initial complexity

Data migration, integrations, bespoke rules, customer channels and acceptance depth affect initial delivery.

Operating boundary

Environments, coverage, monitoring, support channels, provider responsibilities and compliance needs shape ongoing work.

Change capacity

Priority volume, release cadence and the mix of configuration, integration and bespoke engineering shape improvement capacity.

To be approved in a real engagement: fees, term, service windows, response targets, warranties, data/code ownership, provider charges, security obligations and exit provisions.