Policies & Operations
These policies explain how SaaS Fees works day-to-day: what we do, what we don’t do, how revisions are handled, how billing-event assumptions are documented, and how to raise concerns if something went wrong.
Purpose & where it applies
These policies apply to our consulting deliverables such as document reviews, checklists, matrices, and operational wording recommendations. They also apply to support interactions (email) related to those deliverables.
If a proposal, statement of work (SOW), or order form conflicts with this page, the signed proposal/SOW controls for that engagement, and this page fills the gaps.
Scope boundaries (what’s included vs. excluded)
Our services are designed to reduce confusion around pricing and billing events through clear documentation. We focus on definitions, disclosures, and customer-facing wording. For service details, see the anchors on Services.
Typically included
- Review of pricing page structure and plan naming (clarity, sequence, disclosures).
- Definitions for billing events (trial start/end, renewal, proration, cancellation effective date).
- Checklist of “included/not included” boundaries to reduce support tickets and disputes.
- Neutral comparison templates you can publish (no competitor brand claims).
- Plain-English suggested wording (you decide what to adopt).
Typically excluded
- Legal advice, regulatory opinions, or drafting legal terms as counsel.
- Tax advice or jurisdiction-specific tax determinations.
- Processor configuration changes (we can outline requirements; your team implements).
- Chargeback representation, collections, or financial services activity.
- Guarantees of outcomes (e.g., dispute reduction, revenue impact).
Deliverable types (examples)
Revisions & change control
We aim for practical deliverables that can be adopted by your team without prolonged back-and-forth. Revisions are handled as structured changes rather than open-ended editing.
- Revision rounds: unless your proposal says otherwise, we include one revision round focused on accuracy and consistency with your stated assumptions.
- What counts as a revision: clarifying a definition, aligning wording with a confirmed billing event, correcting a mismatch across sections, or reformatting a table for readability.
- What counts as a new request: changing the billing model (e.g., switching to usage-based), adding new plans/features, adding new countries/tax regimes, or expanding into new policy areas not previously covered.
- Change log: we can maintain a simple “assumptions & decisions” log in the document to keep changes auditable.
Tip: For the fastest turnaround, send changes as a single consolidated list and confirm which billing event(s) they affect.
Billing-event assumptions (how we document them)
Most billing disputes come from unclear event timing (what triggers a charge) and unclear boundaries (what’s included). We treat billing events as explicit assumptions that you approve.
Common events we define
- Trial: start, end, conversion moment, and whether a payment method is required up-front.
- Renewal: timing (e.g., on anniversary), notice windows, and invoice availability.
- Proration: upgrades/downgrades, effective date, and rounding approach (if applicable).
- Cancellations: immediate vs end-of-term access and “effective date” wording.
- Refund/credit triggers: what initiates review (request channel, timeframe, evidence).
Our working method
- We collect your existing rules (help docs, UI text, processor settings screenshots, invoice samples).
- We translate them into a consistent set of definitions and “if/then” statements.
- We flag contradictions (e.g., UI says “cancel anytime” but invoices are non-prorated).
- You confirm assumptions in writing (email is fine).
- We recommend customer-facing wording aligned to confirmed assumptions.
We document and rationalize your stated billing logic; we don’t independently verify processor behavior, tax calculations, or legal enforceability. If you need legal/tax review, we recommend involving qualified counsel/advisors.
Refunds & credits guidance (non-promissory)
SaaS Fees is a consulting provider; we don’t process your customer refunds. If we help you draft refund/credit guidance, it’s intended as operational wording, not a guarantee of outcomes. Your final policy should match your business model, processor capabilities, and applicable rules.
How we approach refund/credit language
- We recommend specific request channels (e.g., “write to support”) and required information (invoice ID, date, reason).
- We encourage clear time windows (e.g., “within X days”) where your business can realistically review requests.
- We separate refunds (payment reversal) from credits (account balance/extension) to reduce confusion.
- We add “case-by-case” language where appropriate, while avoiding misleading promises.
Common non-promissory phrasing patterns
“We review requests based on purchase date, product usage, and the reason provided.”
“Submitting a request doesn’t guarantee approval; we’ll reply with the decision and rationale.”
“Include invoice number, plan name, and the email used at checkout.”
“Where a refund isn’t possible, we may offer a credit or plan adjustment.”
Data handling summary
We keep data handling minimal and purpose-driven so we can deliver documentation. This is a summary, not a full privacy policy.
What we may receive
- Pricing page drafts, screenshots, and help-center snippets.
- Invoice examples (ideally redacted).
- Processor setting screenshots (non-sensitive views preferred).
- Support ticket themes (aggregated / anonymized when possible).
What we avoid
- Full payment card data.
- Government IDs or sensitive personal documents.
- Customer secrets unrelated to billing clarity (e.g., product roadmaps) unless necessary.
- Any data you’re not authorized to share.
Retention & access
- We keep files only as long as needed for the engagement and reasonable follow-up.
- Access is limited to people working on your deliverable.
- Use redaction when sharing invoice samples; we can provide a redaction checklist upon request.
Security note (plain language)
Email is convenient but not guaranteed to be end-to-end encrypted. If you need a different sharing method, ask us before sending sensitive files.
Responsibility matrix (policy area × who does what)
This matrix clarifies operational responsibilities. If your engagement requires a different split, we’ll reflect that in the proposal/SOW.
| Policy area | What SaaS Fees does | What the client does | Outputs |
|---|---|---|---|
| Pricing page clarity | Review structure, plan naming, fee disclosures; flag ambiguity and missing definitions. | Provide current copy and constraints; implement changes in site/app. | Annotated review + suggested wording |
| Billing events (trial/renewal/proration) | Translate your rules into explicit assumptions; spot contradictions and edge cases. | Confirm the true behavior and decide final rules; align product settings. | Assumptions table + customer-facing definitions |
| Refund / credit guidance | Draft non-promissory, operationally realistic guidance and request requirements. | Approve final policy; apply consistently; handle cases and communications. | Refund/credit section template + workflow notes |
| Vendor comparison content | Provide a neutral matrix template with consistent factors and definitions. | Fill in values accurately; avoid unverified competitor claims; keep current. | Comparison matrix template + glossary |
| Data handling | Request only necessary artifacts; encourage redaction; limit access. | Send only authorized/redacted materials; use secure sharing if needed. | Data-minimized deliverables |
Appeals & complaints procedure
If you believe a deliverable missed a confirmed assumption, contains a material error, or you had an unsatisfactory support experience, you can open an appeal/complaint. We handle these in a structured way to keep outcomes consistent.
Where to write
Email: [email protected]
Please include “Appeal” or “Complaint” in the subject line so it’s triaged correctly.
- Your name, company, and role.
- Engagement name (e.g., checklist, review, matrix) and delivery date.
- A short summary of the issue and why it matters operationally.
- Links or excerpts showing the confirmed assumption(s) (email, doc section, meeting notes).
- Your requested resolution (e.g., correction, clarification, additional note).
Timelines & steps
- Acknowledgement: we aim to acknowledge within 2 business days.
- Initial review: we review relevant artifacts (assumptions log, emails, version history) and may ask clarifying questions.
- Response target: for most cases, we aim to respond with findings within 10 business days.
- Resolution options: correction to deliverable, documented clarification, or explanation of why the deliverable matches the confirmed assumptions.
- Escalation: if you disagree with the outcome, request a second review by replying in the same thread with “Escalation requested” and your rationale.
We evaluate appeals against what was agreed (confirmed assumptions and scope). We can’t retroactively cover new policy areas without a change request, but we will fix material errors within scope.
Contact us about a policy question
Use this form to draft an email. We’ll reply during business hours (Mon–Fri, 09:00–17:00).