Jax Systems: Customer Lifecycle Playbook

Working draft · 9 November 2026 · Internal planning, not customer-facing copy. This is a first operating playbook, not evidence that any customer has been contacted, any offer has been validated or any system has been built. The published business workspace is publicly accessible; do not put prospect names, client data, notes, credentials or private results in this document.

Purpose: help a Northeast Florida business move from “I have a recurring operational problem” to a useful, supported system it can own. Understand the work first; sell one bounded intervention; transfer knowledge; measure actual results. AI is optional. The owner should never need to buy a second project to get value from the first.

Activation: this playbook does not authorize launch, paid tools, campaigns, outreach, account connections or access to customer data. Start marketing only when Evan explicitly chooses to do so; approve channels, claims and any budget. Drafts are not sends.

1. The customer journey and handoffs

1. Market and attract → a relevant owner understands the problem Jax can help investigate and has one clear next step.
2. Qualify → a real owner problem, decision process and possible fit are recorded; the owner is not pressured to buy.
3. Owner call → the owner describes the current workflow, its consequences, prior efforts and options. Agree whether a further conversation is useful.
4. Discovery / scoping → establish what is happening with appropriate permission, identify alternatives and produce a bounded recommendation. The free-versus-paid entry decision remains open.
5. Proposal and decision → agree on one workflow, deliverables, cost, acceptance, exclusions and ownership. A no or a pause is valid.
6. Onboard and build → make access and ownership safe; demonstrate progress and test normal, error and repeat cases.
7. Accept and hand over → the client validates the agreed result and can operate or safely stop the system.
8. Care and improvement → if separately agreed, support the running system, report actual results and quote new work separately.
9. Expand or exit → propose another workflow only when there is a reason and capacity; on exit, transfer what was agreed and close access cleanly.

Each handoff records owner, next action, due date, decision, blockers and consent. A customer can pause or leave at any stage. This is a suggested sequence; a simple situation may require fewer calls, while a complex one may require more.

2. Attract the right conversations

Who: locally relevant small-business owner or operator with a repeated operational task, a person able to approve changes, and a plausible path to implementing them. Industries, pain, willingness to pay and budget remain hypotheses until checked. Existing customer tools may already solve the issue; Jax should be willing to say so.

Before launch: choose a real audience, one problem/offer, truthful proof or a clearly labeled illustrative demonstration, a simple inquiry path and who will respond. Start with the channels Evan approves; relationship-led local conversations and practical demonstrations are candidates, not assumed winners. No ad spend or paid tooling without explicit approval.

Future production loop: research owner language → choose a specific problem → create a few distinct concepts → check every claim and link → Evan approves distribution → connect source and creative ID to inquiry → learn from qualified conversations and paid work. Use real work and permissioned proof, not invented case studies, testimonials or synthetic customers. Static assets or Evan's own demonstration are sensible first formats; the full video/warehouse system is optional.

Handoff to sales: capture how they found Jax, what they asked about, permission to follow up, and their preferred contact method. A website form, CRM, automation or customer-data store is not created merely by writing this playbook.

3. Qualification: is a conversation worthwhile?

Ask just enough to decide whether to talk—not to conduct the paid assessment by stealth.

• What does the business do, and what kind of work is causing friction?
• Who experiences it, who would use a fix, and who makes the decision?
• What systems or people are involved? Is there an existing provider?
• Is the owner exploring, trying to solve something now, or unable to say yet? What is driving the timing?
• What would a useful outcome be? Are there known constraints, sensitivities or budget concerns?

Fit: repeated problem, owner willing to discuss it, a route to the relevant decision-maker and no unresolved access or risk barrier → arrange a call. Early / uncertain: answer appropriate questions, offer a short conversation or a later check-in if invited. Not a fit: say why, do not imply Jax can help, and suggest an alternative only if it is genuinely appropriate.

If someone asks price early, answer with the current approved starting price or range and explain what is not yet known. Never hide pricing just to force a call. Do not collect sensitive customer records to qualify a lead.

4. The first owner call: listen before pitching

Preparation: review only relevant public facts and any information the owner voluntarily provided. Choose 2–3 questions. Do not present industry research as a finding about this specific business. Plan roughly 30 minutes, but adapt to the owner; phone and in-person are both valid. If someone is driving, arrange a safer time.

1. Frame and permission. After normal human rapport:

“I'd like to understand how this works today, what is getting in the way, and whether there's a useful next step. If it isn't a fit, I'll say so. May I ask a few questions?”

Do not promise a referral, a diagnosis or expertise you cannot actually provide. If the owner is exploring, say that is fine: “Are you mainly gathering information, or is this something you're trying to solve now?” Both are legitimate.

