Professional Services
Engagement shapes for organizations that want help.
OpenBean is designed to be run by your own engineers. For teams that want help with a production rollout, the maintainer team offers nine named engagements. Each has a deliverable, an exit condition, and a clear split of customer and OpenBean responsibilities — paid against the deliverable, not against hours.
Pricing is not on this page. A scoped engagement produces a real number; a templated number produces a templated engagement. Conversations that don’t fit one of the shapes below are answered in writing rather than forced into the nearest one.
Architecture Review#architecture-review
A working session against your actual deployment target, not a generic walkthrough. Written memo at the end, suitable for attaching to your own architecture review.
For
An organization that has a concrete deployment target and wants a working session against their actual environment.
Intake
A named deployment target, a named compliance regime, a list of AI tools the team plans to connect first.
Deliverable
A signed-off architecture memo covering the recommended deployment topology, the security model as it lands in the named compliance regime, the migration path from your current memory surface, and a list of named operational risks specific to the target. Shared under the engagement's NDA.
Exit condition
The memo is attached to your own architecture review; the open questions in the memo are the only things left to resolve before deployment.
Customer responsibilities
Name the deployment target, the compliance regime, and the AI tools; provide the memo's distribution list; schedule the working session within the engagement's stated window.
OpenBean responsibilities
Produce the memo, walk it through a working session, and answer follow-up questions in writing for a stated period after the engagement ends.
What is not in scope
Building the deployment (that's a separate service), choosing AI tools, or recommending competitors.
Deployment Support#deployment-support
Hands-on help standing up your first production instance, ending when your team can run doctor, backup, and restore on its own.
For
An organization that has decided to deploy OpenBean and wants hands-on help with the first production-bound instance.
Intake
A named deployment target, a named owner for the project inside your organization, a written decision to deploy, and the prerequisite access (cloud account, VPS, or on-prem environment).
Deliverable
A working OpenBean instance your team can sign in to; the named owner has the operator's runbook; the engagement's last day is a one-hour hand-off with the named owner.
Exit condition
Your team has run `npm run doctor` clean on its own instance, has executed a backup/restore drill against its own data, and can describe the upgrade sequence from memory.
Customer responsibilities
Provide the prerequisite access, name the project's owner, and ensure the owner is available for the hand-off and the runbook walkthrough.
OpenBean responsibilities
Stand up the instance, run the operator's runbook walkthrough with the named owner, and produce a written hand-off summary.
What is not in scope
Running the instance for you after the engagement ends, providing 24/7 operational support (that's Support, §2.8), or refactoring the application's source code to fit the deployment.
Migration Guidance#migration-guidance
Bringing existing organizational knowledge — wikis, Slack, prior AI tool memories, design docs — into a governed instance, with the gate policy decided up front.
For
An organization bringing existing organizational knowledge into a governed instance.
Intake
A description of the source surface and a destination project structure (a named list of OpenBean Projects the migrated content should land in).
Deliverable
A working migration plan: the order of operations, the writer identities, the gate policy, and a written rationale for each choice. The engagement team is present for the first run and reviews the second; your team owns the third and onward.
Exit condition
The first migration run has produced a set of claims your owner can audit by project, the writer attribution is correct, and the gate policy is in force.
Customer responsibilities
Produce the source surface (the wiki export, the Slack archive, the prior AI tool's memory dump), name the destination Project structure, and staff the team that owns the third migration run onward.
OpenBean responsibilities
Produce the migration plan, be present for the first run, review the second, and write a post-run summary.
What is not in scope
Automated ingestion of unstructured sources, rewriting migrated content to fit the engine's shape, or a service that runs the migration on a schedule.
Migration Assessment (V9 new)#migration-assessment
A written assessment of feasibility, scope, and risk before committing to a Migration Guidance engagement. The assessment is a plan, not the migration itself.
For
An organization considering migration but not yet committed to a date or a source surface.
Intake
A source surface named at a sufficient level of detail to estimate the volume (number of wikis, number of Slack channels, size of the prior AI tool's memory) and a target outcome (search-only access, full governance, or hybrid).
Deliverable
A written Migration Assessment covering: estimated claim volume per source surface; the gate policy the migration would land under; the AI tool inventory and Connection re-creation; the risk surface specific to the named source; a recommended phased plan with named gates; a total-engagement estimate.
Exit condition
You have a written assessment you can attach to an internal decision about whether and when to start a Migration Guidance engagement.
Customer responsibilities
Provide the volume estimate, name the target outcome, and confirm the assessment's distribution list.
OpenBean responsibilities
Produce the assessment and answer one round of clarifying questions in writing.
What is not in scope
Running the actual migration, the writer-attribution work, the gate-policy work. The assessment is a plan; the Migration Guidance service is the execution.
Training#training
Sessions for the team that will operate OpenBean day-to-day. Half-day or full-day, in person or remote, organized by audience.
For
An organization whose team will operate OpenBean day-to-day and needs to build the muscle memory, not just the documentation.
Intake
A deployed or nearly-deployed instance and a named list of attendees (a typical session is 4–8 people). Sessions are organized by audience: engineering / SRE, governance, or developer.
Deliverable
A working session with a written agenda circulated in advance and a written summary circulated after. Each attendee leaves with a specific, named next thing to do in your instance.
Exit condition
Each named attendee has done at least one of the named next things in your instance, with the engagement team present, before the session is over.
Customer responsibilities
Staff the named attendees, provide the deployed instance, and ensure each attendee has the time and access to do the hands-on exercise.
OpenBean responsibilities
Produce the agenda, run the session, and write the summary.
What is not in scope
Certification (OpenBean does not have a certification program and is not building one), and training your customers.
Security Review (V9 new)#security-review
A security-shaped sign-off on OpenBean against your questionnaire — CAIQ, SIG, or custom. An opinion about how OpenBean's documented properties map to your items, not a re-audit.
For
An organization that needs a security-shaped sign-off before OpenBean can be deployed into a regulated environment.
Intake
A security questionnaire or its equivalent (CAIQ, SIG, a custom internal questionnaire, or a named list of security topics the security team needs covered). 60-minute scoping call.
Deliverable
A written Security Review covering: the mapping between OpenBean's documented security properties and the questionnaire's items (every item: covered, partially covered, not covered); the acceptance-suite CHECK numbers that prove each covered property; the deployment-target-specific security posture; the operator's responsibilities for the named compliance regime; the named security questions the engagement team could not answer, with the contact at OpenBean who can.
Exit condition
You have a written review you can attach to a security questionnaire, and the named questions are routed to the right human at OpenBean.
Customer responsibilities
Provide the questionnaire or the equivalent list, name the deployment target, and confirm the review's distribution list.
OpenBean responsibilities
Produce the review, sign off on it, and be available for one round of follow-up questions in writing.
What is not in scope
A penetration test, a SOC 2 audit, a HIPAA attestation. The Security Review is an opinion about how OpenBean's documented properties map to your questionnaire, not a re-audit.
Pilot Program (V9 new)#pilot-program
A structured, time-bounded pilot deployment with named gates. 4–6 weeks is the typical duration. The pilot ends with a written outcome report your team uses to inform a production decision.
For
An organization that wants a structured pilot deployment rather than a one-shot deployment, in order to evaluate fit before committing to a production rollout.
Intake
A named pilot scope (a single team, a single use case, a named set of AI tools, a defined duration), a named executive sponsor, and a written decision about what 'pilot success' means in your context.
Deliverable
A structured pilot plan with named gates, each gate's entry and exit criteria, the deliverables produced at each gate, and a written pilot-outcome report at the end. Signed off by both your organization and the maintainer team before the pilot starts.
Exit condition
The pilot has either met its named success criteria (and the next step is a Production Deployment Support engagement) or has not (and the next step is a written close-out report).
Customer responsibilities
Name the pilot scope, the executive sponsor, the success criteria, and the pilot team; provide the prerequisite access; staff the team's weekly cadence with the maintainer team's pilot lead.
OpenBean responsibilities
Produce the pilot plan, attend the weekly cadence, be available for the daily Slack channel the pilot team uses, and produce the pilot-outcome report at the end.
What is not in scope
A production deployment (that's Deployment Support, separately), a full migration (that's Migration Guidance, separately), or an indefinite engagement.
Support (V9 new)#support
A named, time-bounded support relationship with named response-time targets. Typically a quarter or a year. Operational issues against the running instance, not new work.
For
An organization running OpenBean in production that needs a named, time-bounded support relationship with named response-time targets.
Intake
A running production instance, a named operations contact, and a written support agreement that names the response-time targets, the escalation path, and what is and is not covered.
Deliverable
A working support relationship: a named channel (Slack Connect, shared email, or a ticketing system you provide), named response-time targets (Severity 1: 1-hour response, 4-hour mitigation; Severity 2: 4-hour response, 1-business-day mitigation; Severity 3: 1-business-day response), a quarterly review, and a written incident report for every Severity 1 incident.
Exit condition
The support agreement is renewed, expires, or is terminated; the engagement ends with a written close-out summary.
Customer responsibilities
Staff the named operations contact, use the named channel, provide the severity classification for every issue, and engage the named escalation path when the response-time targets are not met.
OpenBean responsibilities
Staff the named support team, meet the response-time targets, produce the quarterly review, and produce the incident report for every Severity 1.
What is not in scope
Feature work, security audits, deployment work, or migration work. A feature request is routed to the public roadmap, not absorbed into the support engagement.
Health Check#health-check
A second pair of eyes on the operational shape of a production instance, not on the application. Written report, signed off by a senior engineer.
For
An organization running an instance that has been in production for a while, where the team wants a second pair of eyes on the operational shape.
Intake
A production instance with at least 30 days of claim history, a willing operations contact, and a willingness to share `doctor` output, `backup` archive metadata (not the contents), and a representative sample of `config` and `scope_grants` rows.
Deliverable
A written health report covering: a review of the gate policy against the actual claim history; a sizing review; a security review; a concrete list of named, prioritized recommendations.
Exit condition
You have the report, have triaged each named recommendation, and any 'do now' items are either completed or scheduled.
Customer responsibilities
Provide the `doctor` output and the sample of `config` and `scope_grants` rows, and triage the recommendations.
OpenBean responsibilities
Produce the report, walk it through a working session, and answer one round of clarifying questions in writing.
What is not in scope
The engagement team taking operational action on the instance; you own the operational decisions and their execution.
