Presales and solutioning fundamentals

They convert a customer's business problem into a technical answer that can be believed, priced and delivered, before any money has changed hands. In practice that is four things: running the technical half of discovery, shaping a solution that fits the customer's constraints rather than the ideal one, sizing and defending an estimate that delivery will have to live inside, and being the person in the room whose technical statements the customer treats as true. The deliverable is not a diagram, it is credibility — a buyer who believes the approach and a delivery organisation that believes the number. The cost of the role is that you are measured on a commercial outcome you only partly control, and the temptation that comes with it is to win by promising, which is the single behaviour the role exists to resist.

The presales architect optimises for a decision, the delivery architect for an outcome, and that changes almost everything downstream. Presales works with twenty per cent of the information, on a deadline set by the customer's procurement calendar, and produces artefacts intended to persuade as well as to be correct; delivery works with the real system, discovers that assumption six was wrong, and lives with it for two years. Presales is rewarded for breadth and for speed of judgement — being roughly right about eleven things quickly — while delivery is rewarded for depth and for being exactly right about the thing in front of them. The failure mode of each is instructive: a presales architect who never delivers drifts into optimism nobody corrects, and a delivery architect doing presales over-designs and prices the deal out of contention.

Candidates describe presales as "supporting sales", which tells an interviewer nothing about when they are pulled in or what they own at each point.

flowchart TD
    A[Lead qualified by sales<br/>architect not involved yet] --> B[Discovery workshops<br/>architect leads the technical thread]
    B --> C[Solution shaping and sizing<br/>architect owns design and estimate]
    C --> D{Bid or no bid<br/>reviewed with the deal board}
    D -->|no bid| E[Withdraw with a reason recorded<br/>relationship kept]
    D -->|bid| F[Proposal, demo and POC<br/>architect defends the design]
    F --> G[Negotiation and redlines<br/>architect prices every change]
    G --> H[Signature and handover<br/>architect briefs delivery]

The first box is the one worth arguing about. Sales qualifies the lead commercially and often calls the architect in only when a demo is needed, by which point the customer has already been told what the solution looks like and your job has quietly become ratifying it. The stronger arrangement is technical involvement from the first discovery conversation, and the argument that wins it internally is not fairness but rework: late involvement is where unpriceable commitments get made.

The bid or no-bid gate is the stage most candidates omit entirely, and its absence is what produces the pathology of a team that pursues everything. It is also the one stage where the architect's opinion should be able to stop the deal, because the technical feasibility judgement is not one the sales lead can make.

The negotiation stage is where deals are actually lost after being won. Scope moves in procurement — a must-have appears, a date shortens, a rate card is squeezed — and if the architect is not present, each change is accepted without being repriced. The discipline is that every redline goes back through the estimate, even when the answer is that it costs nothing.

Handover is the last box because it is treated as the last box, which is the problem. The architect who signs the promise should be accountable to the team inheriting it for at least the first month, and being able to say so unprompted separates a presales candidate from a demo operator.

In the gap between what will win this quarter and what will be deliverable next year, and it is structural rather than personal. The sales lead is compensated on signed revenue in a period, so a commitment that creates trouble in month eight is nearly free to them and expensive to you; you are the person whose name is on the technical claim and who will be quoted back in a delivery review. It shows up as pressure to say yes to a roadmap item, to soften an assumption, to remove a caveat that "makes us look weak", or to shave a number to hit a price point. The functional relationship handles this by separating roles explicitly: the sales lead owns the commercial position and the customer relationship, the architect owns what is technically true, and neither overrules the other in front of the customer.

The solution architect, and the answer matters because the ownership is usually left ambiguous until something goes wrong. Ambiguity here has a predictable resolution — when a delivery review asks who committed to a three-month migration, the sales lead points at the solution document and the architect's name is on it. So the practical stance is that no technical statement leaves the building unless you would defend it in a delivery post-mortem, and anything you are unsure of becomes an assumption with a condition attached rather than a softened sentence. The corollary is authority: if you own the promise you need the right to refuse a claim, and a presales function without that right is a proposal-writing service that will be blamed for outcomes it could not shape.

Visibility, and specifically a named delivery representative who has read the estimate and the assumptions before anyone signs. What you owe them concretely is the sizing basis rather than the total, the assumptions the number depends on, the risks you accepted knowingly, and an honest statement of what was not investigated. The reason to do it before signature rather than after is that afterwards it is information and beforehand it is a veto — delivery can say the integration effort is understated while the price is still movable. The cost is real: involving delivery slows the bid and sometimes raises the number out of contention. The alternative cost is worse, because a team handed a deal they consider unwinnable delivers it as though it were unwinnable.

By replacing refusal with pricing, because "no" makes you the obstacle and a price makes it a decision. The move is to convert each demanded yes into a conditional one — yes, with these two assumptions, at this cost, delivered in phase two — so the sales lead can still take something positive to the customer and the commitment stays bounded. Where the request is genuinely impossible, say so once, in writing, in plain language, with the reason, and offer the nearest thing that is true. What settles the pattern over time is being right in public: an architect whose caveats turn out to have mattered gets listened to, and one who caveats everything indiscriminately is routed around within two quarters.

MEDDIC is a qualification checklist — Metrics, Economic buyer, Decision criteria, Decision process, Identify pain, Champion — and its practical value is that each letter is a thing you either know or are guessing about. Used honestly it is a list of unknowns rather than a scorecard: if you cannot name the economic buyer, that is the next call to make, not a box to fill with the person you have been talking to. The architect's contribution is mostly to three letters. Metrics, because a business case built on numbers you invented collapses under scrutiny. Decision criteria, because the technical evaluation criteria are frequently written by the incumbent and are worth reading as a competitive document. And pain, because the stated pain and the real one differ more often than not.

Qualification is only useful when it can produce a no, so the example worth having is one that does.

Opportunity: Northgate Logistics - warehouse management replatform
Indicated value: £2.1m over 3 years    RFP due: 14 Aug    Reviewed: 27 Jul

dimension            score  evidence                              gap
-------------------  -----  ------------------------------------  -----------
Compelling event      1/3   "modernisation programme", no dated   no forcing
                            trigger. Current system supported      function
                            until 2031.

Economic buyer        1/3   we have met the IT director. Budget    unreachable
                            sits with the COO, who has declined
                            two meeting requests.

Decision criteria     1/3   RFP requires SAP EWM certification     written by
                            and a named Tier-1 3PL reference.      a competitor
                            We have neither.

Decision process      2/3   procurement-led, 6 vendors invited,    6 vendors
                            scoring weights published. Clear,
                            but crowded.

Pain we can fix       3/3   real: 14% pick-error rate, two
                            manual reconciliations per shift.
                            This is squarely our capability.

Champion              1/3   IT director is friendly and has no
                            budget authority. No internal
                            advocate above him.

Our differentiation   2/3   strong on the pick-optimisation
                            engine, weak on the ERP integration
                            they have specified.

Cost to bid           -     ~22 person-days presales plus a
                            2-day workshop and a POC they have
                            asked all six vendors to run.

TOTAL 11/21   Threshold to bid: 15/21 with no dimension at 1
              except differentiation.

RECOMMENDATION  No bid. Four ones, including the two that cannot be
fixed inside three weeks: we do not reach the buyer and the criteria
exclude us on certification. Respond with a short letter naming the
certification gap honestly, offer a paid two-week assessment of the
pick-error problem instead, and ask for a debrief after award.

The scorecard earns its place by making the recommendation follow from the rows rather than from a feeling. Two of the four ones are structural — a criterion requiring a certification you do not hold and a buyer who will not meet you are not things twenty-two days of effort changes — and it is the combination that decides it, not the total.

The row that makes candidates uncomfortable is pain scoring three out of three. The problem is genuinely ours to solve and the deal is still not winnable, which is the distinction between capability and qualification. Bidding because you would be good at the work is the most common reason unwinnable deals get pursued.

