AnswerLattice Operating Guide

One product, three operating depths

Solo founders remain the primary starting point. Small teams and product groups inside larger companies use the same reviewed support system, adding existing controls only when support ownership or answer risk grows.

Start, Coordinate, and Govern are guidance levels. They are not workspace modes, automatic scores, separate products, or required setup stages.

• Start: one accountable owner launches trustworthy self-service.
• Coordinate: selected teammates divide support and review work.
• Govern: product, support, and engineering protect high-risk answers across releases.
• Company size alone does not decide fit. The operating group and support problem do.

Start with the smallest useful support layer

A founder should not configure every AnswerLattice capability before users receive help. The first job is to cover the most important questions and prove both the known-answer and safe-fallback paths.

• Create one workspace for one product.
• Add the product profile, support email, and two to five support-heavy pages.
• Import the product material you already trust.
• Review ten priority customer questions and approve only answers supported by your product knowledge.
• Run canonical-only Answer Tests for critical expected answers.
• Verify one known-answer path and one missing-answer fallback path in the widget.
• Use Daily Brief after launch and leave stable areas alone.

What a founder can ignore at first

Available features are not mandatory work. Full utilization means using the correct operating depth, not enabling every screen.

• Do not create custom roles while one owner operates the workspace.
• Do not use Support Board for every ticket.
• Do not configure workflow notifications while one review habit is enough.
• Do not open advanced Knowledge Map or review views unless a decision points there.
• Do not request API distribution before approved answer coverage and key controls are ready.
• Do not build a large article library merely to make setup look complete.

Coordinate when support ownership spreads

Move beyond the founder setup when a second person regularly responds to users, reviews answers, ships releases that change official support, or owns recurring follow-up.

• Invite only active support, product, or engineering operators.
• Start with protected Owner, Manager, and Support Staff roles.
• Create a custom role only when a real permission boundary requires it.
• Add Slack or email notifications when work is being missed outside the workspace.
• Use Support Board only for selected issues that need private notes, ownership, or follow-up.
• Record releases that change plans, roles, limits, navigation, integrations, or errors.
• Expand Answer Tests around billing, permissions, cancellation, retention, and security.

Add deeper review controls when answer risk grows

A growing company does not need every employee in AnswerLattice. A bounded product, support, and engineering group can use deeper controls when several functions rely on the same reviewed support knowledge or releases frequently affect existing answers.

• Keep one accountable owner for official support answers.
• Use Knowledge Map to locate the product area and connected review work.
• Preview release impact before activating customer-visible changes.
• Protect critical answers with repeatable tests.
• Use role controls, version history, exports, and audit evidence for accountable review.
• Keep an existing helpdesk as the conversation and SLA system when those operations are required.
• Enable public API or external distribution only when available, verified, and supported by sufficient approved coverage.

Introduce features because a real trigger exists

• Team Access: a second person regularly operates support or review work.
• Workflow Notifications: work is missed without an external alert.
• Support Board: a selected issue needs internal ownership or notes.
• Knowledge Map: a decision needs cross-feature product context.
• Release Impact: a release changes customer-visible product guidance.
• Answer Tests: an answer is important enough to protect from regression.
• Support Truth Export: a buyer or downstream team needs bounded evidence.
• Public API: approved coverage and key controls are ready.

Keep the normal operating rhythm small

• Handle real user fallback before internal improvement work.
• Review only qualified stale-answer, release-impact, or repeated-gap items.
• Approve, edit, classify, defer, or reject the exact item.
• Use one optional weekly review when the quiet Daily Brief needs no decision.
• Do not duplicate the same issue across several queues without one accountable owner.

Know the larger-company boundary

AnswerLattice can support a product group inside a larger company through team access, permissions, tests, release review, exports, and audit history. It remains reviewed support infrastructure rather than a contact-center suite.

• Good fit: one product group needs reviewed support knowledge across widget, hosted help, people, and releases.
• Keep the existing helpdesk when the company needs omnichannel routing, workforce management, or SLA operations.
• Do not assume unverified SAML, SCIM, contractual service levels, public certifications, or procurement commitments.
• Evaluate required controls and integrations directly instead of treating employee count as proof of fit.

FAQ