Contact

Talk to an engineer

Describe the problem rather than the solution. If we are not the right people for it, we will say so — and if we can suggest who is, we will do that too.

Before you write

What makes an enquiry useful

A few specific details at the start usually save a round trip and lead to a faster diagnosis.

What the system is

The platform, roughly what it does and how big it is. A URL is the single most useful thing you can give us — we can establish a great deal from a site that is publicly reachable.

What the problem is, as you experience it

The symptom rather than the diagnosis. 'Impressions fell in March and have not recovered' is more useful than a hypothesis, because the hypothesis is usually two layers above the cause and we would rather test it ourselves than inherit it.

What you have already tried

Prior attempts are valuable, including the unsuccessful ones. Knowing that an approach has been ruled out saves repeating it, and the way it failed is often informative.

What it is costing you

The commercial consequence — lost revenue, migration deadlines, an incident pattern. It tells us the priority order, and it is usually the fastest way to communicate how much urgency there is.

Enquiry

Tell us about the problem

About you
The single most useful thing you can give us — a public site tells us a great deal.
About the problem
Symptoms are more useful than diagnoses. What is happening, when it started, what you have already tried, and what it is costing you.
Optional. “Not sure yet” is a perfectly good answer — most problems need diagnosing before they can be scoped, and we would rather have the conversation.

Read by engineers, not added to a sales sequence. You can also email us directly if you prefer not to use the form.

Or contact us directly

Registered office

If this concerns an active outage, include when it started and the current business impact so the enquiry can be prioritised appropriately.

After you send

What to expect

Worth being explicit, because the alternative — a qualifying sequence — is what most people are braced for.

A technical reply, not a sales sequence

Enquiries are read by engineers. You will get a considered response from someone who can discuss the problem, not a sequence of qualifying emails.

A straight answer about fit

If the problem is outside what we do, or if a different kind of supplier would serve you better, we will say that in the first reply. It costs us a project and saves us both time.

No obligation, and no pressure

A scoping conversation is not a commitment. Where a problem needs diagnosis before it can be quoted — which is most of them — we will tell you that rather than inventing a number.

Confidentiality where required

If you need an NDA in place before discussing details, say so in the first message and we will put one in place before the technical conversation rather than after.

Questions

Frequently asked

What happens to what I send you?

It is read by the engineers who would work on the problem, and it is not added to a marketing list. If you send an NDA requirement we will action that before discussing anything technical.

Do I need to know my budget?

No. The budget field is optional and 'Not sure yet' is a valid answer. On a problem that needs diagnosis before it can be scoped, a budget range is not something a client can reasonably be expected to know — and we would rather have the conversation than lose it to a form field.

Will you sign an NDA?

Yes, and several of our engagements operate under one. Where an NDA is needed, put it in place before the technical discussion rather than after — we would rather start under the terms we will be working under.

How soon will I hear back?

Response time depends on urgency and the context provided. If the enquiry concerns an active outage, include when it started and the current business impact so it can be prioritised appropriately.