Lucas Hartmann runs a 22-person customer service group inside a home-appliances company. For a year he had been saying yes to AI in scattered ways: a chatbot pilot here, an email-drafting tool there, a routing experiment a vendor talked him into. Each piece worked on its own, but nothing added up. When his director asked him in a quarterly review, "So what is your plan for AI in service?" Lucas realized he did not have one. He had activity, not direction. The next two weeks he spent writing a one-page vision for his group. That document changed how he made decisions for the next two years. This chapter is about how he did it, and how you can do the same for your own team.

What a Domain Vision Is (and Is Not)

A vision for your domain is a short, clear statement of how AI will create value in the slice of the organization you actually run. Your domain is your team, your function, or your department. It is not the whole company. That distinction matters. Setting enterprise-wide AI strategy belongs to senior leaders. Your job as a manager is narrower and, frankly, more useful day to day: deciding what AI does and does not do inside the work you are responsible for.

People confuse a vision with a few things it is not. A vision is not a technology roadmap with tools and dates; that comes later. It is not a procurement list of which products to buy. It is not a catalogue of every possible AI use case you could imagine. And it is not a detailed implementation plan.

A vision is the layer above all of those. It states the business value you are after, it names which capabilities you must build or buy, and it gives you a way to decide which opportunities deserve your energy and which do not. Lucas described his as "a north star I can point at when someone pitches me the shiny thing of the month." When a vendor offered him a sentiment-analysis add-on, he held it up against his vision, saw it did not serve any objective he cared about that year, and said no in about five minutes. Without the vision, that no would have taken three meetings.

Without a vision, teams chase whatever is trendy, resources scatter across disconnected experiments, and change feels chaotic. With one, every AI initiative connects to a goal, people understand why the work matters, and your investment decisions are easy to defend.

There is a second, quieter benefit. A vision changes the question you ask yourself. Before he wrote his, Lucas kept asking "should we use AI for this?", which is a question with no stable answer and invites whoever is most enthusiastic to win. Afterward he asked "does this align with what we said we are trying to do?", which anyone on the team can answer. That shift, from reacting to what arrives in your inbox to deciding against a stated direction, is most of what separates strategic management from busy management. It is also why a good vision keeps working for two or three years rather than a quarter.

The Three Pillars of a Domain Vision

A credible vision rests on three pillars. Skip any one and the vision wobbles. Lucas worked through all three on paper before he wrote a single sentence of his final statement.

Pillar One: Start From Business Objectives, Not Technology

Every real vision starts with one question: what are we trying to accomplish in this domain, and where could AI help? Notice the order. The wrong question is "what cool AI capabilities exist?" The right question is "what business outcomes do we need, and is AI the right way to get there?"

Lucas wrote down the outcomes his group was accountable for over the next 18 months. Two stood out: cut average resolution time from 2.5 hours to 1.5 hours, and lift customer satisfaction from 78 percent to 88 percent. Those are specific and measurable. "Become an AI-driven service team" is not an objective; it is a slogan. "Reduce resolution time by 40 percent" is an objective you can build a vision around.

Other examples of objectives that can anchor a vision: reduce operational cost in your area by 20 percent through automating routine steps, cut the time to handle a standard request in half, or reduce repeat contacts by 30 percent. The test is simple. If you removed the word AI from your objective, would it still read as a clear business goal? If it only makes sense when you are talking about technology, it is not strategic enough yet.

Pillar Two: Assess Capability Honestly

The second pillar is being honest about where AI genuinely helps in your domain and where it is hype or a bad fit. Lucas sorted his work into three buckets.

• High potential. Tasks with clean data, defined outcomes, and high volume. In his group, about 80 percent of inbound questions were repeats (warranty terms, delivery windows, basic troubleshooting). Drafting first-pass answers to those was a clear win.
• Medium potential. Valuable but harder. Automated routing of tickets to the right agent looked promising but depended on cleaner tagging than his team currently had.
• Low potential. Where AI either works poorly or should not lead. Sensitive complaints, safety issues with appliances, and anything emotional needed a person in charge. Forcing AI there would cost trust and create risk.

