For Business Process Outsourcing (BPO) knowledge managers and content operations leads

FrontLine Knowledge — one knowledge base across every client, audience-scoped.

Tenant procedures and client-specific references share one index. Visibility resolves at query time. Knowledge-Centered Service (KCS) lifecycle, full-text search with zero-result analytics, ownership and staleness alerts, compliance review gating, decision-tree flows, and an audience-filtered client portal.

app.frontlinehq.io/knowledge

Knowledge

Author, review, and publish articles for your tenant, clients, or LOBs.

Filter by title, summary, category…
All states
TitleCategoryStateUpdated

Standard Greeting Protocol — Inbound Calls

Customer Service

Published

May 20

PCI-DSS Cardholder Verification — v2

Compliance & Regulatory

Approved

May 19

Escalation Matrix — When to Transfer

Customer Service

Published

May 18

Handling PII During Verification

Compliance

Stale

May 5

RetailCo — Product Catalog Quick Reference

Account-Specific

Published

May 14

PIPEDA Verification Script — Updated Draft

Process & Policy

Draft

May 20

Knowledge Managers · Content Operations · Enablement

What's hard about knowledge management at a multi-client BPO

Generic knowledge base (KB) tools assume one company, one workforce, one playbook. The BPO model breaks each assumption on day one.

Risk: cross-client leak

Cross-client confidentiality depends on application-layer filtering

App-layer permission checks gate every request. New LOBs, role bindings, and search refactors widen the leak surface. Every client MSA assumes the filter holds.

Decay window: 90–180 days

Articles go stale when authors move on

The agent who wrote the chargeback procedure changes teams. Six months later the article is wrong. Staleness only surfaces in a manual audit.

Zero-result searches are repeat handle-time

Agents search for an article that exists under a different title. They page the supervisor; the same call gets a different answer each time. Generic KBs treat zero-result queries as log noise.

Compliance review runs on email and Word docs

Regulated procedures get reviewed in attachment chains. The KM lead copies the approved version into the KB by hand. Months later, nobody can show which version agents saw on a given date.

Bilingual operations

Authoring in two languages without losing the link

EN and FR share a procedure but split into separate URLs and version chains. EN gains revisions; FR falls behind. The translation goes wrong without a signal.

Decision logic lives in cheat-sheets and supervisor heads

Refund eligibility, PCI verification, escalation thresholds — these are decisions, not documents. Ordered lists get skimmed; flowchart images go stale. The logic ends up in supervisor heads instead of a system.

What FrontLine does

What FrontLine does for your knowledge program

Seven surfaces engineered for multi-client BPO knowledge work.

Feature 01

Audience scope enforced at the database

Every article carries audience records: tenant, client account, or specific LOB. The visibility check composes into the same query as list, search, and detail endpoints.

  • Three-level scope model. Tenant audiences serve everyone. Client audiences match the user's account bindings. LOB audiences match the bound LOB. One article can carry multiple scopes.
  • EXISTS subquery on every endpoint. The scope check runs as an EXISTS subquery against knowledge_article_audiences. List, search, detail, and related-articles all share the same predicate.
  • Client portal reads the same table. Internal authoring and the client portal read from knowledge_articles. The portal endpoint applies stricter audience filtering.
  • Role-based admin override. tenant_admin, hr_admin, and operations_manager bypass audience scope for tenant-wide review. The role check is explicit and audited.

Audience scope

Caller

Agent · RetailCo / Card Services

Tenant
Always visible
Client
Matches RetailCo binding
LOB
Matches Card Services

Visible articles

47 of 312 in tenant

Feature 02

Full KCS lifecycle with ownership and staleness alerts

