Skip to main content

Agency Manager Feature Contract

Purpose​

This document locks the core feature set for the agency manager and client portal.

It answers three questions for each capability:

  • should this exist
  • where should it live
  • what must it do to be considered real

Product Standard​

The app should be strong in the overlap between:

  • client relationship management
  • delivery visibility
  • time tracking
  • billing visibility and Stripe actions
  • document sharing

It should not try to become an all-purpose agency ERP.

Locked Core Features​

1. Client Accounts​

This feature should exist​

Yes. It is foundational.

What it is​

The agency-facing record of a client relationship.

Org surface responsibilities​

  • create client accounts
  • search and filter client accounts
  • view client status and relationship metadata
  • manage contacts
  • assign which agency staff can access each client account
  • view account summary across projects, billing, time, and documents

Access setup expectation​

For non-owner agency staff, access assignment should be part of the invite and edit-membership flow.

The mental model should stay simple:

  • invite the person
  • choose all clients or selected clients
  • adjust later from the membership or client-access controls when needed

Portal surface responsibilities​

  • expose the client's own account context
  • show key contacts and account health summaries relevant to the client

Must-have behaviors​

  • a client account belongs to one agency
  • a client account can have multiple contacts
  • a client account can own multiple projects
  • a client account is the anchor for billing, documents, and company-level portal access grants
  • the agency owner has full cross-client visibility by default
  • agency owners or admins can grant agency staff either all-client access or assigned-client access
  • agency-side visibility for projects, documents, and updates should follow client-account access by default
  • agency-side billing visibility should be allowed to layer additional RBAC on top of client-account access
  • agency staff without billing permission should not see billing summaries, invoice state, or other financial details for that client account

Explicitly not required in the first product wave​

  • prospect pipeline
  • deal stages
  • sales forecasting

2. Client Portal Access​

This feature should exist​

Yes. It is core to the product identity.

What it is​

A tenant-safe portal where client contacts can log in and view only their own account context.

Org surface responsibilities​

  • invite portal users
  • remove or update access
  • manage contact roles
  • set each company grant to full, delivery-only, or billing-only access
  • choose one or more client-visible account, project, billing, and support contacts

Portal surface responsibilities​

  • authenticated account home
  • account-specific projects, billing, documents, and updates
  • one agreements destination for quotes, contracts, statements of work, and attachments
  • a prioritized needs-your-attention view
  • lightweight acknowledgement, approval, change-request, and feedback actions
  • no access to internal-only agency data

Must-have behaviors​

  • portal identities are scoped to an agency organization
  • portal company access is scoped to client-account grants
  • a single portal identity may hold access to multiple client accounts inside one agency organization
  • a portal user is not treated like a weaker org user
  • invite acceptance and account lifecycle stay in the portal realm
  • role and workspace access scope remain independent
  • agency-selected relationship contacts and client decision signals use shared agency-owned records

3. Projects​

This feature should exist​

Yes.

What it is​

A light project-management layer centered on client-facing delivery truth.

Org surface responsibilities​

  • create and archive projects
  • set status, owners, dates, and summary
  • post updates visible to the client
  • associate documents and time entries

Portal surface responsibilities​

  • view active and archived projects
  • review status, updates, deliverables, and next steps

Must-have behaviors​

  • every project belongs to a client account
  • projects may optionally belong to an engagement or retainer
  • projects expose a concise client-facing state, not internal task noise
  • project updates are drafted internally and become client-visible when published

Explicitly not required in the first product wave​

  • kanban boards
  • heavy task hierarchies
  • sprint planning
  • dependency graphs

4. Time Tracking​

This feature should exist​

Yes.

What it is​

Internal agency time logging tied to real client work.

Org surface responsibilities​

  • create time entries
  • edit recent time entries
  • filter by staff member, client, and project
  • see billable and non-billable totals

Portal surface responsibilities​

  • none by default at raw-entry level
  • optional summarized visibility later if needed

Must-have behaviors​

  • time entries belong to an agency user
  • time entries reference a client account and optionally a project
  • time entries include date, duration, billable flag, and notes
  • summary views derive from time entries rather than replacing them
  • time can later feed invoice recommendations or draft billable line items, but billing must remain editable by humans

