The First 100 Customers Course #10: How Templafy Turned a 10-Person Pilot Into a Company-Wide Deal

TL;DR

Templafy’s first customer was an unnamed Big Four accounting firm. Co-founder Christian Lund says the deal began when the new company had two founders, two engineers, and no market-ready cloud product. The buyer proposed a 10-person pilot. Templafy answered with a conditional yes: define exactly what the pilot must prove, confirm the budget and timeline, and agree what company-wide rollout follows if the proof passes.

The mechanism is earned expertise → a specific point of view → a named mature buyer → a conditional pilot → binary proof → a wide rollout → expansion inside the account. The warning is just as important. Templafy did not cold-start this motion. It inherited years of enterprise access and document-automation experience from its predecessor business. Copy the decision system, not the logo or the mythology.

What you will build

You will build an enterprise first-customer system for a market in transition. The outputs are a transition thesis, a 20-account list, five two-source operator dossiers, a one-page point-of-view memo, a pilot qualification sheet, a binary proof scorecard, and a written post-proof decision. This is not a template for promising an enterprise feature set before you can deliver it. It is a way to discover whether earned insight can open a commercial conversation before a polished product exists.

Who this is for

Use this when a real platform, regulatory, workflow, or cost shift is forcing enterprise buyers to reconsider a known process; you have direct operating knowledge of that process; and a bounded proof can produce observable results without putting the customer at unacceptable risk. It fits a founder who can stay close to discovery and implementation.

Do not use it when your point of view is generic trend commentary, the buyer only needs a standard tool, or the proposed rollout exceeds your security and delivery capacity. It also fails when you need to persuade the customer that a change exists at all. Lund later learned this again with AI messaging: being directionally right but too far ahead cost Templafy sales conversations.

Case snapshot

Stage	Verified or reported fact	Evidence limit
Before the spinout	Years in on-premise document automation and existing enterprise relationships	The first-customer motion did not begin from zero access
2012–2014 transition	One co-founder spent about a year learning the cloud stack before the new business formed	The transcript gives a loose period; the formal company was founded in 2014
Starting team	Two founders and two engineers	Help from the predecessor organization was pulled into delivery later
Named market	Roughly 800 people thought mature enough for the conversation	Not a disclosed contacted list or funnel denominator
First customer	Unnamed Big Four accounting firm on a global deal	Founder-reported; identity, date, and contract value undisclosed
Pilot request	Start with 10 people	Pilot duration and final seat count are not public
Commercial gate	Proof criteria, budget, timeline, deal size, and rollout agreed before work	No public win rate or sales-cycle length
2015 external check	25 staff, approximately $2.5M first investment, Microsoft partnership	Independent report; later than the first deal
2026 interview	About 200 people and eight-figure revenue	Founder-reported and not attributed to one channel

The model: make the pilot a decision, not an experiment

Templafy entered during the enterprise shift from on-premise software to cloud services. Lund says large companies first wanted people who understood what that transition meant. That made domain knowledge commercially useful before the product was ready. The team did not ask the market to specify a feature list. It listened, formed a view, and led the buyer toward a product meant for the wider market rather than one company’s custom request.

The pilot then changed jobs. A normal pilot asks whether a small group likes a product. The Templafy pilot asked whether defined operational behavior worked. If it did, both parties had already described the next decision. This removed the comfortable ending where a successful test creates another committee, another trial, or no rollout at all.

The final move was to land wide and then go deep. Lund’s reasoning was that enterprise security and procurement work can be substantial whether deployment covers ten people or many more. A broad first rollout created an internal market of team-specific document use cases. This is not universal land-and-expand advice. It depends on product safety, buyer commitment, and the founder’s ability to support a wide implementation.

Step 1: prove that the transition is real

Write one sentence that links a forced change to an operational consequence. Avoid “AI is changing everything.” Use: Because [specific change], [named operator] can no longer rely on [current process], which creates [measurable cost or risk] within [time horizon].

Interview five operators and record four fields:

• What changed outside their control?
• Which current workflow breaks first?
• Who owns the consequence and budget?
• What would they need to observe before changing the workflow?

Pass condition: five operators name the same change, owner, and consequence without being taught your language. Stop condition: the thesis only becomes clear after a product demo or a long lesson about the trend.

