The First 100 Customers Course #22: How SightCall Turned Weekly Salesforce Visits Into Its First Major Customer

TL;DR

SightCall did not reach its first major customer through a launch, a large audience or broad outbound. Founder Thomas Cottereau says he entered Salesforce's San Francisco office every week until he reached the Service Cloud team. A working API demo earned a same-day technical test. Salesforce then brought SightCall into a costly printer-support problem at HP, which became the company's first major customer in 2014.

HP was not the literal first customer. Cottereau says one or two smaller customers came before it. The useful mechanism is partner first, buyer second: choose one distribution host already trusted by your buyer, prove value inside that host's workflow, and let the host carry you into a problem it already sees. The warning is equally important. Persistence alone is not a channel. SightCall's access worked because five years of platform engineering produced an integration Salesforce could test without believing a pitch.

What you will build

You will build a partner-first first-customer system with six concrete outputs: a distribution- host shortlist, an embedded-wedge memo, a 20-contact partner map, a falsifiable proof kit, a joint buyer brief and a repeatability checkpoint. Each output has a pass condition and a stop condition. The system is designed to stop a founder from confusing a famous logo with an active route to customers.

This motion fits a product that becomes more useful inside another platform, service firm, marketplace, association or operating workflow. It is especially relevant when the buyer has a complex deployment, trusts an incumbent system, or will not adopt a new vendor without a known route. It does not fit when the so-called partner offers only audience reach, when every integration is unique, or when an end user can adopt and experience value alone in minutes. Self-serve distribution is usually simpler in those cases.

Case snapshot

Element	What the sources support	Evidence limit
Product build	A working prototype in four months; an enterprise-ready platform in five years	Retrospective founder timeline
Early customers	One or two smaller customers before HP	Names, prices and outcomes are undisclosed
First major customer	HP's printer division, signed with Salesforce in 2014	Founder-reported; customer order is not independently confirmed
Partner access	Weekly Salesforce office visits and requests for introductions	Attempt count and duration are unknown
Technical proof	A same-day API-key request and testing reportedly completed by midnight	The Salesforce test record is not public
Buyer problem	Reported 20-30% printer returns, often for simple faults	Baseline, realised reduction and savings are not independently audited
Later channel	More partnerships and enterprise customers	No partner-sourced pipeline or conversion totals

The dated sources help separate the mechanism from the mythology. SightCall's October 2015 financing announcement names Salesforce as a partner and says two large printer manufacturers were using the platform, but it does not name HP. A later independent TechCrunch report confirms a $42 million round and roughly 200 enterprise customers in 2021. Neither source proves HP's contract economics or exact place in the customer order.

The model: borrow workflow, not attention

The causal chain is distribution host → repeated access → workflow-native proof → partner-owned buyer problem → joint deployment → reusable partner package. Each arrow prevents a common category error. Repeated access without proof is networking. Proof without a host is another isolated demo. A host without an active buyer problem is only a logo. A first deployment without a reusable package is consulting.

SightCall's distribution hypothesis existed before its final use case. Cottereau describes APIs as one of the three pillars designed at the beginning: the company would add visual communication to enterprise software and reach customers through those products. What the team had not yet found was the sharp daily problem. That separation is useful. A founder can be precise about the distribution surface while still learning which expensive workflow deserves the product.

The model also explains why the story is difficult to copy literally. Cottereau had deep telecom experience, prior operating experience, a robust platform and enough capital to spend years on enterprise readiness. A builder should copy the sequence and gates, not the five-year cost base or the assumption that any famous platform will open its doors.

Step 1: choose one distribution host

Start with the organisation between you and the buyer, not with a list of end accounts. A distribution host may be a software platform, consultancy, integrator, agency, association, marketplace, reseller, data provider or specialist community. Its value is not reach alone. It owns a workflow, a trust relationship or an economic problem that makes your product easier to adopt.

Create a five-row host worksheet and score each candidate from zero to two on:

