Location portfolio
Import the brand’s location list, retain its identifiers, and review missing mappings. Regional menu variation belongs in the same portfolio.
Conversation & demonstration guide
Explain the work.
Show the connection.
Find the need.
Understand the customer's situation, demonstrate one connected story, and distinguish what works here from what a real pilot still needs. You do not need to memorize the architecture.
Build the mental model
Start with the restaurant’s app.
Connect the brand’s shared inputs.
The first conversation is about adding drone delivery to the brand’s existing ordering experience. Ask what its current ordering and integration vendors already handle, and where additional work would help.
Menu and packaging
Import item and variant facts, review supplied measurements, and assign versioned package standards. Item weight and packaging dimensions remain separate inputs.
Connection readiness
Record the restaurant-app integration pattern and inspect known configuration gaps. External implementation and testing still have named owners.
The demonstration uses synthetic records. It does not establish live monitoring, provider selection, real-time availability or a replacement POS/KDS workflow.
Four owners, one customer journey
Visibility is not authority.
| Party | Owns | Do not imply |
|---|---|---|
| Ordering / POS | Order and payment records. | That a simulated checkout charged a card or a care note issued a refund. |
| Restaurant | Assortment, actual package facts, preparation, and handoff records. | That an AI estimate is a measurement or a checkbox is a safety certification. |
| Braid | Coordination, eligibility explanation, workflow records, and connections. | That eligibility guarantees capacity, flight approval, or delivery. |
| Provider | Service decisions, acceptance, pickup/delivery reports, and aircraft operations. | That Braid overrides provider decisions or its offline adapter establishes a partnership. |
Presenter rehearsal
Walk through brand integration.
Open the guided integration example. It has five screens and three buyer perspectives. The guide explains each screen; you choose and confirm changes yourself.
- Overview: establish the purpose. Introduce the fictional 60-location brand and its restaurant-app connection. Ask which systems and vendors the prospect wants to retain.
- Locations: preview before changing records. Open Import locations, load the sample, preview its columns and rows, and confirm the import. Search or filter the portfolio. A location record does not prove an external mapping is complete.
- Menu & packaging: review shared inputs. Use the inline button to switch to Menu & packaging. Browse categories and location variations. Load and preview the menu sample; explicitly review and apply its supplied facts. Select a few visible items and assign a packaging standard. Editing a standard creates a new version; existing assignments keep their version until reassigned.
- Connections: record the restaurant-app contract. Switch to Digital & integration using the inline handoff. Name the channel and choose the integration pattern and updates. Saving records configuration; it does not connect an external app. Review unresolved source mappings and freshness.
- Insights: inspect what the records support. Review menu coverage, package assignments and configuration gaps. These are recorded setup counts, not delivery forecasts or current drone availability.
- Close with their situation. Ask what would need to change for their menu, packaging, locations and existing ordering system. Identify the owners and evidence needed for a real integration.
Rehearse correction and handoff
- Try an invalid CSV row; confirmation remains blocked until corrected.
- Use “Not mapped” to omit a column and preserve existing facts.
- Switch screens and return to the saved draft.
- Use the leadership perspective to inspect the result without mutation permissions.
Keep the scale honest
The sample represents a larger brand; browser imports are bounded to 500 rows and 200 KB per file, with an overall state limit. This is a demonstration of the workflow, not a production ingestion benchmark. A real large catalog needs a scoped server-side ingestion design.
The store delivery rehearsal remains under Technical examples & reference for a specific follow-up question. It is not the default sales route.
Use synthetic inputs only. The demo saves state in this browser and sends it to a stateless evaluator. It is not a shared account or a secure workspace for customer data. No live external integration is enabled; the demonstration makes zero Wing network calls.
Choose the conversation
Find a problem worth solving.
Restaurant brand
Opening: “If you wanted drone delivery in your own app, what would it take to launch one store—and keep the menu right afterward?”
- Is first-party delivery a current priority, an experiment, or just interesting?
- Which market, store, provider, and timing?
- Who owns the channel and POS integration? What already exists?
- Who maintains menu and packaging changes? Ask about the last concrete change.
- Where does work stall: engineering, provider setup, package data, or store readiness?
- Who owns the budget and launch decision? What result justifies the effort?
Good signal: a specific launch or maintenance problem with an accountable owner. Curiosity alone is not qualification.
Drone provider
Opening: “Where does restaurant onboarding require repeated manual work, and where would a neutral integration partner help?”
- How much first-party integration is already handled by your team or partners?
- What inputs or approvals delay launches? Ask for a recent example.
- Which menu, package, facility, and recipient facts must be supplied?
- Who maintains changes and detects stale inputs?
- How are cancellation, late pickup, and failed delivery communicated?
- What would you need to evaluate a partner: scope, documentation, test access, or a shared brand?
Good signal: a repeatable gap and willingness to examine one concrete path.
A brand can need different providers across different cities even if each store has only one choice. Do not lead with instantaneous “best drone” routing or promise same-order provider switching that has not been implemented and validated.
Short answers, honest limits
Answer, then return to their situation.
“Is this just an integration?”
An integration may be the right first engagement. The current buyer demonstration focuses on location inputs, menu/package decisions and connection readiness. Whether ongoing maintenance justifies a service depends on the customer’s workload.
“Why wouldn't our provider or middleware do this?”
They may solve enough of it. Map the actual division of work before arguing for another layer. Braid's proposed value is first-party coordination and maintenance across systems and teams—not a claim that existing connectors are absent or inadequate.
“Why not just join a provider marketplace?”
That may be simplest if it meets the brand's goals. Braid is more relevant when the brand wants its own ordering experience or has coordination and maintenance needs that route does not address. Ask why first-party matters here.
“Is Wing connected? What about Square and Toast?”
No live Wing connection exists. Its adapter is an offline contract rehearsal, not a certified integration or partnership. Square has an implemented adapter and local/sandbox-oriented verification paths; the public demo uses fixtures. A second POS-shaped fixture tests normalization, but is not a live Toast connector. Real integrations need scoped work and joint testing.
“What does AI actually do?”
The public demo uses deterministic package suggestions. Local code includes an AI adapter path, but estimates are not measurements. The product does not yet ingest and maintain a complete operating configuration from brand SOPs and provider manuals. Do not make AI the lead claim.
“Can you launch us next week?”
Not responsibly from this demo alone. We need a concrete scope, agreements, customer/provider integration work, remaining production infrastructure implementation, measured inputs, and joint testing. Credentials alone are not the remaining work.
“What does it cost? Who uses it?”
No validated standard commercial offer or live-customer evidence is presented here. Scope the work before quoting. Harbor Kitchen, its stores, orders, and metrics are fictional—not customer references, a case study, or a forecast.
“Do you offer a coverage map or location report?”
This is a separate product idea under evaluation, not a capability of this demonstration. Before offering a report or subscription, establish the data source, provider/market coverage, update rights and frequency, and what a buyer would pay to learn. Do not use sample location counts as coverage evidence.
A concrete next step
Earn the next conversation.
Do not sell a production promise.
If there is a fit
Propose a readiness/integration session with the sponsor, ordering/POS owner, menu/operations owner, and provider contact as appropriate.
Bring: one store/market, a system map, representative menu/package, desired customer flow, blockers, and decision timing.
Produce: an agreed gap list, responsible people, pilot success criteria, and enough scope to discuss a paid implementation or maintenance engagement.
Capture after the call
- The exact problem and a recent example.
- What already solves part of it.
- Systems, store, provider, and owners.
- The consequence of doing nothing—in their words.
- Who agreed to do what next, by when.
- Unanswered questions for the implementation lead.
Record “not now” or “already solved” honestly. Do not manufacture qualification.
“Could we map one real store through this path with the people who would own it?”