How ConsultSuite Pro works

Five objects carry almost everything in ConsultSuite Pro. Understanding how they nest is most of what you need to evaluate or onboard.

• Firm — the tenant. Every record in the system carries a firm identifier, and the database enforces that you can only read rows belonging to a firm you are a member of. People, rate cards, brand voice, templates and the knowledge library are all firm-scoped. A person can be a member of several firms; the data never mixes.
• Client — an organisation you work for, with contacts, a portal, a health score and a history of engagements.
• Engagement — one body of work for one client. It owns the budget, the dates, the team, the deliverables, the tasks, the risks, the meetings and the time logged. Almost every screen in the app is a view onto engagements.
• Deliverable — a promised output. It has a due date, an owner, a status, an optional document behind it, and a visibility flag that decides whether the client sees it.
• Portal — the client-facing surface of an engagement. It is not a second product bolted on; it reads the same records, filtered to what has been marked client-visible.

A deliverable moves through a fixed sequence, and each step changes who can see it and what can still be edited.

• Draft. Internal only. The document studio is fully open — write, generate, restructure. Nothing is visible to the client, whatever the visibility flag says.
• In review. An internal reviewer is named. Comments and AI-suggested edits appear as diffs the author accepts or rejects; the AI never applies changes silently.
• Approved internally. On plans with approvals enabled, this step requires an Owner or Admin. On Solo it is a simple status change.
• Published to portal. The client sees the deliverable, and the publication is logged on the engagement timeline. Later edits create a new version rather than mutating what the client already read.
• Client approved or changes requested. The client responds in the portal with an optional comment. Requested changes push the deliverable back to draft and notify the owner.

Every transition is written to the activity log with actor and timestamp, so an engagement can be reconstructed after the fact — which is what you need when a client disputes when something was sent.

Generic AI writing tools produce plausible prose about your industry. The thing that makes a draft usable is that it is about your firm, and that comes from retrieval, not from a better prompt.

When you generate a document, the request is assembled from four sources:

• The knowledge library — case studies, methodologies and reusable proposal sections your firm has saved. Relevant items are selected and passed as source material, and their reuse counters increment so you can see which credentials actually earn their place.
• Live engagement and client data — the scope, dates, team, deliverables and contacts of the engagement the document belongs to, so names, figures and timelines are real rather than invented.
• Brand voice — the tone, vocabulary and banned phrases configured in Settings, with a live voice tester so you can tune it against sample text before it touches a client document.
• The guided brief — the document type's own fields: audience, purpose, length and type-specific questions such as evaluation criteria for a proposal.

Grounding is strictly firm-scoped. One firm's library is never used to generate another firm's document, and prompts and outputs are not retained for model training.

Roles are stored in a dedicated table, separate from user profiles, and checked server-side by a security-definer function. Nothing about permission depends on client-side state, so a role cannot be escalated from the browser.

• Owner — everything, including billing, plan changes and deleting the firm.
• Admin — settings, people, rate cards, templates, invoicing and approvals; not billing ownership.
• Member — delivery work: engagements, deliverables, documents, time, meetings. Sees firm finance summaries only where permitted.
• Viewer — read-only across the workspace, for advisors or non-delivery staff.

Engagement membership is a second, narrower layer: it decides who appears on an engagement's team and who is notified, without widening what their firm role permits. Custom roles, with a per-capability matrix, are a Practice-plan feature.

Three plans: Solo, Firm and Practice. Limits differ across active engagements, monthly AI generations, storage, white-labelling, approvals, custom roles and finance exports. The full comparison lives on the pricing page.

Enforcement happens on the server, inside the entitlement check that every metered action passes through — not in the interface. Hiding a button is a hint; the check is the rule. When you exceed a limit you get a named message (which limit, which plan lifts it), the action is refused, and nothing already created is deleted, hidden or locked. Downgrading leaves your data intact and read-accessible.

Seats are counted as accepted firm members. Client portal viewers are never counted and never billed, on any plan.

Isolation is enforced at the database with row-level security on every table, keyed to firm membership, rather than by filtering in application code. A query that forgets its firm filter returns nothing instead of returning someone else's rows.

Client portal access uses opaque per-client tokens and magic-link sign-in; a portal session can only ever resolve to the one client it was issued for. The product is in early access, and the security page states plainly what we do and do not yet have.

• Open the demo firm — populated data, no signup.
• Help centre — task-level answers by module.
• Template previews — every document type the studio produces.
• Academy — reading paths on winning, delivering and running the work.