Historic Onboarding Suggestion
Current AI-related tooling & User’s Grouping
The Day-One Experience: End to End
Let me walk through what onboarding actually looks like when we connect the three-layer model, the content gathering skill, and the programmatic pipeline.
Before the Clock Starts
This isn’t self-service SaaS. The user has met someone face-to-face. They’ve agreed to proceed. We provision their tenant. The coordinator receives their login.
The Critical UX Moment: “Connect” vs. “Upload”
Every competitor starts onboarding with some version of “upload your past proposals.” Loopio’s primary onboarding activity is “Content Library setup” — migrating Q&A content and past proposals. This is why it takes 2-4 weeks.
The Enterprise Search model inverts this. Instead of “bring your documents to us,” the first action is “tell us where your documents already live.”
Practically, this means connecting MCP sources:
- “Our past bids are on SharePoint” → connect SharePoint
- “We use Google Drive” → connect Google Drive
- “Most things are in email” → connect email
- “Here are some files on my laptop” → drag-and-drop upload (the fallback)
Connecting a source is one action. Uploading documents is one action per document. For a company with 50 past bids scattered across SharePoint folders, that difference is the difference between a minute and an afternoon.
But here’s the realistic nuance. Not every UK SMB has modern cloud storage. Some have documents on a shared network drive that’s not cloud-connected. Some have everything on individual laptops. Some have a mix. The onboarding must handle both paths gracefully — “connect your tools” for companies with cloud infrastructure, “upload your documents” for those without — and most will use a combination.
The platform detects which sources are connected and adapts its guidance accordingly. No judgement, no friction either way. Same pipeline either way once documents enter.
Hour 0-1: Setup and Source Connection
- Coordinator logs in
- Company details auto-populated from Companies House API
- Company name, registration, directors, SIC codes
- AI uses SIC codes to infer sector context (public sector, construction, IT, healthcare) — informs later classification
- Coordinator connects available sources and/or uploads documents
- Content gathering skill begins discovery in background
The Companies House data is programmatic — API call, structured response, auto-populate. No AI needed. But the SIC codes and director information are useful context for the agentic layer later — the AI knows it’s looking at an IT consultancy, not a construction firm, which changes how it classifies content.
Hour 1-2: The Content Gathering Skill Runs
This is where the three layers work in concert. The skill operates in “onboarding mode” — broad discovery, high volume.
Step 1: Discovery (skill via MCP connectors)
The skill searches connected sources using the Enterprise Search patterns — source-specific query translation, parallel execution across all connected sources:
- “Find documents that look like past proposals, bid responses, or tender submissions”
- “Find certifications, accreditations, and policy documents”
- “Find case studies, capability statements, and marketing materials”
For uploaded documents, discovery is trivial — they’re already in the queue.
Step 2: Extraction (programmatic pipeline)
Documents flow through the FastAPI parsing service:
50 documents discovered ↓ [Parallel programmatic extraction]
- 30 PDFs → PyMuPDF4LLM + PDFPlumber
- 12 DOCXs → python-docx
- 5 XLSX → openpyxl
- 3 emails with attachments → extract-msg ↓ Extracted text with structural hints Raw documents → filesystem/S3 (Layer 2) ↓ Ready for interpretation in ~60 seconds
Step 3: Interpretation (agentic — the expensive, valuable part)
The skill’s supervisor assesses the volume — 50 documents producing perhaps 200 pages of extracted text — and determines how many interpretation agents to deploy (same scoping pattern as Pattern 3’s content review skill).
Each agent works through extracted content with hints:
- “This table on page 14 is hinted as possible_qa_structure — confirmed: 15 Q&A pairs extracted”
- “This document appears to be a case study about NHS digital transformation — proposed lifecycle type: capability, proposed category: healthcare/case-study”
- “Found text matching ‘valid until March 2027’ in what appears to be an ISO 14001 certificate — proposed lifecycle type: date-bound, expiry: 2027-03-15”
- “Pages 3-8 of this document contain capability descriptions that overlap with 3 entries already proposed from another document — flagging as potential duplication”
Step 4: Proposal generation
The skill consolidates interpretation into a structured batch of proposed content entries. Each proposal includes:
- The content itself (text)
- Proposed lifecycle type
- Proposed category/tags
- Provenance (which document, which page/section)
- Duplication flags (overlaps with other proposals)
- An info-level annotation: “Imported, not yet used in a bid” (Pattern 3)
Hour 2-3: Coordinator Review
This is the “confirm” step of “parse, propose, confirm.” The coordinator sees the batch — not 50 documents, but perhaps 80-120 proposed content entries grouped by category.
The review is designed for speed:
- High-confidence proposals (Q&A pairs from clearly structured past bids) — bulk accept with one action
- Medium-confidence proposals (case studies, capability descriptions) — quick review, accept or edit
- Low-confidence or duplicated — the coordinator resolves: “These two entries cover the same ground — which do you want to keep?”
- Missed content — the coordinator can flag: “You didn’t find our data protection policy — it’s in this folder” → skill runs again on that specific location
The critical point: the coordinator is reviewing proposed content entries, not reading raw documents. The heavy lifting is done. They’re making yes/no/edit decisions, not doing analytical work.
Hour 3-4: First Bid
Here’s where I want to challenge a hidden assumption. The Session 03 research proposed the first bid at hour 2-4, after documents have processed. But Pattern 1’s Decide phase doesn’t require a complete content library. It requires tender documents — which are separate from the content library entirely.
The coordinator can drop tender documents into the platform while the content library is still being reviewed. The Bid Brief is generated from the tender documents themselves. The familiarity signal and gap headline simply reflect the current state of the library:
- If the library has 80 approved entries: “Strong coverage for ~70% of requirements”
- If the library has 10 approved entries: “Limited library content — coverage assessment will improve as your library grows”
- If the library is empty: “No past content available yet. All questions will need fresh responses”
The bid still works. The AI just operates with more “No Content” and “Needs SME” postures. And crucially — the act of completing that first bid generates content for the library. Every answer the coordinator writes or approves during the Respond phase flows back at Close via Pattern 3’s batch review.
So the content library bootstraps through use. The onboarding skill gives it a head start, but it doesn’t need to be complete before value is delivered.
Days 2-7: Background Enrichment
The content gathering skill continues in the background:
- Processing any remaining documents from connected sources
- The coordinator reviews proposed entries in small batches (not a dedicated session — notifications like “12 new entries proposed from your SharePoint documents”)
- The skill learns from the coordinator’s review patterns — which proposals were accepted, rejected, edited — improving future proposals
The Ongoing Mode
After onboarding, the same skill shifts from “broad discovery” to “change detection”:
- Monitors connected sources for new or modified documents
- When the marketing team uploads a new case study to SharePoint, the skill detects it: “New document in Marketing/Case Studies. Proposed content entry: [preview]. Approve?”
- When a certificate is renewed and the new PDF appears in the Compliance folder, the skill proposes updating the date-bound entry with the new expiry date
- Proactive but never automatic — every proposed change goes through the coordinator
This is the event-driven moment you raised at the start — and it’s the same skill, same pipeline, just running in monitoring mode rather than onboarding mode.
What This Means for the Under-4-Hours Vision
The Session 03 research framed the day-one experience as a linear sequence: setup → process → review → first bid. The model we’ve now established is more concurrent:
Hour 0-1: Setup + connect sources + skill starts discovering Hour 1-2: Skill processes in background + coordinator tours product + coordinator can start reviewing early proposals Hour 2-3: Bulk of content review + tender documents can arrive Hour 3-4: First bid begins (Decide phase) even if library is partial
The bottleneck shifts from “processing documents” (which is now fast — programmatic extraction in seconds, agentic interpretation in minutes) to “coordinator reviewing proposed entries.” And that bottleneck is under their control — they can approve quickly or take their time. The platform delivers value either way.