Step 2: build a named-buyer map, not a giant lead list

Lund estimated roughly 800 people worldwide were mature enough for the early conversation. He used highly specific messaging, including LinkedIn, to create dialogue. The number is useful as a market-definition lesson, not as an outreach metric. There is no disclosed send volume, response rate, or proof that customer one came from LinkedIn.

Start with 20 accounts. For each, name the operational owner, executive sponsor, forced-change signal, current system, and one reason to disqualify it. Then build five dossiers with at least two dated sources. A company enters the working set only when the signal is current and the likely owner has authority over the affected workflow.

Output: five qualified accounts, not 20 decorated profiles. Pass condition: every keeper has a source-backed transition and buyer. Stop condition: the account is present only because its logo is attractive.

Step 3: sell a point of view that earns a working session

Templafy could sell thinking because the founders had spent years in document automation. Lund explicitly calls their existing enterprise access an unfair advantage. If you lack that depth, research must precede outreach. A fashionable opinion is not a substitute.

We see [forced change] making [current workflow] fail in [specific way]. Our view is that the first safe move is [bounded operating change], not [common alternative]. We are testing this with [buyer type]. Would a 30-minute working session on your current proof requirements be useful? No product demo required.

The ask is a working session, not a sale. Bring a one-page memo with evidence, limits, and three questions. Pass condition: the buyer corrects the model and volunteers a real internal constraint. Stop condition: you leave with praise but no owner, proof event, or next decision.

Step 4: answer a pilot request with “yes, if”

A small enterprise pilot feels like progress because the logo is real. It can also become unpaid discovery with no buying process. Templafy did not reject the buyer’s 10-person proposal. It required conditions that made the pilot a commercial decision.

Complete this gate before scheduling work:

Gate	Question	Required evidence
Change	What is moving from today to tomorrow?	Buyer-owned problem statement
Owner	Who owns the result and the decision?	Named operator and sponsor
Budget	Is there money for the post-proof purchase?	Real range or approved source
Timeline	When must a decision be made?	Dated decision meeting
Proof	What binary events show the workflow works?	Written scorecard
Rollout	What happens if every proof event passes?	Scope, process, and commercial next step

Say: Yes, if we agree what this proves and what you will decide when it passes. Walk away when the buyer wants only to see whether users like the tool. Preference can inform product work, but it does not justify an enterprise deployment.

Step 5: write binary proof criteria with the buyer

Templafy’s proof events were concrete: does the add-in appear, is the correct template available, can it accept required inputs, and is the populated information correct? These are stronger than “users are engaged” because each has an observable yes or no.

Use this scorecard for every proof event:

• Starting state: the exact workflow before the pilot.
• Action: what the user or system does.
• Expected result: one observable behavior.
• Evidence owner: who records the result.
• Failure response: fix, scope change, or failed criterion.
• Decision effect: what passing or failing changes.

Pass condition: buyer and founder can score the same event without interpretation. Stop condition: success depends on general satisfaction, future features, or a metric whose baseline was never recorded.

Step 6: choose the widest safe rollout, then expand by use case

Templafy pushed for company-wide value first, such as brand and legal control across documents, then added team-specific cases. This let one approved enterprise become an internal market. It also created serious delivery risk. Lund recalls pulling in every available person, customer frustration with delays, and a difficult implementation. He estimates the work made the product 70% better, but that figure is subjective and founder-reported.

Create a rollout ladder with three scopes: the smallest credible proof, the widest safe first deployment, and later team-specific cases. Each expansion needs its own owner, proof event, and commercial decision. Pass condition: security, support, and implementation can sustain the agreed scope. Stop condition: the logo forces you to promise a rollout your team cannot operate safely.

What failed: open POCs and a message too far ahead

The pilot discipline came from earlier mistakes. Lund says the team had run proofs without the necessary safeguards and learned that it could end up with endless POCs. That is failed execution: work began before the buying decision was defined.

The later AI reset exposes a different failure. Templafy rebuilt around a view that enterprise AI would need organizational control, while buyers were still asking how AI helped one user today. Lund says the message was 80% ahead when it needed to be about 15% ahead. Competitors with a simpler near-term story entered conversations Templafy lost. That is premature timing, not proof that the long-term product view was wrong.