Cost to bid is on the sheet deliberately. Twenty-two person-days plus an unpaid competitive POC is a real number, and the honest framing is that it is the budget for a different opportunity you will now not work on. Presales capacity is the scarce resource, and qualification is capacity allocation wearing a checklist.

The recommendation does not end the relationship, which is the part a strong answer includes. A withdrawal letter that names the gap truthfully, a smaller paid offer aimed at the pain you can actually fix, and a request for a debrief turn a no-bid into an entry point at the next cycle. Vendors who simply go quiet get no debrief and no second look.

The value of writing the gate down is that it makes the no defensible when a sales lead disagrees with it.

flowchart TD
    A[Opportunity received] --> B{Compelling event with a date}
    B -->|no| X[No bid<br/>nurture and requalify next cycle]
    B -->|yes| C{Economic buyer reachable}
    C -->|no| X
    C -->|yes| D{Must-haves met without<br/>new product work}
    D -->|no| X
    D -->|yes| E{Budget within 30 percent<br/>of our honest estimate}
    E -->|no| X
    E -->|yes| F[Bid<br/>named win theme and owner]

The ordering is the substance. Each gate is cheaper to test than the one after it, so the sequence is designed to fail early — establishing whether a compelling event exists costs one conversation, while discovering the budget gap costs a full estimate. Teams that run these tests in the reverse order do most of the work before deciding whether to do the work.

The budget gate is the one most often skipped, and the thirty per cent figure is the interesting part of it. A gap that size is not closed by sharpening a pencil; it is closed by reducing scope, changing the commercial model or discovering that the stated budget was a negotiating position. Any of those is a conversation to have before the proposal, because a bid that is double the budget is not a bid, it is a free education for the customer.

Every path to no-bid ends in the same box, and it is deliberately not "walk away". Recording the reason is what allows a pipeline to be reviewed later — losing four deals to the same missing certification is an investment decision, and it is invisible if the reason was never written down.

The bid box requires a win theme and an owner rather than only a decision. A bid with no articulated reason you should win is a bid that competes on price, which is the one axis where a well-qualified competitor has already beaten you.

Because a lost deal costs you the bid effort once, and an unqualified deal that you win costs you for years. The mechanism is that everything wrong at qualification survives into delivery: no compelling event becomes a project nobody sponsors, a buyer you never reached becomes a stakeholder who never agreed to the outcome, and a criteria set written against you becomes a scope you committed to without capability. Those deals produce write-downs, escalations, reference customers you cannot name, and the quiet cost of your best engineers spending a year on recovery. There is a second cost that is easier to forget: pursuit capacity is finite, so every unqualified deal you carry is a qualified one you did not work. The sentence worth having ready is that presales exists as much to disqualify as to win.

A compelling event is a dated consequence of doing nothing — a contract expiring, a regulation taking effect, a licence renewal, a plant opening, an auditor's finding with a remediation deadline. It matters because it is the only reliable answer to why now, and deals without one stall indefinitely regardless of how well the technical evaluation went. The test is to ask what happens if the decision slips by two quarters and listen for whether the answer contains a date and a cost. "We would keep looking" means there is no event; "our support contract ends in March and extending it costs £400,000" means there is. The trap is accepting a programme name as an event, because "our digital transformation programme" is a budget line rather than a forcing function and it survives being deferred every year.

By looking for the signs that the decision is already made and you are supplying procurement's required third quote. The tells are consistent: no access to anyone above the evaluation team, an RFP whose requirements match one vendor's feature names unusually closely, a compressed timeline that only an incumbent with existing knowledge could meet properly, no willingness to hold a discovery session, and answers to your clarification questions that arrive late and thin. The test is to ask for something a serious buyer grants and a going-through-the- motions buyer will not — an hour with the economic buyer, or a specific technical workshop. Refusal is the answer. What to do with it is not always withdrawal: sometimes you bid deliberately cheap in effort to stay visible, but you do so knowingly rather than by hoping.

The economic buyer is the person who can release the money without asking anyone else, and reaching them matters because everyone below them can say no and nobody below them can say yes. It is hard for a structural reason: the people you are naturally given — the technical evaluators, the programme manager — have an interest in mediating access, since their influence comes from controlling the narrative upward. Pushing past them badly costs you your only advocates. What works is trading value for access rather than requesting it: offer something the buyer's level cares about, such as a business-case review or a peer reference at their seniority, and ask your champion to bring you in rather than going around them. If access is refused repeatedly, that is qualification information rather than a relationship problem.

To find out what the customer is trying to achieve and what will actually be allowed to happen, which are different questions from what they have asked for. Discovery has three outputs. A business outcome stated in the customer's own metrics, because that is what the proposal must be judged against. A constraint set — budget, dates, existing platforms, internal politics, who has veto — because those determine which designs are real. And a picture of the decision itself: who evaluates, against what criteria, on what timeline. Candidates treat discovery as requirements gathering and produce a list of features, which produces a proposal that competes on completeness against every other vendor's list. The discriminating output is a hypothesis about why they are buying, held loosely enough that the next conversation can disprove it.

The difference is not politeness, it is what each question makes the customer tell you.

BAD                              BETTER                          WHAT IT SURFACES
-------------------------------  ------------------------------  ----------------
"What are your requirements?"    "Walk me through what happens   the real process,
                                 today from order received to    the manual steps,
                                 goods dispatched. Where does    where cost sits
                                 someone touch a spreadsheet?"

"Are you looking at the cloud?"  "What has to be true about      the actual
                                 where data sits - regulator,    constraint and
                                 contract, or preference?"       whether it moves

"What's your budget?"            "What has been approved, and    whether money
                                 by whom, and what did it get    exists at all
                                 approved as part of?"           and under whose
                                                                 name

"What's your timeline?"          "What happens on the date you    whether there is
                                 mentioned if none of this is    a compelling
                                 live?"                          event

"Who's the decision maker?"      "Last time you bought           the real process,
                                 something this size, walk me    the sign-offs,
                                 through who had to sign."       the hidden veto

"Any problems with the           "If you could change one thing  the pain the
current system?"                 about it tomorrow without       incumbent will
                                 asking anyone, what?"           not fix

"Would real-time reporting       "What decision would you make   whether the
be valuable?"                    differently if you had this     feature has a
                                 number four hours sooner?"      consequence

The pattern in the right-hand column is that every better question asks about something that has already happened rather than about a preference. Past behaviour is checkable and specific; stated preference is free, so a customer will happily agree that real-time reporting is valuable and then not pay for it. The last row is the clearest case — a feature nobody would act differently on is a feature that will not survive the budget conversation.

The budget question is worth studying because the bad version is not merely unproductive, it is answered dishonestly by default. Asking what has been approved and by whom converts a negotiating question into a factual one, and the answer frequently reveals that the money is attached to a different programme, which changes how the proposal must be framed.

Two of these questions are really qualification questions wearing discovery clothes. Asking what happens on the date if nothing is live tests the compelling event, and asking who signed last time maps the decision process. Discovery and qualification are the same conversation, and treating them as separate meetings is how a technical team spends three weeks designing for a deal with no buyer.

What the bad column has in common is that it can all be answered in one word by someone who has answered it four times this month for four vendors. If your discovery produces the same information the competition has, your proposal will look like theirs, and the customer will decide on price.

By what they cannot compromise on, and it changes the whole proposal. A compliance-driven buyer has an external date and an auditor, so evidence, traceability and certainty matter more than elegance or cost — they will pay a premium for a partner who has passed the same audit and will reject an otherwise-better design with no attestation story. A cost-driven buyer is defending a budget line, usually with a target percentage, so the proposal must lead with a baseline and a saving they can put in a board pack, and features are liabilities. A growth-driven buyer is trying to reach a revenue or capacity outcome, so speed to first value and optionality dominate and they will tolerate technical debt you find uncomfortable. The diagnostic question is what happens if the project succeeds late: the compliance buyer is fined, the cost buyer misses a target, the growth buyer loses a market window.

