Your first 90 days as a chief experience officer

A plan for a role without a playbook

The chief experience officer is a young role. Most new CXOs arrive without a predecessor’s notes or an agreed definition of the job. That makes the first three months harder, and it also means you get to decide what the role is for.

This guide splits those months into four phases. Each phase has a short list of tasks, and each task comes with the questions we would ask if we were in your seat. The questions are the useful part. Print them and write the answers down.

Weeks 1–2: orientation and understanding

The first two weeks feel slow, and they set up everything after them. You are learning what technology the organization runs and what the people using it think of it. You are also checking that the security and compliance basics are in place. Decisions made without this groundwork tend to get reversed later.

There are five tasks in this phase.

1. Take an inventory of tools and technologies

List the tools each department uses for customer experience: CRM systems, feedback platforms, analytics tools, project tracking and any automation. You will probably find more than anyone expected. Teams that couldn’t get what they needed from the official systems often bought or built their own, and those tools rarely show up on a central list.

Questions to guide the inventory:

• What are your project management tools? How do your employees stay on task?
• Do you have any automation tools today? What are they?
• Does each department have its own tools for the same job? Where do they overlap?
• Where is data collected and stored? Is anyone entering the same data in two places? Make notes.
• Is the data you collect good data, or is human error costing you money?
• How do you gather feedback from employees about the tools they use?

2. Meet with IT and operations before you decide anything

It is tempting to form opinions about the tech stack in your first week. Talk to the IT and operations teams first. They know the technical infrastructure behind your customer experience work, and they know where it breaks.

Questions to ask them:

• Which tools help you do your job efficiently?
• Which tools do you wish you did not have to know?
• Which tools are we using well? Which ones do you wish we had invested more in, and why?
• What do you hear from end users again and again? What keeps us from fixing it: time, a lack of people, or not having the right tools?
• Where do most of the bottlenecks happen?

Ask the teams to show you how they use the tools. Twenty minutes watching someone work through a request tells you more about the user experience than any documentation.

3. Study how change has gone before

Find out how the organization manages change, and how well it worked last time. Interview several departments about the most recent rollout and ask what they wish had been done differently. Their answers are the best predictor you have of how your own changes will land.

Keep two things in mind while you do this research:

• Change is about people more than technology. You need people to want the change, or they will find ways to keep their old habits. Think of a time you tried to change a habit of your own. What actually worked?
• Some parts of the organization are harder to change than others. Which ones are they? What limits or restrictions do they work under, and are those slowing the organization down?

4. Review data security and compliance

Review how customer data is protected and which compliance rules apply, so you know where your industry’s standards and regulations set the boundaries. Understanding how data is managed will shape your choices later, especially if you consider consolidating tools. Technology has moved on, and some safeguards put in place years ago may no longer be needed. Others may be missing.

Questions to guide the review:

• How do we handle sensitive information?
• When did we last review our technology and do maintenance on it?
• During past implementations, did we set something aside to come back to later and never return to it?
• Is any of our technology end-of-life? Is there a plan to replace or upgrade it soon?
• How do we confirm that the data we hold is accurate?

5. Look for integration gaps

By now you have probably noticed places where tools and systems could be connected to give customers and employees a smoother experience. Write them down. These gaps are usually where people lose the most time.

Ask the people you interview:

• How many different systems do you log into each day to do your job?
• How many systems do you have to visit to get the information and data you need?
• Do you have to interrupt colleagues during the day for information you cannot reach yourself?

Weeks 3–6: strategy development

In week 3 the work moves from listening to deciding. Over the next four weeks you write the technology roadmap, test whether you need new tools, evaluate vendors and plan how the change will roll out. Every tool you keep or add should serve the customer experience you are trying to create.

1. Develop your technology roadmap

The roadmap will take most of this phase, and it needs a lot of collaboration. Go back to IT and the department heads and dig deeper into what they told you in the first two weeks. Use their feedback to separate quick wins from long-term projects.

To write a roadmap, you need to know where you are and where you are going. Answer these questions first:

• What is working very well at the organization today?
• Where does the organization want to be in six months? In a year?
• What are its goals? Saving cost, a better user experience, security compliance, modernization, or some mix?
• Did you find any pressing problems in the first few weeks that should be fixed right away?
• What themes keep coming up across the department heads?

Once you understand the starting point and what the organization expects, you can begin drafting the roadmap.

2. Decide whether you need new tools at all

Try the tools you already own before you add anything new. Training employees and rewiring workflows is expensive, even when a new tool promises to save time and money. Think about the long-term effect on the organization of every tool you add or change.

How to assess whether you need something new:

• Are there gaps that none of your current tools fill?
• Are there specific pain points or inefficiencies that no current tool can address?
• Are there redundant tools that could be consolidated into one better tool?
• How much can your current tech stack grow and scale?
• How would adding, removing or replacing a tool affect productivity, efficiency and the experience of the people using it?
• What is the cost and benefit of investing in new technology compared with keeping things as they are?
• What outcomes would you expect from buying something new?