Your seven-day implementation plan

1. Day 1: write the transition sentence and list every assumption beneath it.
2. Day 2: interview five operators; keep their language, owners, and objections.
3. Day 3: map 20 accounts and reject every logo without a dated transition signal.
4. Day 4: build five two-source dossiers and a one-page point-of-view memo.
5. Day 5: draft five working-session asks and review every factual claim.
6. Day 6: prepare the six-gate pilot sheet and a binary proof scorecard.
7. Day 7: review, send manually, and log which buyers accept the change, owner, and proof event.

The week passes with two working sessions where the buyer helps define proof and the next decision. It fails usefully when operators reject the transition thesis or cannot name an owner. Do not fix that by widening the audience or building more product.

Lead Scorer implementation

This motion fits Lead Scorer when public evidence can identify the transition, company, and likely workflow owner. The product can organize research, qualification, contact discovery, and reviewed campaign drafts. It cannot manufacture domain knowledge, approve security risk, run an enterprise proof, or activate outreach without human review.

1. Run $icp-offer-context. Store the forced change, narrow buyer, disqualifiers, proof event, evidence limits, and claims you may make.
2. Run $icp-scoring-rubric. An 8–10 requires a dated transition signal, the right scale, a likely owner, and a workflow that can be proved safely. Put 6–7 in watch and 1–5 in stop.
3. Use search_companies, then create_company, create_list, and add_companies_to_list for the 20-account map. Do not enrich the full list.
4. Run $signal-research-dossier for two dated sources per keeper. Separate working-session, pilot-qualified, watch, and stop lists.
5. Use submit_lead_score before paid operations. Run $contact-discovery and find_lead_contact_info only for approved 8+ operators after the credit estimate and human confirmation.
6. Run $cold-email-first-touch and $outreach-qa-audit. Use create_campaign, add_leads_to_campaign, and generate_campaign_drafts for drafts only. Review every message before any activation.

Copyable prompt: “Find 20 enterprise accounts affected by [forced change]. An 8+ requires a dated signal, a likely [workflow owner], evidence of [current process], and a bounded proof event. Return five two-source dossiers and separate working-session, pilot-qualified, watch, and stop lists. Score before enrichment. Draft only. Do not contact anyone or activate a campaign.”

Classify every reply with $reply-triage. Put repeated objections, failed proof assumptions, and timing language into Content Studio. Turn them into useful evidence, capture people who visibly engage with that material, rescore them, and return only qualified signals to reviewed outreach. The loop is transition evidence → qualified account → working session → proof criteria → objection library → useful content → new qualified signal.

Checklist

• One forced transition and one affected workflow.
• Five operator interviews before product-led outreach.
• Twenty accounts, five two-source dossiers, and explicit disqualifiers.
• A point of view grounded in earned knowledge, not trend commentary.
• A named owner, budget, timeline, proof, decision, and rollout.
• Binary proof events with recorded baselines.
• The widest safe rollout, not the widest imaginable promise.
• Score before enrichment and confirm every credit gate.
• Human review before contact or campaign activation.
• No invented first-customer identity, contract value, channel, or conversion rate.

Sources and limits

The first-customer sequence, roughly 800-person market estimate, pilot rules, wide-rollout logic, and later messaging failure come from Christian Lund’s 2026 interview on The SaaS Podcast. SaaS Club also published separate notes on selling a point of view before a product and the cost of messaging too far ahead. These are all derived from the same founder interview, not independent verification.

A 2015 FinSMEs report independently supports the 2014 SkabelonDesign spinout, first funding of approximately $2.5 million, and Microsoft partnership. Templafy’s 2020 company announcement records a $25 million round, nearly $70 million total external capital, and more than 2 million licenses sold. VentureBeat independently reported the 2021 $60 million round and the company’s reported customer-base growth.

The sources do not disclose the first customer’s identity, contract value, acquisition channel, pilot duration, final seat count, CAC, sales cycle, win rate, retention, or expansion revenue. They do not show that this motion produced the first 100 customers. The honest lesson is narrower and more useful: a pilot becomes a distribution asset only when it is attached to a decision.