Asking why the same thing was not done last year, and asking who will be worse off if it succeeds. The stated driver is nearly always the sanctioned one, and it is not a lie so much as the version that survived being written down — "we are modernising the platform" is true and hides the reason the money appeared, which might be a failed audit, a merger, an incoming CTO, or a single executive whose credibility is attached to it. Two other reliable probes are asking what was tried before and why it stopped, and asking what else the budget could have been spent on. The reason this matters commercially is that a proposal aimed at the stated driver competes on features, while one aimed at the real driver addresses the thing the buyer is personally exposed to.

By finding the pain the incumbent structurally cannot fix, rather than by being better across the board. Displacement is hard because the incumbent has switching costs on their side, existing relationships, and knowledge of the estate you do not have, and because most evaluation criteria are written in the incumbent's vocabulary. So the productive question is what the customer has asked for repeatedly and not received, and whether the reason is architectural, commercial or organisational — an incumbent's inability to expose data from a monolith they will not refactor is durable, whereas slow support can be fixed by a phone call from their account manager the week you appear. The second half of the answer is risk reduction: the buyer's real fear is a migration failing on their watch, so a phased path with a reversible first step beats a superior end state.

Say so, in writing, with both options priced, and let the customer decide. The conflict is common — a requirement for a nightly batch window inherited from a system being replaced, or a specified technology that cannot meet the throughput the business case assumes — and the two failure modes are opposite. Complying silently wins the evaluation and produces a solution that does not deliver the outcome, which is discovered during acceptance and becomes your problem. Refusing to comply loses points in a scored RFP. So the workable answer is to answer the requirement as asked, then add a clearly marked recommendation showing what it costs and what the alternative achieves against their own stated metric. That is also the behaviour that earns technical credibility, because the customer usually knows the requirement is stale.

Enough to know the outcome, the hard constraints and who decides, which is usually less than an architect wants and more than a sales lead will offer. The practical stopping rule is that you can state the customer's problem back to them in their own metrics and they agree, and you can name the three constraints that would invalidate your design. Beyond that, more discovery yields diminishing returns compared with putting a draft shape in front of them, because a design that is eighty per cent right provokes better information in an hour than another two workshops of questions. The failure in the other direction is real too: designing after one call produces a solution that quietly assumes the customer's integration landscape is clean, and that assumption fails in the same way every time.

By treating the budget as a first-class requirement rather than as an insult to the design. Practically that means starting from the outcome and asking what the cheapest architecture that achieves it looks like, then adding only what a named requirement forces. The discipline is to cut scope rather than quality: fewer integrations, a narrower first phase, one region instead of three, manual process retained where automation does not pay yet — while keeping the things whose absence causes failure, which are usually data correctness, security and an operable deployment. What you must not do is deliver the ideal design at a shaved-down number, because that gap is absorbed by the delivery team as unpaid overtime and then as an escalation. If the budget genuinely cannot buy a viable solution, that is a no-bid finding, and saying it early is the valuable act.

Three priced options move the conversation from whether to buy to which to buy, and each option only works if its cost is stated honestly.

Customer: regional insurer, claims intake replatform
Outcome sought: cut claim acknowledgement from 3 days to same-day
Stated budget: "around £600k this financial year"

GOOD - £420k, 5 months, phase one only
  shape     new intake API and document ingestion in front of the
            existing mainframe claims engine. Rules engine untouched.
            Reporting stays on the nightly extract.
  gets      same-day acknowledgement for the 70% of claims that
            arrive with complete documents.
  TRADE     the mainframe remains, so the 30% needing manual
            enrichment are unchanged and the cost per claim barely
            moves. Buys the headline metric, not the efficiency case.

BETTER - £610k, 8 months, recommended
  shape     as above, plus automated document classification and
            an exceptions workbench for the manual 30%.
  gets      same-day for ~92% of claims and a measurable handling-
            cost reduction the finance director can put in a board
            pack.
  TRADE     needs 4 weeks of their claims handlers' time for
            labelling and workbench design. That is the real cost
            and it is theirs, not ours. If they cannot free the
            people, this option becomes GOOD at BETTER's price.

BEST - £1.35m, 16 months, two financial years
  shape     as above, plus retiring the mainframe rules engine onto
            a configurable decisions service and real-time reporting.
  gets      the ability to change a claims rule in a day rather than
            a quarter. Strategic, not operational.
  TRADE     crosses a financial year, so it needs a budget approval
            they do not currently have. Also carries the only real
            delivery risk of the three, because the mainframe rules
            are undocumented and discovery of them is unbounded.

What we ask for: a decision between GOOD and BETTER by 20 Aug, and a
named owner for the 4 weeks of handler time if BETTER is chosen.

The structural point is that none of the options is the ideal architecture priced at the budget. Each is internally coherent, and the trade line is the part that makes the set credible — a customer reading three options with only benefits listed concludes that the cheapest is being undersold to push them upward.

The recommendation is named, and it sits slightly above the stated budget on purpose. Six hundred and ten thousand against "around £600k" is a conversation; eight hundred thousand is a disqualification. Knowing which side of that line you are on is a commercial judgement the architect has to make, not the sales lead.

The trade on BETTER is the one that matters most, because the cost is the customer's own people rather than money. Presales routinely under-states customer effort, and it is the commonest cause of a project that is late for reasons the vendor cannot fix. Naming it as a condition, with an owner and a date, converts it from an excuse later into a decision now.

BEST exists partly to make BETTER reasonable and partly because it is genuinely where the customer should end up. What makes it honest rather than a device is that its unbounded risk is stated — undocumented mainframe rules are the kind of discovery that doubles an estimate — and that it is explicitly placed in a budget cycle they do not yet have.

They compress the time and effort a bid takes, and they raise the floor on quality when the architect assigned is not a specialist in that domain. A reference architecture with a known sizing model lets you produce a defensible estimate in days rather than weeks, and reused assets — accelerators, migration tooling, prior compliance evidence — are a legitimate differentiator because they reduce the buyer's risk rather than only your cost. The cost is a specific and common failure: a reference architecture applied without checking which of its assumptions hold produces a proposal that reads as generic, and buyers detect it immediately because the diagram does not contain any of their own systems. The usable rule is that reuse belongs in the sizing basis and the delivery approach, while the solution narrative has to be theirs.

When it costs more than the outcome is worth to the buyer, when it takes longer than the compelling event allows, or when the customer cannot operate it. The third is the one architects miss: a design requiring platform engineering maturity the customer does not have is not superior, it is a handover to a team that will run it badly and then blame you. There is also a competitive dimension — an over-engineered proposal loses to a simpler one on price and on perceived risk, and the buyer never sees the quality difference you were paid nothing to provide. The judgement is not to design badly but to design to the actual requirement, including the operational one, and to place the rest in a roadmap you can point at. Saying "here is what I deliberately left out and when it becomes worth doing" is the strongest version of this answer.

Answer it truthfully, immediately, and with the nearest real alternative attached. The instinct is to soften — "this is on our roadmap", "this can be configured" — and it is the most expensive habit in presales, because the claim is verified during delivery or by a competitor in the next meeting, and either outcome costs more than the point you were trying to protect. So the shape is: state plainly that the capability does not exist, say what does exist and how close it gets, state what the workaround costs and who bears it, and if there is a roadmap item give the honest status rather than a date. Buyers accept gaps far better than most vendors expect. What they do not forgive is discovering the gap themselves after being told otherwise.