2. Walk through real work. Use these as prompts, not a checklist to interrogate the owner:

• “Walk me through the last time this happened—from the first request to the final handoff.”
• “When you say it is slow or inefficient, what specifically happens?”
• “Who handles it, and what do they have to check or repeat?”
• “What's already working? What have you or your provider tried? What happened?”
• “How often does it happen, and what does it cost in time, missed opportunities or rework—if you know?”
• “If it worked better, what would be noticeably different for you and your team?”

3. Decision context and alternatives. “Who else should be involved? What are you comparing—your current process, an existing provider, a built-in feature, doing it yourselves, or outside help? What will matter most in deciding?” Ask what is good and bad about the incumbent. An existing vendor is not presumed to be failing.

4. Reflect, don't diagnose beyond the evidence. “It sounds like [their words], which happens [frequency if known] and affects [impact if known]. Did I get that right? What have I missed?” Separate owner statements, observed evidence and unknowns. If helpful, with permission give a brief relevant observation or alternative, without turning the qualification call into an unagreed full assessment.

5. Agree on a next step—or stop. “Would it be useful to map the work and the options in more detail, or would another path be better?” If they want information rather than a decision, offer an appropriate summary. If they need time, ask what information or people matter and whether a later check-in would be welcome. Set a date only by mutual agreement; don't require a verbal commitment to buy before continuing the conversation.

Handling common responses

• “I'm just looking.” “That's fine. What are you hoping to learn or compare?” Offer information appropriate to their stage; no forced urgency.
• “We already have a provider.” “What's working with them, and what do you wish were different?” If they can solve it, that may be the best option.
• “We can do it ourselves.” “Possibly. What would your team need to make that workable?” Consider native features or training; don't manufacture a dependency.
• “What will it cost?” Share the latest approved starting context and what affects the quote. Do not present an estimate as a fixed commitment before scope is agreed.
• “I need to think.” “Of course. What is still unclear, or who else needs to weigh in?” Send a concise recap only if useful; allow a no without chasing.
• “Can you guarantee the result?” “I can define what we'll deliver and how we'll test it. I can't promise a business outcome we don't control.” Any warranty or remedy requires explicit agreed terms.

5. A second conversation, when useful

Start with an accurate, neutral recap—not an attempt to make the owner feel bad again:

“Last time you described [actual problem and consequence]. Has anything changed? Is this still worth discussing?”

Confirm decision criteria, decision-makers, timing and whether they want to consider a next step. With permission, describe the bounded discovery or implementation option appropriate to what is actually known, its price context, what the owner would receive and what happens afterward. Offer a short written recap, a decision-support summary or a proposal if useful. Schedule a follow-up around a real event only if the owner agrees.

Do not assume they have already decided, insist on a second meeting, denigrate competitors, create artificial scarcity or claim every month of delay loses money. A legitimate decision can be “do nothing,” “use the current vendor,” “not yet,” or “no.”

6. Discovery and the business case

Open offer decision: the 9 November direction calls for a clearly priced path and raises a still-unresolved choice between paid discovery and free scoping. Earlier business-model notes make paid assessment mandatory. Test and decide deliberately; this playbook does not settle that conflict. A training-led entry is another hypothesis, not an approved replacement.

Current example for discussion, not an automatic quote: $999 discovery, credited toward a $2,499 first scoped deployment; if that exact deal is approved and both fees are included, the remaining deployment balance is $1,500, not $2,499 again. The same 9 November note cites $499/month ongoing support and separate pricing for additional locations; all scope, dependencies and terms must be agreed before use. The existing Offer tab shows older ranges; reconcile it with current direction before customer-facing use. Never promise that every job fits the example price.

For whichever entry is agreed, define what the customer receives and what is not included. With permission, map the current workflow, speak with actual users where relevant, review approved data and systems, identify native-tool/process alternatives, and rank candidate improvements by evidence, effort, risk and adoption. Recommend at most one first workflow for a specific proposal. The discovery deliverable remains useful even if they don't buy deployment.

Business-case worksheet:

• Current work: example, frequency, people involved and how the figure was obtained.
• Consequence: observed or owner-estimated time, rework, delay or lost opportunities; identify unknowns.
• Options: keep current approach, improve existing tools/provider, internal change, or a scoped Jax project.
• Costs: implementation price, client effort, third-party fees, support, transition and any switching cost.
• Expected effect: a conservative scenario or range labeled as an assumption, not guaranteed savings. Avoid double-counting time and revenue, and never treat every missed inquiry as a sale.
• Decision: owner states whether expected benefit and risk justify action; doing nothing remains an option.

