Readiness brief

Answers in progress on this browser have been restored.

No field on this form is mandatory. Complete what you know and skip what you do not. Each answer makes the pack more specific: a full brief produces a plan your customer can act on, while an empty one produces a plan full of Missing rows.

Choose your pack

One per request

Pick the one that matches what is uncertain. Both cost the same, so nothing pushes you towards the lighter one.

A proof of concept costs your customer time and access. Where a demonstration can answer the question, the Demo pack is the right one. If your brief picks the other, we will say so before we draft, and the choice stays yours.

This step names the parties. The team buying the pack and the customer being sold to are kept distinct throughout, because it decides what may appear in which file. The internal charter carries what your team needs. The customer charter carries what you would be content for them to read in front of you.

Who is asking

All fields optional

Your name and role Who we reply to. Example: Priya Raman, Principal Sales Engineer

Your organisation The team buying the pack. Example: Northwind Systems

Your email Where we acknowledge the request and confirm the delivery date. Example: priya.raman@northwind.example

Evaluating customer The organisation you are selling to, as they write it. This name appears on the customer charter. Example: Acme Corp

The details

All fields optional

Request title A stable working name for this case. Example: Acme Corp: storage platform evaluation

The customer problem What is wrong today, and what it costs them.

Intended outcome What good looks like for the customer if this works.

Proposed solution boundary What the evaluation covers, and what it deliberately does not.

The decision this unlocks What your customer needs to decide next. Example: whether to fund a paid pilot

Decision date Leave blank if it is a trigger rather than a date.

Or the trigger Example: after the board's Q4 budget review

What comes back

A Readiness pack returns an internal charter for your team, a customer charter for you to share, and a working workbook. Both charters are delivered finished, and the workbook is locked except for the cells your team fills in. All 3 are generated from one record, so the identifiers, scope, criteria, responsibilities, dates, evidence, and decisions agree across them.

Every pack also reports where the evaluation stands against 5 checkpoints, and whether it can produce a decision yet. Most first packs come back Not ready, and that is the finding: it names what has to happen before your customer's time is spent.

This step shapes the pack. What you send us shows the situation. It does not show who has to be convinced, what they believe today, or what would settle the argument. Sharp answers here produce a plan your customer can act on. Anything you leave blank is recorded as Missing, with what it prevents and who has to resolve it, so a gap is never invented over.

The brief: demonstration

All questions optional

Q1 What does this demonstration have to achieve? The decision it is meant to unlock, not the features it shows. Example: Get the CTO to fund a 6-week paid pilot. They have seen a competitor demo and believe our ingestion is slower.

Q2 Who is in the room, and what does each of them need to see? Roles are enough. A role with no named person is recorded as Proposed, with the action which would name one. Example: CTO, needs to see failover working. Head of Ops, needs to see it without a console. Procurement lead, attending, needs nothing shown.

Q3 What scenario will you run, and whose day does it describe? The journey through the product, in the customer's own words for their own work. Example: A night-shift operator gets a storage alert at 02:00 and has to decide whether to escalate.

Q4 What will the audience actually see happen? Written so a participant could confirm it afterwards. A capability which cannot be observed in the session does not belong in it. Example: The alert appears within 5 seconds of the fault, and the operator resolves it in 3 clicks without opening a terminal.

Q5 What environment and data will you have? And whether the data is representative enough to carry the argument. Synthetic data which nobody recognises loses the room. Example: Shared sandbox, refreshed weekly. Sample data is generic and does not use their asset names.

Q6 Who is presenting, and who else is on your side of the table? Including anyone who has to be available and is not in the room. Example: One presenter from your team, with the solution architect on standby for integration questions, not yet confirmed.

Q7 What do you show if something fails while they are watching? The environment, the data, or an integration. A session with no fallback ends in an apology. Example: A recorded run of the same scenario, and the architect walks the sequence live.

The brief: proof of concept

All questions optional