It is a deliberately small first delivery that produces real value and establishes the platform the rest depends on — a first integration in production, a single business process end to end, the security and deployment foundations laid properly. It helps win for a commercial reason rather than a technical one: it fits inside the budget and the approval authority the buyer already has, so it converts a decision requiring a board into one their director can sign. It also reduces the buyer's personal risk, since a reversible three-month commitment is easier to defend than a two-year programme. The honest cost is that a phase one sold as the whole answer creates disappointment, so the sequencing and what phase one deliberately excludes have to be written down where the buyer's colleagues will read them.

By making the customer state the numbers and by pricing what those numbers cost. Non-functional requirements in an RFP are usually aspirational — five nines, sub-second everywhere, full disaster recovery — because they were written without a price attached, and answering yes to all of them is how a proposal acquires obligations nobody costed. The productive move is to ask what the consequence of missing each one is: what happens in the business if the system is down for an hour, or if a report takes ten seconds. That converts a wish list into tiers, and tiers can be priced and traded. Then state the levels you are actually committing to in the assumptions, because an availability figure mentioned in a slide and not qualified in the proposal is the figure you will be held to.

It is coarse-grained sizing — small, medium, large — used when the information does not support a number, and its legitimate purpose is triage: deciding which items need real estimation, comparing options quickly in a workshop, and communicating relative scale without implying precision. It works because it is honest about its own accuracy, and because a range attached to each size can be calibrated from past delivery, which makes "three larges" mean something within a factor rather than nothing at all. The failure is mechanical and near-universal: someone converts the sizes to days, sums them, and the total appears in a proposal as a firm price. Once a T-shirt size has been multiplied by a rate it has become an estimate without ever having acquired the evidence of one, and that is the arithmetic behind a large share of loss-making fixed-price deals.

The number that survives a delivery review is one whose basis can be inspected line by line.

Claims intake replatform, BETTER option. 8 months. Bottom-up.

workstream              effort   role mix                    cost
                        (days)
----------------------  -------  --------------------------  ---------
Discovery and design       40    1 architect, 1 BA             £42,000
Intake API and gateway    120    2 senior BE, 1 mid BE        £104,000
Document ingestion         95    1 senior BE, 1 data eng       £85,500
Classification model       70    1 ML eng, 1 data eng          £70,000
Exceptions workbench      110    1 senior FE, 1 mid FE, 1 UX   £93,500
Mainframe integration      85    1 integration specialist      £93,500
Test automation and UAT    90    1 senior QA, 1 mid QA         £67,500
Non-functional and
security testing           30    1 security eng                £33,000
Deployment and IaC         45    1 platform eng                £45,000
Delivery management        80    0.5 delivery lead, 8 months   £72,000
                        -------                              ---------
Subtotal                   765                                £706,000

Rate basis: blended by role, UK nearshore mix, 2026 card less 8%
  architect £1,100/d   BA £1,000/d        senior dev £950/d
  mid dev £700/d       QA £750/d          data eng £850/d
  ML eng £1,150/d      UX £900/d          security eng £1,100/d
  integration specialist £1,100/d         platform eng £1,000/d
  delivery lead £900/d
Every line is days x the blended rate of its own mix, so any line can be
recomputed from the card above. Worked example: the intake workstream is
120 days at (950 + 950 + 700) / 3 = £866.67/d, which is £104,000.

Risk-based contingency, applied per line, not as a flat percentage:
  Mainframe integration      +40%   undocumented rules, no test
                                    environment promised yet    £37,400
  Classification model       +25%   accuracy target unproven
                                    on their document mix       £17,500
  Everything else            +10%   normal estimation variance   £54,250
    (10% of £542,500, being the £706,000 subtotal less the two
     lines already carrying their own risk loading)
                                                               ---------
Contingency                                                    £109,150

TOTAL                                                          £815,150
Price to customer at 24% gross margin target ............... £1,072,600
Price offered ................................................ £610,000
                                          <- gap of £462,600. See below.

Two features make this inspectable. Effort is decomposed to workstreams small enough that someone who has done the work can disagree with a single line, and contingency is applied per line at a rate justified by a named risk rather than as a comfortable ten per cent across the total. Flat contingency is arithmetic that hides exactly where the danger is, and the mainframe line is where this estimate will be wrong.

The last three lines are the point of showing this. A bottom-up estimate priced at target margin comes out at over a million against an option quoted at £610,000, which means the option as described is not deliverable at that price and someone has to know before signature. That is the conversation presales exists to force, and it has exactly three honest resolutions: cut scope, accept a lower margin as a deliberate strategic decision at the right authority level, or decline.

What is not an honest resolution is reducing the effort numbers until the total fits. This happens routinely, it is invisible in the document, and the mechanism is always the same — the mainframe line loses its forty per cent, the test days halve, delivery management drops to a quarter of a person. Each is defensible alone and the aggregate is a project that is thirty per cent underfunded before anyone writes code.

The rate basis is stated because a total without it cannot be checked or reused, and it carries a rate for every role that appears in the mix column rather than for the convenient half of them. A card that omits the BA, the data engineer or the UX rate leaves several lines unverifiable, which quietly defeats the purpose of a bottom-up sheet: a reviewer who cannot reproduce a line has to take it on trust, and the lines people take on trust are the ones that turn out wrong. It also names the discount already applied, which matters in negotiation: a procurement team asking for ten per cent needs to be answered from a position where you know what has already been given.

A second estimate produced by a different method is the cheapest error check available, and the interesting output is the gap rather than the number.

Same scope, top-down, from delivered comparables.

Method 1 - analogous project
  Nordvik intake replatform, delivered 2024. Similar mainframe
  front-ending, similar document volumes, no ML component.
  Actual: 690 days, £638k.
  Adjustments  + classification model, not in Nordvik      +90 days
               + their document mix is 3 sources, not 1    +35 days
               - we now have the ingestion accelerator     -60 days
  Adjusted                                                  755 days

Method 2 - proportional from a known anchor
  Across 6 delivered integration projects, mainframe front-ending
  has run at 30-38% of total effort. Our integration and ingestion
  lines total 180 days.
  Implied total  180 / 0.34 = 529 days     <- much lower

Method 3 - team and duration
  8 months, 6.5 FTE average as scoped = 8 x 21 x 6.5 = 1,092 days
                                        <- much higher

Bottom-up  765 days
Method 1   755 days   gap  -1%
Method 2   529 days   gap  -31%
Method 3  1,092 days  gap  +43%

Method 1 agreeing with the bottom-up within one per cent is the reassurance worth having, and it is only meaningful because the comparable was adjusted explicitly for the three ways this project differs. An unadjusted analogue that happens to match is a coincidence, not a check.

Method 2's thirty-one per cent shortfall is the one to investigate rather than dismiss, and the investigation is productive. On those six projects the integration share was high because the front-end work was thin; here the exceptions workbench and the model are substantial, so integration is a smaller fraction and the ratio does not transfer. That is a real answer, and the ability to explain a diverging check is what makes an estimate defensible.

Method 3 diverging upward exposes something different: the schedule and the effort do not agree. Eight months at the staffing implied by the role mix buys about a thousand days of capacity, and we have scoped 765. Either the team is smaller than the plan implies, or the duration is driven by dependencies rather than effort — here, the customer's four weeks of handler time and the mainframe test environment. Naming that is more useful than reconciling the numbers, because it identifies the schedule as dependency-bound rather than effort-bound.

The rule this illustrates is that top-down and bottom-up are not alternatives. Bottom-up gives you a number you can defend line by line and is systematically optimistic because it can only count work you have thought of; top-down carries the forgotten work in its history and cannot tell you where the effort sits. Use both, and treat any gap over about fifteen per cent as an unresolved question rather than an average to be taken.

It replaces a single figure with an optimistic, most likely and pessimistic value, from which an expected value and a spread can be computed.

Mainframe integration workstream, three-point.

              optimistic  most likely  pessimistic
              (O)         (M)          (P)
              ----------  -----------  -----------
Effort, days      55           85          190

PERT expected value  E = (O + 4M + P) / 6
                       = (55 + 340 + 190) / 6  =  97.5 days

