Kelex Group Limited

BRING US A PROBLEM

Start with the need you can describe—not a finished specification.

Use this intake to describe an operational problem, a website or web-system requirement, or a situation that is still becoming clear.

You do not need a complete specification. We need enough context to understand what is known, what is uncertain and what the next useful decision should be.

NEED → CONTEXT → ACCESS → DECISION

See what may fit Kelex

Intake Brief Structure

  1. CURRENT CONTEXT
  2. THE NEED
  3. PEOPLE INVOLVED
  4. DESIRED OUTCOME
  5. AVAILABLE ACCESS
  6. NEXT STEP
A conceptual structure for an intake brief: current context, need, people involved, available access and a useful next step.

BEFORE YOU BEGIN

A useful brief explains the need without requiring every answer.

You may be bringing a recurring operational failure, a clear website requirement, a more complex web system, or a situation that is still uncertain. Focus on what is happening now and what the work needs to achieve.

  • You do not need a complete specification.
  • Give enough context to understand the need.
  • Clear and uncertain starting points are both acceptable.
  • Do not submit passwords, credentials or regulated personal data.

Do not include passwords, private access credentials, regulated personal data or information you are not authorised to share.

Intake

Your draft remains available while this page stays open. Refreshing or leaving the page may clear it.

Online delivery is still being connected. You can prepare and review the complete brief on this page without losing the information during the current session.

1. About you

Provide enough information for us to understand who is bringing the opportunity.

Required
Required

Use an address where you can receive a response about this brief.

Optional

Leave this blank when you are bringing this independently.

Required
Required
2. Starting point

Tell us what kind of situation you are bringing so we ask the right questions.

What are you bringing us?

You do not need a complete specification. Give us enough context to understand what is known, what is uncertain and what the work needs to achieve.

A straightforward need can remain straightforward. We do not add complexity simply because we can.

3. Current context

Describe what is happening today before describing a preferred solution.

Required

A short working title is enough.

Required

Describe the current situation, existing website, workflow or environment we should understand.

0 / 1500

Required
Optional

Leave this blank when nothing relevant currently exists.

5. Access and decision authority

Indicate what may be available for a credible investigation.

What access may be available?

Required — select at least one

Required

0 / 1200

Required

Describe the person, role or group rather than providing private contact details.

Required
6. Context and next step

Share constraints, prior attempts and what would be useful next.

Optional

Describe previous process changes, tools, software, websites or workarounds and what happened.

Optional

Optional. We can consider it without assuming it is the right answer.

Optional

This may include timing, existing systems, internal approvals, access or operational boundaries. Do not include confidential legal advice or regulated personal information.

Required
Optional

Submitting this brief does not guarantee that we will investigate or build a system.

AFTER THE BRIEF

A brief begins a review—not a commitment to build.

When delivery is connected, we first determine what is already clear, what still needs investigation and what next step is justified.

CLARIFY
We may request additional context about the need, access or decision authority.
DISCUSS
A conversation may be useful when the need appears credible but requires deeper understanding.
DECLINE
The request may not fit our current operating approach, capability or stage.
INVESTIGATE OR DEFINE
A defined investigation or build path may be considered when the need, access and decision path are sufficiently credible.

INFORMATION BOUNDARY

Share enough to explain the need—not protected information.

The first brief should describe the work, website or system without including private credentials, regulated personal data, confidential client records or information you are not authorised to disclose.

  • Do not submit passwords or access keys.
  • Do not submit banking or payment credentials.
  • Do not submit confidential customer records.
  • Do not submit medical, biometric or government-identification data.
  • Do not submit private legal documents or privileged advice.
  • Do not upload files during this phase.

Access can be discussed later when the investigation, authority and information boundaries are clearer.

Bringing capability rather than a project need?

Use the collaboration route when you can contribute research, technical capability, domain knowledge, operational access or a credible path to implementation—not when you need us to investigate or build something.

Propose a collaboration