Rob Urban / Strategy · Agents · Organizational change
AI Transformation Strategist.Improvement is the point.
I connect enterprise priorities, hands-on AI agent development and the people who make change work. The measure is what gets better for the business and the people it serves.
The principle
A company should be able to explain why life will be better after the transformation. For its customers. For its employees. For the people responsible for the result.
01 / The reason to change
Keep what works. Improve what matters.
The employee with six windows open is often doing something impressive. They are holding together a process the company has never quite finished connecting.
They know which system has the current answer, which manager can make an exception, and which reassuring message should never be sent until somebody checks the actual reservation, order or account. Customers experience that effort as service. Leadership may see only the time it takes.
When I look at an AI transformation opportunity, I want to understand that work before proposing its replacement. Some of it deserves automation. Some deserves better information. Some deserves a person with more authority and fewer obstacles.
As an AI transformation strategist, I help organizations decide where AI can improve performance, turn that decision into a deliverable program, and build the agents and workflows that support the change. My work connects executive priorities to customer journeys, technical decisions, employee capability and measurable operating results.
I have extensive experience across strategic advisory, enterprise technology, conversational AI delivery and organizational change. What interests me is the connection between those disciplines. A service promise becomes a workflow. The workflow becomes an architecture and a conversation. The resulting experience either helps someone accomplish something or gives them another obstacle to negotiate.
Transformation has to earn the disruption it creates. If a familiar process is dependable, economical and appreciated by the people using it, replacing it requires a persuasive reason. New software has learning costs. A migration interrupts attention. An agent can create new kinds of exceptions. Those costs belong in the decision before the announcement.
Sometimes that means a substantial redesign. Sometimes it means connecting two existing systems, simplifying an approval or giving the service team a reliable answer in the moment they need it. I am comfortable recommending any of those outcomes. A useful strategist should also be comfortable saying that the proposed transformation is larger than the problem.
02 / Strategy that stays involved
I work across the distance between a funded priority and a working service.
A VP of Customer Experience may need to improve resolution without making customers feel pushed away. A Director of Operations may be carrying a growing backlog with the same team. A technology leader may need to make both ambitions work inside a complicated estate of systems, permissions and contracts.
I can contribute at each of those levels: structuring the problem, building the business case, facilitating the difficult decisions and translating them into something a product manager, engineer and service leader can deliver together. I also work hands-on with agent design and development. That proximity to the build improves the advice.
When a prototype exposes an unresolved policy, I bring the decision back to the right owner. When a strategy assumes an integration can perform a transaction it cannot support, I revise the plan. When an employee explains why a proposed handoff will fail during the evening shift, that becomes a delivery requirement.
| Where I am working | What I make concrete |
|---|---|
| With the sponsor | The improvement worth funding, its economics, the decision authority and the conditions for continuing. |
| With functional leaders | The service journey, operating changes, dependencies and measures each team can own. |
| With product and engineering | Agent scope, conversation behavior, tool boundaries, acceptance tests and release decisions. |
| With employees and managers | The new daily work, training, escalation paths, feedback and support after launch. |
In a C-suite discussion, I explain the commercial choices and the uncertainty around them. In a working session, I need enough technical detail to understand why an action failed and enough customer insight to recognize when a technically correct answer is unhelpful. Both conversations concern the same investment.
My AI solutions architecture work goes deeper into system design. Here, the emphasis is the transformation mandate: getting multiple functions to deliver and sustain a better way of operating.
03 / Before the roadmap
Give the disagreement enough detail to become useful.
“Improve customer experience” can conceal very different intentions. Finance may want lower service cost. CX may want fewer repeat contacts. Operations may want predictable work. Digital may want more self-service. Technology may need to retire infrastructure that has become difficult to maintain.
I use interviews, working sessions and evidence from the actual service journey to turn those intentions into a shared decision. I want recent examples of completed work, failed work and work that required someone unusually experienced to rescue it. I want frontline participation as well as leadership sponsorship.
Suppose the initial complaint is a high volume of calls about order status. One hypothesis is that an agent could answer those calls. Another is that customers are calling because an expected update never arrives. A third is that the status itself is misleading. The investigation should distinguish those conditions before the company pays to automate an answer.
The resulting brief identifies the people affected, the current baseline, the desired improvement, the process owner, the constraints and the evidence that would change our recommendation. It also records disagreement. A director cannot execute “everyone supports the vision” when two departments have incompatible definitions of success.
A useful decision
Retain the existing booking system. Repair the availability feed. Pilot assistance for a bounded group of inquiries. Require human approval for exceptions. Expand only if completed bookings become easier without increasing incorrect promises or repeat contacts.
That is specific enough to assign work and challenge assumptions. It gives the team permission to improve the service without turning every weakness into a platform replacement.
04 / Where the work changes by industry
The business determines the experience.
My experience across hospitality, travel, attractions, marketing, professional services and enterprise technology informs how I approach these problems. The examples below show how I would scope and deliver the work in different company settings.
These are illustrative engagement scenarios, not accounts of named client deployments or claims of measured results. The details and measures would be established with each organization.
Independent hotels / Resort groups / Private clubs
Let the guest arrive with fewer unanswered questions.
A hotel group wants to automate pre-arrival inquiries. The attractive first demonstration answers questions about breakfast and check-in. The more consequential work begins when a guest asks for connecting rooms, a particular accessibility feature or an arrival arrangement outside normal hours.
I would work with the hospitality and technology leaders to distinguish published facts, live inventory, requests and confirmed commitments. A property description can support an explanation of room types. It cannot establish that two specific rooms are available together next Friday. The agent needs an authoritative source or a clear route to someone who can confirm.
The build might combine approved property information with reservation lookup, a request workflow and a staff handoff. A guest-facing response should say what has been confirmed, what remains pending and who owns the next step. At a private club, the same discipline applies to member eligibility, event access and booking privileges.
Employee assistance may produce the better first release. Give reservations staff an accurate briefing and the next useful question, then expand customer-facing automation where the evidence supports it. In luxury service, time saved should create room for attention.
I would measure: request accuracy, staff preparation time, repeat inquiries, completed arrangements and whether the guest has to explain the same need again.
Travel businesses / Vacation rentals / Destination operators
A changed itinerary has consequences in several places.
Imagine a traveler whose arrival changes after a transfer has been booked and property access instructions have been scheduled. A conversational system can acknowledge the change immediately. The operational work is determining which downstream arrangements need updating and which supplier has actually accepted the new plan.
I would map those dependencies with operations, reservations and the partners responsible for fulfillment. The agent could gather the change, identify affected services and prepare or execute permitted updates. It should retain an explicit status for each arrangement rather than announce that everything is handled after sending a single message.
The traveler needs a coherent answer. Staff need a record of confirmations, unresolved items and deadlines. Supplier failure needs an owner. This is where front-office conversation and back-office orchestration become one service design problem.
The test: did every affected arrangement reach a confirmed or clearly escalated state before the traveler needed it?
Theme parks / Museums / Zoos / Cultural attractions
Help a family plan a visit the attraction can actually deliver.
A family may be asking about tickets while trying to solve something more complicated: whether the visit will work for a young child, an older relative, a school group or a person with a specific access need. A ticket link answers only part of that question.
I would bring guest services, admissions, membership and operations into the design. Which information changes with weather or operating conditions? Who owns event availability? Which accessibility details are verified? When should a group inquiry become a conversation with a coordinator?
An agent could explain approved visit information, help visitors find the right ticket category and route a group request with the relevant details attached. It should never infer a safety exception or promise that an experience is suitable based on an incomplete description.
Behind the scenes, interaction patterns can show where the website, signage or confirmation email needs improvement. If the same avoidable question keeps appearing, I want to fix its source as well as improve the answer.
The useful evidence: fewer preventable arrival problems, appropriate ticket choices, clearer group handoffs and better-supported guest services staff.
Professional services / Agencies / Legal practices
A faster acknowledgment should lead to a better first conversation.
Consider a firm receiving inquiries across forms, email, phone and messaging. The immediate temptation is to respond faster everywhere. The deeper opportunity is to prepare the right person to respond well.
I would define what the firm needs to know, what it should avoid collecting at this stage and which inquiries need prompt human attention. The agent can organize the request, identify missing information and route it according to approved criteria. A legal practice would keep professional assessment and engagement decisions with the responsible people.
Access boundaries matter. An assistant preparing an inquiry summary should not search unrelated client materials simply because those documents are in the same storage system. A useful internal briefing includes relevant facts, unresolved questions and provenance for retrieved information.
The operating change is equally significant: somebody must own the queue, accept the handoff and close the loop. Otherwise the company has replaced an unanswered form with a more eloquent unanswered form.
Manufacturers / Distributors / Field service companies
Follow the exception all the way to fulfillment.
An industrial customer asks whether an alternative component can arrive sooner. Sales sees the account, the ERP contains inventory and order information, and a technical specialist understands compatibility. The customer experiences one question. The company sees three departments.
I would map which decisions are rules-based, which require current system data and which require technical judgment. An agent might retrieve order status, assemble approved product information and create a well-prepared exception task. Compatibility approval stays with the designated expert unless the company has an explicitly validated rule for that decision.
For a field service business, the corresponding problem may be dispatch. A schedule opening does not establish that the right technician, equipment and parts are available. The workflow must preserve those constraints before it offers an appointment.
What matters: a correct, fulfillable commitment, less internal chasing and a clear owner when the standard process cannot complete the request.
Enterprise software / Subscription businesses
Make resolution survive the handoff from support to engineering.
A software customer reports a recurring failure. An assistant can summarize the ticket and suggest an article. A more useful design recognizes the customer’s environment, checks authorized account context, gathers reproducible details and separates a known workaround from an unresolved defect.
I would partner with product, support and engineering on the evidence required for escalation. The agent should help create a useful defect report and keep the customer informed without inventing a release date. Account boundaries must remain intact during retrieval and diagnosis.
There is also a prioritization decision. If a confusing product setting causes repeated contacts, a product improvement may remove more effort than a sophisticated support agent. I want the transformation program to surface that choice rather than protect its original AI scope.
I would track: verified resolution, reopened cases, avoidable escalations, time waiting between teams and whether recurring causes are being removed.
Regulated service operations / Financial institutions
Give specialists a better-prepared case.
In a tightly controlled operation, workforce augmentation can be a sensible starting point. For example, an assistant could organize permitted records, identify missing evidence and prepare a source-linked chronology for a specialist reviewing an unusual account event.
I would work with the institution’s control owners to specify access, retention, review and decision authority. The agent’s summary needs to preserve uncertainty and distinguish recorded facts from inferred relationships. The specialist should be able to inspect the underlying evidence and correct the summary.
I would not make an automated final judgment about wrongdoing the default design. The program needs boundaries appropriate to the institution, validated by its responsible experts. The transformation opportunity is better preparation, less repetitive assembly and a review process whose actions can be reconstructed.
The standard: case preparation improves while evidence quality, required review and accountable human decisions remain intact.
05 / From scenario to working agent
Take one request seriously enough to build the whole path.
Return to the hotel guest asking to move a reservation by one night. This is a useful build example because a friendly answer is easy to produce and a correct change requires several decisions.
I would start with a product manager and the relevant engineers by defining the permitted task. Which reservations qualify? Which channel can establish identity? Can the system change a prepaid booking? Who approves a rate difference? What happens when the reservation service times out after a request has been submitted?
- Understand and verify. Identify the requested change and authenticate through the approved process before accessing reservation details. Ask for missing information without collecting unnecessary personal data.
- Check the actual options. Retrieve current availability and applicable conditions from the systems that own them. Treat retrieved text as information, never as authority to change access or approval rules.
- Explain the proposed transaction. Present the dates, price difference and material conditions in language the guest can understand. Obtain the required confirmation before committing the change.
- Execute within explicit authority. Call a narrowly scoped action with server-side permission checks. Design retries so a delayed response cannot create duplicate changes or charges.
- Verify and close the loop. Check the resulting reservation state. Confirm completion only when the system supports that claim. If the outcome is uncertain, reconcile it or transfer a complete record to a person.
This work includes prompts and conversational design, but also tool contracts, state handling, evaluation data and failure recovery. I can build and refine the experience while working with engineers on the controls that must be enforced outside the model.
Voice, chat and asynchronous messaging need different treatment. On a call, the system must handle interruptions, recognition errors and the time a caller will tolerate silence. In messaging, someone may return hours later, after inventory or pricing has changed. Persisted context helps resume the conversation; it does not remove the need to recheck time-sensitive facts.
A handoff should carry the verified identity state, requested outcome, relevant facts, actions attempted, results and unresolved decision. The employee should be able to continue the work. The customer should know whether the transfer is immediate, queued or a callback request.
I favor the simplest architecture that reliably completes the job. Some tasks fit a defined workflow. Others benefit from an agent choosing among permitted tools. Anthropic’s engineering guidance on effective agents makes a useful distinction between predefined workflows and model-directed action. That distinction helps keep autonomy proportional to the task.
Test what happens when the easy answer is wrong.
Before release, I want representative cases covering ordinary requests, ambiguous wording, inaccessible records, contradictory policies, unavailable tools, duplicate submissions, interrupted sessions and requests outside authority. I also want tests where the correct behavior is to ask a question, decline an action or transfer to a person.
Averages can hide important failure modes. An agent may perform well overall while repeatedly mishandling one room category, language, channel or exception. I would review results by those meaningful segments and investigate the full action trace, with sensitive data handled according to the organization’s policies.
The launch decision should rest on agreed acceptance criteria and an operating plan. At high conversation volumes, the design also needs load testing, dependency limits, monitoring, cost controls and a practical way to narrow or disable automation when conditions change.
06 / People, process and the platform
A cloud migration moves the service logic, too.
When transformation includes moving from an on-premises contact center to a cloud platform, the work extends beyond transferring telephone numbers and recreating queues. Years of business decisions may be embedded in routing, schedules, agent states, reporting definitions and exception handling.
I would build an inventory with the people who run the operation: automatic call distribution rules, IVR and virtual-assistant paths, skill assignments, business hours, overflow behavior, callbacks, recording policies, quality processes, workforce planning and channel continuity. Then we decide what to preserve, improve or retire.
Terminology needs reconciliation. An “available” employee, an “answered” interaction or a “resolved” case may mean something different in the new system. Without mapping those definitions, leadership can mistake a reporting change for an operating improvement.
I would plan staged validation, representative routing tests, staffing coverage for the transition, cutover responsibilities and rollback criteria. An AI initiative should not quietly depend on a simultaneous platform migration unless the program has accounted for that dependency.
Make the new way of working worth learning.
Employees deserve a clear explanation of what is changing and why. They also deserve time to learn, a place to raise concerns and an honest account of how their work will be measured. A system introduced as assistance will lose credibility quickly if managers use its early errors against the people asked to test it.
I operationalize change management through role-specific preparation: supervisors practice reviewing agent output, service staff rehearse exceptions and handoffs, technical owners rehearse failure recovery, and leaders agree how feedback changes the release. The training must include actual work, with support available after the launch meeting.
AI can remove easy interactions and leave people handling a more demanding mix. Workforce planning and quality management should reflect that change. A longer average handling time may accompany better service if the routine work has disappeared and the remaining cases require more judgment.
Adoption is a design signal. When experienced employees keep a workaround, I investigate what it protects. It may reveal a missing capability, an unrealistic target or a real exception the transformation team overlooked.
07 / The business case
Count the improvement the organization can actually use.
A reduction in handling time can create capacity. It becomes financial value through an operating decision: absorbing growth, reducing overtime, improving response times or changing staffing requirements. Those outcomes have different assumptions and should appear separately in the business case.
Consider a deliberately simple planning example. A team handles 20,000 eligible interactions per month. If an assistant saves two minutes on 60 percent of them, the gross capacity released would be 400 hours. If review, corrections and administration require 100 hours, the modeled net is 300 hours.
Illustrative arithmetic, not a client result
20,000 interactions × 60% × 2 minutes ÷ 60 = 400 gross hours.
400 − 100 hours of added work = 300 modeled net hours.
Those 300 hours are not automatically payroll savings. The organization must determine where the time appears, whether it is usable, what demand it can absorb and whether the benefit persists. The financial model also includes implementation, integration, platform usage, ongoing evaluation, training, maintenance and support.
I would test the assumptions with a bounded pilot and a comparable baseline. Changes in seasonality, staffing, demand or case complexity can distort a simple before-and-after comparison. The measurement plan should identify those influences rather than credit every favorable movement to AI.
My scorecard combines completion, service quality, employee effort, risk and economics. Containment matters only alongside evidence that the customer actually achieved the intended outcome. A conversation ending is not proof of resolution.
Interaction analytics can help identify recurring friction and candidate improvements. Automated summaries and classifications need sampling against real interactions before leaders rely on them. An attractive dashboard does not settle whether the underlying labels are accurate.
The program should have an explicit stopping rule. If the agent adds review work, increases repeat contact or cannot meet an important quality condition, we revise the design, narrow the scope or stop. The investment decision is stronger when stopping remains a legitimate outcome.
08 / Running the transformation
Give every milestone a decision and an owner.
Multiple agent projects can look independent until they compete for the same data team, identity service, policy owner or contact center release window. I keep those dependencies visible and sequence the work accordingly. Five simultaneous prototypes are of little help if none can get the integration required for a useful pilot.
A practical program moves through discovery, bounded development, controlled use and expansion. At each stage, I want a named owner, an acceptance decision and the evidence needed to make it. The roadmap should show which assumptions have been tested and which remain open.
Governance belongs in those decisions. Who owns the knowledge source? Who approves a new action? Who reviews a material failure? Who can suspend the agent? The NIST AI Risk Management Framework offers a voluntary structure for organizing AI risk work. I would use an appropriate framework to support the operating process, with responsibilities that people can actually carry out.
I also want the program to leave the organization stronger. Reusable evaluation cases, conversation patterns, integration contracts, decision records and training materials can reduce the effort of the next release. Industry-specific playbooks should preserve useful lessons while making room for differences between businesses.
That balance matters to me. A resort, a museum and an enterprise software company can share good engineering practices. Their customers, commitments and operating constraints deserve their own design.
My broader AI business strategy work addresses organization-wide priorities. AI and marketing systems integration addresses customer data and commercial workflows. This role brings the transformation program and agent delivery together around a specific operating improvement.
09 / Practical questions
What a working relationship can look like.
When should a company bring in an AI transformation strategist?
When the desired improvement crosses functional boundaries, the investment requires a credible business case, or the organization needs help connecting strategy to delivery. I can contribute during opportunity definition, program design, an active agent build or a rollout that needs clearer ownership and adoption support.
Do you work directly with engineers and product managers?
Yes. I work across scope, architecture tradeoffs, conversational design, agent development, evaluation and release readiness. The responsibilities should be explicit so the team knows which decisions I own and where engineering, product, security and process owners retain authority.
Does transformation require replacing our existing systems?
No. I begin with the improvement required and assess the current environment against it. Existing tools may need better integration, clearer information or a simpler process. Replacement is justified when it solves a material limitation and the expected benefit supports the cost and disruption.
Is your approach tied to one technology vendor?
I approach the work through business outcomes and delivery requirements. Platform-specific capability needs to be verified against the actual environment, with the right specialists involved. Tool selection should reflect integration, service, operating and governance needs.
How do you keep the work from becoming another pilot that never scales?
I identify the production owner, integration path, operating costs, acceptance criteria and adoption requirements early. A successful prototype earns a next step when those conditions are viable. Expansion follows evidence from real use, with ownership and support in place.
Further reading: The engineering and governance references linked above support those specific discussions. The scenarios, planning arithmetic and proposed engagement approach are my own illustrations; they are not published client case studies.