Okouro docs
en fr

Okouro is subscribed per account. Every account sits on a free plan as its baseline, plus the paid plans offered to your account. Plan names, prices and limits vary by deployment, so rely on what your account actually shows rather than assumed tiers.

How plans are priced

Every plan carries a rate card with three parts:

  • Base fee - the monthly amount the plan costs, whatever the team size.
  • Included seats - the billable consultants the base fee already covers.
  • Per-consultant price - the monthly price charged for each billable consultant beyond the included seats.

Your monthly amount is the base fee plus the per-consultant price for every billable consultant beyond the included seats. On the free plan the base fee and the per-consultant price are both zero, so the rate card never adds to the bill.

A billable consultant is any consultant whose status is not Inactive. Active consultants count, and consultants on the bench count just the same.

Peak billing

The provider bills the highest number of billable consultants reached during the month, not the count of any single day. People added mid-month raise the peak; marking someone Inactive lowers the peaks that follow. The amount shown in the app is an estimate of the upcoming charge, computed from today’s count. The charge history is the source of truth for what was actually billed.

Consultant limits

Paid plans set no cap on consultants: growth is pay-per-head, priced by the rate card. The free plan keeps a small consultant allowance, which acts as its cap.

What a plan grants

Besides the rate card, a plan bundles two things:

  • Quotas - caps on clients, active missions, analytics history measured in months, and quote templates.
  • Features - weekly and bi-weekly timesheets, and split allocations.

The analytics-history quota bounds how far back reporting windows can reach.

When you reach a quota, creating more of that resource is blocked until you move plans or free up room.

Subscribing to a paid plan

Choosing a paid plan from Organization > Subscription reserves the subscription instead of activating it: the status turns Pending, no entitlement is granted yet, and you are redirected to a secure payment page hosted by the payment processor, where the first charge is taken.

The plan activates automatically once the first charge settles (the processor notifies Okouro). A reservation that stays unpaid expires on its own after 24 hours.

Manage your subscription

Only administrators manage the subscription, from Organization > Subscription. The card shows:

  • The current plan and its status - Pending, Active, Past due, or Canceled. A missing or canceled subscription displays as the free plan.
  • An estimated price per month and the next billing date.
  • An amber Cancels on line while a cancellation is pending.

Usage meters compare what you use against each quota, showing Unlimited where the plan sets no cap. The plan, price and readings all reflect your account’s live subscription.

The card on file is shown redacted (brand, last four digits, expiry) and can be updated at any time through the processor’s secure portal. Card data never passes through Okouro.

Change, cancel, reinstate

  • Switching between paid plans of an already-active subscription applies immediately, with no new payment page.
  • Moving down to the free plan cancels the subscription at the end of the period, after which the account runs on the free plan.
  • A pending cancellation can be Reinstated.

Past due

When a payment fails, premium access is suspended on a stated date and resumes automatically once the payment provider collects a payment. Update your payment method at the provider to restore service sooner.

Charges

Recent charges are listed with their period, amount, and a succeeded or failed outcome. Failures also carry a reason.

Operator setup: payment processor

The billing backend is selected by operators in application.toml, under [app.billing.provider]:

  • type = "Stub" - development: simulated payments served by local dev pages.
  • type = "Stripe" - production integration with Stripe.

A Stripe configuration looks like:

[app.billing.provider]
type = "Stripe"
success_url = "https://your-domain/"
cancel_url = "https://your-domain/"
return_url = "https://your-domain/"
config = { secret_key = "sk_test_...", webhook_signing_secret = "whsec_..." }

[app.billing.provider.config.prices.business]
flat_price_id = "price_..."
metered_price_id = "price_..."
meter_id = "meter_..."

One price binding is declared per paid plan code (here, business):

  • flat_price_id - the recurring base-fee price.
  • metered_price_id - the per-consultant seat price.
  • meter_id - the Stripe meter aggregating seat gauges with MAX aggregation.

The redirect URLs land the administrator back in the app: success_url after a completed purchase, cancel_url when the purchase is abandoned, return_url after managing the card.

Prerequisites in the Stripe dashboard: a meter with MAX aggregation, the prices bound above, and a webhook pointing at the controller’s /billing/provider-events endpoint, delivering at least checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.deleted, and customer.updated.

In development, the Stub backend emulates the payment page locally (/dev/stub-checkout, /dev/stub-portal) so the whole loop can be exercised without a processor account.