This content was auto-generated from Fusion SMB documentation and is pending SME review. Please verify accuracy before using in partner-facing contexts.
Pre-Sales Qualification & Evaluation Intake
This lesson covers the qualification step that happens after a lead comes in through the web form and before binaries are sent. It exists to catch compatibility deal-breakers — an unsupported HA stack, an unconfirmed container runtime, an untested filesystem — early, while the change is still cheap.
It sits between the Demo Environment Setup, which you use to practise the product yourself, and the PoC Guide, which you run with the prospect once they've cleared qualification.
Why a tiered intake
Earlier intake forms asked for everything up front: command outputs, full smb.conf, FIO numbers, iperf measurements. Completion rates were low, and the few completions still didn't catch the issues that actually killed deals — a prospect running Podman when only Docker was tested, a cluster built on CTDB when only Pacemaker/Corosync was supported. The deal-breakers were hiding behind questions the prospect never reached.
The current form inverts the priorities:
- Tier 1 questions are cheap and decisive. A prospect can answer them in a couple of minutes. The answers either clear a deal or surface an escalation.
- Tier 3 questions are heavy and diagnostic. They belong during the evaluation, ideally on a screen-share with pre-sales or support — not as homework before engagement.
| Tier | Purpose | When to collect |
|---|---|---|
| Tier 0 | Contact and context | On the web enquiry form |
| Tier 1 | Compatibility gates — catch deal-breakers | Send to the lead, or ask on the first call |
| Tier 2 | Qualification and scope | On the pre-sales call, or as optional form fields |
| Tier 3 | Deep technical baseline | During the evaluation, not before |
Tier 1 — the seven compatibility gates
Walk through these in order on a pre-sales call, or send them as a short form. Each gate has an answer pattern that should make you stop and loop in engineering before promising anything.
1. Deployment runtime
How will Fusion SMB be deployed: bare metal, VM, container (Docker / Podman / LXC), or Kubernetes?
Bare metal, VMs, and Docker are well-trodden. Podman, LXC, and bespoke Kubernetes are not — confirm with engineering before committing. If they're running a container, also ask which engine and version, and whether they run it privileged or with host networking.
2. Single-node vs HA
Single SMB node, active-passive, or active-active / scale-out?
If they want HA, go straight to gate 3 — the HA mechanism question is where deals get blocked.
3. HA mechanism
Pacemaker/Corosync, CTDB, custom/in-house failover, or other?
Pacemaker/Corosync is the recommended and supported HA stack. It is the aligned answer.
- CTDB is not supported. If they name CTDB, set expectations on the call — do not let it surface mid-evaluation.
- Custom / in-house failover needs engineering review before you commit to a timeline.
Confirm the current supported HA matrix before quoting it to a partner — the supported stack should be re-checked against the latest release notes each cycle.
4. Linux distribution and kernel
What distro and version, and what kernel, are the SMB hosts running?
Binaries are built for specific distro/kernel combinations. A one-line answer here avoids "it won't start" surprises after delivery. Don't ask for command outputs yet — lsb_release, uname -r, gcc -v are Tier 3.
5. Underlying / exported filesystem
GPFS, BeeGFS, Lustre, GlusterFS, CephFS, StorNext, DAOS, WekaFS, ZFS, ext4/XFS, MyriadFS, or other?
Drives both compatibility and ACL behaviour. Anything off the tested list is a flag.
The intake form lists the filesystems above; confirm the current officially-tested list before clearing a prospect on this gate.
6. Authentication source
Active Directory, LDAP, local accounts, or other?
The account source materially changes the configuration conversation. If they say AD or LDAP, note the topology — it will come back during the PoC.
7. ACL model
POSIX-based, native Windows ACLs (xattrs), filesystem-native ACLs, DOS attributes, or no security?
Mismatched ACL expectations are a frequent source of friction during evaluations. Confirm the underlying filesystem actually supports the model the prospect wants.
Stop-and-escalate triggers
Four answers should make you pause and loop in engineering before sending binaries or committing to a timeline:
- A non-supported SMB cluster manager — CTDB, or a custom / in-house failover stack. The recommended and supported HA stack is Pacemaker/Corosync.
- A container or orchestration runtime we have not confirmed — Podman, LXC, or a bespoke Kubernetes setup.
- An exported / underlying filesystem not on the tested list, or an unusual ACL expectation.
- An OS distribution or kernel outside what the binary is built for.
If the prospect names any of the above, your job on the call is to acknowledge it, not to improvise compatibility. "Let me confirm with engineering and come back to you within X" preserves both the deal and the truth.
Tier 2 — qualification and scope
Once Tier 1 has cleared, the Tier 2 questions size the opportunity and shape the PoC plan. Cover these on the call:
- Client operating systems — Windows, macOS, Linux, other.
- Current SMB solution and the pain driving the evaluation — Samba version, performance ceiling, stability, support gaps. A rough current benchmark number is useful context here; detailed
smb.confand FIO numbers are Tier 3. - Rough scale — concurrent clients, concurrent connections, number of shares. Ballpark is fine.
- Rough performance target — read/write throughput, IOPS, IO type that defines a successful eval. Ballpark only at this stage — precise FIO baselines come during the eval.
- Workload profile — sequential vs random, small vs large files, mixed.
- Specific features to evaluate — Multichannel, RDMA, Continuous Availability, failover, single-IP / single namespace, compression, QUIC.
- Success criteria and decision process — what does a successful eval look like, and who signs off?
Tier 3 — collect during the evaluation
These are valuable, but they are also why the old form had low completion. Gather them once the prospect is engaged and the binary is being installed — ideally on a screen-share with pre-sales or support, not as homework:
- Host command outputs —
lsb_release, release files,$HOSTTYPE,catof the binary arch,gcc -v. - Storage and hardware detail — storage software, CPU, memory, NICs, link speed, number of interfaces, FIO numbers.
- Network detail — measured network speed (
iperf), RDMA on/off, topology. - Benchmarking tools and parameters; client-side applications.
- Current Samba detail — version, current benchmark, full
smb.conf. - Current infrastructure baseline — FIO read/write, IOPS read/write.
- Detailed SMB performance requirements — per-metric targets.
How to use the form in practice
- As a form — send Tiers 0–1 to the lead. They're quick to answer. Delete the internal Pre-sales note lines from the source document first; they're internal guidance, not prospect-facing copy.
- As a call / email guide — work top to bottom on the pre-sales call. The Pre-sales note lines tell you why each question matters and what answer should raise a flag.
- Tier 2 can be sent or asked on the call.
- Tier 3 is a reminder list only. Do not ask it up front; collect it during the evaluation.
The design principle: pull the cheap-but-critical fit questions to the front; push the friction-heavy benchmark work to during the eval. Tiers 0–1 should take a prospect only a couple of minutes.