OpsPatchOpsPatch
Describe your problem

Operating sequence

How OpsPatch works

Start with the problem

You do not need to decide whether it needs automation, reporting, workflow changes or a larger system. Send us what is happening today.

  • NowWhat is happening now
  • BreakWhere the process breaks
  • OwnerWho uses or owns it
  • SystemsWhich systems are involved
  • InsteadWhat should happen instead

  1. 01

    PROBLEM

    Send what you have

    Short description, screenshots, spreadsheets, exports or URLs.

  2. 02

    REVIEW

    We review the problem

    Where the process breaks, which systems are involved, and what actually needs to change.

  3. 03

    SCOPE

    You get a defined scope

    Deliverables, assumptions, dependencies, price, and what is explicitly outside scope.

  4. 04

    BUILD

    We build and verify

    The fix is implemented against the agreed operating behaviour.

  5. 05

    HANDOVER

    Handover

    Documentation, ownership and support expectations are made explicit.

01

You send what you have

You do not need a specification. Incomplete information is normal. The first job is to understand the problem, not to make you write a technical brief.

A short description

What is going wrong.

Screenshots / examples

An affected record or screen.

Files / exports

Spreadsheet, CSV, report or other useful material.

Systems involved

Shopify, WMS, ERP, CRM, internal tools.

Example problem

Shopify Some orders fail to reach WMS

Current workaround
Manual morning check
Useful evidence
Order ID · affected screenshot · missing WMS record

02

We work out what is actually wrong

Before proposing a build, we separate the symptom from the underlying problem. The aim is not to turn every enquiry into software work.

  • PathWhere the current process starts and ends
  • OwnerWhich system owns which record
  • CopyWhere information is copied manually
  • ExistingWhether an existing tool already solves most of the problem
  • FailureWhere errors can occur
  • StableWhether the process is stable enough to automate
  • SpanWhether the problem is contained or crosses several systems

Sometimes the right answer is configuration. Sometimes it is a smaller automation. Sometimes the process needs to be clarified before anything should be built.

What you get first

Our read

What we think is actually failing.

Our approach

The smallest useful way to solve it.

Initial range

A likely starting range based on what is known so far.

We may also tell you what we would not build. That is part of the job.

03

Fix or Systems?

Not every operational problem needs the same level of intervention. You do not need to choose this yourself.

Fix

Appropriate when the problem is contained.

  • One workflow, limited dependencies, one clear owner
  • Existing systems remain authoritative
  • A defined output and a clear project end

Weekly reporting, lead routing, admin workflow, website enquiry flow, targeted automation, handover cleanup.

Typical Fix scopes

Systems

Starts when the solution becomes part of the operational infrastructure.

  • Several systems exchange records or status
  • Orders, stock, fulfilment or customer state must stay aligned
  • Failures require retries or recovery
  • The integration remains important after launch
Typical Systems scopes
When a fix becomes a systems project
FixSystems
One contained workflowShared operational state
Limited dependenciesMultiple systems
Clear local ownerOwnership across systems
Failure handled inside the workflowRecovery must be coordinated
Defined interventionOperational infrastructure

04

We define the scope before build starts

The scope should make it possible for both sides to answer: what exactly are we building, what is outside the project, and what will count as complete?

  • InputsWhat information or events enter the process.
  • SystemsWhich platforms are involved and what role each one plays.
  • OwnershipWhich system is authoritative for each important record or state.
  • RulesWhat should happen under normal conditions.
  • ExceptionsWhat happens when something fails, is missing, arrives late, or cannot be mapped.
  • OutputsWhat the finished work must produce.
  • HandoverDocumentation, access, ownership and recovery information.
  • AcceptanceHow we know the agreed work is complete.

05

Price follows the agreed scope

The first range is directional. It is not presented as a fixed quote if important dependencies are still unknown. Once the work is understood, scope and price are agreed before build starts.

Commercial process

Initial range

Based on the information available. Used to establish whether the project is commercially sensible.

AGREED SCOPE

The work, dependencies, responsibilities and price are confirmed before build starts.

Scope change

If new systems, dependencies or outputs appear later, they are reviewed before they are added.

No silent expansion. No work quietly drifting beyond what was agreed.

06

We build against the agreed outcome

Build work is organised around the operational outcome, not around producing activity. The principle stays the same: build the smallest thing that solves the operational problem properly.

07 · Failure path

We design the failure path

  1. Event
  2. Validate
  3. Write / update
  4. Success

On failure

Retry, bounded · Queue · Named owner · Manual recovery

Nothing important should fail silently.

08

We review the working output

Does the operational process now work the way we agreed it should? Not: did we finish writing the code?

09

We hand over the work

The people running the process should understand what they own after launch. Handover is part of delivery.

10

The project has a defined end

We do not default to an open-ended retainer. Further work can be scoped separately.

What we do not recommend

  • ReplaceReplacing software that already solves the problem through sensible configuration.
  • UnstableAutomating a workflow that still changes every week.
  • OwnerBuilding before anyone can say which system owns a record.
  • AIAdding AI because it is available, rather than because it has a clear operational job.
  • OpenOpen-ended work where a defined project should close.

What a good project leaves behind

At the end of the work, the important questions should have clear answers.

WHAT RUNS?
The working output.
WHAT OWNS WHAT?
System and process ownership.
WHAT HAPPENS WHEN IT FAILS?
Defined recovery.
WHO CAN CHANGE IT?
Access and responsibility.
HOW IS IT OPERATED?
Documentation and handover.

That is the standard.

Have a problem but not a scope?

You do not need to turn the problem into a project brief before contacting OpsPatch. Send it as it actually looks.

  • What we think is actually wrong
  • The smallest useful way to approach it
  • What we would not build
  • What needs to be clarified
  • The likely initial range
Describe your problem