Standard deviation   SD = (P - O) / 6
                        = (190 - 55) / 6  =  22.5 days

  E             97.5 days   ~50% chance of coming in at or under
  E + 1 SD     120.0 days   ~84%
  E + 2 SD     142.5 days   ~98%   <- what I would commit fixed-price on

Note what the shape says: M is 85 but E is 97.5, because the
pessimistic tail is 105 days above M while the optimistic case is
only 30 below. Effort distributions are right-skewed - work can
overrun without limit and cannot underrun below zero.

The arithmetic matters less than what the skew reveals. Most likely was 85 days and the expected value is 97.5, which is the fifteen per cent that vanishes when a team estimates by asking how long something will take and writing down the answer. Every workstream estimated at its mode produces a project estimated at its mode, and a project only lands on its mode if nothing goes wrong anywhere.

The pessimistic value is the number that carries the information and the one people refuse to state. A hundred and ninety days against a most-likely of eighty-five is a wide spread, and its width is the honest statement that we have no documentation and no test environment. Narrowing that range is a specific piece of work — two days with their mainframe team — and it is worth more than any amount of re-estimating.

The confidence line is how this connects to the commercial model. Committing fixed-price at the expected value means roughly even odds of losing money on the workstream; committing at two standard deviations prices the risk you are taking on. That is what a contingency figure represents, and stating it this way is the difference between contingency as a number and contingency as a position.

Contingency is money and time set aside for risks you have identified but cannot size precisely, and it is distinct from padding, which is unstated slack inside individual estimates. Ownership is the part that decides whether it works: held by the delivery lead or a change board, released against named risks with a recorded reason, and reported so that consumption is visible while the project still has options. It goes wrong in three ways. It is padded invisibly into each line, so nobody knows how much exists and it is all spent by month three. It is stripped in negotiation because it is the only line item with no named deliverable attached, leaving the risk in place and the cover gone. Or it is treated as budget, and spent on scope. The sentence to have ready is that contingency removed from a proposal does not remove the risk, it moves it onto whoever delivers.

The choice of model is a risk allocation decision, and each one puts a specific risk on a specific party.

                    FIXED PRICE        TIME & MATERIALS   OUTCOME-BASED
------------------  -----------------  -----------------  -----------------
Effort overrun      vendor             customer           vendor
Scope growth        customer, via      customer, paid as  disputed - this
                    change control     it happens         is where these
                                                          contracts fail
Requirements        vendor - priced    customer - pays    vendor, plus the
uncertainty         blind, so priced   to discover        risk the outcome
                    high                                  was never
                                                          achievable
Customer-side       vendor absorbs it  customer pays for  vendor, unless
delay               unless the         idle time or       dependencies are
                    contract has       re-plans           contractually
                    dependency relief                     carved out
Quality and rework  vendor             customer, which    vendor
                                       is why T&M needs
                                       an engaged buyer
Benefit not         customer           customer           vendor - and the
realised                                                  measurement is
                                                          the whole
                                                          negotiation

Vendor margin       high variance,     stable, low        highest ceiling,
                    can be negative    ceiling            can be zero

Buyer's real fear   "we'll be nickel   "this will run     "they'll argue
                    and dimed on       forever with no    about whether it
                    change requests"   accountability"    worked"

Right when          scope is genuinely  scope will        the outcome is
                    stable and well     evolve and the    measurable from
                    understood; the     buyer wants       data neither
                    buyer needs         control and       party controls,
                    budget certainty    speed             and both trust
                                                          the baseline

The row that decides most disputes is scope growth. Under fixed price it is the customer's cost through change control, which is contractually correct and commercially corrosive — every change becomes a negotiation and the relationship degrades into one about paperwork. Under time and materials it is paid as it occurs, which is honest and requires a buyer with the governance to manage a budget they can see moving.

Fixed price is widely believed to transfer risk to the vendor, and it transfers it in one direction only. The vendor carries effort and quality risk; the customer carries the risk of paying a premium for uncertainty they could have absorbed more cheaply, and of a vendor who, once losing money, optimises for minimum compliance with the letter of the specification. That second effect is the real cost of a badly priced fixed-price deal and it lands on both parties.

Outcome-based contracts fail on the middle rows rather than the outcome itself. If the measurement baseline is disputable, if the customer's own actions affect the metric, or if a dependency you do not control can stop the outcome, you have accepted unbounded risk for a bonus. They work in narrow conditions: an instrumented metric both parties trust, a baseline agreed in writing before starting, and explicit relief where the customer's performance is on the critical path.

The bottom row is the answer to give when asked which model is best. None of them; the model should follow the certainty of the scope and the buyer's appetite, and a vendor pushing one model regardless of the situation is optimising their own risk position rather than solving the customer's problem.

When the scope is genuinely well understood, when you have delivered something closely comparable and have the actuals to prove it, and when the customer's real need is budget certainty they are prepared to pay a premium for. All three conditions matter. Without comparable actuals you are pricing from imagination and the contingency required to be safe usually makes you uncompetitive; without budget certainty as a genuine requirement you are selling an expensive property the buyer does not value. It also needs the contractual machinery to work: a precise scope definition, an assumptions and exclusions list, a change control process both parties expect to use, and dependency relief where the customer's own delays would otherwise cost you. Fixed price with a vague scope is not a commercial model, it is a dispute with a start date.

Measurement, dependency and baseline, in that order of frequency. The measurement problem is that the metric is affected by things you do not control — a marketing change, a pricing decision, a seasonal shift — so a genuine improvement can be invisible in the number and a windfall can be credited to you dishonestly. The dependency problem is that customer-side delay or a third party's failure can make the outcome unachievable while your obligation stands. The baseline problem is the one that produces litigation: if the pre-existing number was never agreed in writing from an instrumented source, the entire fee becomes arguable after the work is done. Signing one responsibly requires a baseline fixed before commencement, defined relief events, a floor covering your costs, and a cap so the customer does not later refuse to pay a success fee they now consider excessive.

Executive summary first, then the solution, then delivery approach, then commercials, then the compliance matrix and appendices — and the order reflects who reads what rather than logical flow. The executive summary exists for the people who will not read further and must contain the outcome, the approach in a paragraph, the differentiators and the price. The solution section answers the buyer's questions in the buyer's own numbering, because evaluators score against their list and anything they have to hunt for scores zero. Delivery approach addresses their real fear, which is that this fails on their watch, so it carries the plan, the risks and the governance. Commercials come after value has been established. The compliance matrix is what a procurement team actually uses to shortlist, and a proposal that is beautiful and non-compliant does not reach the scoring stage.

The partial answers are where a bid is won or lost, because everyone can answer the ones they fully meet.

REQ 4.7  "The solution shall provide real-time replication of claims
          data to the customer's on-premise data warehouse with a
          maximum lag of 5 seconds."

COMPLIANCE  Partially compliant.

WHAT WE PROVIDE TODAY
Change-data-capture streaming from the claims store to your warehouse
with a measured end-to-end lag of 20-40 seconds at your stated peak of
1,200 claims per hour. This is in production at two UK insurers, and
we can provide a reference for both.

WHERE WE FALL SHORT
We do not commit to a 5-second ceiling. Our architecture batches
micro-commits at 15-second intervals to bound the load on the
warehouse; removing that would require a synchronous write path we
would not recommend, because a warehouse outage would then apply
back-pressure to claims intake.

WHAT WE PROPOSE INSTEAD
1  We meet 5 seconds for the three event types where latency has an
   operational consequence - claim registered, claim assigned, payment
   authorised - by publishing those to a dedicated low-latency topic.
   Committed as a contractual SLA.
2  Bulk claims detail continues at the 20-40 second path.
3  If a 5-second ceiling across all data is a hard requirement, we
   will quote the synchronous option as a priced option in Annexe C
   at an additional £85,000 and a 6-week schedule impact, with the
   availability caveat above stated in writing.