7. Proposal and agreement

The proposal is a decision document, not a list of AI buzzwords. It includes:

1. The owner's problem, baseline and desired result in plain English; what is measured versus assumed.
2. One workflow and the exact deliverables, prerequisites, integrations and exclusions.
3. How acceptance will be tested: named scenarios, expected results, evidence, who reviews and how defects are handled.
4. Fixed project price, credit treatment, payment milestones, third-party charges and any taxes or additional costs as applicable. The client can see the total and any remaining balance.
5. Target timing with dependencies and what happens if access, decisions or inputs are delayed. No blanket speed guarantee.
6. Data and account responsibilities, human approvals for consequential actions, security/privacy requirements and applicable vendor or regulatory constraints. Escalate if sensitive data or a regulated workflow exceeds capability.
7. What the client owns, licenses or must keep paying for; training, documentation, handoff and an exit path.
8. Optional support terms, scope of small changes, incident contact and any agreed response commitments. New capabilities require a separate written quote.
9. Change-control, cancellation and any warranties/remedies agreed in the actual contract. Use appropriate legal review for live agreements; this draft is not legal advice.

Handoff: begin paid work only after the relevant agreement, permissions and payment milestone are confirmed. Do not treat a conversation, draft proposal or suggested fee as a signed deal.

8. Onboard, build and test

Kickoff: restate the outcome, scope, schedule, assumptions and acceptance criteria. Identify the buyer, day-to-day workflow owner, technical access owner and approver. Agree a communication cadence and escalation path; no invented service-level promises. Confirm source-of-truth systems, data categories and retention/deletion expectations.

Access: prefer client-owned accounts, named access, least privilege, and read-only access until a specific write is needed and approved. Use a secure mechanism for secrets; never put passwords, verification codes, tokens or customer records in public notes, chat transcripts or an AI provider without authorization. Consent to a discovery call is not permission to access client systems. Stop and reassess if data sensitivity, contract terms or security controls are unclear.

Build: implement the smallest approved slice. Check the native tool or simple process option before adding software. Track actual founder/review time and vendor costs. Communicate material blockers and scope changes promptly; don't silently expand the job.

Test before launch: run agreed normal-path tests; missing/bad inputs; duplicates or repeats; permissions and integration failures; and rollback/manual fallback. Inspect generated output and any external messages. Use test or anonymized data where possible. Consequential writes, communications and production cutover require the agreed human approval; if a test fails, fix or document a decision, not a fabricated pass.

9. Acceptance and handoff

Show the named client owner the real workflow. Run each agreed acceptance scenario, review exceptions, record results and resolve or explicitly agree on remaining issues. “Done” is the agreed acceptance decision—not a polished demo or an invented time-saving number.

Deliver a plain-language operating guide: what the system does, where it runs, who owns each account, ordinary operation, exception handling, how to pause or roll back, support contact, dependencies and third-party charges. Train the actual users. The client receives the agreed materials and access even if it declines support; continued operation still depends on its own active accounts, licenses and integrations.

Record the actual starting measurement and a feasible follow-up date if the owner agrees. Do not claim success before sufficient real use.

10. Care, learning and a clean exit

Care is optional and separately scoped. Define the supported system, monitoring if actually provided, communication channel, coverage/response expectations, included small fixes, excluded work, client dependencies, costs and cancellation. Support does not silently include an unlimited build backlog. A care plan exists only if the customer agrees to it.

Review: compare actual outcomes with the baseline when data supports it; show changes, issues, usage/adoption, costs and what remains unknown. Early before/after comparisons are not proof that Jax caused an improvement. Escalate outages and exceptions according to the agreement. Protect client information; request explicit permission before any case study, testimonial, logo, quote or referral.

Expansion: if an owner wants to address another workflow, revisit the diagnosis and offer a fresh, fixed-scope proposal. Do not pressure customers into another project or bundle new capabilities into care without agreement.

Exit: confirm requested end date and contractual obligations; hand over agreed documentation, client-owned assets, access inventory and export options; explain ongoing vendor dependencies; stop or transfer approved automations and billing responsibilities; revoke Jax access when no longer needed; and confirm retention/deletion per agreement and applicable obligations. A customer's system must not depend on a hidden lock-in mechanism.

11. Operating records, metrics and decision rights

When an appropriately private system is chosen, record the minimum needed: source/consent, company and owner-approved contact, stage, the owner's words, decision-maker, next action/date, agreed commercial terms, delivery owner, acceptance evidence and support status. Keep customer records out of this public workspace. The exact CRM/tool is not chosen or configured by this document.