Most domains have only two or three genuinely high-impact opportunities and a long tail of nice-to-haves. A good vision spends its energy on the two or three. Lucas resisted the urge to list ten things. He named two.

Pillar Three: Readiness and Sequencing

The third pillar accepts that change does not happen instantly. Your vision should include honest assumptions about four things: the skills your team has or needs, the state of your data, the cultural openness of the team, and the resources (budget, time, attention) you can actually commit.

Lucas rated his group on each from 1 to 5. Tool literacy was a 4; people were comfortable with software. Data literacy was a 2; few understood why an AI draft might be confidently wrong. Cultural openness was a 2 as well, because the loudest worry on the floor was "robots are coming for our jobs." Wherever he scored a 3 or below, he knew the vision had to include time and money for getting ready, not just for deploying tools.

That assessment drove his sequencing. He decided to start with AI-drafted replies for routine questions, because it was the quickest win and would build the team's confidence. Only after that would he move to routing, which needed better data. Sequencing is the difference between "we will use AI everywhere" (which scatters effort) and "we will start here, learn, then expand" (which compounds).

A Worked Example: Plotting Opportunities and Writing the Statement

Lucas used a simple two-by-two grid to decide his focus. One axis was business impact (low to high). The other was implementation feasibility (low to high). He plotted each candidate.

• Draft routine replies: high impact, high feasibility. Top-right quadrant. This became Phase 1.
• Smart routing of tickets: high impact, medium feasibility (needs better tagging first). Phase 2.
• Sentiment dashboards: low impact, medium feasibility. Cut from the vision.
• Auto-resolving complaints end to end: medium impact, low feasibility and high risk. Explicitly excluded.

The high-impact, high-feasibility quadrant is where a vision earns its keep. With his focus clear, Lucas drafted the statement itself. Here is what a strong one looks like, and why it works:

"Over the next 18 months, our service group will use AI to draft first-pass answers for the roughly 80 percent of inquiries that are routine, cutting average resolution time from 2.5 hours toward 1.5 hours. Every AI-drafted reply is reviewed and personalized by an agent before it goes out. In a later phase, once our ticket tagging is cleaner, we will use AI to route escalations to the best-fit agent. We will not use AI to handle safety complaints or to make decisions about a customer's service level; those stay with people. We are investing in two days of data-literacy training per agent and creating a new senior-resolver role. Success is measured by resolution time, satisfaction score, and agent satisfaction. We are removing tedium, not jobs."

That statement is strong because it ties to specific numbers, is clear about what AI will and will not do, addresses the team's real fear directly, names the investment in readiness, and includes success metrics beyond mere automation. Compare it to a weak version: "We will become an AI-first organization by leveraging machine learning to drive digital transformation and enhance the customer experience." That sentence has no outcomes, no clarity on where AI applies, no readiness plan, and could describe any company on earth. It guides no decisions.

The Same Three Pillars in Other Domains

Lucas works in service, but the three pillars do not care what industry you are in. Walking the same method through unfamiliar domains is the fastest way to see the pattern rather than the example.

Take a manager who leads product development at a software company, wondering where AI belongs across design, requirements, and testing. Her business objectives are concrete: cut the feature development cycle from eight weeks to six, and improve testing coverage without adding headcount. Her capability assessment finds high potential in requirements analysis, where AI can find gaps and suggest edge cases; medium potential in generating boilerplate code, which is a real productivity gain if her engineers accept it; and low potential in user experience design, which is too subjective and depends on deep user insight. Her readiness assessment is uncomfortable but useful: engineers are skeptical about AI code quality, the requirements team is open to tools, and the UX team is actively resistant. Her vision follows from all three: use AI for requirements analysis and for boilerplate and scaffolding so engineers are freed for complex logic, and explicitly exclude UX design decisions to keep human creativity and user insight central. The result accelerates throughput without pretending to replace expertise.