QUESTION BACK TO YOU
Requirement 4.7 does not state what decision depends on the 5-second
figure. If it exists to support the fraud screening described in 6.2,
option 1 satisfies it fully. We would welcome a clarification.

The compliance word is stated first and stated accurately, because procurement teams re-score any answer where the claim and the detail disagree, and a "compliant" that unravels in the detail costs you credibility on every other answer in the document. Partial compliance answered well frequently outscores a bare compliant tick from a competitor.

The structure does something a yes or no cannot: it separates the requirement from the reason behind it. Meeting five seconds for the three events that have an operational consequence is very likely to satisfy the actual need, and it is offered as a contractual SLA rather than as a claim — a committed number on a narrow scope is worth more to a buyer than an unverifiable one on everything.

Naming why you fall short as a design decision rather than a limitation changes how it reads. The back-pressure argument gives the evaluator a technical reason to prefer your answer, and it is the kind of detail that gets quoted internally by a sympathetic architect on the evaluation panel.

The priced option is the commercial safety net. It means the answer cannot be scored as a flat failure, it puts a real number against a requirement the customer may not have costed, and it frequently causes the requirement to be relaxed — buyers drop requirements when they see the price, and they cannot do that if you never showed them one.

The question back is the part most vendors omit. It is legitimate in nearly every RFP process, it signals that you read the document as a whole rather than answering line by line, and the clarification often converts a partial into a full compliance before scoring.

Assumptions and exclusions are the only part of a proposal that reduces your exposure, and they only work when they are specific enough to be tested.

ASSUMPTIONS - if any of these is untrue, the price and the schedule
change, and we will raise it as a change request within 5 working days
of becoming aware.

A1  A mainframe test environment refreshed from production monthly is
    available to us from 1 October. If unavailable, add 4 weeks.
A2  Claims rules are documented to the level of the extract supplied
    at Annexe F. Undocumented rules discovered during build are out
    of scope and estimated on discovery.
A3  Two claims handlers are available for 4 weeks between weeks 6 and
    12 for labelling and workbench design, named by you before
    kickoff.
A4  Document volumes do not exceed 1,200 per hour peak and 8,000 per
    day. Above that, re-sizing applies.
A5  Sign-off on each phase gate within 5 working days. Delays beyond
    that extend the schedule day for day.
A6  We work from our own premises with VPN access. Any on-site
    requirement beyond the workshops in section 5 is chargeable.
A7  Third-party licences - warehouse, OCR engine - are procured by
    you and are not in our price.

EXCLUSIONS - explicitly not in scope or price.

E1  Data migration of claims closed before 1 Jan 2022.
E2  Decommissioning of the legacy intake portal.
E3  Training beyond the train-the-trainer sessions in section 5.4.
E4  Penetration testing by a third party. We support one test; the
    test itself and any remediation of pre-existing findings in your
    estate are excluded.
E5  Changes arising from regulatory guidance published after the
    proposal date.
E6  Support and maintenance after the 30-day warranty period. Priced
    separately in Annexe D.

Every assumption here has three properties, and an assumption missing any of them protects nothing. It is falsifiable — a date, a volume, a named artefact — so there is no argument later about whether it held. It names the consequence, so the change conversation has already been half-had. And it is something the customer can act on, which is the difference between a protective clause and a piece of legal decoration.

A3 is the most valuable line and the one usually left out. Customer resource is the commonest cause of delay and the hardest to raise mid-project, because doing so sounds like blame; agreed in advance with a named owner, it becomes a shared commitment. A5 does the same job for sign-off latency, which quietly consumes more schedule than any technical risk.

The exclusions matter for a different reason: they defeat assumed inclusion. Buyers reasonably assume that decommissioning the old portal, or training everyone, or fixing what a penetration test finds, comes with the project. Discovering in month six that it does not is a relationship event, and E2 and E4 cost nothing to write now.

What makes this section survive negotiation is putting it in the body of the proposal rather than in an appendix, and walking the buyer through it verbally. Assumptions the customer has not read are worth very little in practice — you will win the contractual argument and lose the account — whereas assumptions discussed in the room become the framing for every change request that follows.

Because the price and the scope statement are both interpreted through them, and without them every ambiguity resolves in the customer's favour by default. A proposal is read months later by people who were not in the room, usually in a dispute, and the question is always the same: what did the price include. An assumption is how you record something you were told but could not verify; an exclusion is how you record something a reasonable buyer would otherwise assume was included. The reason candidates undervalue this is that both feel defensive and unsalesy, and sales leads often ask for them to be trimmed. The counter is that they are not there to win arguments later but to make the commercial conversation happen now, while the customer still has choices and the price is still movable.

Some evaluators read only this page, so it has to work alone.

EXECUTIVE SUMMARY

You told us that a claim currently takes three days to acknowledge,
that 30% of claims need manual enrichment before they can be
assessed, and that your FCA remediation plan commits you to same-day
acknowledgement from April 2027. That date is the constraint this
proposal is built around.

We propose to place a new intake and document-processing layer in
front of your existing mainframe claims engine, rather than replacing
it. Automated document classification and an exceptions workbench
handle the manual 30%. Your rules engine, and the eleven years of
claims logic in it, are untouched.

Be clear about the dates. On an October 2026 start, an eight-month
delivery completes at the end of May 2027, which is after your April
2027 regulatory date. The phasing is what closes that gap: same-day
acknowledgement for standard claims goes live in month five, in
February 2027, about two months ahead of the date, and the two
months of work that fall the wrong side of it are the non-regulated
remainder - complex claim types, reporting and decommissioning. If
you need the whole programme inside the date, the start has to move
forward to August 2026 or the tail scope has to come out; we would
rather say that now than in March.

Expected outcome, against your own figures: acknowledgement within
the same working day for approximately 92% of claims, and a reduction
in manual handling of around 6,400 hours a year, which at your stated
handling cost is £310,000 annually.

Three reasons to choose us. We have delivered mainframe front-ending
for two UK insurers, both available as references, and our ingestion
accelerator removes roughly six weeks from the schedule. We are
proposing to keep your rules engine, which we believe is the lower-
risk path to your April 2027 date. And we will commit to the same-day
acknowledgement SLA contractually, measured from your own data.

Price: £610,000 fixed, phased against four milestones. This assumes
availability of a mainframe test environment from 1 October and four
weeks of two claims handlers' time; both are set out in section 8.

The decision we are asking you to make by 20 August is between this
scope and the reduced scope in Annexe B at £420,000, which meets the
regulatory date but does not address the manual 30%.

The first paragraph is theirs, not ours, and that ordering is the whole technique. It states their problem in their numbers and names the regulatory date as the organising constraint, which demonstrates comprehension before making any claim. Proposals that open with a paragraph about the vendor's heritage have spent the only paragraph that was certain to be read.

The solution paragraph contains one architectural decision and its reason — front the mainframe rather than replace it — because that is the whole design at this altitude. An executive summary containing a component list is answering a question nobody at that level asked.

The date paragraph is deliberately unflattering, and that is why it belongs on the first page. An October start plus eight months lands in late May, which is after an April date, and any evaluator with a calendar will work that out in about ten seconds. Saying it yourself, together with what is and is not inside the date and what would have to change to move it, converts the weakest fact in the proposal into evidence that your schedule is real. Vendors who instead write a comfortable phrase like "well ahead of your regulatory date" lose the deal at the moment the buyer does the subtraction, and they lose it on credibility rather than on schedule.

Quantified outcome in the customer's own units is what makes the page circulatable. £310,000 a year against £610,000 once is an argument a sponsor can make to a finance director without your help, and enabling that internal argument is the actual job of a proposal.

The differentiators are three, they are specific, and none of them mentions a competitor. Two references, a named accelerator with a schedule effect, and a contractual SLA are all checkable, which is what separates differentiation from adjectives.

