Blueprint Playbook / Start Here
Welcome
Your Blueprint Call
Success Guide
This guide exists to help you run one of the most important calls in Youtiva's sales process — the Blueprint Call — with confidence, structure, and the kind of depth that makes engineers say "this is the best handoff we've ever gotten." Everything in here is built around one goal: your success on this call.
What this guide is
This isn't a training manual you read once and put down. It's a working guide you keep open during prep, reference between phases, and fill out after the call. Every section is built around what actually happens on a Blueprint Call — the real questions, the real scripts, the real decisions you'll need to make in the moment.
Use it before the call
Study Company Background and Your Mission. Run through Pre-Call Prep 10 minutes before you join.
Use it during the call
Keep the Call Flow tabs open. Use the phase scripts and questions as a live reference, not a script to memorize.
Use it after the call
Fill out the Handoff Form immediately while it's fresh. This is what the engineer works from — your notes are their blueprint.
Use it when you're stuck
Objections & FAQ has responses to every pushback you'll encounter. Fit Signals tells you how to read the room in real time.
Everything in this guide — and where to find it
Company
Company Background
Youtiva's mission, the ownership model, what gets built, the 120-day process, the guarantee, who we're for, and proof points. Read this before your first call — and revisit when a prospect asks a tough question.
→
The Playground
14 live, interactive AI technology modules — the same ones Youtiva builds for clients. Use it to show prospects what the technology actually does. Share the link as a leave-behind after the call.
→
Blueprint Call
Your Mission
Why the Blueprint Call matters, what's at stake, your five real objectives, the full call flow chart, and the north star sentence you're building toward. Read this every time before a call.
→
Pre-Call Prep
A checklist of everything to gather from CSC notes and their website before you join. 5–10 minutes of prep that separates a generic conversation from one that lands.
→
Call Flow
1
Open & Frame 0–10 min
Scripts for setting the frame, the low-context opener, and the warm-up question. How to calibrate as they talk.
→
2
Discover the Pain 10–40 min
8 discovery questions to extract named workflows with current and target states. How to anchor the pain when you find it.
→
3
Map the Environment 40–70 min
6 questions to capture their tools, data sources, formats, years of history, compliance needs, and integration requirements. The bridge to Phase 4.
→
4
Sketch the Vision 70–80 min
The pivot script, three vision questions, and the sentence you're building toward. How to shift from listener to collaborator and get them emotionally invested in the outcome.
→
5
Pre-Close & Book the Engineer 80–90 min
5 steps: earn the right to talk money, frame as infrastructure, introduce the range, read the reaction, book the engineer call on the spot. Scripts for every path.
→
Post Call
Handoff Form
The structured form that maps directly to the Blueprint Assessment document the engineer works from. Six sections: client snapshot, workflows mapped (with current and target states), data & systems audit, success metrics, deal signals, and CSS notes.
→
Resources
Qualify & Hand Off
Hard qualifiers (must-haves) and strong fit signals (good-to-haves). The gray area rule. A clear framework for the judgment calls you'll make at the end of every call.
→
Fit Signals
Strong fit vs. weak fit grid, plus verbatim phrases to listen for — ownership readiness, knowledge risk, and genuine urgency. Use this in real time to read where a prospect stands.
→
Objections & FAQ
13 objections across three categories — product & technology, process & investment, timing & urgency. Full responses for each. Full responses for each.
→
One more thing before you start
Every great system Youtiva has built started with a great Blueprint Call. The engineer designs the architecture. The client makes the decision. But the quality of everything that follows — the proposal, the build, the relationship — traces back to how well you did your job in this conversation. Use this guide. Ask one more question. Go one level deeper. That's where the real work gets done.
Blueprint Playbook / Your Mission
CSS briefing
The Blueprint call is
where it all begins.
Every great Youtiva system starts with a great Blueprint call. Not with the engineers. Not with the proposal. With you — asking the right questions, earning the prospect's trust, and understanding their business deeply enough to hand it off like a teammate, not a closer.
What's at stake
This call is where deals are won or lost.
Not in the engineer call. Not in the proposal. Here — in the first 90 minutes a prospect spends with Youtiva. The quality of your discovery determines the quality of everything that follows. A sharp Blueprint call means the engineer walks in already knowing the business. It means the architecture is relevant. It means the prospect feels understood instead of sold to. Do this right and the rest of the process runs on rails.
Remember this
Youtiva takes six clients per quarter. Every prospect you bring to the engineer call has been hand-selected. You are the first filter — and the first impression. Make both count.
Your real objectives on this call
01
Understand their business — deeply.
Not surface-level. Not a few boxes checked. You are trying to understand this business well enough to describe it back to an engineer who has never met them. Keep asking. Go deeper than comfortable. The best question you can ask is always the follow-up.
02
Discover — don't pitch.
Your job is not to sell Youtiva. Your job is to understand them so thoroughly that by the end of the call, they feel like you've already started building something for them. The pitch happens naturally — when you reflect their own words back at them and connect it to what's possible.
03
Qualify ruthlessly — for their sake and ours.
You are qualifying for a premium, selective offer. A bad fit in the engineer call wastes everyone's time and erodes trust. The best thing you can do for a prospect who isn't ready is tell them clearly — and leave the door open for when they are.
04
Hand off like a teammate.
When you pass a prospect to the engineer, they should feel like they're continuing a conversation — not starting over. The engineer should already know the business, the pain, the "one thing," and what to watch out for. Your handoff notes are as important as the call itself.
05
Be relentless in the pursuit of their success.
Great systems are made on Blueprint calls. Ask one more question. Go one level deeper. Stay curious longer than feels necessary. The detail that changes the entire architecture is almost always the one buried under the third follow-up question. Keep going.
Why this matters more than you think
Your work compounds
A great Blueprint call doesn't just book a next step — it sets the tone for the entire client relationship. When you do this well, the engineer closes easier. The client is more engaged. The build goes smoother. And Youtiva delivers something they talk about.
Every sharp question you ask on this call is an investment in a system that will run inside someone's business for years. That's the weight of what you're doing — and it's worth taking seriously.
Every sharp question you ask on this call is an investment in a system that will run inside someone's business for years. That's the weight of what you're doing — and it's worth taking seriously.
The call flow at a glance
The north star
The one sentence to walk away with
By the end of every Blueprint call, you should be able to finish this sentence clearly: "The biggest opportunity for [Company] is building a system that handles [specific workflow] — which right now is costing them [time/money/risk] and living entirely in [person/tool/chaos]." If you can say that, the engineer call will be easy to sell.
Your job is not to pitch Youtiva. Your job is to understand their business so well that by the end, they feel like you've already started designing something for them. The pitch happens naturally — when you reflect their own words back and connect it to what's possible.
Blueprint Playbook / Pre-Call Prep
Before the call
Pre-Call Preparation
5–10 minutes of prep separates a generic conversation from one that feels like you already understand their world. This is your edge going in.
What to gather before you join
From CSC notes / application
What was the stated pain or trigger?
Company size and industry
Any AI tools they mentioned using
Is the decision maker confirmed on the call?
Which funnel did they come from?
From their website (2 min scan)
What do they actually do — in plain terms?
Who are their clients / who do they serve?
Any clues on team size or complexity?
Signs of high document or knowledge volume?
Any obvious AI or tech mentions?
Before you join — set your intention
The one thing to walk away with
By the end of this call, you should be able to finish this sentence: "The biggest opportunity for [Company] is a system that handles [specific workflow] — which right now is costing them [time/money/risk] and living entirely in [person/tool/chaos]." If you can complete that sentence clearly, the engineer call will run itself.
Blueprint Playbook / Phase 1 — Open & Frame
Phase 1 · 0–10 min
Open & Set the Frame
Get them relaxed. Establish that this is a working session, not a sales call. Signal that their time will be well spent — then get them talking.
Purpose of this phase
Before any question lands, the prospect needs to know what kind of conversation this is. Your framing sets the tone for everything that follows — if they think they're being sold to, they'll guard up. If they think you're here to understand them, they'll open up. Say the frame out loud. Don't assume they know.
Script
Main opening frame — say this first
"So the way I like to run these — the first half is really just me understanding your business. No slides, no pitch. The more you share, the more useful this gets. Then in the second half, I'll start reflecting back what I'm hearing and we can talk about what a system built around your specific situation might actually look like. Does that work for you?"
If context is light — add this before the frame above
"Before we dive in — I did take a look at [Company Name] before this call. I want to make sure the time we spend today is actually useful for you, so I may ask some questions that feel basic. That's intentional — the more I understand how your business actually works, the more useful this session becomes. Sound good?"
Warm-up — once they've confirmed the frame
"Give me the quick version — what does [Company] do, and what's your role in it?"
What to listen for
Calibrate as they talk
The warm-up question isn't small talk — it's calibration. How they describe their business tells you their sophistication level, what they value, and where their head is. Don't interrupt. Let them go. The way they describe their own company is often a preview of where the pain lives.
Blueprint Playbook / Phase 2 — Discover the Pain
Phase 2 · 10–40 min
Discover the Pain
Find the real friction — the workflows costing them time, money, or risk. Get specific. Vague pain doesn't build urgency. Named, described pain does.
Purpose of this phase
This is the most important phase of the entire call. Your job here is to find the specific, recurring workflow that is costing them the most — in time, in money, in risk, or in consistency. Don't settle for vague answers. Keep asking the follow-up. The detail that changes the architecture is almost always buried one level deeper than where most Client Success Specialists stop.
Discovery questions — work through these naturally
"Walk me through a typical week — what are the recurring things your team spends the most time on?"
Start here. This is the most important question. Let them go. Don't redirect or jump in — exhaust this one completely before moving on. Everything useful is somewhere in this answer.
"Where does work slow down or pile up? What's the thing your team dreads doing?"
Emotional language is a signal — "we hate this," "it kills us," "nobody wants to deal with it." Flag it. It'll be your anchor in the pre-close.
"Walk me through exactly how that works today — step by step. Who does it, how long does it take, and what does it produce?"
This is the workflow extraction question. You need the current state in enough detail to write it up: who does the task, how frequently, how long it takes, what tool or person it depends on, and what the output looks like. The blueprint document needs this level of specificity.
"What would that process look like if it ran perfectly — what's the ideal version?"
This is the target state. You need their vision of what "fixed" looks like — not your interpretation. Write it down in their words. The engineer will use this as the design target.
"Are there other workflows like this — other things that follow the same pattern of being time-consuming, manual, and dependent on the same people or documents?"
You're looking for 3–6 named workflows, not just one. The blueprint document will map all of them. Each one you surface here strengthens the architecture and the deal size. Keep asking until they run out of answers.
"Is there knowledge in the business that basically lives in one or two people's heads — that would be hard to replace if they left?"
Key person dependency is one of the most powerful hooks in the Youtiva value proposition. If they say yes — don't move on. Ask: "What kind of knowledge? How long did it take that person to develop it? What happens when they're out sick?"
"How is your team currently using AI — and where have those tools fallen short?"
Tells you their fluency level and frustration point. "We've tried everything and nothing goes deep enough" is your perfect setup for the ownership conversation. "We're not really using AI yet" means you need to calibrate your language accordingly.
"If that problem didn't exist — what would your team be doing with that time instead?"
This reframes the cost of the problem from "annoying" to "strategic." Gets them thinking about what they're actually losing, not just what's frustrating them. The answer often becomes a success metric in the blueprint.
What you're building toward — the workflow map
By the end of Phase 2, you need this for each major workflow
Name: What's this workflow called? (e.g. "Document intake," "Legal research," "Client reporting")
Current state: Who does it, how long does it take, what does it depend on?
Target state: What would this look like if it ran automatically and consistently?
Cost of the problem: Time per week/month, who's bottlenecked, what's at risk if nothing changes?
Aim for 3–6 workflows. The blueprint document maps all of them — each one strengthens the architecture case.
Current state: Who does it, how long does it take, what does it depend on?
Target state: What would this look like if it ran automatically and consistently?
Cost of the problem: Time per week/month, who's bottlenecked, what's at risk if nothing changes?
Aim for 3–6 workflows. The blueprint document maps all of them — each one strengthens the architecture case.
When you find the anchor
Reflect it back immediately — get them to confirm their own pain
"So it sounds like [workflow] is happening [frequency] and it's basically running on [person/tool] right now — is that right? And if that person wasn't there, or that tool changed, this whole thing would break down?"
Why this works
Getting them to confirm their own pain in their own words is more powerful than you describing it back. When they say "yes, exactly" — that's the moment the call turns. Note the exact language they used. You'll use it again in the pre-close and hand it to the engineer verbatim.
Blueprint Playbook / Phase 3 — Map the Environment
Phase 3 · 40–70 min
Map the Environment
Get a lightweight picture of their data, tools, and tech setup. You don't need to go deep — just enough for the engineer to know what they're walking into.
Purpose of this phase
You are not designing the system here — you're gathering enough for someone else to design it. Keep these questions conversational. If they don't know an answer, that's completely fine — note it as "TBD / engineer to explore" and move on. A rough picture is infinitely more useful than nothing.
Questions to cover
"What software does the team live in day-to-day — CRM, document management, communication tools, practice management, anything like that?"
You're building the integration picture. Get a named list — "Clio, NetDocuments, Gmail, QuickBooks" is far more useful than "some case management software." Each named tool is a potential integration point the engineer needs to plan for.
"Where does your business's data actually live — documents, client records, financials, communications? And roughly how much history are we talking — months, years?"
Two things matter here: where it lives (SharePoint, shared drive, local servers, cloud) and how much of it there is. "We have 9 years of case files in PDF on a shared drive" tells the engineer a lot. Years of history = depth of institutional knowledge that can be ingested.
"What format is most of it in — PDFs, Word docs, spreadsheets, inside a database?"
Format determines ingestion complexity. PDFs and Word docs are straightforward. Proprietary database formats need an export pipeline. Knowing this in advance lets the engineer plan the data architecture before the call.
"Is there sensitive or regulated information involved — client data, anything with strict access rules or compliance requirements?"
Critical for legal, healthcare, and finance clients. Flags compliance constraints before the engineer is blindsided. If yes: "What kind? HIPAA? Attorney-client privilege? PCI? SOC 2?" Just flag the category — don't go deep. This determines hosting recommendation (private cloud vs. on-premise vs. dedicated server).
"Do you have an internal IT person or team, or is that handled externally — or not at all?"
Sets expectations around deployment complexity and what resources the client brings. No IT = engineer plans for more hand-holding. In-house IT = smoother deployment, potential API access already available.
"Of the systems you mentioned — which ones have APIs or data export options that your team already uses?"
Optional but high-value. API access is the difference between a clean integration and a manual export pipeline. If they already pull data from QuickBooks or their CRM, there's likely an integration path the engineer can use.
What you're building toward — the data picture
By the end of Phase 3, you need this
Existing data sources: Named systems + what kind of data + how many years of history + what format
Integration requirements: Which systems need to connect to the AI system and how (API, export, manual ingestion)
Data sensitivity: The category and compliance framework (attorney-client, HIPAA, PCI, standard business data)
Hosting signal: Does this need on-premise, private cloud, or dedicated server? (High sensitivity = full private deployment)
This feeds directly into the Data & Systems Audit section of the blueprint document.
Integration requirements: Which systems need to connect to the AI system and how (API, export, manual ingestion)
Data sensitivity: The category and compliance framework (attorney-client, HIPAA, PCI, standard business data)
Hosting signal: Does this need on-premise, private cloud, or dedicated server? (High sensitivity = full private deployment)
This feeds directly into the Data & Systems Audit section of the blueprint document.
Transition out of this phase
Bridge to Phase 4
"That's really helpful context — I have a much clearer picture of where everything lives. I want to shift gears for a second. Now that I understand the environment, I want to make sure I understand what success looks like for you. Can I reflect back what I'm hearing and see if I've got it right?"
Don't let this phase drag
If they want to go deep on technical details, acknowledge it and park it: "That's exactly the kind of thing our engineer will want to map out — I'll flag it for them. Let me make sure I've captured the big picture first." Then move to Phase 4.
Blueprint Playbook / Phase 4 — Sketch the Vision
Phase 4 · 70–80 min
Sketch the Vision
The call shifts from consultative to collaborative. Reflect back what you've heard, describe what's possible in plain language, and get them emotionally connected to the outcome.
Purpose of this phase
You've spent the last 45 minutes listening. Now you shift gears. You take everything you've heard and reflect it back as a coherent picture — one they can see themselves in. The goal is to get them nodding along and saying "yes, exactly." That confirmation is what earns you the right to talk about next steps.
Script — open Phase 4 with this pivot
Pivot — reflect the pain back as a system problem
"Okay — let me reflect back what I'm hearing, and you tell me if I'm getting this right. It sounds like the biggest friction point is [workflow] — which is happening [frequency], and right now it's running on [person/tool]. The risk there is [key person dependency / inconsistency / time cost]. If we could take that off your team's plate and encode it into a system that runs it the same way every time — and that your whole team draws from — that's where I'd want to start. Does that match what you're seeing?"
Vision questions — go deeper after the pivot
"If this system could do one thing that would genuinely change how the business operates — what would that be?"
This is the most important question in this phase. Write their answer down verbatim. This becomes the north star for the engineer call and should show up in your handoff notes word-for-word.
"What would it mean for you personally if that was handled — what does it free you up to do?"
This shifts the conversation from operational to personal. Getting them to describe what their life looks like without this problem creates emotional investment in the outcome, not just the solution.
"And beyond this first use case — are there other areas of the business where you can see something like this being useful?"
Optional — use if the conversation is going well. This seeds the idea of the expanding architecture without you having to pitch it. If they light up and start listing things, the deal is essentially won.
Where this phase ends
The sentence you're building toward
By the end of this phase you should be able to say clearly: "The biggest opportunity for [Company] is a system that handles [X] — which right now is costing them [Y] and living in [Z]." That sentence is what you hand to the engineer. If you can say it, you're ready for Phase 5.
Blueprint Playbook / Phase 5 — Pre-Close
Phase 5 · 80–90 min
Pre-Close & Book the Engineer
Introduce the investment range softly, gauge the reaction, build excitement for the engineer call, and get it booked before you hang up. Never leave without a next step.
Purpose of this phase
Your job here is not to close the deal — it's to confirm they're in the right ballpark financially, get them genuinely excited about what comes next, and book the engineer call before you hang up. Don't rush this. Don't skip steps. Every step below exists for a reason.
Step 1
Earn the right to talk about moneyDon't mention price until they've confirmed the vision resonates. If they're not nodding along at the end of Phase 4, you don't have permission yet. Check in first.
Confirmation check — before you mention anything financial
"Before I talk about next steps — does what I've described feel like the right direction for where you want to take the business? I want to make sure I'm not designing something in my head that doesn't actually match what you need."
If they hesitate here
Don't rush past it. Ask: "What feels off about what I described?" You may have missed a nuance in the pain — or there's a stakeholder concern you haven't surfaced yet. Get it out now. It's better to surface misalignment here than have it come up when price is on the table.
Step 2
Frame it as infrastructure, not a serviceBefore any number lands, make sure they understand what they're investing in. A $50k SaaS subscription feels expensive. $50k for infrastructure they own permanently feels completely different. Set the frame before the number.
Framing script — say this before any price conversation
"Just so you have the right frame going in — what we build isn't software you subscribe to. It's infrastructure you own. Once it's deployed, it runs in your environment, under your domain. There's no ongoing dependency on us to keep it operating. You're not renting access to something we control — you own it completely. The codebase, the architecture, the IP. That's why the investment looks different from a SaaS tool."
Step 3
Introduce the range — softlyGive a range, not a number. Never anchor low. Your job is only to confirm they're in the conversation — the exact investment is the engineer's job to present on the next call.
Price range script
"The engineering call will give you the exact number — that's where we scope everything properly. But so we're not surprising anyone: projects like what we've been talking about typically sit somewhere between [low range] and [high range], depending on scope and complexity. Does that feel like a range you'd be willing to explore if the architecture makes sense?"
Never quote a fixed number on this call
The phrase "if the architecture makes sense" is intentional — it keeps the door open and moves price justification to the engineer call where it belongs. If they push for a specific number, hold the line: "I don't want to give you a number that isn't based on what we actually scope — that's what the engineering call is for."
Step 4
Read the reaction — and choose your pathAfter the range lands, pause. Let them respond. Then match your next move to what you hear.
→ Book the engineer call
They said yes or "that's fine"
Pushed back lightly but stayed engaged
Asked "what does that include?"
Said "that's actually less than I expected"
→ Slow down, re-anchor
Went quiet or said "that's more than expected"
Asked "can we do something smaller?"
Re-anchor to ownership value and ROI, then re-ask
Use: "What would make this feel worth it?"
→ Disqualify gracefully
They said "that's way out of our budget" with zero engagement. Don't push. Thank them, close cleanly, and mark as nurture. A respectful exit leaves the door open for later.
Step 5
Book the engineer call — on the spot, right nowNever let the call end without a booked next step. If they're qualified, the calendar opens now — not in a follow-up email. Aim for one week out: long enough for the engineering team to properly design the architecture, short enough to hold momentum.
Booking script
"Great. Here's what happens next — I'll put together a summary of everything we covered today and send it to our senior engineer before your call. They'll come in already knowing your situation, your workflows, and what we've been discussing, so it won't feel like you're starting over. The architecture review works best about a week out — that gives the team time to properly design your system so when you sit down together it's your actual blueprint, not a generic conversation. Does [date one week from today] work, or is there another day that week that's better for you?"
Once a time is confirmed
"Perfect — I'm sending you the invite right now. And before that call, I'd encourage you to think about any other workflows where you can see this kind of system being useful — the engineer will love having that context. We'll start with the highest-ROI use case, but they'll want to understand the bigger picture too."
Before you hang up — confirm three things
1. The architecture review is booked — specific date and time confirmed, approximately one week out.
2. The decision maker (or the right decision makers) will be on that call.
3. They know the call will include a real architecture proposal and an investment number.
2. The decision maker (or the right decision makers) will be on that call.
3. They know the call will include a real architecture proposal and an investment number.
Blueprint Playbook / Qualify & Hand Off
After the call
Qualification Criteria
A prospect is ready for the engineer call when they meet most of these. You don't need all of them — but the more boxes checked, the stronger the call will be.
Hard qualifiers — must have
Established business with real, recurring workflows — not early stage or pre-revenue
Decision maker was on the call, or will be on the engineer call
Price range didn't kill the conversation — they stayed engaged after hearing numbers
At least one specific, describable workflow or pain point surfaced
Strong fit signals — good to have
Has already used AI tools and can articulate where they fell short
Mentioned key person dependency or institutional knowledge risk
Expressed genuine interest in ownership vs. another subscription
Has a clear "one thing" — a specific outcome they want the system to produce
Data is accessible (even if disorganized) — not locked with no integration path
Gray area rule
If you're not sure — proceed and flag it clearly in your notes. A gray-area prospect is the engineer's call to make, not yours. Your job is to keep obviously wrong fits out, not to over-filter.
Blueprint Playbook / Handoff Form
Post-call
Technical Handoff
Fill this out right after the call while it's fresh. This becomes the Blueprint Assessment document the engineer works from. The more specific you are, the stronger the architecture proposal will be.
What this becomes
This form maps directly to the Blueprint Assessment document structure: Client Snapshot → Workflows Mapped → Data & Systems Audit → Success Metrics. The engineer uses this to design the architecture before the proposal call. Every field you fill in is one less thing they have to figure out on the fly.
01 — Client snapshot
02 — Workflows mapped
Document each workflow surfaced during Phase 2. Aim for 3–6. For each one: what's happening now, what the ideal state looks like, and roughly how much time/cost it's consuming.
Workflow 1 — Priority / highest ROI
Workflow 2
Workflow 3
Workflows 4, 5, 6 — additional workflows surfaced
03 — Data & systems audit
04 — Success metrics (what "good" looks like for them)
Fill in what you heard from them — specific time savings per workflow and the business outcomes they described. These become the success metrics in the blueprint document.
05 — Deal signals
06 — CSS notes for the engineer
CSS recommendation
Blueprint Playbook / Fit Signals
Quick reference
Reading the Prospect
Use these during or after the call to quickly assess where this prospect stands. Strong fits move to architecture. Weak fits get nurtured or disqualified early.
Strong fit signals
Has hit the ceiling with SaaS AI tools
Recurring, knowledge-heavy workflows
Specific pain they can articulate
Key person dependency / knowledge risk
Decision maker is in the room
Established business with real volume
Budget conversation wasn't defensive
Wants ownership, not another subscription
Weak fit / disqualify signals
Still deciding if AI is relevant to them
Looking for a cheaper SaaS alternative
Early-stage, no established workflows
Decision maker not engaged or absent
Budget clearly out of range
Wants a strategy doc, not a build
Highly fragmented or inaccessible data
No urgency and no specific problem
Phrases to listen for verbatim
Ownership readiness
"I'm tired of paying for tools that don't actually work for us."
"I don't want to be dependent on a vendor who can change pricing on me."
"I want something that's actually built around how we work."
Knowledge risk
"If [person] left tomorrow, we'd be in real trouble."
"A lot of the judgment calls just live in my head right now."
"We haven't really documented how we do things — it just gets passed on."
Genuine urgency
"We're growing faster than our team can keep up."
"A competitor just started doing something that's making us nervous."
"We're at a point where we either figure this out or hire three more people."
The north star
The goal of the Blueprint call isn't to close — it's to qualify well enough that the architecture call is worth everyone's time. A clean "not a fit" now is better than a wasted engineering conversation later.
Blueprint Playbook / Company Background
Know your company
Youtiva Company Background
Reference this before every call. The more fluent you are on Youtiva's mission, model, and proof points, the more credibility you carry into the conversation.
A message from the founder
Who we are
Mission
What Youtiva is and why it existsYoutiva builds private AI infrastructure for established businesses that have outgrown what generic AI tools can do. The company exists because most AI in the market is rented — and rented intelligence never compounds for the business that uses it.
The one-sentence version
We build private AI infrastructure so your business owns and compounds its intelligence — instead of renting it from platforms you don't control.
The landlord analogy — use this when you need a vivid frame
"Right now, most businesses are building on rented land. The AI landlord owns the property, can raise rent, change the lease, and benefit from everything you build on it. We help you buy the land."
Core positioning statement
We help serious operators evolve from experimenting with AI to owning intelligence infrastructure. Not a rescue story — an elevation story. From AI user to intelligence owner.
The ownership model
Differentiator
What makes Youtiva different from every AI toolThis is the most important concept to internalize. The difference isn't features — it's the fundamental model: ownership vs. rental.
What every AI tool is
You rent access — someone else owns it
Limited context window — can't hold your full operational depth
Built for everyone — optimized for no one
Can be repriced, deprecated, or shut down
Your intelligence strengthens their platform
What Youtiva builds
You own the system — codebase, architecture, IP
Persistent memory — compounds over time
Built specifically for your workflows and data
Runs in your environment — no vendor dependency
Your intelligence stays inside your business
How to say this in one breath on the call
"What we build isn't software you subscribe to. It's infrastructure you own. Once it's deployed, it runs in your environment — no ongoing dependency on us. You're not renting access to something we control. You own it completely."
The tool ceiling — what prospects have already hit
Generic AI tools have four structural limits: the isolation problem (each person's AI never talks to the rest of the company), the context ceiling (tools can't hold your full operational depth), the training gap (you can instruct but can't train them on your logic), and the landlord problem (someone else controls the platform). Private infrastructure solves all four.
What gets built
Product
The four layers of a Youtiva systemWhen a client asks "what exactly do you build?" — walk through these four layers. Each one is meaningful on its own. Together they form a unified intelligence that compounds.
1 — Context ingestion
We encode the business — products, terminology, client history, edge cases, workflows. The system works from your knowledge, not general internet knowledge.
2 — Memory architecture
A persistent knowledge layer that grows with use. Every document processed, every decision made — the system retains it. This is what makes it compound instead of reset.
3 — Decision logic & routing
We embed the specific rules and judgment calls that define how the business operates. The system doesn't just retrieve information — it knows what to do with it.
4 — Private portal & deployment
The system lives in the client's environment — their private cloud, their servers. Accessed through a private portal under their domain. Everyone draws from the same intelligence layer — ending the isolation problem permanently.
Simple way to describe this to a prospect
"Think of it as a brain built specifically for your business. It knows your workflows, remembers everything, makes decisions the way your best people do — and it runs inside your company, not inside our platform."
The expandability point — critical for the CSS call
The architecture is modular and built to expand. Phase 1 focuses on the single highest-ROI use case. But because the foundation is already there, every additional use case added later is faster and cheaper to build. This is what makes it infrastructure, not just a solution to one problem. Clients aren't buying a fix — they're buying a foundation that compounds indefinitely.
How it gets built
Process
The 120-day build processThree steps from first conversation to live system. The first two steps happen before the client pays anything — clarity before commitment is a core part of how Youtiva operates.
How to describe the process simply
"The first two steps are free — we design the system and show you exactly what it costs and what it returns before you commit to anything. If it makes sense, we build it in 120 days. If it doesn't, you leave with more clarity than you came in with."
Risk removal
Guarantee
The 120-day delivery guaranteeThis is one of the most powerful trust points in the Youtiva offer. Lead with it confidently — it signals that Youtiva carries the execution risk, not the client.
If we don't deliver — you don't pay.
No partial payment. No kill fee. No ambiguity. If the system we blueprinted isn't deployed within 120 days, the engagement is free.
✓
You own the architecture and codebase when deployment is complete
✓
The system runs in your environment — no ongoing dependency on Youtiva
✓
You own the intellectual property — including everything the system learns
✓
No subscription required to keep it operating after deployment
How to deliver the guarantee on the call
"We don't ask you to commit to something you don't fully understand. You see exactly what gets built and what it costs before you decide. And once you're in — if we don't deliver what we blueprinted in 120 days, you don't pay. The execution risk is ours."
Why the guarantee exists
Youtiva carries execution risk because infrastructure built incorrectly is worse than no infrastructure at all. It has to be done right — and Youtiva stakes the engagement on that. This is what separates a real build from a consulting engagement.
Fit
Fit criteria
Who Youtiva is for — and who it isn'tOnly six new clients are taken per quarter. Youtiva is deliberately selective — this isn't a volume play. Understanding who's a fit protects the quality of every build.
Right fit
Established business with real operational complexity
Already using AI tools — knows their limitations
Ready to invest in infrastructure, not another tool
Wants ownership — not a subscription
Decision maker is engaged and involved
Willing to be an active participant in the build
Not the right fit
Still exploring whether AI is relevant
Looking for cheap automation or task hacks
Early-stage with no established workflows
Needs to be convinced ownership matters
Wants a strategy document — not a build
Unwilling to invest in architecture
The identity shift Youtiva produces
Before Youtiva: intelligent early adopter, experimenting with AI, aware there's a deeper level available, but constrained by architecture.
After Youtiva: intelligence architect, infrastructure-level operator, strategic leader in their market, building a system that compounds every quarter. From AI user to intelligence owner.
After Youtiva: intelligence architect, infrastructure-level operator, strategic leader in their market, building a system that compounds every quarter. From AI user to intelligence owner.
Credibility & proof
Proof
Results, credentials & objection responsesUse these when a prospect asks "why should I trust you?" or "has this worked for other businesses?" Drop these naturally — don't recite them as a list.
Case study results — say these with specificity, not enthusiasm
70%
Reduction in EMR lookup time — multi-clinic healthcare group
98%
Fraud detection recognition rate — financial services
60%
Reduction in meeting documentation time — professional services
<10 min
Tax research that previously took 2 hours — CPA firm
Who's been served
Law firms
Healthcare groups
CPA firms
Wealth management
Sales organizations
Compliance & regulatory
Logistics operations
Real estate firms
Marketing agencies
Media companies
Team credibility
6+ years building AI systems — not a newcomer to this space
Founded and sold a SaaS company — understands both sides of building and depending on software
Engineers with backgrounds from Netflix, Meta, and Tesla
Multi-industry deployments across professional services, healthcare, finance, and operations
Blueprint Playbook / The Playground
Live technology demo
The Youtiva Playground
The Playground lets prospects interact with Youtiva's core AI technologies before committing to anything. Use it during or after calls to make the technology tangible — not theoretical.
What it is
The Playground contains approximately 14 live, interactive AI technology modules — the same ones Youtiva builds and deploys for clients. These are baseline models, not client-specific builds. Think of it as the engine before it's been configured for a particular business. Every module is interactive — prospects can actually use it, not just watch a demo.
Critical framing — say this before showing any module
"What you're seeing here is our baseline technology — it's not tuned to your business yet. Think of it as the engine before it's been trained on your data, your workflows, and your decision logic. When we build yours, it behaves like this — but it knows your business."
When to use it
During the Blueprint call — to validate a specific use case
If a prospect describes a workflow involving document analysis, inference, or voice — pull up that module and show them what it looks like in practice. Seeing it beats explaining it.
After the call — as a leave-behind that keeps them engaged
Share the Playground link in your follow-up. It gives them something to explore before the engineer call and keeps Youtiva top of mind.
When a prospect says "can you show me what this actually does?"
Don't try to describe it — show it. The Playground was built specifically for this moment.
Technology categories
Inference & Analysis
Inference Engine, Document Analysis, Video Analysis, Audio Analysis
Real-Time Intelligence
Web Search, Video Avatar, Facial Emotion Detection
Automation Intelligence
Agents, Assistant, Browsing, Voice AI
Data & Systems
ML & Analytics, Simulation, Avatar Generation, Domain-Specific Systems
Blueprint Playbook / Objections / FAQ
Handle with confidence
Objections & FAQ
The most common questions and pushbacks you'll encounter on Blueprint calls. Tap any to see the full response. Most objections aren't resistance — they're requests for more information.
About the product / technology
"Our data is too messy / disorganized to start." ▼
Response
"That's actually the most common thing we hear — and it's almost never true. Messy data isn't a barrier to building, it's the starting point. Every company we've built for started there. The Blueprint process is specifically designed to bring structure to what you have. You don't need to be ready. You just need to be willing."
"What if AI changes fast and what you build becomes obsolete?" ▼
Response
"What we build isn't tied to any single model. The real value is in the architecture, the encoded business logic, and the institutional knowledge the system accumulates. Models will keep improving — and when they do, your system gets an upgrade. The intelligence you've built stays yours."
"This sounds like it's only for big enterprise companies." ▼
Response
"That assumption is exactly what Youtiva was built to disprove. The 120-day model, the hands-on execution, the scoped approach — all of it exists to make owned intelligence accessible to businesses that are ready for it, not just enterprises with eight-figure budgets."
"We're not technical enough to build or maintain something like this." ▼
Response
"You don't need to become an AI company. You need to become an intelligence owner — those are very different things. We do the architecture and build. Your team doesn't need to maintain the AI itself. You architect once, we deploy it, and it compounds from there."
"Will we become dependent on Youtiva after it's built?" ▼
Response
"The opposite, actually. Once deployed, the system runs in your environment. You own the codebase, the architecture, and all the IP. There's no ongoing dependency on us to keep it operating. You're not subscribing to something we control — you own it completely."
"What's the difference between this and just using ChatGPT with a custom prompt?" ▼
Response
"ChatGPT is a generic tool available to everyone — it doesn't know your business, your clients, or your decision logic. What we build is private infrastructure trained on your specific data, embedded with your workflows, and owned by you. It's the difference between renting a car and owning one that's been built to your exact specs. And unlike ChatGPT, it retains institutional memory — it gets smarter the more it's used."
About the process & investment
"How much does this cost?" ▼
Response
"The engineering call will give you the exact number — that's where we scope everything properly. But so we're not surprising anyone: projects like what we've been talking about typically sit somewhere between [low range] and [high range], depending on scope and complexity. Does that feel like a range you'd be willing to explore if the architecture makes sense?"
"120 days seems like a long time. Why does it take that long?" ▼
Response
"It's actually faster than the alternative. Building this internally with a full engineering team typically takes 12–18 months and costs $500K+. 120 days is compressed because we've spent six years solving the problems most teams hit during that build. You're getting six years of experience applied to your specific situation."
"Can we start with something smaller / cheaper first?" ▼
Response
"I understand the instinct — and I want to be honest with you. What makes this work is building it properly from the start. The reason Phase 1 delivers the ROI it does is because we're building real infrastructure, not a patch on top of existing tools. A smaller scope usually means a weaker foundation, which means everything you want to add later costs more and takes longer. The most efficient path is doing Phase 1 right."
"We need to think about it / talk internally first." ▼
Response
"Of course — and I want to make sure you have everything you need for that conversation. Can I ask: is there a specific part of what we covered today that needs more clarity before you're comfortable moving forward? I'd rather surface that now than have you go back and forth on something I can answer in five minutes."
What this objection usually means
"We need to think about it" almost always means something specific is unresolved. Find out what it is — don't let them leave without knowing what's standing between you and a yes.
"We already have someone handling AI / an IT team doing this." ▼
Response
"That's good context — and I'd ask one question: is what they've built trained on your data and owned by your business, or is it a configured version of a tool someone else controls? There's a meaningful difference. What we build isn't a configuration — it's custom infrastructure. When we're done, your IT team can run it, maintain it, and extend it without us. We're not replacing them — we're giving them something worth running."
About timing & urgency
"We're not ready yet / we want to wait." ▼
Response
"That's a fair position — and I won't push. But I'd ask you to consider one thing: intelligence compounds. Every month you build owned infrastructure, your system gets smarter and your advantage grows. Every month you wait is a month you're not compounding. That's not urgency theater — it's just math. The question isn't whether to build. It's whether to build now or later, knowing that later costs more competitive ground."
"Is the Blueprint call actually free? What's the catch?" ▼
Response
"It's genuinely free — no catch. The reason we do it this way is that we're selective about who we work with. We only take six new clients per quarter, and we want to make sure the fit is right on both sides before anyone commits. If it's not a fit, we'll tell you directly. If it is, you'll leave with a clear picture of what your system would look like — even if you decide not to move forward."
Handling objections — the general principle
Most objections on the Blueprint call aren't real resistance — they're hesitation. People hesitate when something is unresolved, not when they've made up their mind. Your job is to find what's unresolved and address it directly. Don't talk past objections. Acknowledge first, then reframe.