• Trust: does the buyer already rely on this organisation?
• Problem visibility: does it see the pain before an outside vendor?
• Mutual value: does your product improve its own offer or retention?
• Workflow access: can you act inside the system where the problem occurs?
• Reuse: can one proof and integration serve multiple accounts?

SightCall chose large enterprise software vendors. Salesforce already owned the Service Cloud workflow and the executive relationship with HP. SightCall could add a missing visual layer without asking HP to replace the system it trusted.

Pass condition: one host scores at least eight out of ten, including workflow access and reuse. Stop condition: the candidate offers promotion but cannot name the workflow, buyer owner or another account with the same problem.

Step 2: write the embedded wedge

A partnership pitch usually starts too high: shared vision, market size and mutual opportunity. Replace it with a four-field embedded-wedge memo. Name the trigger inside the host's workflow, the input your product receives, the action it enables and the buyer outcome that changes. Keep it to one page.

SightCall's wedge was observable. When a voice-only support interaction could not diagnose a physical problem, the agent could start visual guidance through Service Cloud. The customer showed the device with a phone camera; the agent could see the issue, annotate the image and guide a fix. The later Salesforce activation documentation still describes the API key, tenant and Salesforce-domain connection, while Salesforce AppExchange lists SightCall as a paid visual-support app. Those later sources prove the integration became durable, not that every early claim is accurate.

Pass condition: the host can explain the trigger and buyer outcome in one sentence, then identify the owner of the workflow. Stop condition: the memo begins with your features, depends on a broad transformation story, or requires a different integration for each account.

Step 3: earn a route to the product owner

Cottereau moved his family to the Bay Area because the enterprise-platform route required proximity. He says he entered Salesforce's office every week, met people and asked for introductions until he reached the Service Cloud team. The public sources do not give the number of visits, contacts or months. Do not turn the anecdote into a universal cadence or a claim that stubbornness caused the outcome.

Copy the contact architecture instead. Map 20 people across engineering, product, partnerships, solutions, field sales and customer success. Mark who owns the workflow, who can test, who sees buyer demand, who controls platform risk and who can make the next introduction. A senior title is less useful than a role connected to one of those jobs.

Make each contact evidence-bearing. A practical message is:

We built a small proof for [workflow]. It lets [user] do [action] when [trigger], without [current cost]. Here is the test. Who owns this part of the product?

Follow up only when you can add something: a working endpoint, a failed test, a user observation, a security answer or a corrected hypothesis. Pass condition: a relevant owner tests, corrects or routes the proof. Stop condition: six evidence-bearing attempts produce no sponsor, learning or next contact. Change the host or wedge instead of increasing volume.

Step 4: make the proof falsifiable

The Salesforce meeting did not finish with a request for more slides. Cottereau says the team requested an API key the same day. A lead product engineer tested the integration by midnight and invited him back the following day. That account is founder-reported, but it gives a useful standard: the partner must be able to reproduce the result without the founder narrating.

Your proof kit should contain:

1. a sandbox or test account with a five-minute setup path;
2. three cases covering normal operation, boundary conditions and failure;
3. explicit reliability, latency, security and data-handling requirements;
4. the expected output and a visible failed state;
5. a log that both teams can inspect;
6. one owner and date for the next decision.

Pass condition: the host runs the test alone and can state where the capability fits in its product. Stop condition: the proof remains a founder-controlled demo, the success criteria move after every test, or the platform requires production customer data before it can evaluate basic feasibility.

Step 5: let the host carry an owned buyer problem

A useful host does not only introduce a name. Salesforce already had an executive relationship with HP and heard the printer-division problem. Cottereau reports that customers were returning 20-30% of printers, often because of a simple issue such as a paper jam. Salesforce brought SightCall into the conversation, and SightCall deployed visual support inside Service Cloud contact centres across several regions.