Ending on a dated decision between two named options is the move most summaries lack. It presumes a decision rather than requesting consideration, it gives the buyer an easier and cheaper alternative so that the answer is not yes or no, and it puts the assumptions on the page where they cannot later be described as buried.

Because the people who release the money are not the people who evaluate the technology, and their involvement is measured in minutes. A chief financial officer or a steering committee member receives a hundred-page proposal, reads the first page and the price, and asks the evaluation team one question. What follows from that is a set of writing constraints: the outcome and the number must both be on the page, the language must be the buyer's rather than the vendor's, and it must be intelligible to someone who does not know what the technology is. It also has to be written last, despite being read first, because it can only summarise a solution that exists. The reliable failure is a summary written first, describing the vendor rather than the customer's problem, and never revisited when the solution changed.

By making claims about yourself that are specific and checkable, and by shaping the evaluation criteria rather than attacking the alternative. Disparagement fails for a practical reason: the buyer has usually chosen to speak to that competitor, so criticising them criticises the buyer's judgement, and any inaccuracy in your criticism destroys everything else you have said. The technique that works is to raise the question your strength answers — asking how the migration will be reversed if phase one fails, if reversibility is where you are strong — and let the buyer apply it to everyone. Where a direct comparison is unavoidable, use their published material and be scrupulously accurate. The line worth saying in an interview is that you can be sharply competitive about architecture and approach without ever naming the other vendor.

It maps every numbered requirement in the RFP to your response, with a compliance statement and a page reference, and it decides scores because it is the artefact the evaluation team actually works from. Evaluators are scoring dozens of requirements across several vendors under time pressure, and an unanswered or hard-to-find requirement scores zero regardless of what your solution section implies. So the matrix is not an administrative appendix, it is the interface to the scoring process: answer in their numbering, use their words, use only the compliance vocabulary the RFP defines, and never leave a row blank. The related discipline is answering the question asked rather than the one you would prefer, because a well-written response to an adjacent requirement reads to an evaluator as an evasion and is scored as one.

It is built around one or two of the customer's own moments, in their vocabulary, with their data if at all possible, and it answers a question they have actually asked. A feature tour walks the product's navigation and demonstrates completeness, which is exactly the wrong thing, because completeness is what every vendor claims and it forces the buyer to compare feature lists. A demo that lands opens with the outcome — here is a claim acknowledged in forty seconds that takes you three days — and then shows only what is needed to make that credible. The discipline is subtraction: leave out what they did not ask about, stop when the point is made, and be willing to abandon the script when someone asks a question, because the question is more valuable than the remaining slides.

An unbounded POC is the most reliable way to spend six weeks and lose the deal anyway, so the scope document is where the work is.

PROOF OF CONCEPT - Northgate document classification
Duration: 3 weeks, ending 12 Sep. Effort: 12 person-days, ours.
Cost: no charge, on the conditions below.

QUESTION THIS POC ANSWERS - one question, agreed in writing
"Can automated classification reach 90% accuracy on Northgate's own
document mix without manual template configuration per broker?"

Nothing else is being tested. Performance, security, integration and
user experience are explicitly out of scope for this POC.

IN SCOPE
- 2,000 anonymised documents supplied by Northgate, spanning at
  least 8 broker sources, by 22 Aug
- our classification pipeline, hosted by us
- a confusion matrix and per-source accuracy report
- one 90-minute readout to the evaluation team and the COO

EXIT CRITERIA - success
- overall accuracy >=90% across the 2,000 documents
- no single broker source below 75%
- no manual per-broker configuration used
- report delivered by 12 Sep

EXIT CRITERIA - failure, stated as plainly as success
- accuracy <90%. We will say so in the readout and explain what
  volume of labelled data would be required to reach it.

WHAT NORTHGATE COMMITS TO
- documents by 22 Aug. This is the dependency the POC lives on.
- a named business owner for the readout
- a written decision within 10 working days of the readout, and
  progression to commercial discussion if the criteria are met

STOP CONDITION
If the documents are not supplied by 29 Aug, or if the scope is
extended to include integration or performance testing, the POC
stops and is rescheduled as a paid engagement. We will notify you in
writing on the day rather than absorbing the slip quietly.

The single agreed question is what makes this a proof of concept rather than a free pilot. POCs sprawl because each stakeholder adds the thing they care about, and a POC testing seven things proves none of them while consuming a month of presales capacity — so the out-of-scope sentence is doing more work than the in-scope list.

Failure criteria stated as plainly as success is the part that earns trust and the part vendors omit. A POC that cannot fail is a demonstration, and buyers know it; committing in advance to report a shortfall and to say what would be needed to close it is unusual enough to be a differentiator on its own.

The customer's commitments are the real subject of this document. A POC with no customer obligations is a vendor working alone, which proves nothing about whether the organisation will engage during delivery, and the document deadline is the specific dependency that most often kills the timeline. Requiring a written decision within ten days is how you avoid a successful POC that simply goes quiet.

The stop condition is the clause that requires nerve and pays for itself. Every experienced presales team has absorbed a POC that ran three times its length because scope crept and nobody would call it, and the cost is capacity plus a customer who has learned that your commitments are soft. Notifying in writing on the day, rather than after, is what makes it a term rather than a threat.

Because with no agreed definition of success, the result is judged against whatever each stakeholder privately hoped for, and someone in the room is always disappointed. Worse, an open-ended POC has no end: the scope grows as new evaluators join, your engineers stay engaged for weeks, and the eventual outcome is a report nobody acts on because there was no decision attached to it. Exit criteria fix three things at once. They bound your cost, they force the customer to state what would convince them, and they attach a next step to the outcome so that success produces a commercial conversation rather than a thank you. The question worth asking before agreeing to any POC is what decision this changes and who makes it — and if there is no answer, the POC is a substitute for a decision rather than an input to one.

Objections are answered badly in the same two ways, by deflecting and by conceding everything, and both are visible in writing.

OBJECTION 1  "Your platform doesn't have native SAP EWM integration.
              Vendor B does."

WEAK       "We integrate with everything through our API layer, so
            SAP is not a problem."
            - denies the gap, invites the buyer to test it, and will
              be contradicted by their own SAP team within a week.

BETTER     "Correct - we do not have a certified EWM connector, and
            Vendor B does. Here is what that difference actually
            costs you. We would build the integration against your
            EWM instance: 85 days of effort, in our price, delivered
            by an integration specialist who has done it twice
            before, with a reference. A certified connector would
            save roughly 6 weeks of that and would still need
            configuration against your customisations, which our
            discovery found to be substantial in the goods-receipt
            flow. So the real gap is about six weeks of a sixteen-
            month programme, and we have priced it rather than
            assumed it away. Where we think we are ahead is the
            pick-optimisation engine, which is the 14% error rate
            you told us is costing you £2.1m a year."

OBJECTION 2  "Your last project with a company our size was two
              years late. We spoke to someone there."

WEAK       "That project had unusual circumstances and the client
            changed scope significantly."
            - true and worthless. Reads as blaming a customer, which
              is what the buyer will remember.

BETTER     "That is fair, and I would rather tell you what happened
            than explain it away. We scoped 14 months and delivered
            in 34. Two things went wrong and one was ours. Theirs:
            the data quality in the source system was far worse than
            either party understood, and remediation added about
            eight months. Ours: we accepted a fixed scope without
            having profiled that data, and we did not have a stop
            condition to force the conversation - we absorbed the
            slip for two quarters before escalating it properly.

            What changed as a result. We now run a paid two-week
            data assessment before quoting any migration of this
            shape, and that is why section 4 of this proposal
            includes one rather than a data-quality assumption. And
            our contract now has a dependency-relief clause that
            triggers a joint review at 15% schedule variance, which
            is in the draft at Annexe E. You can speak to the
            programme director at that client - I will ask them, and
            they will tell you both halves of this."