Suggested stages: new inquiry → qualifying → owner call → discovery decision → discovery underway → proposal → agreed / not proceeding / paused → onboarding → building → acceptance → live → optional care → completed / exited. Set clear dates, owners and reasons; do not treat a scheduled call, proposal or verbal interest as signed revenue.

Suggested measures: qualified inquiries, held owner calls, agreed discoveries, accepted deployments, delivered/accepted projects, optional care uptake, client-reported outcomes, founder time, actual delivery costs and support exceptions. Track numerators and denominators, date and source; show “not enough data” rather than a fabricated conversion rate. For acquisition, connect source/creative to qualified calls and paid work where possible; clicks and rendering volume are diagnostics, not the goal.

Human gates: Evan approves launch, channels, claims, spending, prospect communications, pricing and agreements. The client authorizes system access, production changes and acceptance. AI may help draft or summarize in an approved environment, but it does not independently commit terms, access data, contact people, publish, spend or ship a production change.

Proposed SMART review: after Evan explicitly activates marketing, for the first 30 calendar days record the source and outcome of every inquiry that comes through the approved channels, then conduct one dated review of qualified conversations, offers, costs and observed objections. Use the actual sample, even if zero; decide whether to continue or revise. No assumed lead volume or conversion rate.

12. Reusable scripts and checklists

Owner-call note template

• Context / source and permission to follow up:
• One recent workflow example, actors and current tools:
• Owner's words about friction; frequency and impact if known:
• What works and what has been tried:
• Alternatives and constraints, including current provider / native tools:
• Desired outcome and baseline; facts vs estimates vs unknowns:
• Decision-maker(s), criteria, timing and any budget context volunteered:
• Fit / not fit / uncertain, why; agreed next action, owner and date:

Follow-up draft — review before sending

Subject: Recap and next step

Hi [name], thanks for walking me through [workflow]. As I understood it, [problem in their words] affects [known consequence]; [uncertainty or useful existing approach]. Please correct anything I missed. We discussed [specific next step, scope and approved price context if relevant]. [Agreed next action/date, or “No action needed unless you'd like to continue.”] Thanks, Evan.

No message is sent merely because this template exists.

Delivery acceptance checklist

• [ ] Scope and baseline agreed; account ownership and named client approver recorded.
• [ ] Normal, bad-input, repeat, permission-failure and rollback/manual-fallback tests run and evidenced.
• [ ] Actual client owner reviewed acceptance results and any exceptions.
• [ ] Users trained; documentation, access, ongoing costs and dependencies explained.
• [ ] Support is separately agreed or declined; exit/transfer expectations documented.

Small example — explicitly fictional

A local service owner says follow-up on quote requests is inconsistent. Ask for the last few examples, who owns follow-up, the current software's built-in capabilities and what “inconsistent” means. If the team's existing tool already supports the workflow, improving its settings or training may be preferable to a new build. If not, agree a limited discovery path; only then propose an appropriately scoped intervention, acceptance test and user training. No savings number or customer outcome is assumed.

13. Source notes and open decisions

Sales: Drew Long's four-image sales framework contributes the opening frame, buyer-readiness questions, pain-before-pitch, fair comparison, quantified business case, voluntary follow-up and next-call recap. Its sales/conversion claims are unverified; aggressive competitor attacks, manufactured urgency, guarantees and pressure are not Jax policy. Geo's two-meeting framework adds a useful recap and discipline about next steps, not a mandatory two-call or commitment-before-information rule.

Marketing: Greg Isenberg and Cody Schneider's creative system contributes source-grounded creative, human review and measurement; its cost/performance anecdotes are not independently verified, and no production system is activated. Evidence-led GTM research informs hypotheses and disconfirmation, not a claim that demand is validated.

Delivery and operations: 567 Labs' AI Consulting Playbook informs discovery, proposals and engagement boundaries; Michele Torti's delivery walkthrough informs kickoff, testing and handoff, while its customer-lock-in suggestion is explicitly rejected. Luke Pierce's training-led alternative challenges the paid-audit entry and remains an option to test, not an approved pivot.

The full indexed Jax source library and preserved source notes remain in Obsidian. This is a working synthesis of the most relevant reviewed sources—not a claim that every past resource has been re-audited or loaded automatically. Review and update it from actual customer feedback before using it as a live operating procedure.

Decisions still needed before launch: paid discovery vs free scoping vs another entry; reconcile the newer specific pricing with old site ranges; define the exact entry/deployment deliverables, credit and support terms; select first audience/channel and an approved budget; choose a private record system; finalize data handling, contracts and actual escalation contacts. No customers, results or conversion benchmarks are invented here.