Qualification
When you contact Lab 317 — whether you email Sterling, submit a demo request, or get referred — the first thing that happens is qualification. Not a pitch. Not a capabilities deck. A structured conversation designed to figure out whether what you need is something we can build well.
We ask five questions. They're not trick questions. They're the questions whose answers determine scope, timeline, feasibility, and fit. If we skip them, we're guessing — and guessing is how you end up with a project that technically works but doesn't solve anything.
1. What's the pain point?
Not "what do you want to automate?" — what's actually breaking? What's slow, expensive, or falling through the cracks? The answer here sets the entire direction. A company that says "we need AI" gets a different engagement than one that says "we're losing leads because nobody replies before Tuesday."
2. What have you tried before?
Prior attempts help us calibrate scope. If you tried Zapier and it couldn't handle the edge cases, that tells us something specific about complexity. If you hired a developer and the project stalled at integration, that tells us something about your environment. If you haven't tried anything yet, that tells us you're early — which is fine, but it changes the conversation.
3. What does success look like?
Your definition of done, not ours. Some clients want a number — "reply to every inbound lead within 60 seconds." Others want a feeling — "I want to stop worrying about the inbox on weekends." Both are valid. Both produce different system designs. We need to know which one we're building toward.
4. What's the timeline?
Urgent means we scope tightly and deploy fast. Exploratory means we can take time with architecture. "We need this yesterday" and "we're planning for Q3" are both fine — they just produce different engagement shapes. The worst answer is no answer, because it usually means someone else is setting the deadline and hasn't told you yet.
5. Who's the decision maker?
Not to go over your head — to make sure the person who signs off is in the conversation early enough to matter. Projects where the decision maker appears at week four with a new set of requirements are projects that go sideways. We've seen it. We'd rather not see it again.
Builder Confidence Check
We run a builder confidence check before configuration starts.
Once qualification is complete, we don't jump to a quote. We run a feasibility assessment against what you've described — your pain point, your environment, your definition of success, and the timeline you need. The output is a confidence signal: can we build this, and how confident are we that it delivers what you described?
If the answer is high confidence — we proceed. You get a clear scope, a timeline, and a price.
If the answer is uncertain — we'll tell you. We'll explain what's causing the uncertainty (usually integration complexity or ambiguous success criteria) and what we'd need to resolve before committing. Sometimes that means a paid discovery phase. Sometimes it means you need to answer a question we can't answer for you.
If the answer is low confidence — we'll say so. No quote. No "let's try it and see." If we don't think we can deliver what you need, that conversation happens before you've spent anything, not after.
This is the gate that prevents the week-five surprise. It exists because we've been on the other side of engagements where nobody checked feasibility until the budget was spent. It's not a pleasant experience for anyone, and it's entirely preventable.
After Launch
Two things can happen after launch. They require different responses.
Something that was working has stopped.
This is support.
Email [email protected].
Include the agent name. Describe what you expected to happen and what happened instead. If you have a timestamp, include it.
We triage incoming issues and escalate critical failures immediately. You'll hear from a human — not an autoresponder, not a ticket number with a promise to get back to you.
If the fix is configuration, we handle it. If the fix requires a code change, we scope it and give you a timeline before we start.
Something is working but I don't understand what it's doing.
This is different from broken. This is help.
Email Sterling or your project contact.
We offer training sessions, documentation walkthroughs, and office hours. The goal is your team understanding what the system does well enough to manage it confidently — not permanently depending on us to explain it.
We stay involved until your team actually uses the thing. Not just technically running. Actually uses it.
Want to talk through the process?
I'm Sterling. This is the same process I walk every prospect through — whether you're ready to start or just trying to understand how we work. No commitment on the first conversation.
Email Sterling →
— Sterling, Lab 317 Sales