The first objection is handled by pricing the gap rather than disputing it. The buyer's concern is not the absence of a certification, it is the risk and cost the absence implies, and a specific number attached to a named person with a reference addresses that in a way "we integrate with everything" cannot. Ending on the axis where you are genuinely stronger redirects without disparaging anyone.

The second is the harder case, and the only workable move is to concede immediately and completely. Any qualification in the first sentence — "that project had unusual circumstances" — is heard as evasion, and blaming the previous client tells this buyer exactly how they will be discussed. Owning the part that was yours, specifically, is what makes the part that was not yours credible.

Distinguishing the two causes and taking only one is the senior move. Data quality was genuinely outside your knowledge; accepting a fixed scope without profiling the data was your decision, and so was absorbing the slip silently for two quarters. That second admission is the one that lands, because it is a judgement failure rather than bad luck, and buyers are listening for whether you can identify one.

The changes named are verifiable and appear in this proposal, which is what converts contrition into evidence. A paid assessment in section 4 and a relief clause in Annexe E are things the buyer can read now. And offering the reference who will confirm the bad version is the strongest available signal, because only a vendor telling the truth can afford to make that offer.

Agree first, completely and without qualification, then say what you have done about it. The instinct is to soften, and softening is what converts a survivable weakness into a credibility problem, because the buyer already has the information — someone told them, or they found it — and your response is being scored on honesty rather than on the weakness itself. So the sequence is: acknowledge it plainly, describe the consequence accurately, state what changed as a result and where that change is visible in this proposal, and offer the evidence including references who will confirm the unflattering version. What you must not do is trade the concession for a compliment or move immediately to a strength, because an agreement followed by "but" is heard as a disagreement. The weakness is rarely disqualifying; the handling frequently is.

Say you do not know, say when you will come back, and come back on that day even if the answer is that you still do not know. This is the single most tested behaviour in a presales interview because it is the one that separates people who will make things up under pressure from people who will not, and it is trivially detectable — a bluffed answer contains no specifics and the follow-up question exposes it in seconds. If you have partial knowledge, say which part is solid and which is inference, in those words. The reason the discipline holds up commercially is that a buyer's evaluation of a vendor is largely an evaluation of whether the vendor's statements can be relied upon, and one visibly honest "I will find out" buys more trust than five confident answers.

Acknowledge it in one sentence, do not narrate the diagnosis, and move to the next thing that makes the point. Buyers are entirely used to software failing and their judgement is about composure and honesty rather than about the fault, so the damage comes from the recovery — the five minutes of silent clicking, the blame directed at the network, or the pretence that the broken thing worked. The practical preparation is a recorded fallback of the critical flow, a second environment, and knowing which two moments in the demo actually matter so you can protect them. Afterwards, follow up with the working version and, if the failure was real rather than environmental, say so plainly. The one unrecoverable move is claiming a feature works when the room has just watched it not work.

The handover is where presales quality becomes visible, and it is the stage most candidates describe as sending the documents over.

flowchart TD
    A[Scope, assumptions<br/>and exclusions pack] --> B[Named delivery lead<br/>reviews before signature]
    B --> C[Estimate walkthrough<br/>roles, rates, contingency and its owner]
    C --> D[Risk and dependency register<br/>transferred with owners and dates]
    D --> E[Verbal commitments written down<br/>anything promised but not contracted]
    E --> F[Joint kickoff<br/>presales architect in the room]
    F --> G[Thirty-day check<br/>presales still accountable]

The second box is the one that changes outcomes, and it is placed before signature deliberately. Delivery reviewing an estimate afterwards can only object; reviewing it beforehand can change the price or the scope. The objection to this is always that it slows the bid, and the answer is that it slows the bid by days and prevents write-downs measured in months.

The fifth box is the highest-value and most-skipped item. Every deal accumulates statements made in rooms — that the reporting requirement is really just a CSV, that the customer will handle their own data cleansing, that the go-live can shift if the test environment is late — and none of them is in the contract. Writing them down at handover, including the ones that are inconvenient, is the difference between a delivery team inheriting a scope and inheriting a surprise.

The contingency owner appearing explicitly in the estimate walkthrough matters because contingency with no named owner is spent by default. If it was priced against the mainframe integration risk, delivery needs to know that, or the money is consumed by ordinary overruns in month two and the identified risk arrives uncovered.

The last box is what makes the whole chain real. Presales that is measured only on signature has no incentive to hand over well, and a thirty-day accountability — the architect attends the first delivery review and answers for the estimate — is the cheapest available correction. The strongest thing a candidate can say here is that their own estimates were checked against actuals afterwards, and what that comparison taught them.

Context, and specifically the reasoning behind the choices rather than the choices themselves. The documents transfer the what — scope, architecture, price — and lose why the mainframe was retained, which requirement was traded away and in exchange for what, which stakeholder holds a veto, what the customer said they would tolerate, and which assumptions were made because nobody would answer the question. Also lost are the unwritten commitments, the relationships, and the architect's judgement about where the estimate is thin. The consequence is a delivery team that re-litigates settled decisions, breaches an understanding nobody recorded, or spends its contingency on the wrong risk. The structural fix is overlap rather than documentation: a delivery representative present during the bid and the presales architect present for the first month, which costs real capacity and is cheaper than the alternative.

Because it is free to say, it is remembered precisely, and it is eventually tested by someone who was not in the room. The sentence usually is not a lie — the platform can probably do a version of it, with configuration, in a later release, under conditions nobody stated — and the compression is where the cost sits: the customer hears a capability that exists today at no additional price, and that becomes their baseline for every subsequent conversation. By the time delivery discovers the gap, it has become a scope dispute, a write-down or a reference you cannot use. The alternative costs one sentence more. Say what exists today, what it does not do, what closing the gap costs and who bears it, and let the customer weigh it. Buyers can price a qualified yes; they cannot price an unqualified one, and neither can your delivery team.

Whether you can analyse a commercial outcome honestly, and whether you learned something specific enough to have changed your behaviour. A strong answer names the deal, states why it was lost with the real reason rather than the comfortable one, distinguishes what was outside your control from the decision that was yours, and describes a change that is checkable — a qualification gate now applied, a question now asked in the first meeting, a partial-compliance answer now written differently. It is also willing to say the deal should never have been bid. A weak answer blames price, blames the incumbent relationship, or claims the customer made a mistake, all of which may be true and none of which shows judgement. The secondary test is composure: presales involves losing more often than winning, and someone who cannot discuss a loss without defensiveness will not survive the job.

Because it is a claim about disposition rather than evidence of behaviour, and it collapses on the obvious follow-up: name the last deal you recommended walking away from, and what happened when you said so. Almost everyone asserts disciplined qualification, and the interviewer is listening for the specifics that only someone who has actually done it can supply — the dimension that failed, the conversation with the sales lead who disagreed, whether the recommendation was accepted or overruled, and what the deal cost when it was pursued anyway. The stronger version includes a loss of the argument, because a candidate whose no-bid recommendations were always accepted is describing an unusually cooperative organisation or is not describing anything. The related trap is over-claiming in the other direction: an architect who wants to disqualify everything is also not doing the job.

"Tell me about a commitment you made in a deal that delivery had to live with, and how that went." It resists preparation because it requires a real deal, a decision that was yours, and a consequence that arrived after you had moved on to the next opportunity. A strong answer names the commitment specifically — a date, an integration, an SLA, a fixed price against uncertain scope — states what information was available when it was made and why the decision was defensible then, describes accurately what it cost delivery, and identifies the change in practice that followed, such as an assumption now always written down or a delivery review now held before signature. It is comfortable with the version where the commitment was wrong. A weak answer describes a deal that went well, or retreats into process without a case, or reveals that the candidate never found out what happened after signature — which is the actual disqualifier, because a presales architect who does not track their own promises into delivery has no feedback loop and cannot be improving.