Now take a manager responsible for field service engineers across ten regions, whose people spend their days on paperwork, travel, and diagnostics. His objectives are to raise billable hours per engineer from 70 to 80 percent and cut travel time by 25 percent. His capability assessment finds high potential in diagnostic assistance, where AI can learn from past cases and suggest next steps; medium potential in route optimization; and low potential in actual repair decisions, which are too dangerous and too situation-specific. His readiness assessment notes that his engineers are experienced but skeptical of solutions handed down by "tech folk," and that his field managers are already under-resourced. His vision therefore leads with the relationship: AI is an assistant to engineers rather than a replacement, learning from their expertise, suggesting diagnostics that speed problem-solving, and taking on the administrative burden, with engineers staying in control and gaining time back for higher-value work. He commits to investing in mobile interfaces and training, and he measures success by billable hours and by engineer satisfaction.

A quality assurance director in manufacturing shows what a strong statement looks like written out. "Over the next 24 months, AI will enhance our quality operation by automating visual inspection, detecting 95 percent of the surface defects currently caught manually, and by learning from our defect data to predict quality issues before production, reducing rework by 20 percent. AI handles the algorithmic, repetitive pattern-recognition work; our QA engineers focus on root cause analysis, process improvement, and complex judgment calls. We are investing in cameras, data infrastructure, and team reskilling. Success metrics are defect detection rate, rework reduction, and inspector satisfaction, because we are eliminating tedium, not jobs. We are explicitly not using AI for hiring, promotion, or performance evaluation decisions; those remain human." Every strength from the pillars is visible in that paragraph: specific outcomes, clarity about which work is a good fit and which is not, direct engagement with the team's fear, a named list of what AI will not touch, metrics that go beyond automation, and a realistic timeframe.

Across those domains the anchoring objectives look different but rhyme. They tend to be things like lifting customer satisfaction by a set percentage through faster and more personalized service, cutting operational cost through intelligent automation, accelerating time-to-market from eighteen months to twelve, expanding into a new geography without proportionally expanding headcount, reducing quality defects through AI-assisted inspection, or improving employee retention by making the work more interesting and higher-impact. What they share is that each is measurable, each belongs to the business rather than to the technology, and each would still make sense if you deleted every mention of AI.

Four Traps That Sink a Vision

Technology-first thinking. Starting with "we need to use this tool for everything" instead of "here is what we are trying to accomplish." Tools chosen before problems lead to solutions that do not fit, team confusion, and wasted budget. Always start with the objective, then ask what capability would help, then ask whether AI is even the right answer.

Over-ambition. Trying to transform everything at once ("AI across all our processes by next quarter"). This overwhelms the team, spikes anxiety, and spreads quality thin so that one failure poisons the whole effort. Pick your two or three highest-impact opportunities and start there.

Ignoring readiness. Writing a vision that assumes skills, data, or openness your team does not have. If your people distrust algorithms and have low data literacy, a vision built on sophisticated prediction will stall and make people cynical. Be honest, and build the runway into the plan.

No prioritization. A vision that treats every opportunity as equal scatters resources and confuses people about what comes first. Build sequencing in: Phase 1 is the high-readiness quick win, Phase 2 depends on what Phase 1 teaches you.

Judgment Checkpoints Before You Commit

Before Lucas shared his vision, he ran it through a few quick tests, and you should too.

• The business-objective test. Remove the word AI. Does what remains still read as a clear business goal? If not, it is not strategic enough.
• The skeptical-peer test. Say it to a manager in a different area. "That makes sense for your context" means you grounded it well. "Sounds nice, but..." means you missed feasibility or cost. "How will you measure that?" means your metrics need work.
• The team-conversation test. Share it with two or three team members, not just executives. "How do I fit into this?" answered well means you clarified roles. "I'm worried about..." means a real concern is unaddressed.
• The honesty test. Ask whether you believe this will work in your context, or whether you are saying it because it sounds impressive, a vendor sold you, or it is simply trendy.

