The platform is ready. Now we need to tell the right story to the right people.
This proposal outlines how TGL introduces the new platform — internally to the team, and externally to clients and prospects. The two rollouts have different audiences, different goals, and different timing. This document covers both.
Two audiencesFive phasesInternal firstPending CEO approval
What we're launching
Platform, not product. Infrastructure, not feature.
Before we can talk about how to launch it, the team needs to agree on what we're actually launching and what that means for how we talk about it.
The single most important framing decision: The platform is TGL's "built differently" story — not the product we sell. Clients don't buy the Platform; they buy Products. The launch is not a product announcement. It's a capability unlock that makes every Product better and makes it possible to build more, faster. The external message leads with what that means for the dispatcher, the CSR, the AP specialist — not with infrastructure.
What the platform is
The infrastructure layer
Module frameworks + orchestration layer. The engineering foundation that every Product is built on. Replaces piecemeal tooling with a stable, scalable architecture.
Internal: This is a major milestone — it changes how we build. External: Reference it as depth and credibility, not as the thing we're selling.
What clients experience
Better Products. More Products.
Clients benefit through the Products deployed on top of the platform. Platform improvements cascade automatically to every Product built on it.
The message: The tools your team uses are getting better — and there are more of them now. That's the platform launch, from where the client stands.
What this changes
TGL's capacity to build
New Products can be built from existing infrastructure. When a Capability improves, every Product using it improves automatically. The catalog grows faster. Quality floors stay high.
Internally: This is the "why we built it this way" story made real.
Two audiences, two rollouts
Internal first. External when we're ready.
The team needs to understand and own the platform story before any of it goes to clients. These two tracks run sequentially, not simultaneously.
Goal: Every team member understands what the platform is, what the five core concepts mean, and how to talk about it accurately — internally and to clients
Tone: This is a milestone. Build pride and clarity. Make it feel real.
Risk to manage: Overcomplicating the internal story or letting confusion about terminology (Module vs. Product vs. Capability) leak into client conversations
🌐
External audience — clients & prospects
Who: Current clients (warm, invested), prospects (skeptical, evaluating), and the broader trades market (not yet in relationship)
Goal: Clients understand that TGL's capability just grew — and that the tools their teams use are better and more numerous as a result
Tone: Confident and specific. Lead with the person and the outcome, not the infrastructure. This is the "built differently" story made visible.
Risk to manage: Over-engineering the message with Platform/Module/Capability terminology that means nothing to a dispatcher
Five-phase summary
The sequence that makes this land.
Phase
Name
Timing
Audience
Key output
1
CEO approval and messaging lock
This week
Jacob + you
Approved messaging framework, green light to proceed
2
Internal team education
Week 2
Full TGL team
Every team member can explain the platform accurately
3
Current client announcement
Week 3–4
Existing clients
Clients feel the benefit, not the architecture
4
External market launch
Week 4–6
Prospects + market
Website, content, and sales materials updated
5
Ongoing: catalog expansion
Continuous
All
New Products shipped on the platform, announced by outcome
This document is a proposal. Nothing here is in motion until Phase 1 — Jacob's review and approval — is complete. The messaging framework tab is the most important thing to review first. Everything else follows from it.
Messaging framework
What we say. To whom. In what order.
The platform launch has two different stories to tell. The internal story is about what we built and why it matters to how we work. The external story is about what the client's Tuesday looks like differently. These stories draw from the same truth — they just lead with different things.
Core concepts — internal vs. external framing
The five terms. How to use each one.
These are the canonical TGL concepts, in dependency order from infrastructure to commercial surface. The internal framing and external framing are different — this table is the reference.
Concept
Internal framing
External framing
Never say
Platform
The engineering layer we build on. Module frameworks + orchestration. Platform decisions are architecture decisions — they don't change because a customer wants something different.
TGL's "built differently" story. Why we can build more, faster, with consistent quality. Reference when explaining differentiation — don't lead with it in product marketing.
"Our platform does X for your dispatcher" — the Platform enables Products; Products do X
Module
A framework within the Platform for a specific type of capability (Tools, Pages, Email, Agents, Telecom, etc.). The mold Capabilities are built from. Platform engineers own Modules.
Module names can appear on the site in passing without heavy explanation. They show depth. They don't get top billing — Products and people do.
Listing Modules as client features. "We added a new Module" is not a client announcement on its own.
Capability
A specific, named, deployable implementation within a Module. The inventory product engineers select from. "What Capabilities do we have for this?" is a product engineer's question.
Capabilities are visible and browsable on the site — they show depth. Discovery happens at the Capability level; deployment happens at the Product level.
Calling a Capability a Product. A Capability has no defined beneficiary — it's a building block, not an offering.
Product
The commercial and operational unit. One beneficiary, one entity, one process. Product engineers own Products. Products are what clients deploy using Rivets. Always capitalized.
What clients buy, deploy, and talk about. A named outcome for a specific person. "When a technician completes a job, this Product routes the follow-up…" Lead with the person and the change.
"Features," "tools," "solutions," or "modules" as synonyms for Product. The word is Product.
Rivet
The pricing and consumption layer. Product engineers set the Rivet cost per run. Plans are sized by estimating entity volume and building in 30% headroom.
The currency of the subscription. Clients hold and spend them across the catalog. Explain once per surface, then use the word with confidence. Like in-game currency — owner buys the plan, team decides where it goes.
"Credits," "tokens," or "points." It's Rivets. Don't describe them as a task counter — they're a currency.
The external headline
How to open the external story.
What the platform launch means to a client, in one sentence: The tools your team runs on just got better — and there are more of them now. That's the story. Everything else is how we prove it.
Lead with this — external
The outcome, for the specific person
"Your dispatcher gets [X] minutes back every time [Y] happens — because the platform running underneath it handles the routing, the follow-up, and the logging automatically."
The platform is why it works. The platform is not the headline. The dispatcher and the minutes are the headline.
Support with this — external
The "built differently" credibility layer
"We hardcode patterns, not workflows. Every Product TGL builds runs on the same infrastructure — which means when that infrastructure improves, every product gets better automatically. You don't ask for an update. It just happens."
This is depth. It comes second, not first.
Voice guardrails
What to say. What to never say.
✓ Use these
"The platform" (not "our platform solution")
"Products" (not features, tools, or solutions)
"Rivets" — explain once, then use with confidence
Named roles: dispatcher, CSR, AP specialist
Specific outcomes: "45 minutes back," "three fewer systems"
"Built differently" as a credibility claim, backed immediately
"The catalog" when referring to the library of Products
✗ Avoid these
"Revolutionary new platform" — never
"Unified platform," "all-in-one," "end-to-end" — banned
"Streamline," "transform," "empower," "unlock" — banned
"Users" — name the actual role
Leading with Module/Capability terminology in client copy
"Exciting new features" — lead with the person
Making the CEO or TGL the hero — the dispatcher is the hero
Announcement copy examples
On vs. off. The same story, told two ways.
Off (what not to write):
"We're thrilled to announce the launch of The Graphite Lab's revolutionary new platform — a fully unified, end-to-end solution that transforms how trades businesses operate. Our cutting-edge technology empowers your entire team to streamline workflows and unlock new levels of efficiency."
On (what to write instead):
"We've been building something. Every Product TGL ships — the one your dispatcher uses on Monday morning, the one your AP specialist runs at end of month — runs on new infrastructure now. What that means for your team: the Products get better automatically, and there are more of them coming. We don't ask you to re-onboard. You just notice things working better."
Internal rollout · TGL team
The team needs to own this story before it goes anywhere else.
The platform launch starts internally. Every person on the TGL team — engineering, PS, ops, leadership — needs to understand what was built, what the five core concepts mean, and how to talk about it accurately when clients ask. This section covers exactly how that happens.
Phase 2Week 2Full TGL team
What the team needs to walk away with
Three things. Not twenty.
1. Clarity on what we built
What is the platform, exactly?
Module frameworks + orchestration layer. Platform engineers build and maintain it. It's the infrastructure that every Product runs on. Not what we sell — what we build on top of. Every team member should be able to say this in one sentence without looking it up.
2. Confidence with the concepts
The five terms, in order
Platform → Module → Capability → Product → Rivet. Every team member should know the dependency order, what each term means, and — critically — what it does NOT mean. The goal isn't deep technical literacy. It's confident accurate usage when a client asks.
3. A consistent answer to "what changed?"
When a client asks, everyone says the same thing
The whole team needs a single consistent answer: "The infrastructure underlying every Product just got rebuilt from the ground up. Products improve automatically. More Products are coming. Your team doesn't need to do anything differently." One answer. No variation.
Internal rollout phases
The sequence — click each phase to expand.
CEO briefing
Leadership alignment
Full team session
Reference materials
1
Phase 1 · This week
CEO briefing and messaging lock
Jacob reviews and approves the messaging framework before anything goes to the team
InternalGate
›
Inputs needed from Jacob
Gate: Nothing in Phase 2 or beyond starts until this phase is complete. The messaging framework is the foundation — if it's off, everything downstream needs to be rebuilt.
2
Phase 2 · Week 2 · Before full team session
Leadership alignment
Leads understand the story and are ready to reinforce it with their teams
Internal
›
Actions
Goal: Leads walk out of this session ready to field questions from their teams. They don't need deep technical literacy — they need a consistent, accurate, confident answer to "what is the platform and what does it mean for my work?"
3
Phase 3 · Week 2 · All hands or dedicated session
Full team launch session
The whole team hears the story at once — live, from the CEO
Internal
›
Suggested session agenda — 45 min
After the session
4
Phase 4 · Week 2–3 · Ongoing reference
Reference materials — wiki and TGL Client Portal
The team has what they need to answer any question accurately and consistently
Internal
›
Deliverables to build
External rollout · clients & market
Lead with the dispatcher's Tuesday, not the architecture.
The external rollout reaches two groups with different levels of relationship to TGL: current clients who are already engaged, and prospects and the broader market who are evaluating. Both groups need to understand what changed — through the lens of the people whose work it affects, not through the infrastructure underneath.
Phases 3–5Weeks 3–6After internal is complete
Hard dependency: The external rollout does not start until the internal rollout is complete. Client-facing team members need to understand the platform story before they're talking to clients about it. Nothing external goes out while the team is still being briefed.
Audience breakdown
Three external groups. Three different angles.
Current clients
Warm. Invested. Deserve to hear it first.
They're already running TGL Products. The platform launch means the tools they're using are better and more are coming. Lead with continuity and benefit — "nothing changes in how you work with us; everything gets better." Personal outreach from their account team before any broad announcement.
Prospects
Evaluating. Skeptical. Need the "built differently" story.
They've been over-promised. The platform launch gives TGL a credibility asset: a real infrastructure reason for why TGL can build more, faster, with floors that hold. Don't lead with features — lead with the methodology. The Tenfold Floor, the one-role/one-entity rule, the Rivet structure. Show the thinking.
Broader market
Not yet in relationship. Trades owners and teams.
These are the dispatcher, the CSR, the AP specialist who haven't heard of TGL yet. The platform launch is content fuel — specific Product announcements, role-specific outcome stories, the catalog browseability. They don't need to understand the platform. They need to find a Product that changes their Monday.
External rollout phases
Client first. Market second.
1
External phase 1 · Week 3–4
Current client announcement
Clients hear it from their account team before they hear it anywhere else
ExternalClients only
›
Approach
The message frame: "The infrastructure running under every Product your team uses just got rebuilt. That means the Products get better automatically, and there are more of them available now. Nothing changes in how you work with us — everything gets better. We wanted you to hear it from us first."
2
External phase 2 · Week 4–5
Website and sales materials update
The platform story is visible, accurate, and findable — without leading the marketing surface
ExternalMarket-wide
›
Website updates
Sales materials
3
External phase 3 · Week 5–6
Content and market announcement
The platform story reaches the market — through outcome stories, not architecture announcements
ExternalMarket-wide
›
Content to create
Content rule: Every piece of external content about the platform launch passes the same test: does it name a specific person whose work changes, and does it describe what changes — not what the platform shows or contains? If the answer to either is no, rewrite it before it ships.
4
External phase 4 · Ongoing from week 6
Catalog expansion — announce by outcome
Every new Product is its own announcement. The platform is why it's possible. The dispatcher is why it matters.
ExternalOngoing
›
The ongoing rhythm
The principle: Don't announce the platform again. Announce the Products. Each Product is proof that the platform works. Let the catalog be the ongoing story — one specific outcome at a time.
Open questions & gaps
What this proposal can't answer without Jacob.
This proposal is built from the brand assets provided. Several decisions that will materially affect the rollout still need input from Jacob. These are listed below in priority order.
Decisions needed before rollout starts
Blockers first.
⬜
Which Products ship on day one? The external launch is most powerful when it's paired with new or improved Products clients can immediately deploy. What's in the queue and ready to announce? This drives the content calendar for the external rollout.
⬜
Is there a client-facing name for the platform? The brand materials use "The Platform" internally. Does Jacob want to give the platform a proper name for external use (like the client portal has a name), or does it stay referenced generically as "TGL's platform"? This affects website copy and the external announcement.
⬜
What replaces the current client tooling? The brief says the platform "replaces the tools our clients use today." What are those tools, and is the transition from old to new a separate communication workstream? If clients are moving off existing tools onto the new platform-backed Products, that transition needs its own communication plan — separate from the launch announcement.
⬜
What is the internal team session format? All-hands or a dedicated platform launch session? If it's added to an existing all-hands, how much time does it get? The session outline above is built for 45 minutes. If the time window is different, the agenda needs to be adjusted.
⬜
Are there any existing clients with transition anxiety to manage? If some current clients are on tooling being replaced, they may need a more hands-on communication and transition plan before the broad announcement. The PS team should identify these accounts before anything external goes out.
Lower priority — good to have before external launch
These can be answered in parallel.
○
Does TGL have an approved list of current Modules? The brand materials reference "Tools, Pages, Email, Agents, Telecom" and "eleven frameworks." The Capabilities catalog page and the website's "how we build" section need the canonical current list. This should come from Jacob or the platform engineering lead.
○
Is there a client story or testimonial ready to use? The voice guide is explicit: lead with a specific person, a specific moment, a specific change. If there's a client who can speak to what changed after a TGL Product was deployed — ideally one built on the new platform — that story is the single most powerful piece of launch content available.
○
What is the timeline for the founder piece / long-form post? The external rollout calls for a founder-voice piece as one of the first content assets. This requires Jacob's time and voice directly — or a close collaboration on a draft. Setting a target date and format (LinkedIn article, blog post, email) is needed before external phase 3 can be planned in detail.
○
Who owns external content sign-off? Per the TGL communication pathway map — all external communications carrying risk require internal sign-off. Platform launch content is brand-defining. Who reviews and approves each piece before it ships externally? This should be defined before content production starts.
Recommended first step: Jacob reviews this proposal and answers the five blocker questions above. Once those are answered, the messaging framework can be finalized, the internal session can be scheduled, and the external timeline can be locked. The proposal is designed to be ready to execute as soon as those answers exist.