Engagement

How the relationship is structured.

Two shapes, an agreed scope of systems, and a working rhythm. No rate card is published here because a price given before an environment is understood is a guess presented as a commitment.

Two shapes
01The default, and what the company is built around.

Retained capacity

A standing allocation of capacity against an agreed set of systems. Ferrafox operates what is in scope, develops it as the business changes, and is accountable for it continuously. Work is planned in a regular cycle rather than negotiated as a series of separate approvals.

  • Organizations with systems that must keep running and keep changing
  • Estates spread across several suppliers that nobody currently owns end to end
  • Businesses that need technology capability without building the function internally
02Usually a route to the above, not an alternative to it.

Defined project

A scoped piece of work with a defined outcome: an assessment, a migration, a platform build. We take these where the outcome is genuinely bounded. Where a project would deliver something nobody is then responsible for operating, we will say so, because that is how estates end up in the state that brought you here.

  • An assessment of an existing environment before any commitment
  • A discrete build or migration with a clear end state
  • A first engagement, where both sides want to work together once before committing
Getting started

Four stages to a working relationship.

Nothing is proposed, replaced or taken over before the current environment is understood and written down.

01Weeks

Assessment

We map the technology environment as it is: systems, integrations, ownership, risk and cost.

  • Current-state map of the estate
  • Risk and dependency register
  • Where responsibility currently sits
02Weeks

Architecture

A target architecture and a sequence to reach it, costed and prioritised against business need.

  • Target architecture and rationale
  • Sequenced roadmap
  • Recorded decisions and trade-offs
03Months

Transition

We take on the systems in scope, alongside whoever holds them today. Nothing is switched over blind.

  • Documented handover of each system
  • Access, monitoring and pipelines in place
  • Agreed scope of responsibility
04Ongoing

Continuous operation

We operate and continue to develop the environment, with standing capacity for change and regular technical review.

  • Operation of the systems in scope
  • Standing development capacity
  • Scheduled technical review
Included

What a retained engagement carries.

A named team
The same people, engagement to engagement. Context is the expensive part; rotating staff through an account destroys it.
An agreed scope of systems
Written down: what Ferrafox operates, what the client retains, and where the boundary sits. Ambiguity here is where every supplier relationship fails.
A planning cycle
Regular sessions with the people accountable internally, covering what shipped, what the systems are telling us, and what comes next.
Standing capacity for change
Improvements do not need to be re-justified as new projects. That is the difference between a partner and a supplier.
Documentation that survives us
Architecture, decisions and runbooks maintained in the client’s own systems, current enough for someone else to pick up.
Rhythm

What a month looks like.

Continuously
Operation of the systems in scope: monitoring, maintenance, security posture and response to what any of it surfaces.
Each cycle
Development against an agreed plan, released in increments that can be reviewed and reversed.
Each month
A working session with the people accountable internally. What shipped, what the environment is telling us, what changed in the business, what comes next.
Each quarter
A technical review against the architecture: what has drifted, what is accumulating, what should be retired, and what the cost position looks like.
Boundaries

What we will not do.

Being specific about this early saves both parties a selection process.

We do not price undefined scope
A fixed price given before an environment is understood is a guess presented as a commitment, and both parties pay for it later. We would rather scope an assessment first.
We do not take work we cannot operate
If the shape of an engagement means Ferrafox builds something nobody will be responsible for afterwards, we will say so before starting rather than after.
We do not make leaving expensive
Source, infrastructure, domains and tenancy stay in the client’s accounts throughout. Exit is documented at the start of an engagement, not negotiated at the end of one.
We do not publish a service level we have not agreed
Response and availability commitments are set per engagement, against systems whose real requirements we understand. A number on a website is marketing, not a commitment.
Back to the approach
09Contact

Tell us what your organization runs on.

The first conversation is about the environment as it stands today: what exists, what it costs to keep running, and where responsibility currently sits.

Start a conversationcontact@ferrafox.com