Sometimes you genuinely don’t have the right tool. The organization has been making do with manual work, or with a tool that was never designed for that business process. Even then, weigh how a new tool will change the daily work of the people who use it before you buy.

3. Evaluate vendors, current and new

Evaluate the vendors you already pay as well as the ones you are considering. Meet the vendors whose products shape your users’ experience, learn how their business works, and make sure the relationship is productive for both sides.

Factors to consider:

• Contract and return. What does the current contract cost? Is the organization getting the return it expected from the product?
• User satisfaction. How satisfied are the people who use this vendor’s tools? Are there reviews or testimonials that speak to the experience the vendor provides?
• Configuration and flexibility. How far can the tool be tailored to your business needs and preferences? At what cost?
• Training. Does the vendor provide training and resources to help users get the most from the tool?
• Support. How responsive is the vendor’s support team? Do they deal with questions, concerns and technical issues promptly?

4. Plan the change

A change plan needs input and agreement from many departments. Change only works when the people affected understand why it is happening and how. Put yourself in their position and answer the question they will ask first: what’s in it for me?

Talk to your security officer early

Contact your security officer before you adopt or change any technology. Your organization almost certainly has a data governance framework it expects you to work within. Discussing your plans with IT and security before you act saves rework and earns you allies in two teams you will rely on.

Weeks 7–10: implementation and execution

This is where your research and planning turn into action. You launch a pilot, train and onboard the people who will use the new tools, configure those tools to fit the organization, and start monitoring how it all performs.

1. Run a pilot first

Trying to change everything at once is a reliable way to change nothing. Take your time and start with a pilot. People who had a good first experience become the ones who carry the change to everyone else.

1. 1

   Set the scope. Write down the target audience, the timeframe, the resources available and how success will be measured.

2. 2

   Recruit early adopters. Find people who pick up new technology quickly and like talking about it. People who also enjoy teaching others are even better.

3. 3

   Choose a representative group. Make sure the participants cover a range of roles and user experiences.

4. 4

   Gather feedback. Use surveys, interviews and usage data to learn what participants experienced, where they struggled and what they would improve.

5. 5

   Iterate. Adjust the pilot based on what you heard.

6. 6

   Evaluate against your objectives. Compare results with the objectives and success measures you set in step 1.

7. 7

   Measure the effect on KPIs. Look at user engagement, customer satisfaction and revenue, or whichever indicators your change plan named.

8. 8

   Plan the wider rollout. Ask the early adopters from step 2 to help you scale the pilot to a larger audience.

2. Train and onboard people properly

Don’t introduce new tools and processes without planning the training and onboarding that go with them. Make sure everyone can get to the resources they need to find answers and finish their work quickly. You are probably asking people to break habits they have had for years, so give them more help than you think they need.

Everyone wants to do their job well. To win people over to a change, show them how it makes their own job easier.

3. Customize and configure

If you followed the earlier steps for choosing tools and evaluating vendors, this part can be enjoyable. Work with the vendors and IT to configure the new tools around the specific needs and requirements of your organization.

4. Plan data migration and integration carefully

Don’t cut corners on migration and integration planning. Depending on the type of data, the security policies that apply and the tools involved, moving data can be the hardest step to get right. Work out a plan with IT, security and the vendors before anything moves into production.

5. Keep monitoring and adjusting

You never really leave this step. Keep tracking how the new tools perform and what the people using them say, and adjust as you learn.

Weeks 11–12: evaluation and planning ahead

By week 11 it is time to step back and look at what you have done. The last ten weeks probably felt like a blur. Meaningful change takes longer than ten weeks, and improving the user experience is a long effort with no shortcut.

Use these two weeks to measure the impact of what you started and find the areas that need more attention. Go back to the KPIs in your change plan and the success measures you set for the pilot, and compare them with where you started.

Treat the 90-day plan as a starting point. Most of what you set in motion will take six months or longer to show its full effect, and there is no formula that makes the CXO role finished. The questions in this guide stay useful long after the first 90 days. Come back to them each time you take on a new program or a new department.

Where Kinetic fits

Many CXOs finish their first two weeks with the same finding. Every department has its own tools, and people log into several systems to finish one task. The official systems are hard enough to use that teams have built their own workarounds. Replacing those systems is rarely the answer, and the guide’s advice to use what you own first applies here too.

Kinetic is the build platform for that situation. You keep the systems you already run and build the portals, forms and workflows that connect them, so a customer or employee makes one request and the work moves across the systems behind it. AI drafts the forms and workflows inside Kinetic through MCP, and your team reviews and runs them.

If your inventory turned up integration gaps, see how Kinetic builds on the systems you already own, or book a working session. It is a free two-hour session where we map one process with you and finish with a written plan.