--- name: enterprise-engagement description: Develop an enterprise AI engagement and customer point of view. Use for technical pursuits, first conversations, opening decks, engagement proposals, collaborative scoping and sponsor alignment, or adapting commitments when the work changes. license: MIT --- # Enterprise engagement Enter the conversation with a useful point of view about the business and a way to test it. Help the customer see a more valuable operation, understand why it may now be possible, and decide where to begin. Adapt to the relationship: an exploratory executive meeting, a technical evaluation, an internal initiative and a competitive pursuit need different arguments. For an engagement already underway, build on the current proposal, design, delivery evidence and recent conversations. Understand the progress made and the next decision, preserving useful work and commitments. When those sources show materially different expectations, reconcile them before making a new commitment. Keep the current understanding in the team's existing working material so another participant can pick up the work. ## Find a reason for this customer to act Understand how the organization creates value and what is preventing it from doing more. Read the supplied account material, recent conversations and relevant public context. Look for a consequential pressure: a service the business cannot economically provide, demand it cannot absorb, decisions arriving too late, complexity that restricts growth, or scarce expertise concentrated in a few people. A technology announcement matters only if it changes one of those conditions. Establish the engagement's starting point. A company with broad AI access but shallow use may need role-based working sessions, reusable workflows and a path for local inventions to spread. A team with a valuable prototype may need integration and an operating owner. An executive exploring a new business capability may need a developed concept and demonstration. Investigate existing licenses, successful employee practices, abandoned experiments and the support available before assuming the assignment is a custom application build. Develop a specific thesis connecting that pressure to a change in work. For an industrial supplier, the opportunity may be to quote complex requests that engineering currently declines, rather than to write quotations faster. For a bank, it may be to maintain an informed view of more customers between scheduled reviews. These are starting hypotheses to investigate, not facts to attribute to an account without support. Know whose problem the thesis solves. The executive who funds a service, the manager responsible for its performance, the people who do the work and the team that must operate the technology may each face a different tradeoff. Identify where their incentives align and where the proposed change creates work or loses discretion. Use that understanding to shape the engagement, rather than treating stakeholder names as a contact list. ## Make the opportunity concrete enough to discuss Prepare a recognizable episode from the customer's work. Show what arrives, the decisions and systems involved, where expertise changes the outcome, and how a better experience would unfold. The strongest opening demonstration lets the audience see a difficult judgment or a cross-functional plan improve. A polished summary of supplied information often leaves the customer's main problem untouched. Explore relevant capabilities when the opportunity depends on what is possible now. Inspect the appropriate product and developer surfaces, available tools and customer environment; use what you discover to strengthen or change the thesis. Avoid selling a fixed architecture before understanding whether a maintained capability can do the work. Equally, do not reduce the opportunity to whatever is easiest to demonstrate with the first tool available. Design questions around choices. Asking which system owns a work order can determine the integration boundary. Asking why a specialist rejected a superficially valid request can reveal the actual reasoning task. Asking what the business would offer with twice the expert capacity can expose demand absent from today's queue. A useful question changes the concept, architecture, economics or engagement; it is not simply another field to populate. ## Shape a deployment worth committing to Connect an ambitious target to an initial deployment that demonstrates its defining mechanism. If the service depends on interpreting specifications and checking fulfillment constraints together, a first deployment should exercise both. Bound the customer population, transaction scope or product family where that makes delivery feasible, while preserving the mechanism that creates value. Develop the operating bargain with the customer. Work out what the field team brings, what customer engineers and domain experts contribute, how existing vendors or delivery partners participate, and who will inherit the capability. Treat architecture, access, procurement, security and organizational requirements as design inputs to resolve together. For example, an existing service platform's extension and release process may provide a faster supported path than a separate application with a new operating team. For a commercial pursuit, connect the technical proof to the buying decision. Understand who controls budget, which alternatives are being considered, how procurement evaluates the offer, and what would justify the next commitment. Frame a proof of value around the uncertainty that could change the purchase, with an intelligible path into operation. Avoid an impressive demonstration that has no relationship to the customer's evaluation or deployment process. Scope the work in outcomes and responsibilities. Explain what the initial deployment accomplishes, what the customer must supply, what the team will learn, and how changed findings affect the next commitment. Use assumptions to advance a concrete proposal; distinguish assumptions with material commercial consequences from routine design choices. Develop pricing or contractual detail when the task calls for it, using the economics and responsibilities of the proposed work. Qualify the engagement as well as the idea. A promising use case may still lack a person who can change the workflow, access to representative work, or capacity to absorb delivery. Decide whether the next commitment should be discovery, a bounded feasibility investigation, deployment, or a pause. Explain what would make a larger commitment justified. Enthusiasm from a sponsor does not by itself supply an operating owner or customer engineering time. For an opening proposition where the apparent bottleneck and the proposed proof do not yet line up, [the quotation engagement example](references/quotation-engagement.md) shows how contradictory account evidence changes the thesis, the customer contribution and the next offer. Use it to reason about that situation, not as a standard proposal format. ## Adapt the engagement when the work changes Revisit the engagement when business priorities, evidence or constraints change. Establish what was agreed, what is newly requested, and who can decide the affected commitment. A sponsor can change the desired outcome without being able to commit a platform team's release window. Prepare the conversation with both the business consequence and a feasible delivery proposal. Understand what a consequential objection protects. An operations manager may be protecting review capacity, a platform owner a support obligation, and a sponsor a commercial date. Separate the constraint from a preferred solution. When feasibility is disputed, identify the observation or experiment that could settle it. When the disagreement is a legitimate priority choice, develop the options and take the remaining tradeoff to the accountable decision maker instead of seeking endless technical consensus. Distinguish a clarification of the promised outcome from a defect, new scope or a changed assumption. That distinction affects who absorbs the work and which commitment needs renegotiation; it should not become a pretext for refusing necessary correction. Trace a material change through user experience, access and integration, evaluation, delivery effort, operating cost and adoption where relevant. Seek the implementers' estimate before presenting an engineering date as agreed. Offer choices that preserve the reason for the engagement. For a new request, recommend whether to substitute it for existing work, narrow its first population, fund an extension, or defer it. Explain the resulting outcome, date, customer contribution and remaining limitation. Make clear what you recommend, what the customer has accepted, and what still needs a decision. A discussion of an option is not a delivery promise. For example, a service-triage pilot was scoped to recommend a response for one product family. The sponsor now wants the system to dispatch technicians at launch, while the scheduling owner cannot support write access until the next release. Investigate whether dispatch is essential to the pilot's value or a new expansion. If triage still resolves the original bottleneck, recommend retaining the first release with a native dispatch draft for an authorized planner, and scope automated dispatch separately. If the claimed benefit depended on eliminating that planner handoff, revise the value case and release proposal instead of calling the draft equivalent. Bring the sponsor and scheduling owner the choice together; do not promise the missing interface on their behalf. After agreement, carry the change into the design, engineering brief, forecast and customer-facing material that depend on it. Use the team's established records and authorized channels. When interests remain in conflict, identify the person who can settle the tradeoff and the decision needed by a useful date. Keep independent work moving without allowing an unresolved assumption to become an implicit commitment. ## Lead a productive conversation Build the meeting around the insight, the changed experience, the hard tradeoff and the choice in front of the audience. Use exhibits that explain the idea: a customer episode, an operating-flow comparison, a solution demonstration or the economics of extending a service. Put supporting research and technical detail where the audience can inspect them without breaking the story. Finish the requested briefing, deck, demonstration plan or engagement proposal. Recommend a next move specific enough to act on, and make it clear how that move advances the target. A successful opening gives the customer something useful to agree with, challenge or improve.