Q1 What question does this evaluation answer? And what a demonstration could not settle, which is why it costs your customer time and access. Example: Whether ingestion holds 40,000 events a second on their own event mix, which no demo environment can show.

Q2 What has to be true for them to say yes? Each criterion with what is measured, the target, and where the target came from. A target with no basis is a number somebody chose. Example: Sustained 40,000 events a second, because that is their Black Friday peak plus 20 per cent, from their own capacity plan.

Q3 What is today's number, and who has it? What each target is relative to. Where no baseline exists, establishing one becomes the first milestone and needs an owner. Example: Nobody has measured current throughput. Their platform lead would have to, and has not agreed to.

Q4 How is each criterion measured, and what makes a run count? Method, tooling, who runs it, and the conditions which make a result representative. A result from the wrong conditions settles nothing. Example: Their own load harness, 4-hour run, production event mix, on the cluster size they would actually buy.

Q5 What will be captured, and by whom? Evidence nobody agreed to capture is evidence nobody will have when the decision is made. Example: Harness output and dashboard exports, captured by their platform engineer, countersigned by our architect.

Q6 What has to happen, in what order, and what has to be in place first? Milestones with owners and dates or triggers, and the prerequisites which block each one. Example: Network access by the 20th, owned by their security lead, blocks everything. Cluster build follows.

Q7 What would stop this, and who is allowed to stop it? An evaluation with no stop condition runs until somebody loses patience. Example: If access is not granted by the 20th we pause rather than compress the test window. Their sponsor or ours may call it.

Q8 Who accepts the result, and on what evidence? The person who decides, not the team they sit in. A decision owned by a function is owned by nobody. Example: Their CTO, on the harness output and a joint readout. No date agreed.

Material and constraints

All questions optional

Supporting materials What you will attach, and its version. List it rather than pasting it, and do not paste confidential content into this page. Example: Discovery notes v3, their RFP section 4, our reference architecture.

Data, environment, access, and integration constraints What is genuinely available, not what you would like to be. These become prerequisites with owners in the pack. Example: No production data may leave their estate. VPN access takes 10 working days.

Known risks and dependencies Anything you already expect to go wrong, and anything you are waiting on somebody else for. Example: Their security review has not started. Our architect is on leave from the 24th.

Confidentiality or handling notes Anything restricting how the material may be used, including a non-disclosure agreement between you and your customer. Example: Under mutual NDA. Their name may appear in the pack but not in any example.

Desired delivery date Standard delivers by 18:00 UK time on the 2nd working day after receipt. Same day is available before 12:00 UK time, Monday to Friday. Example: before the steering call on the 18th

Anything else

Optional

Anything else which would help Where the deal stands, what your customer has already seen, the objection you expect, or the part of this you are least sure about. Example: They ran a PoC with a competitor last year which overran and was abandoned. Nobody wants to say so out loud.

Send

To
Subject
You attach
You pay
Brief

Browsers cannot attach files for you. Downloading the brief and opening the email are 2 separate steps, with the payment between them. You attach both yourself before sending.

Download the brief. Your browser saves a .md summary of everything entered here, with a request reference.
Pay at Stripe, standard or same day. The reference goes with the payment, and Stripe brings you back here.
Open the email once you are back. It opens pre-addressed, with the reference and the payment written in.
Attach the .md file and your supporting material, and send. We cannot start without the brief. The return date is confirmed on acknowledgement.

Where your answers go. Nothing you type reaches Apex Edge Sales Engineering until you send the email yourself. Stripe, which takes the payment, receives the request reference and the email address you gave, and none of your other answers. This page stores your answers in this browser only, and clears them when you open the email or select Clear form, keeping them again only if you download a corrected brief.

Readiness brief

Choose your pack

Who is asking

The details

What comes back

The brief: demonstration

The brief: proof of concept

Material and constraints

Anything else

Send

Clear the form and start again?

Brief downloaded. Now choose your speed.