Seven-state machine on every article: draft, captured, structured, approved, published, stale, archived. Ownership transfers are first-class. The nightly sweep flags expired articles and notifies the owner; pass 2 escalates to the reviewer.

  • Seven-state machine. Each transition emits an audit event with from_state and to_state. The list view filters by state; every row carries a state badge.
  • Owner and reviewer accountability. Every article carries owner_employee_id and reviewer_employee_id. The two-pass staleness sweep notifies the owner first, then the reviewer 30 days later if no action.
  • Compliance review gate. Compliance & Regulatory articles route through the assigned reviewer's queue. The article holds in pending_approval until approved. Editing after approval resets the chain.
  • Versioned edit history. Each edit writes a new knowledge_article_versions row. Reverts create a new version pointing at the prior content.

Knowledge-Centered Service lifecycle

Each transition emits an audit event

DraftCapturedStructuredApprovedPublished· CurrentStaleArchived

Owner edits → version, sweep flags expired, reviewer signs

Feature 03

Full-text search with zero-result analytics

Postgres tsvector indexes title, summary, body, and tags. Every zero-result search is logged, grouped, and normalized. Quality index per article surfaces top and bottom performers on the editor dashboard.

  • Indexed full-text search. tsvector across title, summary, body, and tags. Audience scope and category filters compose into the same query.
  • Zero-result query log. Captured with caller_kind, query_text, and timestamp. Grouped and normalized for the editor view; twelve searches for the same query show as one row with twelve hits.
  • Quality index per article. Nightly rollup computes quality_index from views, unique-agent reach, and resolution usage. Editors sort by quality, views, or unique-agents-30d.
  • Related articles. Content similarity (term frequency–inverse document frequency) surfaces on each article detail page. Editor pins override the algorithmic match.
app.frontlinehq.io/knowledge/analytics

Editor analytics

Top performers

Quality · Views

Standard Greeting Protocol — Inbound

0.92246

Escalation Matrix — When to Transfer

0.88182

After-Call Work — Wrap-up Standard

0.81151

Zero-result queries

Hits

chargeback timeline

9×

return without receipt

7×

language line French Quebec

5×

Feature 04

Bilingual platform UI today; EN ↔ FR article pairing on the roadmap

Every UI surface ships fully bilingual (EN ↔ FR) and resolves to the user's locale. Article bodies can be authored in either language. The sibling-row schema that links an EN article to its FR translation and stale-flags one when the other changes is on the Atlas roadmap — not shipped today.

  • Platform UI is bilingual today. Every surface — author, editor, agent reader, client portal — renders in EN or FR based on the user's preferred locale. Quebec users see the platform in French from day one.
  • Articles can be authored in either language. An English procedure and a French procedure can both exist in the KB. They aren't linked structurally yet, so editors track translation pairings outside the platform until the sibling-row schema ships.
  • On the roadmap — sibling-row schema. A future migration adds locale, translation_group_id, and translation_stale_at to knowledge_articles. Source edits will set translation_stale_at on every other-locale sibling. Track status on the Atlas: spec 32 bilingual_content feature.

Article editor · language siblings

Edit article

EnglishFrench

Standard Greeting Protocol — Inbound

Required opening for every inbound interaction. Covers brand mention, agent identification, recording disclosure.

Translations

FrançaisPublishedUpdated 2 days ago

Protocole de salutation standard — Entrée

Feature 05

Knowledge Flows — decision trees with agent-facing execution

A visual canvas builds the node and edge graph. The agent runtime walks one question at a time. Every session is captured for quality assurance (QA) review and coaching linkage.

  • Six node types. prompt, branch, input, action, compliance_gate, terminal. The graph validates terminal coverage before publish.
  • Agent runtime with session capture. Agent opens /knowledge/flows/[id]/run, answers one question at a time, reaches a terminal. Each transition is audited; abandons are recorded.
  • Compliance gates inline. Required acknowledgement checkbox plus label before continuing. The acknowledgement is audited per session.
  • Article parity. Flows share categorization, audience scope, and version history with articles. Same lifecycle, same editor surfaces.

Decision tree · agent runtime

Session #2841 · refund_eligibility

Abandon

branch

Has the customer received the product?

Yes — proceed to verification

No — escalate to ops

Next: compliance gate · PCI verification

Feature 06

Client portal reader for self-serve knowledge