Explicitly not required in the first product wave​

  • payroll processing
  • capacity planning engine
  • automatic screenshots or invasive monitoring

5. Invoices​

This feature should exist​

Yes.

What it is​

Agency and client visibility into invoice state, grounded in Stripe.

Org surface responsibilities​

  • view invoice history per client account
  • send invoice links or trigger appropriate billing actions through Stripe-backed flows
  • see overdue, failed, paid, draft, open, and void states

Portal surface responsibilities​

  • view invoice list
  • view invoice detail and payment status
  • pay or follow Stripe-hosted payment actions when supported

Must-have behaviors​

  • invoice state must mirror Stripe state
  • invoice history belongs under the client account
  • clients can clearly distinguish paid, due, overdue, and failed invoices
  • invoice workflows should support both manual line items and line items suggested from tracked time

Eventual required behaviors for a serious billing product​

  • support the post-send invoice lifecycle without forcing agencies back into Stripe for common corrections
  • handle common outcomes such as voiding open invoices, applying credits or adjustments, and refunding paid invoices
  • keep those actions aligned with Stripe-native finance truth instead of inventing app-only states

Important note​

"Send invoices from here" should mean the app is the operating surface for invoice workflows, not that it must replace Stripe's invoice engine in v1.

6. Subscriptions And Retainers​

This feature should exist​

Yes.

What it is​

Visibility and control for recurring client billing such as retainers or recurring service plans.

Org surface responsibilities​

  • create or manage client subscriptions through Stripe-backed flows
  • view subscription status and plan context
  • see renewal, cancellation, and delinquency state

Portal surface responsibilities​

  • view current subscription or retainer status
  • update payment method or access Stripe billing portal where appropriate
  • understand what service relationship is currently active

Must-have behaviors​

  • subscriptions are tied to a client account
  • subscriptions do not require a project link in order to exist or bill correctly
  • subscriptions may optionally reference an engagement or project when that adds reporting or client context
  • Stripe remains the source of truth for recurring billing state
  • the app can expose plan/service context that Stripe alone does not express well
  • subscription creation should feel native to the client account workflow, not like a detached Stripe admin action

Planning note​

Client account should be the billing anchor.

Project or engagement linkage can be additive context, not a required precondition for routine recurring billing.

Explicitly not required in the first product wave​

  • complex usage metering
  • multi-subscription orchestration per client unless the business proves the need

7. Client Drive​

This feature should exist​

Yes.

What it is​

A client-facing shared file space for account and project artifacts.

Every client account should get a drive-like shared workspace by default.

The right starting model is not:

  • agency-only uploads plus later client upload support
  • a heavy document workflow product before the drive works well

The right starting model is:

  • a default client workspace drive exists as soon as the client account is active
  • agency and client can both contribute files
  • explicit upload requests sit on top of that drive as a lightweight coordination layer

Org surface responsibilities​

  • upload files
  • organize files by account or project
  • control visibility
  • manage categories such as contracts, assets, deliverables, and billing docs
  • request files or materials from the client

Portal surface responsibilities​

  • browse and download shared files
  • distinguish account-wide files from project files
  • upload files back to the agency from the first usable release
  • respond to file requests from the agency

Must-have behaviors​

  • files belong to a client account and may optionally belong to a project
  • visibility is explicit
  • file metadata exists independently from file storage
  • clients can find files without relying on email history
  • file exchange is bidirectional from the first usable release
  • both agency-originated files and client-originated files preserve uploader/source context
  • lightweight request statuses exist for agency-requested uploads
  • client-uploaded files are visible by default to agency members who already have access to that client account

Visibility recommendation​

Start with client-account-level visibility on the agency side.

Do not begin with per-file internal staff scoping as the default model.

If an agency needs narrower visibility later, that should be an exception layered on top of the base client-access model rather than the baseline for every upload.

Start with a simple request layer, not a full workflow engine.

Recommended statuses:

  • requested
  • submitted
  • reviewed
  • closed

Explicitly not required in the first product wave​

  • Dropbox replacement behavior
  • deep folder permissions matrix
  • collaborative editing in-app

8. Client Docs​

This feature should exist​

Yes.

What it is​

Structured client-facing documents such as statements of work, briefs, notes, and polished deliverable docs.