Treat every number in that account as a discovery claim until the buyer measures it. No public source independently audits HP's baseline, reduction or savings. Your joint buyer brief must therefore name the existing workflow, baseline method, economic owner, host responsibility, your bounded role, test population, success measure, procurement path and deployment boundary. The host's reputation cannot substitute for measurement.

Pass condition: the buyer owns the problem and baseline, while the host owns a real part of the proposed solution. Stop condition: you are renting the host's logo but still performing all discovery, justification and implementation alone.

Step 6: turn the deployment into a partner package

Cottereau says the company continued signing customers and partnerships after HP. The 2015 announcement confirms Salesforce, Tata Communications and Capgemini as partners and refers to multiple enterprise users. It does not provide partner-attributed pipeline, conversion, revenue share or retention. The safe lesson is a repeatability test, not a claimed flywheel.

Build the package before declaring a channel: one reusable connector, one proof script, one security answer set, one joint discovery brief, one implementation boundary, one enablement page and ten named next accounts. Record which elements survive the first deployment unchanged. If the second account needs the same trigger, workflow and proof, you have the beginning of a channel. If it needs a private product branch, you have learned from a customer but not built a repeatable motion.

Pass condition: the partner can name another account with the same costly workflow and can run the same first proof. Stop condition: the partner has no enablement owner, every introduction depends on the founder's personal presence, or the first customer's custom work cannot be bounded.

What failed, and what not to copy

First, technical possibility did not immediately produce a market. SightCall had early PoCs but no precise enterprise use case. The company needed a host and a live buyer problem to turn the platform into an operational outcome. A founder with a horizontal technology should not count PoCs as customer validation when each tests a different use case.

Second, the weekly office story can become founder mythology if the proof disappears. Repeated contact created access; it did not make the technology work. The robust API and independent partner test converted attention into trust. A weak product with a more aggressive cadence would not reproduce the mechanism.

Third, a later public-pricing experiment conflicted with SightCall's enterprise motion. Cottereau describes a Fortune 100 prospect asking for one licence after seeing the online price, while the sales team expected to build an organisation-wide business case. This is one anecdote, not a controlled channel test. Use it as a diagnostic: when value depends on integration, avoided cost and organisational rollout, a checkout page may shrink the buyer's frame rather than reduce friction.

Your seven-day implementation plan

Day	Action	Required output	Decision gate
1	List and score five hosts	One host above 8/10	Reject reach-only partners
2	Interview three users of the host workflow	Trigger, workaround and baseline method	Stop if no repeated expensive problem appears
3	Write the embedded-wedge memo	Trigger, input, action and outcome	Host owner can explain it in one sentence
4	Build the smallest reproducible proof	Sandbox and three tests	Host can test without founder narration
5	Map 20 partner contacts	Six role-specific first touches	Every touch carries evidence
6	Prepare joint discovery	Buyer brief with baseline and responsibilities	Host and buyer each own a decision
7	Run the test and review objections	Continue, change-host or stop memo	No automatic “keep trying” outcome

Lead Scorer implementation

Lead Scorer can reproduce the research, qualification and drafting discipline around this motion. It cannot manufacture partner trust, test your integration or approve a campaign. Use it as the execution surface around the founder's work, with a human gate before every expensive or external action.

Phase 1: define two ICPs, not one

Invoke the icp-offer-context skill to define the end buyer, disqualifiers, permitted proof and exact product boundary. Then add a separate host profile: which workflow it owns, how your product improves its offer, which integrations are reusable and what evidence counts as an internal sponsor. Store partner contacts and buyer accounts in separate lists. Mixing them creates a meaningless score because a platform product manager and a buyer operations leader perform different jobs.

Define the buyer ICP and a separate distribution-host ICP for [product]. Disqualify hosts that offer only audience reach, require one-off integration work, or cannot name a workflow owner. Preserve the claims we may prove; do not infer customer outcomes.

Pass: both profiles name role, active problem, evidence, disqualifiers and next action. Stop: “enterprise platform” or “strategic partner” is the most specific description available.

