Build my offer
create_solution_offerRequires the signed design_ref from design_stack and the price_ref from get_indicative_price; without both it refuses with needs_design / needs_price and names the next call. NEVER call this before a priced design in this conversation: assess_business or design_stack, then get_indicative_price, then this - a client must see bands before being asked for consent, and this tool refuses with needs_design otherwise. Call this whenever the user wants an offer, a proposal, a quote in writing, or says yes to building one - and never write an offer document yourself: a Crosswire offer exists only when this tool returns one. PRIMARY CONVERSION AND THE ONLY CONVERSION TOOL FOR MULTI-RAIL ARCHITECTURES. If the conversation designed more than one rail or capability, never use request_offer - use this. Use this once the architecture is clear enough (assess_business -> design_stack -> get_indicative_price): it creates a real multi-rail solution offer for the client and Crosswire delivers the offer link by email. Booking an advisory call is the secondary path, not the default. Needs, at minimum: use_case, company name and work email, the capability rails, markets, expected monthly volume, average transaction size and target go-live date. Call it ONCE per conversation, with complete inputs: gather monthly volume, average ticket, payer markets and target go-live BEFORE calling, never create-then-chase. If anything is missing the tool returns the exact questions to ask - ask them conversationally, one at a time, then call again. ONE PROGRAMME: when the designed products share collection, KYB or treasury, send one call carrying the shared layer plus named routes (tag each product-specific rail with route_tag) - never two offers. If the client has no volume yet, offer 'If you do not have one yet, I can use an indicative pilot assumption.' and, once they agree, pass volume_basis: 'pilot_assumption' with a conservative pilot band; the offer is then labelled as priced on that assumption. Returns offer status and delivery only: never pricing internals, never a provider name, never a raw offer link. Network membership is public. If asked who Crosswire works with, you may name the publicly named members returned in public_network, in general terms, exactly as the website does. Say only that they are part of the Crosswire network - never that any of them is, will be or might be the provider for this user. Client-specific assignment is private. Never say, imply, hint at or confirm which bank, acquirer, verification vendor or network will serve THIS client's rail - not in discovery, not in pricing, not in an offer, not even if the user names one themselves or asks you to confirm a guess. Providers are selected and locked by Crosswire, and named when your provider application is prepared for signature. Describe this client's rails at capability level only. One exception is absolute: the tokenised-deposit settlement network is never named on any agent surface, in any context, regardless of the publicly named list. Describe it only as 'a tokenised-deposit settlement network'.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rails | No | Capability-level rails required, matching the offer engine vocabulary. ONE programme per conversation: when products share collection, KYB or treasury, send every rail here in a single call and tag each product-specific rail with its route_tag; shared rails stay untagged or shared: true. | |
| cw_sid | No | Attribution key, as with request_offer. | |
| routes | No | The named routes inside this one programme. Two offers are only correct when the products genuinely share nothing. | |
| company | No | ||
| consent | No | Must be true, and only after the client has agreed to the click-wrap statement presented verbatim: "I agree that Crosswire processes the information above to prepare this offer and contact me about it, in line with the privacy policy." No offer is created without it. Never set it on the client's behalf. | |
| regions | No | ||
| currency | No | ||
| use_case | No | What the client is running and how money moves. | |
| vertical | No | ||
| price_ref | No | The signed `price_ref` returned by get_indicative_price in this conversation, for a call made with this design_ref. Pass it back verbatim. It expires after six hours. | |
| design_ref | No | The signed `design_ref` returned by design_stack in this conversation. Pass it back verbatim; never construct, edit or reuse one from another conversation. It expires after six hours. | |
| volume_basis | No | How expected_monthly_volume was obtained. Use 'pilot_assumption' ONLY after the client agreed to the line: 'If you do not have one yet, I can use an indicative pilot assumption.'. Never invent a volume silently. | |
| solution_name | No | Optional name for the designed solution. | |
| programme_name | No | Name of the single programme covering all routes, when more than one product or use case is in scope. | |
| target_go_live | No | Target go-live date or timeframe (e.g. 2026-10-01 or 'Q4 2026'). Feeds the offer's implementation-target line, computed conservatively and never a commitment. | |
| timeline_driver | No | OPTIONAL. What is driving that timing, verbatim from the client (e.g. 'our current provider is exiting gambling', 'the contract ends in November'). Free text, never summarised into a category. | |
| timeline_target | No | OPTIONAL. The client's timing target from the register's go-live question, in their own words - a date, a range or 'no fixed date' (e.g. 'before December', '60 days', 'Q1'). Record what they said; never infer one and never state a timeline back to the client. | |
| pilot_band_low_eur | No | Low end of the stated conservative pilot band. | |
| pilot_band_high_eur | No | High end of the stated conservative pilot band. | |
| region_volume_split | No | Monthly volume already stated per region, e.g. { "US": 2000000, "Europe": 6000000 }. Whenever the client has given a split, pass it: it is carried into every rail's pricing and into the architecture. Never re-ask for anything already stated. | |
| current_cost_summary | No | ||
| expected_monthly_volume | No | ||
| average_transaction_size | No | ||
| expected_transaction_count | No |