Two of those deserve a longer look. In the team conversation, the response Lucas found most useful was the flat one: "I do not understand how this helps us." That is not resistance, it is a signal that the vision has not been connected to the work those people actually do, and the fix is in your words rather than in their attitude. And there is a fifth test worth adding, the capability reality check. For every opportunity in your vision, ask whether you have, or can genuinely build, the skills, data, and systems to pull it off inside the timeframe you are claiming. If the honest answer is "probably not that fast," you have two respectable options: adjust the vision, or leave it intact and add the readiness investment explicitly to your plan. What you cannot do is state the timeline and hope. On the honesty test, be specific about the failure modes you are testing for: are you saying this because it sounds impressive to executives, because a vendor convinced you, because you watched it work at another company with different constraints, or because it is the fashionable thing right now? Great visions are specific to your domain, and generic hype is easy to spot in someone else's vision and hard to spot in your own.

Keeping It Responsible and Human

A vision shapes how your people experience AI, so build in three commitments. First, watch for inequitable outcomes. Lucas noted that automated replies might serve customers with accessibility needs worse, so his vision promised to monitor escalation patterns across customer groups. Second, be honest with the team. "This changes your role but does not eliminate your position" and "we are automating the tedious parts, not the skilled parts" beat vague optimism that breeds cynicism. Third, name where humans keep authority. Lucas wrote plainly that an agent always reviews a draft before it is sent and that safety complaints never touch AI. Clarity on who is accountable is part of the vision, not an afterthought.

It is worth being concrete about what equity risk looks like, because it rarely announces itself. An automated service vision can quietly deliver worse service to customers with non-standard needs, including accessibility requirements; it can escalate at different rates for customers from certain regions or demographics; and it can exclude people who simply cannot use the interface at all. Naming those risks in the vision, alongside a commitment to monitor for them, is what turns fairness from a value into a practice. On the human side, add one more promise to the two above: that people will have input into how this is implemented, because a team that helps shape the rollout stops experiencing it as something being done to them. And on authority, answer three questions explicitly. Which decisions will AI support but not make? Which remain entirely human? And how does an AI mistake get escalated and corrected when it happens? Lucas's version of that last one fit in a sentence: the AI suggests, the agent decides and remains accountable, and anything the agent flags comes to him the same day.

Wiring In the Metrics

A vision without measures quietly becomes a wish. Lucas attached numbers to his so he could tell, six months in, whether it was working. He picked three kinds of metric on purpose. The first was the business outcome itself: resolution time and satisfaction score, the things his director actually cared about. The second was an adoption metric: what share of routine replies were starting from an AI draft, so he could see whether the tool was being used at all. The third was a human metric he refused to skip: agent satisfaction, measured by a short monthly pulse, because a vision that hit its numbers while burning out the team would be a failure dressed as a success.

The discipline is to define these before you start, not after, so you cannot quietly move the goalposts. Lucas wrote a simple baseline line for each: resolution time 2.5 hours today, satisfaction 78 percent today, AI-draft adoption 0 percent today, agent satisfaction 3.6 out of 5 today. Three months in, adoption was at 55 percent and resolution time had fallen to 2.0 hours, but agent satisfaction had dipped slightly because the review step felt clumsy. That dip was the signal to fix the workflow, not to push harder. Metrics did not just prove the vision; they told him where to steer next.

Your Vision Is a North Star, Not a Cage

One last point Lucas learned. A vision guides decisions; it does not lock you in. Six months into Phase 1, his data improved faster than expected, so he pulled routing forward. The vision still held because it was about outcomes, not a rigid schedule. And the words on the page were only the start. The real work was repeating the message, in stand-ups and one-on-ones, until every agent could explain in their own words why the group was doing this and what it meant for them.

Terms Worth Keeping Straight

