Recently, I co-led a workshop series on omnichannel orchestration use cases and was reminded how pivotal they are to both business and user success. Beyond defining requirements, use cases cut through ambiguity, align teams, and accelerate value realization. The group agreed resoundingly that gaining a deeper understanding of how different functions contribute to the overall solution helped in decision making about alignment. To me, the rare level of shared vision, commitment, and engagement was a great example of how important cross-functional collaboration is to project success.
At a Microsoft + EPAM event on AI that I attended, three main foundational friction points were called out: infrastructure readiness / maturity, having well defined user/customer experiences as a compass, and aligning on the right use cases.
So what are the ‘brilliant basics’ of use cases?
Why: Use cases can be “sexy” because they transform abstract concepts into tangible, high-value solutions. They help translate business needs into actionable requirements, bridge the gap between technical and business teams, and provide clarity on priorities, sequencing, and desired outcomes.
What: A use case describes how people (“actors”) interact with systems (technology / data / AI) to achieve a specific goal. Through both visual and narrative formats, use cases reduce complexity, validate real-world viability, and turn vague ideas into documented business, data, and technology requirements. They provide enough detail for planning and decision-making without getting lost in implementation specifics.
When: Early and often. Complex solutions require thoughtful planning, making early collaboration essential. Bringing stakeholders together at the start helps avoid rushed decisions, misaligned priorities, and suboptimal adoption. Regular check-ins keep teams focused on user needs, business KPIs, and desired outcomes.
Who: People are the secret sauce. Successful use cases require stakeholders to align on objectives and expectations – failing to do so often creates friction and weakens outcomes. Development teams gain a clearer understanding of the business problem they are solving, helping to prioritize and design more effectively. Business teams gain insight into technical considerations, enabling smarter investment decisions and more realistic planning. The result is a stronger partnership focused on shared goals.
Asking the right business questions is always the best place to start, which then shapes effective use cases. Taking the time to bring cross-functional teams, and leadership, along in the journey is equally important. Having internal talent that are fluent in user stories and use cases, and that understand customer experience, is key. Including change management and optimization processes as part of execution and continuous learning helps in achieving sustained, repeatable and scalable solutions.
Does this sound familiar? “What did we buy? What does our scope include? Why aren’t we getting what we need?Who owns this contract? What are the renewal terms and costs?”
Often asked for feedback on various technology platforms, I have encountered an assumption of vendor fault or the flawed technology. Invariably I push back and ask if there is clarity over what was bought, why and how it will be used (use cases), and by whom… then I ask if there is a designated relationship lead or SME connecting across relevant stakeholders. Lots to unpack here, but the original contract is often a root cause of missed expectations, frustration, or scope creep / complexity. This is even more of an acute issue when AI is a part of contract scope. I love contracts – truly, and I spend time to get them right in order to avoid pitfalls and scope creep later. Here are my top ‘tips’ (aka scars):
Contract scope: it’s critical to spend time on the MSA and scope of work (SOW) with the 3rd party – this may significantly impact (positive or negative) long term needs and complexity. If you inherit vendor or agency relationships, take the time to actually read all the agreements! Some basic things to think about on technology / data / AI related scoping:
Deliverables and services: clearly define what you are specifically ‘buying’ or contracting, associated deliverables, timing, license feels and/or renewal terms. Ideally build in incentives or disincentives so that everyone has ‘skin in the game’ and is accountable. Require business reviews and status reports. Ask for visibility into. and feedback on, feature roadmaps if applicable.
Ownership: define who owns what – process, content, data, source code, assets, etc.! Understand if the vendor is including anything proprietary that won’t be included when / if you severe the relationship. Understand what may happen if the vendor company is sold.
Stakeholder review of MSA and contacts: it is critical to involve the right SMEs during the scoping process, which may include input from data / data compliance, customer service, and technology groups in addition to the ‘regular’ stakeholders such as legal, finance, and the end users of the service or product/platform.
Team: this may seem basic, but require an allocation by function, role and level from the vendor as well as transparency to where and when they potentially offshore or white-label outsourced work.
Support: how many customer service / training hours does the vendor provide to the team, if applicable? How are SLA tiers (service level agreements) defined? What is the crisis management and/or escalation process? What’s the frequency of team meetings, etc. included in the scope? What reporting or status updates are included and at what frequency?
Integrations: will the new partner systems natively integrate with yours, or are they different from your internal systems? Think about customer experience management related platforms (e.g., analytics, CRM, marketing automation systems like DAM, data/AI modeling and reporting platforms/solutions, etc.). If it’s not a native API, then negotiate a cap or flat fee for this – for example, native APIs may cost $0-$50k+, but custom work may run $250k+ per integration.
Data, data, data: it is vital to ask who owns and / or has access to the data, and how will the data will be used, transmitted, or mined. Make sure your company is ready to receive the data (e.g., your company’s data lake or ‘data estate’ is set-up) and determine if any custom configuration, remediation, or integrations are needed vs. native API’s. Other data related questions: will the Compliance function report on / monitor this data, and if so, is this included in the SOW? Will the provider include opt-out suppression with their database if applicable? How are they keeping the data compliant and clean? Has the vendor ever had any data breaches? Etc.
Exclusivity: if there is an investment stake, how exclusive is it? What benefits will you get that others do not? How are competitive conflicts handled? Will competitors have access to randomized data and insights that includes your programs? What does the revenue-share look like over time and what is the tiering? Will you get first right to test and adopt new roadmap features as well as visibility and input into the partners roadmap?
Scale: if applicable, how transferable is the initial program or pilot to the next use case? What part of the program systems, content, and infrastructure can be templated? What’s the cost to scale and are there tiered discounts?). What is expected of local market resources, headcount, and technology?
Compliance: define the local / global compliance process, risk, and accountability. How will the vendor confirm and comply with your systems, policies, and reporting? If patient related, how will the partner monitor community or social media comments for AE’s/SE’s? Require the partner to comply with local government or healthcare system compliance requirements, depending on relevancy in the project scope.
Assets: my top complaint in contracts is that companies neglect to require the vendor to automatically provide copies of associated source code/files as permitted contract wise, downloads of all content and creative, etc. at the conclusion of development (as applicable or allowable). When related to content, this should no additional cost (often companies end up not being able to track this down or paying for it again later). Require that the vendor automatically upload all content assets into a digital asset management (DAM) system per their taxonomy and inclusive of all rights management terms / documentation. Not doing this can result in delays, legal risk, and added cost.
Stability: understand how the contracting partner is funded and how secure they are financially. Be clear on implications and accountability if the company goes under, merges, or is acquired.
Yes, the above is a long and ‘dry’ list – but the devil is in the details. Accountability is on both sides – the client or purchaser and the vendor or supplier. Taking the time to get the minutia right will set up for a positive outcome and partnership. What can you do in addition to the above tips?
Use AI to: scan and synthesize prior RFPs and/or contracts – in your area but ideally across your company, inventory existing technology and/or software/SaaS based licenses to the RFP use cases you are targeting, align user requirements and prioritize use cases. Carpe diem!
