Future of Threekit Support October 2026
01 — 10
The purpose

Before we decidewhat we support and how,let's focus onwhat is actually delivered.

To the customer, and to support.
Scope and ownership come after, not before.

02 — 10
First, let's take a step back

A standard customer journey at Threekit

GO-LIVE MANAGED SERVICESORIMPLEMENTATION PARTNER CUSTOMER SUCCESS IMPLEMENTATION ACCOUNT EXECUTIVES &SALES ENGINEERS SALES CYCLE LEADCONV MARKETING &BUSINESS DEV QUALIFICATION LIVE

At each stage, the customer's needs are refined and data is collected.

After months of upstream work, Support inherits what ships, almost always undocumented.

03 — 10
What we found building the AI tracker

Every AI project is built differently

Simplest

Hardcoded

3

No GoTo tenant, logic in code (RAG finders): Therma-Tru, TaylorMade, Sloan.

Middle

GoTo tenant + code

4

A tenant for data, the rest built by hand: Andersen, Certor, Lovesac, A-Dec.

Most composite

Full stack

5

Tenant + backend API + front end + email + external services: Aventa, Brizo, Waudena, Cintas, Takara.

36 AI projects (including demos) in the tracker, ~70 repos across threekit and threekit-labs.
No two built the same, and the data lives somewhere different each time: Porter, Cloudflare, or GCP Cloud Run; Postmark or not.

04 — 10
Cintas · delivered with no documentation

Nobody could tell us what had been delivered

Cintas architecture

We received no documentation, and no one could say exactly what had shipped. We only drew this diagram now, after go-live. It turned out to be four separate experiences on one shared backend, behind an admin portal that is just a page of links, some pointing to things the customer can't even access.

05 — 10
Cintas · what it generates at the customer

What happens when "delivered" is not defined

17
support cases in ~4 weeks since go-live
14
of 17 from one contact we never onboarded
7
are manual data-sync requests, not bugs
4
are access / environment confusion
Case themeCountWhat it tells us
Manual data / product sync7Run by one engineer, by hand, with no documented script, so Support can't do them
Access / environments4The customer doesn't know what they can access
Product bugs4One mobile-quiz bug logged twice
"How do I edit my content?"2The customer doesn't know what they received
06 — 10
Cintas · in the customer's words

The symptoms, told by the customer

Inconsistent delivery, no QA env

"...why our Workwear & FAS experiences were built with a dev environment, but our Hospitality experience was not. Also, is sharing screenshots locally going to be the only way to QA Hospitality moving forward."

The manual sync treadmill

"I am reaching out to request a sync for the Threekit Workwear experience. Let me know if you need any additional information."

Broken access, handover gaps

"...Roger's access in the admin portal is completely broken, and we need to make sure he gets full access back... We also have 4 partners to grant view-only access to the FAS Analytics Dashboard."

And, from the customer: the editing-capabilities question

"Our team realizes we need to be prepared for updated content and layouts as analytics become more prevalent with these quizzes. Across all three experiences, what do editing capabilities look like on my end? For example, can I edit the copy and layout of the Hospitality homepage with the access I have now? Can I change the imagery of the parent sections on the FAS results page? And the quiz questions, if we want them tweaked, do I have those capabilities with my current setup? If not, what does the process look like for edits that are not content related?"

07 — 10
The consequence for support

We cannot support what we cannot see or locate

  • No debugging, maintaining, or handing a product to the customer when it is undocumented and we don't know where its data and code live.
  • Access is not granted with the project. Cintas repo transfers have been requested for weeks, still pending.
  • Several AI projects live in threekit-labs, an org support cannot access at all.
  • And we cannot help a customer who doesn't understand their own tool and has no way to take ownership of it.
08 — 10
Takara · the next to deliver

We were told it would be simple

Takara architecture

We were told Takara was simple. The diagram says otherwise. This diagram allows us to do what we could not do with Cintas: discuss internally what should be supported by who, sit with the customer, walk the diagram, mark the blocks we own 100% (any issue there comes straight to us), and offer the ones they could run themselves, like the UI, if they have a web team.

09 — 10
The ask

Fix the foundation first

01 · Standard
A support-handover standard: architecture diagram + data inventory + access + runbook, for every project.
02 · Pilot
Apply it to Takara now, before go-live.
03 · Gate
Restore the definition of "delivered": customer sign-off and a support handover.
1 · Know what's deliveredand where data lives
2 · Standardize + documentwhat we can
3 · Define support vs customerwho runs what
4 · Then scope + ownershipper customer
10 — 10