Org surface responsibilities​

  • publish client-ready docs
  • keep internal notes separate from client docs
  • attach docs to account or project context

Portal surface responsibilities​

  • read client-visible docs
  • review important account documents in one place

Should exist early in the product arc​

  • shared structured docs or notes that support back-and-forth collaboration when plain files are not enough

Must-have behaviors​

  • docs can exist alongside file uploads but are not identical to raw files
  • client-visible docs are explicitly marked and stored separately from internal notes
  • docs should support a simple polished reading experience, not just downloads

Planning note​

Bidirectional collaboration should start with practical file exchange first.

Rich collaborative docs can grow after that, but the product should not ship a one-way agency-to-client file model and call the workspace complete.

Also, client uploads should not depend on the agency creating a formal request every time. The drive should support normal back-and-forth exchange, while requests add structure when needed.

9. Billing Dashboard​

This feature should exist​

Yes.

What it is​

A billing control area across org and portal that turns Stripe finance state into understandable account context.

Org surface responsibilities​

  • client-by-client billing overview
  • invoice and subscription attention states
  • upcoming renewals and failed payments

Portal surface responsibilities​

  • account billing summary
  • open balance, upcoming charges, invoices, payment method entry points

Must-have behaviors​

  • billing status is understandable without finance jargon
  • invoice truth and subscription truth are visible but not conflated

10. Lightweight Project Manager​

This feature should exist​

Yes, but light on purpose.

What it is​

Simple delivery management shaped for agencies rather than software teams.

Must-have behaviors​

  • project status
  • owner
  • dates
  • updates
  • deliverables
  • file attachments
  • optional milestone layer

Should not be forced in early versions​

  • tickets everywhere
  • subtask trees
  • velocity reports
  • agile ceremony abstractions

Truth rule:

The product should help an agency manage work with clients, not imitate Jira.

11. Agency Stripe Connection​

This feature should exist​

Yes.

What it is​

The agency-level connection between this app and the agency's own Stripe account.

Org surface responsibilities​

  • connect Stripe
  • view connection status
  • resolve onboarding or access issues
  • understand whether billing features are ready

Portal surface responsibilities​

  • none directly

Must-have behaviors​

  • one agency can connect its Stripe account to the app
  • the app can act on behalf of that agency's Stripe account for client billing workflows
  • the app can surface when Stripe access or requirements are incomplete

Planning recommendation​

Prefer a Stripe Connect-style model so the agency keeps its direct Stripe relationship and dashboard access while the app operates as a product-specific layer on top.

12. Service Catalog And Billing Presets​

This feature should likely exist​

Yes, though it can land after the first billing slice.

What it is​

Agency-owned billing building blocks that make invoice and subscription creation fast and consistent.

Org surface responsibilities​

  • define recurring service plans or retainers
  • define reusable invoice line items or billing presets
  • map app service concepts to Stripe prices where needed

Portal surface responsibilities​

  • view the service context behind invoices or subscriptions

Must-have behaviors​

  • the app can describe what a subscription represents in agency language
  • reusable presets speed up invoice and subscription creation without becoming a full ERP catalog system

Supporting Features That Should Exist​

  • dashboard summaries
  • notifications and reminders
  • search and filtering
  • audit/activity timeline
  • account notes
  • contact records

Portal Navigation Availability​

The client portal should only advertise content destinations that contain something applicable to the selected client account and the current contact's access scope.

  • Overview and Support remain available as permanent utility destinations.
  • Projects, Files, Agreements, Billing, and Resources appear only when their client-visible workspace contains relevant records.
  • A destination must respect both record visibility and the portal contact's access scope. Hidden agency records must never make a client link appear.
  • Removing an empty destination must not remove the only path to a useful action. For example, Request a project remains available from Overview when the empty Projects destination is hidden.
  • Optional destinations remain hidden while availability is loading so the sidebar does not flash irrelevant links.
  • Direct or stale links remain safely handled by the destination's normal authorization and empty-state behavior.

Features That Should Be Deliberately Deferred​

  • proposals and quoting suite
  • full CRM funnel
  • chat/messaging platform
  • accounting replacement
  • helpdesk replacement
  • heavy project-management framework
  • white-label customization layer before the core product works well