AI voice assistants are changing the way enterprises handle customer and employee interactions. Instead of relying on manual workflows or long support queues, a well-built voice assistant can answer questions, book appointments, route issues, or troubleshoot problems through natural, conversational exchanges. The result: callers get to a meaningful action sooner, agents stop repeating themselves on routine cases, and the operations team has a system that can scale with demand without scaling headcount linearly.
Building a custom voice assistant for your enterprise may seem complex, but it doesn't have to be. With the right approach, you can create a system that becomes an extension of how your business already works, integrating with your existing systems and data rather than sitting on top of them.
This step-by-step guide on how to build a voice assistant covers the tools and technologies you need, the full build process, and the best practices that separate AI voice assistants that actually work from ones that frustrate users and get quietly decommissioned.
Key Takeaways
- Building an AI voice assistant starts with clear goals and defined use cases, ensuring the solution delivers measurable value from day one.
- A successful voice assistant relies on strong ASR, NLU, and TTS working together to create natural, real-time conversations.
- Secure integrations and flexible infrastructure are essential for connecting voice assistants to enterprise systems while protecting sensitive data.
- Training with real-world data and continuously refining skill coverage and conversation design improves accuracy, adaptability, and long-term performance.
What Is an AI Voice Assistant?
An AI voice assistant is a software system powered by artificial intelligence that interacts with users through spoken language. It uses automatic speech recognition to convert speech to text, applies natural language processing to interpret what the user wants, determines the right action or response, and delivers that as synthesized speech via text-to-speech. Modern voice assistants handle multi-turn conversations, maintain conversation history across exchanges, and connect to backend systems to take action, not just answer questions.
Voice Assistant vs. Voice Agent vs. Chatbot
These three terms get used interchangeably, but they describe different things.
A chatbot is the simplest of the three. It responds to text input, typically through a website widget or messaging app. Most chatbots handle a narrow range of scripted exchanges and struggle with anything that falls outside their defined patterns.
A voice assistant adds a speech layer. It uses automatic speech recognition (ASR) to convert voice input to text, processes that text using natural language understanding, and returns a spoken response via text-to-speech (TTS). The defining characteristic is the voice interface. Voice assistants like the ones in this guide are designed for spoken interaction, which changes how you design conversations, handle latency, and manage errors.
A voice agent goes a step further. A voice agent doesn't just respond to queries; it takes action. It can execute multi-step workflows, call APIs, make decisions across systems, and complete tasks on behalf of the user. A voice agent handling a billing dispute, for example, doesn't just answer "your balance is $47." It looks up the account, reviews recent transactions, identifies the discrepancy, and initiates a resolution, all within the same conversation.
In practice, the lines blur. The market has shifted from chatbots and conversational AI toward agent-driven interfaces, and modern enterprise voice assistants often include agentic capabilities. When someone says "build a voice assistant," they usually want something with real action-taking ability: less conversational AI, more action-taking agent. This guide covers both and explains how they fit together.
How AI Voice Assistants Work
Every voice assistant pipeline runs through three core stages.
First, automatic speech recognition (ASR, also called speech-to-text) converts spoken audio into text. The speech recognition engine handles the raw complexity of the user's voice: overlapping words, background noise, varied accents, and domain-specific terminology. The quality of your ASR output directly constrains everything downstream.
Second, dialogue understanding processes the transcribed text. This is where the system figures out what the user actually wants and what the right spoken answer is. It maintains chat history across turns so the assistant can handle follow-up questions, corrections, and topic shifts without losing track of the conversation.
Third, text-to-speech (TTS) converts the system's response back into audio output. Modern TTS systems built on neural networks produce natural-sounding voices with controllable tone, pace, and emphasis, which matters more in voice than in text because users hear every awkward pause.
These three stages work in a tight loop. Every spoken turn goes through ASR, dialogue understanding, and TTS before the user hears a response. That pipeline needs to run fast. Latency is visible in voice in a way it isn't in text.
Key Components for Building a Voice Assistant
Automatic Speech Recognition (ASR)
Automatic speech recognition converts spoken words into text that the system can process. When choosing a speech recognition solution for an enterprise build, the criteria that matter most are:
- Accuracy: Reliable transcription of audio input even in noisy call center environments, with varied accents and speaking styles.
- Language support: Coverage for all the languages your users speak.
- Real-time processing: Low enough latency to maintain conversational turn-taking.
- Adaptability: The ability to learn domain-specific vocabulary, product names, and industry terms that general-purpose speech recognition models often mangle.
Teams building custom voice assistants often evaluate open-source ASR options such as OpenAI Whisper, which handles multilingual and accented speech with broad coverage. Legacy projects like Mozilla DeepSpeech are still available as historical references, but the repository is archived, and DeepSpeech is no longer a safe default for new production builds. Enterprise deployments typically also evaluate commercial ASR providers, weighing accuracy benchmarks for their specific domain, latency requirements, and support expectations.
For wiring ASR and TTS providers into a Rasa voice agent, see the Speech Integrations reference for currently supported providers and configuration patterns.
Natural Language Understanding (NLU)
Once speech recognition produces text, NLU figures out what to do with it. Traditional natural language processing approaches built NLU around predefined intent categories, which required extensive manual labeling and broke down whenever users phrased something in an unexpected way. Heavy intent libraries are slow to maintain and brittle in production.
Rasa's approach centers on dialogue understanding, which uses large language models to evaluate the full context of a conversation rather than pattern-matching against a fixed list of intents. Modern transformer models, the core architecture behind today's language models, can interpret what the user actually means rather than what keywords they used. That means the system can handle interruptions, multi-turn exchanges, ambiguous phrasing, and topic shifts without requiring a new intent for every variation. Skill selection happens based on what the user needs, not which keyword they used.
This distinction matters in voice specifically. Spoken language is messier than typed language. Users restart sentences, correct themselves mid-thought, and ask follow-up questions that only make sense in context. Dialogue understanding makes natural interactions work without forcing users into rigid patterns.
Text-to-Speech (TTS)
Text-to-speech (TTS) is the output layer. It converts the assistant's text responses into audio output that the user hears. Modern neural networks and deep learning produce synthesized speech with realistic rhythm, natural stress patterns, and emotional tone. The output isn't robotic.
What you want from a TTS system in an enterprise build:
- Controllable speaking rate and tone to match different interaction types (informational vs. urgent vs. empathetic)
- Support for the languages and regional accents your users speak
- Voice customization so the assistant has a consistent, on-brand sound
Open-source TTS options exist, including community-maintained projects in the Coqui/Mozilla TTS lineage, but production teams should verify maintenance status, voice quality, licensing, latency, and language coverage before standardizing on one. Commercial TTS providers typically offer higher-quality voices and lower latency, which is worth evaluating for customer-facing deployments where voice quality directly affects user perception.
Integration, Orchestration, and Infrastructure
ASR, NLU, and TTS are the surface of the system. The infrastructure underneath determines whether the assistant can actually do anything useful.
For a voice assistant to deliver real value, it needs to connect to the systems your business runs on: CRM platforms, ERP systems, knowledge bases, ticketing systems, APIs. That connectivity is what lets the assistant pull account data, trigger workflows, escalate tickets, or check inventory mid-conversation.
Orchestration is what coordinates all of this. Rasa's orchestrator acts as the coordination layer: it decides what skill to invoke, passes the right context, maintains conversational state across turns, and manages handoffs when the conversation moves between topics or requires a human agent. It's not routing. It's runtime coordination that keeps the experience coherent even when conversations get complicated.
Finally, infrastructure. Voice assistants need low-latency performance, scalable architecture, and flexible deployment options. Rasa's real-time voice capabilities include voice-ready and voice-stream channel connectors that link a Rasa agent to telephony and contact center infrastructure such as Jambonz, Twilio Media Streams, AudioCodes, and Genesys Cloud. The streaming-based design supports natural turn-taking and faster recovery from recognition errors. A modular setup makes it easier to integrate new systems, test changes, and update skills without rebuilding from scratch.
How to Build Your Own Voice Assistant: Step-by-Step
Get hands-on experience: the Rasa Tutorial walks through the same step-by-step guide below in a working code example, then layers voice on top in the Adding Voice to Your Assistant section. You can build a complete AI voice assistant end-to-end in about 30 minutes with the free developer edition.
Step 1: Define Purpose and Scope
Start with the use case. What specific problems will your voice assistant solve? Will it handle inbound customer service calls, help employees look up internal information, or support a specific workflow like appointment scheduling or order tracking?
Picking a clear focus makes every subsequent decision easier. It shapes your ASR requirements, your dialogue design, your integration priorities, and your success metrics. A voice assistant built to handle voice assistants for customer support has very different requirements than one built for internal HR self-service.
Start narrow and build out. A telecom company might launch with billing inquiry support, then extend to plan recommendations, then add multi-step troubleshooting. Each phase builds on what works rather than betting everything on a broad scope that's hard to test and harder to validate.
Define success criteria before you build. What's the target containment rate? What does a successful interaction look like? Without these benchmarks, you can't measure progress or make confident decisions about when to expand.
Step 2: Choose the Right Technology Stack
The technology decisions you make here have long-term consequences. Think about security, scalability, and how the stack fits with your existing systems.
- Customizable platform: You need a system that can handle simple, predictable interactions and complex multi-step workflows in the same platform. Appointment reminders and troubleshooting a network outage are very different problems. The platform should handle both without requiring two separate systems.
- Data security and compliance: In regulated industries like banking, healthcare, and insurance, voice input is sensitive data. Rasa's on-premises deployment options let teams keep voice data on their own infrastructure, under their own security model, which matters when you can't put customer calls into someone else's hosted environment.
- Integration flexibility: The stack needs to connect cleanly to ASR providers, CRM systems, ERPs, and any knowledge bases the assistant will draw from (often via retrieval augmented generation against a vector store). Integration points that require custom glue code for every new connection will slow you down.
Flexibility matters as much as capability. A stack you can own and extend is more valuable long-term than a capable system you're locked into.
Step 3: Design the Conversational Flow
Conversational design for voice is different from text. Users can't scroll back, can't click links, and can't visually scan a menu. Every interaction has to work in a single forward-moving exchange.
Map the common scenarios first. What are the five or ten interactions that will make up the majority of conversations? Design those well before handling edge cases. For each scenario, define: how the conversation opens, how the assistant confirms what the user wants, what information it needs to collect, what action it takes, and how it closes or hands off.
Design short responses. Long TTS responses frustrate users. A response that reads fine on screen can feel exhausting when spoken aloud. Keep answers focused. If the user needs more detail, let them ask.
Plan for interruption. Users will interrupt, change their mind, or ask an unexpected follow-up in the middle of a scripted flow. The assistant needs to handle this gracefully, not break.
Rasa Studio (the platform's browser-based UI for prototyping and refining agents) lets teams map out voice-first conversational paths visually, test how the agent responds to unexpected input, and iterate quickly. Developers still extend backend logic, custom actions, and integrations where the use case requires it. The platform's multilingual content system keeps voice, chat, and other channel responses consistent without maintaining separate copies of everything.
Step 4: Train with Real-World Data
Training determines how well your assistant handles real user behavior. Lab-constructed test cases aren't enough. You need data that reflects how your users actually speak.
- Gather representative data: Use past call recordings, support chat logs, or realistic scenario simulations. The training data should reflect the accents, speaking styles, domain vocabulary, and interaction patterns your users bring.
- Refine language model performance with machine learning techniques: Train your language models on speech-to-text transcriptions, including the imperfections. Real transcriptions of audio files include filler words, mid-sentence corrections, and occasional misrecognitions. Modern language models need to handle these, not just clean input. Continuous machine learning on production data is what closes the gap.
- Improve dialogue understanding: Teach the system to distinguish between queries that sound similar but need different responses. "What's my balance?" and "Can I increase my credit limit?" are both account questions but require completely different actions.
- Include edge cases: Less common queries, unusual phrasing, and out-of-scope requests all need to be represented in training. Production users will surface things your design team didn't anticipate.
Continuous training is ongoing work. After launch, conversation logs become your best training resource. Review them regularly, catch misunderstandings early, and retrain.
Step 5: Test and Refine
Testing a voice assistant requires more than checking that responses are correct. You're testing an end-to-end experience that includes audio quality, latency, and conversational coherence under real conditions.
- Conduct usability testing: Run realistic conversation simulations covering a broad range of inputs, accents, and interaction styles. Don't just test the happy path.
- Check speech recognition accuracy: Transcription errors compound downstream. A small ASR degradation can cause a large increase in failed interactions. Measure transcription accuracy on audio files representative of real users' voices, not just end-to-end task completion.
- Stress-test the system: Test under concurrent load to find latency degradation and bottlenecks before they appear in production.
- Test across environments: Call center environments, mobile devices, and smart speakers all have different audio characteristics. Test in conditions that match how users will actually interact.
- Gather feedback: Internal teams and pilot users will find issues that automated testing misses. Structured feedback loops before general release improve launch quality.
Rasa's Inspector makes it easier to test individual skills and end-to-end conversations during development, catching issues before they reach production.
Step 6: Deploy and Monitor
Deployment isn't the end of the build. It's the beginning of the operational phase.
Choose your deployment model. Cloud deployment offers easier scaling and faster iteration. On-premises or private cloud gives you control over data residency, which is often non-negotiable in regulated industries. Rasa supports both. For enterprises in financial services, healthcare, insurance, or government, on-prem isn't an edge case; it's the default expectation.
Deploy incrementally. Start with a limited rollout: a single channel, a subset of call volume, or a specific use case. This gives you real production data without full exposure. Validate performance, fix what needs fixing, then expand.
Define your monitoring KPIs before launch. The metrics that matter most for voice agents in production:
- Time-to-first-meaningful-action: How long from when the caller speaks to when the assistant takes a real action, not just an acknowledgment. The leading indicator for caller satisfaction in voice
- Containment rate: What percentage of interactions the assistant handles without human escalation
- ASR accuracy: Transcription error rate for your specific domain and user population
- Turn-to-resolution: How many conversational turns it takes to complete a task
- Latency: End-to-end response time and perceived responsiveness during streaming
- Escalation patterns: Which topics or scenarios the assistant can't handle, and why
Monitor conversation logs actively in the early weeks. Production traffic surfaces edge cases, phrasing patterns, and integration issues that testing didn't catch. Build a feedback loop between monitoring and training so the assistant improves continuously.
Voice Assistant Development Best Practices
Design for Security and Privacy
Voice input is sensitive. Users share account information, personal details, and sometimes confidential information during voice interactions. In industries like finance, healthcare, and government, handling this data incorrectly isn't a UX problem; it's a compliance failure.
On-premises and private cloud deployments keep voice data on your infrastructure, under your access controls. You don't rely on an external provider's data retention or security policies. IT teams can enforce encryption in transit and at rest, control who has access to conversation logs, and demonstrate compliance to auditors.
Regulations like GDPR and HIPAA shape specific requirements: what data you can retain, how long you can keep it, what consent you need before recording, and what audit trails you need to maintain. Build these requirements into the system design from the start. Retrofitting compliance into a production system is significantly harder than building it in.
The Rasa Platform is built for private deployment. Teams in regulated environments use it specifically because they need to run on their own infrastructure rather than routing customer conversations through a vendor's hosted environment.
Build for Adaptability and Long-Term Performance
Voice agents that don't change stop working. User language evolves. Business processes change. New products and services need coverage. An assistant that was well-tuned at launch will drift from user expectations over time without ongoing attention.
Personalization drives better outcomes. When an assistant draws on conversation history, account context, and user preferences, responses feel relevant rather than generic. Rasa's memory layer maintains this context over time, carrying forward what's useful and expiring what isn't, with policy controls over what gets retained and for how long.
Make improvement systematic. Review conversation logs on a regular cadence, not just when something breaks. Track resolution rates and escalation patterns. Identify the interactions where the assistant struggles and retrain those first. Over time, this process extends what the assistant can handle reliably.
Optimize for Latency and Real-Time Performance
Latency kills voice experiences in a way it doesn't for text. A 400ms delay in a chat interface is barely noticeable. The same delay in a voice interaction makes the conversation feel broken. Users interpret silence as confusion, failure, or dropped calls.
The primary latency culprits in voice pipelines are ASR processing time, LLM inference time, and TTS generation time. These add up quickly in a sequential pipeline. A few design principles reduce the pain:
Stream everything you can. Rather than waiting for complete ASR output before starting processing, stream partial transcription results and begin context evaluation early. Rather than waiting for a complete response before starting TTS synthesis, stream TTS output as it's generated. Rasa's voice-stream connectors are built around streaming for this reason.
Use turn-taking signals. Natural conversation has cues for when someone is done speaking. Implementing end-of-speech detection correctly avoids unnecessary pauses and prevents the assistant from interrupting users who are mid-thought.
Acknowledge while processing. For interactions that require backend calls or complex processing, an immediate brief acknowledgment ("Let me look that up") keeps the conversation alive while the system works. Silence of more than a second or two prompts users to repeat themselves, which compounds the problem.
Optimize your integration calls. Database lookups and API calls within a skill contribute directly to perceived latency. Cache what can be cached. Parallelize calls that don't depend on each other. Reduce round-trip trips wherever the flow allows.
Handle Edge Cases and Fallback Scenarios
No voice agent handles everything perfectly. The question isn't whether users will encounter something outside the system's capability; it's whether the agent handles those moments gracefully or badly.
Design fallbacks explicitly. When the assistant can't understand input or can't fulfill a request, the response matters. A vague "I didn't understand that" is worse than a specific "I couldn't catch that. Can you say it again?" or "I can't help with that directly, but I can connect you with someone who can."
Build graceful degradation. Speech recognition errors happen. When transcription confidence is low, the assistant should verify rather than proceed on a bad interpretation. A quick confirmation ("Did you say you want to cancel your subscription?") costs one turn but gives the user a chance to correct misheard speech input before the assistant acts on the wrong instruction.
Instrument your escalation paths. Human handoff isn't a failure state; it's a designed outcome for interactions the assistant can't or shouldn't handle autonomously. Build the handoff path intentionally: pass context to the agent so the user doesn't repeat themselves, trigger on specific conditions rather than catch-all failures, and track escalation patterns so you know what to train next.
Test failure modes explicitly. Build a test suite that specifically covers low-quality audio input, out-of-scope requests, partial utterances, and rapid topic changes. These are the conditions that expose a weak fallback design.
Voice Assistant Tools and Platforms
Choosing the right tools is a significant decision. The ecosystem divides roughly into open-source frameworks for teams that want maximum control and commercial platforms that trade flexibility for faster time-to-value.
Open-Source Frameworks
Open-source tools give teams direct control over every layer of the stack. The tradeoff is that integration, infrastructure, and production operations are largely your responsibility.
Common components in voice agent builds include:
- OpenAI Whisper or other self-hostable ASR models for teams evaluating self-managed transcription with multilingual or accented speech support.
- Commercial ASR and TTS providers such as Deepgram, Azure Speech, Cartesia, and Rime, depending on latency, language coverage, voice quality, and deployment requirements. Rasa includes built-in speech integrations for several of these.
- Rasa Platform for orchestration, skills, dialogue understanding, memory, and backend integrations. Refer to the developer documentation for full technical details.
Legacy projects like Mozilla DeepSpeech and Mozilla TTS show up in older guides, but DeepSpeech is archived, and the Mozilla TTS lineage now lives in community-maintained Coqui forks. They're useful historical references rather than safe defaults for new production builds.
Rasa offers a free Developer Edition for teams exploring the platform before committing to an enterprise deployment.
Enterprise Platforms
Enterprise platforms handle more of the operational complexity, typically including managed infrastructure, built-in monitoring, and support. The evaluation criteria for enterprise buyers tend to center on deployment flexibility, data control, and integration depth.
Pick based on what your team needs to own. If data residency, model transparency, and the ability to evolve the system over time matter, a platform built for enterprise deployment with deep customization will serve you better than a managed service that's faster to start but harder to control.
Why Rasa for Enterprise Voice Assistants
Rasa is the enterprise agent orchestration platform for customer-facing and employee-facing AI agents. For voice specifically, it's built around the requirements that show up consistently in regulated, high-stakes environments: sovereign deployment, streaming performance, composable skills, and production observability.
Here's what that means in practice.
Sovereign voice on your terms. Rasa can run in your environment and connect to the speech and telephony providers that fit your security, latency, and data-residency requirements: voice-stream connectors handle Jambonz, Twilio Media Streams, AudioCodes, and Genesys Cloud. The streaming-first design supports natural turn-taking and fast recovery from recognition errors. Teams in financial services, healthcare, and government keep the components they need under their control rather than routing the entire customer experience through a vendor's hosted environment.
Skills are composable and governable. Rather than building one large voice agent that becomes progressively harder to test and change, Rasa lets teams build discrete skills: reusable units of capability that can be developed, tested, and updated independently. A billing skill, a troubleshooting skill, and an account management skill can be owned by different teams and composed into a single coherent voice experience.
The orchestrator coordinates the experience. Rasa's orchestration layer determines what happens next: which skill to invoke, what context to pass, how to handle handoffs, and how to maintain continuity when users jump between topics. This is runtime coordination, not routing. It's what keeps multi-turn conversations coherent when users interrupt, digress, or ask something unexpected.
Dialogue understanding handles real speech. Rasa's dialogue understanding layer evaluates full conversational context rather than matching against a fixed list of intents. In voice, where users restart sentences, correct themselves, and ask follow-up questions that only make sense in context, this matters more than in any other channel.
You can see what happened. The Inspector gives teams visibility into which skill was used, what context was used, and why a particular response was generated. When something goes wrong in production, you can trace it. That transparency is hard to replicate in systems where logic is buried in vendor workflows you can't inspect.
Rasa works across voice, chat, and internal channels on a single platform. A skill can be reused across voice and chat, then adapted for the interaction patterns of each channel: confirmation strategy, latency budget, and fallback design all change in voice, but the underlying capability stays the same. For enterprises running multiple AI agent deployments, this prevents the ecosystem drift that happens when different teams ship different behaviors that eventually fracture the user experience.
Start building. The fastest way to see this in action is the Rasa Tutorial, which builds a working customer service assistant and then adds voice on top using the same skill. Grab a free developer edition license, follow the tutorial, and you'll have a working voice assistant in roughly half an hour. The full developer documentation covers everything beyond that first build.
FAQs
What is the difference between an AI voice assistant and a traditional IVR system?
Traditional IVR systems rely on rigid menus and predefined call trees. Users navigate by pressing numbers or saying specific words that match a limited vocabulary. AI voice assistants use speech recognition and dialogue understanding to interpret natural language, manage multi-turn conversations, and adapt dynamically to what the user says. The experience is fundamentally different: one is a menu, the other is a conversation.
Do I need to build every component (ASR, NLU, TTS) from scratch?
No. Most enterprise builds combine existing ASR and TTS providers with an orchestration platform like Rasa for dialogue management and skill coordination. This modular approach lets teams choose best-in-class components for each layer while maintaining control over how the system works together. You don't write your own ASR engine; you choose one that fits your accuracy and deployment requirements and connect it.
How can I ensure my AI voice assistant stays accurate over time?
Accuracy requires ongoing attention. Review conversation logs regularly to catch where the assistant struggles, retrain on new data when patterns shift, and test edge cases continuously. The assistant should get better as it accumulates production data, but only if there's a process for reviewing that data and acting on it. Monitoring KPIs like containment rate and turn-to-resolution gives you leading indicators before accuracy degrades noticeably.
Is it better to deploy voice assistants in the cloud or on-premises?
The right model depends on your industry, compliance requirements, and what you need to control. Cloud deployment offers easier scaling and faster iteration. On-premises or private cloud gives you control over data residency and security policy, which is required in many regulated industries. Many enterprises in financial services, healthcare, and government treat on-prem as the default, not the exception.
Can I create my own voice assistant?
Yes. The main decisions are your technology stack (ASR, dialogue understanding, TTS, orchestration), your deployment model, and your integration requirements. OpenAI Whisper covers self-hosted ASR; commercial or self-hostable TTS options round out the speech layers. Rasa's free Developer Edition gives you the orchestration and dialogue layer without upfront cost, which is a practical starting point for teams building their first voice assistant or evaluating the platform before an enterprise deployment.
How long does it take to build a voice assistant?
It depends heavily on the scope. A focused voice assistant handling a single well-defined use case can reach a testable prototype in weeks. A production-grade system with multiple skills, enterprise integrations, and full compliance requirements is a multi-month effort. Starting narrow, validating the core interaction, and expanding iteratively is almost always faster than attempting full scope on the first build.
How much does it cost to build a voice assistant?
Costs vary across infrastructure, licensing, and development effort. Open-source components reduce licensing costs but shift effort to integration and operations. Commercial ASR and TTS providers typically charge per minute of audio processed. Enterprise platforms like Rasa have licensing costs that scale with deployment scope. The total cost of ownership for a self-hosted platform is often lower than vendor-hosted alternatives over a multi-year horizon, especially when you factor in what you're not paying for: per-seat fees, data egress costs, and the cost of rebuilding when a vendor changes their platform.