Phase 2: research signals before buying contact data

Use signal-research-dossier to require at least two dated sources for every host and buyer account. Useful host signals include a new marketplace category, integration roadmap, partner programme, customer request, product release or service gap. Buyer signals include an active migration, support-cost initiative, field-service change, executive mandate or hiring pattern connected to the workflow.

Run icp-scoring-rubric with five partner dimensions: workflow ownership, integration reuse, buyer trust, active demand and named sponsor evidence. Score each from zero to two and require at least seven out of ten, with no zero on workflow ownership or reuse. This gate prevents contact discovery from becoming the most expensive way to learn that a company is only adjacent.

Research each host using dated primary sources. Score workflow ownership, integration reuse, buyer trust, active demand and sponsor evidence. Keep only scores of 7/10 or more, and reject any host scoring zero on ownership or reuse. Show evidence and uncertainty for every point.

Approval: the founder reviews the evidence and accepts the shortlist. Only then may contact-discovery find verified details for the qualified partner contacts. Credit spend remains behind the normal confirmation gate.

Phase 3: draft around an artifact

Use ai-authored-campaign only after the embedded-wedge memo and proof kit exist. Each draft should reference one verified signal, offer one testable artifact and ask for the owner of a specific workflow. A message that asks for a generic partnership call has no falsifiable next step. Keep the first batch to six contacts across different roles so replies teach you where the problem lives.

Create drafts for the approved partner contacts. One personal message per person. Reference one dated signal, offer [proof artifact], and ask who owns [workflow]. Do not activate, send, or add unsupported claims. Leave every message for human review.

Pass: every draft remains accurate if the recipient forwards it to engineering or the end buyer. Stop: the message depends on praise, a vague synergy, urgency or an outcome not demonstrated by the proof.

Phase 4: turn objections into proof and content

After the founder reviews and activates the campaign manually, use reply-triage to classify responses as interested, timing, wrong person, objection or no. Route wrong-person replies back into the partner map. Group technical objections into proof-kit changes. Group repeated market questions into a source-backed Content Studio brief, then score people who visibly engage with the published evidence before drafting any follow-up.

The loop is reply → objection class → proof or content → new signal → rescoring. Human approval remains at shortlist acceptance, contact-credit spend, message review, campaign activation and any follow-up. Lead Scorer does not guarantee a first customer and should not erase the founder from the relationship the motion depends on.

Saveable checklist

• One host owns both buyer trust and the relevant workflow.
• The wedge names a trigger, input, action and measurable outcome.
• Partner contacts and buyer accounts live in separate lists.
• Every contact attempt adds evidence rather than only repeating the ask.
• The host can run the technical proof without founder narration.
• The buyer's baseline is measured; it is never copied from another case.
• The host and buyer each own a concrete part of the next decision.
• The first deployment can become a connector, proof script and enablement package.
• Contact discovery and sending remain behind explicit human approvals.
• Six unproductive evidence-bearing attempts trigger a change of host or wedge.

Sources and evidence limits

The early story comes from Thomas Cottereau's full interview on The SaaS Podcast, published in April 2024. It is a direct founder account, not an independent audit. The course therefore calls HP the first major customer, preserves the one-or-two-small-customer caveat, and treats the weekly visit frequency, API test, 20-30% return rate and savings as founder-reported.

SightCall's October 2015 announcement supports the $8.4 million round, Salesforce partnership and use by large printer manufacturers, but does not identify HP. Salesforce's marketplace and SightCall's activation guide support the later product integration. TechCrunch's 2021 report supports the $42 million Series B and reported scale.

Total funding figures conflict: the podcast says $54 million while TechCrunch reported $67 million in 2021. This article excludes the total. No public source provides HP's contract value, procurement timeline, realised savings, renewal, partner economics, early CAC, conversion rate, retention or the time from first Salesforce visit to signed order. Those missing numbers are not blanks to fill. They are limits on what a builder should claim and metrics the next experiment must collect.