• Strategic AI vision. A clear, domain-specific statement of how AI will create value, aligned to business objectives, honest about capability and readiness, and specific enough to guide decisions and prioritization.
• Domain. Your organizational area: a department, function, business unit, or region. Not the entire enterprise.
• Business objective alignment. Connecting AI initiatives to measurable business outcomes such as revenue, cost, satisfaction, speed, or quality, rather than to technology opportunities alone.
• Capability assessment. An honest evaluation of where AI genuinely creates value in your domain and where it does not, including where human judgment matters too much to delegate.
• Organizational readiness. The skills, cultural openness, data infrastructure, and resources needed to implement AI initiatives effectively.
• Sequencing. The planned order of initiatives, typically taking high-impact and high-feasibility opportunities first and building capability for harder ones over time.
• North star. A unifying goal that guides decisions and keeps a team oriented in a consistent direction.

Practice and Reflection

Reading someone else's vision is easy; writing your own is where the work is. Set aside an hour and go through these five exercises for your domain.

Clarify your business objectives. Write down three or four key outcomes your domain is accountable for over the next eighteen to twenty-four months. For each, ask whether AI could help and how, what success would look like and how you would measure it, and how realistic the timeline is both with AI and without it. That last comparison is revealing more often than people expect.

Map your opportunities. Draw the two-by-two grid with business impact on one axis and implementation feasibility on the other, and plot every AI opportunity you can think of. The ones landing in the high-impact, high-feasibility quadrant are your vision's focus areas. Everything else is a candidate for a later phase or for the cutting-room floor.

Assess your readiness. For each major opportunity, rate your organization from 1 to 5 on four dimensions: skills, meaning whether teams have or can build the data literacy and judgment required; data, meaning whether yours is clean, accessible, and governed; culture, meaning whether the team is open to this or will resist; and resources, meaning whether you genuinely have the budget and attention. Anywhere you rate a 3 or below, your vision needs to include readiness building rather than assuming it away.

Draft the statement. Write three or four paragraphs covering what you are trying to achieve, where AI will add value specifically, how you will sequence the work, what success looks like in numbers, and how you are addressing your team's concerns about readiness, roles, and accountability. Then share it with a peer or mentor and ask for the blunt version of their reaction.

Stress-test it. Ask yourself the uncomfortable questions. What could go wrong with this vision? What assumptions am I making that might not hold? If this takes 50 percent longer than I am projecting, is it still worth doing? And, the most useful one, what evidence would change my mind about this vision?

Finally, take two minutes on a smaller reflection. Look back at the past week and find one decision, task, or conversation where having a written vision would have changed your approach. What would you have done differently, and what would the outcome have been? That link between the concept and your own week is where this stops being theory.

Related Lessons

A domain vision is the front end of a chain of strategy work, and several other lessons pick up where it leaves off.

• Building an AI Roadmap takes the vision you just wrote and operationalizes it into a sequenced plan with phases, dependencies, and resources. Vision says what and why; the roadmap says in what order and with what.
• Measuring AI Impact and ROI defines how you find out whether the vision is actually producing the value you projected, which is what keeps a north star honest.
• Communicating AI Strategy Upward covers presenting the vision to senior leadership and stakeholders, since a vision nobody above you understands rarely gets funded.
• AI Governance Frameworks ensures your vision carries the governance and risk considerations it needs, particularly around what you have declared AI will not do.
• Building Organizational AI Culture creates the conditions your vision needs to survive contact with the team, because a vision executes only as well as the culture underneath it.

Key Takeaways

• Vision is strategy, not technology. Start from the business outcomes your domain owns, then ask where AI helps. If your statement only makes sense when you mention the technology, it is not a vision yet.
• Keep it to your domain. You do not need an enterprise AI strategy. You need a clear, honest vision for your team or department, and you can cede the company-wide picture to senior leaders.
• Be specific. Concrete outcomes, named opportunities, and real success metrics guide decisions. Generic "we will be AI-driven" statements guide nothing.
• Assess capability honestly. Sort your work into high, medium, and low potential, and focus the vision on the two or three genuinely high-impact opportunities.
• Readiness is part of the vision. Rate your team on skills, data, culture, and resources. Where you score low, build training and trust into the plan before you scale.
• Sequence to compound. Start with the high-readiness quick win, learn from it, then expand. Do not try to transform everything at once.
• Communication is the real work. The statement is just words. Repeating why the direction matters, until the team can explain it themselves, is what makes a vision real.