Published articles surface in the client portal via the EXISTS audience subquery. Four filters compose into one query: search, client picker, chained LOB picker, category picker.

  • Audience-filtered list. Portal endpoint runs the same audience subquery as internal. Stricter scope rules apply.
  • Four filter dimensions. Free-text search, client account picker, chained LOB picker, category picker. All four compose into one round-trip query.
  • Drafts hidden from the portal. Only published and stale articles return. Drafts and archived states never reach the portal.
portal.frontlinehq.io/retailco/knowledge

Client portal · knowledge

Search articles, summaries, categories…

RetailCo
Card Services
All categories

47 articles

Card return policy — RetailCo

Process & Policy · RetailCo

2d ago

Holiday return window — extended

Customer Service · RetailCo

1w ago

Chargeback escalation path

Compliance & Regulatory · RetailCo

2w ago
EN content shown · FR pending publish

Feature 07

Every read, edit, and publish in the unified audit log

Every privileged operation emits an immutable audit_events row. Knowledge events land in the same table as every other module.

  • Per-action audit. knowledge.article.publish, archive, approve, update (with field-level diff). Each row is immutable.
  • View tracking. knowledge_article_views records actor_user_id, caller_kind, and viewed_at on every read.
  • Version-of-read. Reads capture the version the agent saw. Auditors retrieve the exact content from an incident timestamp.
  • Unified viewer. Filter the audit log by actor, action, resource, and date range. One viewer covers every action across modules.

audit_events · knowledge module

Live stream

ActorActionTargetTime
Aisha D.article.publishStandard Greeting08:42
Hannah C.article.approvePCI Verification08:14
Sweeparticle.stale_flagHandling PII03:00
Aisha D.translation.createdGreeting · FR siblingYesterday
Filter by actor, action, resource, date
Cross-team feature · shared with Clients

Internal authoring and the client portal read the same table

Knowledge sits at the seam between agent operations and client self-serve. Both surfaces read knowledge_articles. The portal endpoint applies a stricter audience filter so client users see only the rows scoped to their account and LOBs. One source of truth. Two surfaces. No export and no second store.

  • Same EXISTS subquery on both ends. Internal list, search, and detail endpoints share the audience predicate with the portal endpoint. The portal adds stricter scope rules; the predicate shape is the same.
  • Client portal filter set. Search across title, summary, and category. Client account picker. Chained LOB picker. Category picker. All four compose into one round-trip query.
  • Drafts hidden from the portal. Only published and stale articles return to the portal. Drafts and archived versions never reach the portal.
  • Internal admin review pass. tenant_admin, hr_admin, and operations_manager roles bypass audience scope during a client screen-share. The role check is explicit and audited.
See it from the Clients team's view
app.frontlinehq.io/knowledge

Internal authoring

Standard Greeting Protocol — Inbound

Published2d ago

PCI-DSS Cardholder Verification — v2

Approved1d ago
writes to

knowledge_articles

312 rows · audience-scoped

reads from
portal.frontlinehq.io/retailco/knowledge

Client portal · RetailCo

Card return policy — RetailCo

Process & Policy

Holiday return window — extended

Customer Service
For the decision maker

Business outcomes for the operations leader

What this looks like in BPO P&L terms.

Handle time

Agents find the answer on the first search

Per-language ranked search, related articles, and zero-result analytics drive median search-to-read time down. The article searched but unopened tells the editor which title to rewrite.

Confidentiality

MSA confidentiality clauses defensible at the query layer

Three-level audience scope runs as a database subquery. Cross-client leakage requires a deliberate database change to occur.

Compliance

Audit-ready knowledge without prep weeks

Regulated articles route through the assigned reviewer. Every edit, publish, and view is captured. Auditors get versions and timestamps in seconds.

Margin

One knowledge surface replaces the SharePoint stack

Multi-client BPOs typically run three to four KB tools plus a folder structure. Consolidation drops per-agent KB cost and ends the question of which tool to look in.

What knowledge ops gets back

Directional outcomes — real magnitude depends on your editor cadence, audience scope discipline, and starting baseline.

Cross-client visibility

Audience scope ships as the database default

Zero hours/quarter rebuilding cross-client visibility — every article carries its audience scope at the data layer, not in folder hygiene.

Agent search quality

Zero-result searches down sharply

After several editor cycles closing top-frequency gaps. The zero-result queue is the fix-me list, not a metric to hide.

Compliance review

Days → hours

Reviewer approval queue replaces the email chain. Magnitude depends on your prior cycle length.

Knowledge surface

One source across every client

Replaces the SharePoint / Confluence / per-client folder stack with one platform, one search, one audit chain.

Regulatory posture

PIPEDALaw 25 (Quebec)CCPAPCI-DSS awareHIPAA-awareSOC 2 Type II (audit Q3 2026)Audit log retention (PIPEDA 7-year)

FrontLine Knowledge vs. SharePoint / Confluence / Zendesk Guide

Five differences multi-client BPO KM leads notice in the first month.

FrontLine KnowledgeGeneric KB

Three-level audience scope (tenant / client / LOB) enforced at the database

Generic KBs rely on folder permissions or page-level roles.

Full KCS lifecycle (draft / captured / structured / approved / published / stale / archived)

Most ship with draft / published / archived. Captured, structured, and stale require custom workflows.

Zero-result search analytics surfaced as the editor's fix-me queue

Search exists; zero-result tracking surfaced for the editor with normalized query grouping does not.

Compliance review gate routing regulated articles through an assigned reviewer

Review depends on email chains or page-level locks.

Knowledge Flows — decision-tree SOPs with audited compliance gates

Generic KBs offer ordered lists or flowchart images.

In production today

Authoring lifecycle, audience scope, search with zero-result analytics, compliance review gate, audit log, client portal reader, and the Knowledge Flows sub-spec (32A) all ship today. Bilingual sibling-row article pairing and richer effectiveness analytics are on the roadmap — see the Atlas for live status.

FAQ

Questions KM leads ask before signing

From fit calls. Short, direct answers.

How are client-specific articles isolated from other clients?+
Audience scope runs as an EXISTS subquery shared by every list, search, and detail endpoint. tenant_admin, hr_admin, and operations_manager roles bypass the scope for internal review; the role check is explicit and audited.
What happens to in-flight articles when an author moves on?+
Ownership transfers reassign owner_employee_id; the new owner inherits staleness notifications and the audit chain records the transfer. The two-pass staleness sweep escalates to the reviewer after 30 days if the new owner doesn't act.
How does FrontLine handle bilingual EN ↔ FR knowledge?+
The platform UI ships fully bilingual today — Quebec users see every surface in French from day one. Article bodies can be authored in either language. The sibling-row schema that structurally pairs an EN article to its FR translation and stale-flags one when the other changes is on the Atlas roadmap (spec 32, bilingual_content feature) — not shipped today. Editors track translation pairings outside the platform until it lands.
How do we know what agents can't find?+
Every zero-result search lands in the analytics page grouped and normalized — twelve searches for the same query show as one row with twelve hits. The fix-me queue drives next-cycle authoring; quality_index surfaces articles viewed but rated 'not helpful'.
Can the client portal show only the client's own content?+
The portal list endpoint runs the audience subquery with stricter scope rules. Four filters narrow further: free-text search, client picker, chained LOB picker, category picker.
How do regulated articles get reviewed before publish?+
Compliance & Regulatory articles route through the assigned reviewer's queue and hold in pending_approval until approved. Editing after approval resets the chain; the audit log captures every decision with the version each reviewer saw.
Do you ship with starter content?+
Yes — a starter library covers universal BPO knowledge (greeting protocols, escalation matrices, personally identifiable information (PII) handling, after-call work). For migration from an existing KB, the design-partner team works with you on a content audit + import plan; the platform exposes the same authoring API the UI uses, so bulk import scripts are straightforward to assemble for most source systems.

Ready to see it in your environment?

Two ways to take the next step.

FrontLine Knowledge | FrontLine