Start with one decision brief and one buyer committee, then prove each claim with an artifact buyers can inspect. Use hard topic filters like the ICP split of 40% firmographic fit, 40% pain intensity, and 20% buyer access, and prioritize rows at 75% or higher. Publish in sequence: commercial route, integration behavior, compliance caveats, finance-ops traceability, then outcome narrative. For sensitive copy, require qualifiers such as "where supported" and route W-9, Form 1099, FEIE, and FBAR statements through cross-functional review.
If your payments content does not help a buyer choose between real operating options, it is less likely to build authority. In this category, authority comes from demonstrated expertise: evidence, tradeoffs, and clear non-fit scenarios, not generic B2B volume.
Use this guide to build decision support, not audience volume. Different stakeholders evaluate different risks, but they share one need: content that helps them choose an approach, defend it internally, and manage the operational consequences.
That is why comparison content matters. Buyers do not need another piece saying payments are complex. They need help comparing options, understanding tradeoffs, and seeing where an approach is not the best fit. When comparison content starts to sound promotional, trust drops.
Start with one hard decision. Do not try to cover the whole category in one piece. The goal is to help a capable buyer make a narrower, higher-stakes call with fewer blind spots.
Use this check before you draft: would the piece still be useful if your product name were removed? If not, you are probably writing sales copy, not authority content. Content is more credible when it solves the reader's problem before it pitches anything.
Do not target a vague "B2B payments audience." Define an ICP with verifiable criteria so the piece maps to a real buying committee. One planning model uses firmographic fit (40%), pain or trigger intensity (40%), and buyer access (20%), then prioritizes accounts at 75% or higher.
You do not need to publish the scoring math, but you do need that level of discipline behind topic selection. The same topic lands differently by role, so the angle should match the decision-maker's constraints and tradeoffs.
Trust stays high when scope is explicit. When source material is limited, frame examples as "where supported" and "when enabled" unless current evidence supports something more specific.
This is accuracy, not legal padding. Before making specific coverage or compliance claims, confirm what is actually supported. The common failure mode is overconfident specificity. It implies universal availability, fit, or outcomes when the evidence supports only a narrower claim.
The rest of this guide follows that same sequence: start with the decision, narrow to the right buyer, then build proof, distribution, and governance. That is how content becomes commercially useful, not just visible. For the proof layer, our guide to writing case studies for a B2B SaaS audience is a useful companion.
Before you draft, settle the audience and the outcome. If either is unclear, the piece will read broad instead of authoritative, and it will be harder for a buyer to use.
Choose one primary reader for the article set. This only works when you target the right audience and address that audience's specific needs and pain points.
Before you commit, check persona assumptions against what has and has not worked in prior sales and marketing performance. Use that evidence to narrow the angle instead of blending multiple committees into one draft.
Define one KPI and one primary business objective for the piece before you write. That keeps the draft focused on a decision and avoids "cover everything" content that helps no one make a call.
Mark the claims that need explicit qualifiers before drafting: W-9 handling, Form 1099 thresholds, and coverage boundaries. This is where overstatement usually happens, so identify uncertainty early instead of trying to soften claims late.
For Form 1099 topics, be precise and contextual. It is a set of IRS information returns for non-salary income. Thresholds vary by case, including $600 in one context, $10 for royalties, and a calendar-2026 change to $2,000 for non-employee compensation generally reported on Form 1099-NEC.
If the piece touches W-9 or 1099 handling, test whether your guidance still works at scale. The year-end risk is operational, not just editorial. Tax details not collected and validated upfront can turn into a January filing scramble, and correction volume can become a major team drain. Manual W-9 and TIN checks may work around 100 payees but can fail at 5,000 partners.
For distribution planning later, see A Guide to Link Building for SaaS Companies.
Once your evidence pack is ready, narrow to one buyer problem that ends in one economic decision. Build the article around that single choice. If the topic changes business outcomes, it usually deserves priority over awareness content.
Pick one decision with clear tradeoffs, not a broad topic label. For example: Merchant of Record vs direct merchant setup, or whether to introduce Payout Batches for a manual payout workflow.
B2B decisions usually involve deep self-directed evaluation, internal justification, and multi-person approval. If one piece tries to solve multiple decisions for multiple audiences, differentiation weakens and the content becomes harder to use.
Use a one-sentence decision brief before drafting. It should cover:
If that sentence is fuzzy, the topic is still too broad.
Make the economic stake explicit so the reader can use it internally. Common tensions include customer acquisition cost, win rate, approval delays, or implementation risk.
You do not need unsupported benchmarks, but you do need a clear operational consequence. Name the metric or queue that should move if the recommendation is followed. If you cannot point to a P&L line, operational queue, or launch timeline, the piece is probably still top-of-funnel commentary.
If your team uses an ICP Fit Score-style model, prioritize topics linked to high-priority accounts, for example >= 75% in that model, before broad trend pieces.
Use the same decision, but lead with the evidence the risk owner actually cares about. For finance stakeholders, that usually means risk, controls, and operational impact. For developer-led readers, it usually means implementation clarity and integration risk.
Trust drops when the proof order is wrong. Keep the decision constant and change the lead based on what this audience uses to approve implementation.
Assign the piece to one buyer-journey stage before drafting. Buyers often evaluate multiple options in depth and build an internal case before moving forward, so stage fit determines whether the content is actually usable.
You are ready to write when three answers are crisp: what decision is being made, what economic tension it affects, and what proof this audience trusts first. If any answer is vague, narrow again.
Authority comes from claims a buyer can verify, not from broad positioning. Once the decision is fixed, map each product mechanic to evidence the reader can inspect in docs, UI, logs, or policy language.
Use one mechanic at a time and describe only what a reader can actually verify. For syndication and distribution mechanics, anchor the explanation to visible artifacts rather than internal assumptions, such as canonical URL setup or native post format.
Use a simple test: can a skeptical buyer check this claim against an artifact? If not, tighten or remove it. A strong draft maps every behavior claim to one proof asset, such as a doc excerpt, UI state, payload example, or traceable record.
Do not write one blended story for every stakeholder. Operational readers need evidence about reliability, exception handling, and investigation clarity. Commercial readers need tradeoffs tied to pipeline quality and implementation effort.
Keep the mechanic the same, but change the lead based on who approves. Content loses trust when it sounds broad but does not answer the actual approver's decision criteria.
Treat canonical setup, native expertise-driven posts, and lead-enrichment fields as workflow gates, not buzzwords. Show where the gate appears, what it affects in the flow, and what proof the reader can review. Keep this practical and bounded. Do not make universal performance claims unless you can verify them directly.
Each topic should include a plain failure-mode paragraph. Explain what can fail, how that failure is identified, and what record trail supports investigation.
This is where authority gets stronger. You are showing not just the happy path, but how teams can verify and handle issues when outcomes are messy, like strong content staying unseen without distribution, duplicate-content risk from missing canonicals, wasted effort on low-fit leads, or weak AI-answer visibility when the brand is absent from trusted data sources.
For a step-by-step walkthrough, see Content Marketing for B2B SaaS That Holds Up Under Real Work.
A staged sequence can make the story easier to verify. One practical order is commercial fit first, integration second, controls third, finance evidence fourth, and outcome proof last. It is not a universal rule, but it is a practical way to avoid thin comparison pages that search overviews can summarize without sending visits back.
| Order | Asset | Checkpoint |
|---|---|---|
| 1 | Lead with the business-model decision | Check claims in pricing language, onboarding steps, or visible UI state |
| 2 | Prove the integration path with real technical evidence | Trace one operation from request to event history to final state |
| 3 | Add the compliance explainer with strict caveats | Map claims to policy language and use strict qualifiers where scope can vary |
| 4 | Give finance ops a traceable record story | Let a finance lead answer "what record do I inspect next?" at each step |
| 5 | Close with a case-study teardown, not a testimonial | Use a before-and-after structure and avoid false precision |
Start with a decision explainer on the commercial routes you support. Keep it neutral: show what changes operationally by route rather than declaring one model "best."
Set one checkpoint for every claim: can a skeptical buyer verify it in a product artifact such as pricing language, onboarding steps, or visible UI state? If not, tighten or remove it.
Next, publish the developer deep dive on integration behavior with one clear happy path and one failure path from your existing docs. The goal is to help a team validate how the system behaves under normal and messy conditions.
Use a simple test: can an engineer trace one operation from request to event history to final state? If the draft has only high-level diagrams and no concrete request or event detail, it is too abstract.
Third, publish the compliance explainer as an operational map, not legal positioning. Show where checks appear in the flow, what they gate, and which policy or onboarding artifacts a reader can review.
Use strict qualifiers where scope can vary, such as "where supported" and "coverage varies by market or program." If product or compliance cannot map a claim to current policy language, cut it.
Fourth, write directly for finance ops with a traceability lens: exception review, investigation steps, and the records teams rely on today. Keep it practical and limited to records your team already uses.
Your checkpoint is simple: can a finance lead answer "what record do I inspect next?" at each step of an investigation? If the answer is unclear, the piece is still too high-level. If useful, link to our audit trail explainer instead of repeating examples.
Publish the case-study teardown last, after the first four assets are live. Then connect a specific pricing, process, or implementation change to an outcome narrative with a clear mechanism and evidence trail.
Use a before-and-after structure and avoid false precision. If exact adoption or margin numbers cannot be disclosed, say so and use directional language tied to the operational change.
Prioritize by decision impact and proof readiness first, then use search volume as a secondary filter. In technical B2B markets, volume-first planning often brings unqualified traffic and weak pipeline outcomes.
Start with real buyer friction and the language your sales and customer-success teams hear. Then create one matrix row per topic with three practical fields:
Define one concrete problem for one buyer group.
Mark early education, active evaluation, or late-stage validation.
Choose the format that can support the claim now, for example: product walkthrough, technical brief, compliance explainer, case-study teardown.
If a row cannot map to one buyer problem and one proof type, it is still too vague to prioritize.
| Topic row | Persona pain point | Funnel stage | Proof asset type | Decision impact | Proof readiness | Verification checkpoint | What to ship |
|---|---|---|---|---|---|---|---|
| MoR vs direct setup | Revenue/product team needs a commercial model decision | Evaluation | Decision explainer + walkthrough | High | Medium | Can this be shown in onboarding steps, pricing language, or visible UI state? | Publish after artifacts are gathered |
| Webhooks retries and failure handling | Developer needs to validate system behavior | Evaluation to late-stage | Technical brief | High | High | Can this be shown with reproducible examples and clear status traces? | Prioritize early |
| Reconciliation and exception tracing | Finance Ops needs record traceability | Late-stage validation | Ops explainer or case-study teardown | High | Medium to high | Can this be shown with reconciliation outputs or month-end evidence? | Prioritize when finance is in committee |
Score each row on two dimensions:
This avoids the common gap where SEO work and conversion work drift apart. Reported B2B examples reinforce the pattern: BOFU pages cited at 4.78% versus 0.19% for TOFU, and 60% to 80% of organic leads coming from 10% to 20% of pages. These are directional signals, not universal benchmarks.
Attach a blunt test to every row: Can this claim be tied to an inspectable proof asset and a layered attribution view (for example, source -> conversion event -> pipeline outcome)? If not, reduce scope before publishing.
Make the checkpoint operational: name the artifact, owner, and publish approval status. If a reviewer cannot quickly inspect the evidence, the topic is not proof-ready.
When proof is thin, narrow the claim instead of forcing thought leadership. Keep the mechanism clear, keep scope bounded, and use qualifiers where coverage varies. Use this downgrade pattern:
The matrix is not for finding the loudest topic. It is for choosing the next topic you can actually prove.
For the governance side, How to Build a Payment Approval Workflow: Thresholds Roles and Delegation of Authority covers thresholds, roles, and delegation in more detail.
Before you lock the next content sprint, sanity-check which monetization decisions your team can actually evidence in production. Then map those to the right module: Compare Gruv workflows.
Distribution should follow verification, not just reach. Publish the full argument on your site, then place it where buyers cross-check credibility: LinkedIn, developer communities, niche publications, and selective content syndication.
Keep your site page as the source of the full argument, then mirror it into channels buyers use during evaluation. LinkedIn can serve the research layer, while the trust layer should let readers inspect mechanics directly, such as a developer community thread, niche publication placement, or product-doc excerpt.
Send implementation-heavy explainers to developer-facing channels, where readers can validate behavior and edge cases. Send economic tradeoff pieces to business stakeholders, where scrutiny often centers on cost, risk, and operating tradeoffs.
If a claim needs product or API behavior to be credible, pair the article with a doc excerpt, request example, or API snippet. Use one test before distribution: can a skeptical reader verify the claim without booking a demo?
A common failure mode is treating content as informational only and reposting generic summaries everywhere. In this category, credibility comes from less hype and more inspectable evidence.
For compliance- and tax-adjacent content, treat every publishable claim as governed content, not standard marketing copy. If a draft mentions FEIE, FBAR, or other tax/compliance filing topics, route it through product, compliance, and finance before publication.
| Topic | Check | Grounded detail |
|---|---|---|
| FEIE physical presence test | Verify the day-count condition directly | 330 full days during any period of 12 consecutive months |
| Full day definition | Keep the definition explicit | 24 consecutive hours |
| FEIE amount references | Keep the qualifying context with any amount | $132,900 (tax year 2026) applies only for qualifying individuals and requires reporting income on a tax return |
| FBAR date-sensitive statements | Do a final recency check | FinCEN posts event-based updates, including an additional extension notice dated 10/11/2024 |
| Source hierarchy | Anchor claims to primary guidance | IRS Practice Unit is not an official pronouncement of law; use IRS FEIE guidance and Instructions for Form 2555 (2025) |
Build a real pre-publish review lane. Create one review lane for drafts that touch onboarding, tax forms, reporting, or coverage statements. Product verifies behavior and doc alignment. Compliance verifies wording, limits, and qualifier needs. Finance verifies reconciliation, reporting, and operator interpretation.
Run this review early, before line edits, so teams can fix claim scope instead of polishing overstatements. A practical gate is to flag any sentence that reads like a rule, entitlement, availability statement, or filing implication.
For FEIE references, verify the underlying conditions directly. The physical presence test uses 330 full days during any period of 12 consecutive months, and a full day is 24 consecutive hours. Also keep the failure condition explicit: missing required days can fail the test, including for illness, family problems, vacation, or employer orders.
Force qualifiers into the template, not the cleanup pass. Require qualifiers in the draft template itself: "where enabled," "where supported," and "coverage varies by market or program." That makes overbroad claims easier to catch before approval.
Keep FEIE language conditional, not absolute. If you mention amounts like $132,900 (tax year 2026), keep the qualifying context with it: the exclusion applies only for qualifying individuals and requires reporting income on a tax return.
Do not present exceptions as defaults. IRS waiver language for adverse-country conditions is conditional, not a general path. Apply the same discipline to FBAR wording: FinCEN posts event-based updates, including an additional extension notice dated 10/11/2024, so date-sensitive statements need a final recency check.
Maintain a claim registry tied to source artifacts. Maintain a claim registry for scrutiny-prone statements. Track claim text, required qualifier, owner, source artifact, and last-verified date. For product claims, link exact product artifacts. For policy or filing claims, link the primary guidance or form instructions directly.
Do not treat convenience sources as legal authority. For example, an IRS Practice Unit can be useful context but is explicitly not an official pronouncement of law. For FEIE, anchor claims to IRS FEIE guidance and Instructions for Form 2555 (2025); for FBAR, store the FinCEN page and verification date. If a claim cannot be inspected and verified, narrow it or remove it.
Match your resourcing model to the work that drives trust and revenue, not just headcount. A hybrid setup can be practical, but it is not a default rule. One workable approach is to keep high-interpretation assets close to internal reviewers and use partners for packaging and distribution when throughput is the main constraint.
Score the model on speed, control, and technical accuracy. Choose based on what buyers need to verify and how quickly your team can validate drafts. Anchor the decision to a revenue-tied North Star Metric (NSM), so each asset maps to a buyer-journey moment and business outcome.
| Model | Speed | Control | Technical accuracy | Usually fits when |
|---|---|---|---|---|
| In-house team | Depends on reviewer bandwidth | Direct internal control | Depends on access to source material and reviewers | Product depth and claim precision are core to trust |
| Specialist agency | Depends on onboarding and briefing quality | Shared through briefs and review cycles | Varies; test with pilot work | You need more execution capacity |
| Hybrid | Depends on handoff quality | Split by asset type | Stronger when ownership boundaries are clear | You need technical depth and consistent publishing output |
A simple check: review latency and handoff friction can decide which model is fastest in practice.
Build in-house when proof and nuance are the differentiator. Build in-house when authority depends on demonstrating how things work, not just describing the category. Direct access to reviewers and source artifacts can help keep claims precise and qualified.
At minimum, your internal setup needs:
Use a specialist agency when bandwidth is the bottleneck. An agency can help when your team has the knowledge but cannot sustain execution cadence. A key risk is relevance: when comparison content reads like promotion, credibility drops. Relevance can also drop when an agency lacks strong B2B understanding.
Use a concrete five-point evaluation before signing:
If you run a hybrid model, split work by risk and interpretive load. Keep higher-risk assets internal, and outsource repetitive repackaging and distribution support when needed. That can protect accuracy where trust is fragile while still increasing output.
For handoffs, provide a structured evidence pack: approved source draft, required qualifiers, excluded claims, audience, asset goal, and last-verified date. Do not let external repurposing introduce unsupported claims or strip qualifiers, because both can erode trust.
Even with the right in-house or partner split, authority can break in a few predictable places. Recovery is less about publishing more and more about tightening proof, qualifiers, and reporting so buyers can verify claims before they talk to sales.
| Issue | Risk | Fast recovery |
|---|---|---|
| Generic advice | Content could apply to almost any company | Rework it around a specific operating context and the decision it should inform |
| Compliance overclaims | Trust erodes fast | Add qualifiers such as "where supported," "where enabled," or "coverage varies by market or program" |
| Traffic-only reporting | Traffic alone is not proof of authority | Report against buying-progress signals and add an AI visibility checkpoint |
| Happy-path-only technical content | It can read like promotion | Add one short "what fails and how to respond" block |
Generic advice weakens authority content. If a draft could apply to almost any company, rework it around a specific operating context and the decision it should inform so the reader can connect it to a real operating decision.
Use a simple checkpoint: what decision changes if this claim is true? If you cannot tie a claim to a concrete source artifact, narrow it or cut it. Checkbox content patterns are commonly linked to weak ranking and conversion outcomes.
Compliance overclaims erode trust fast. Recover by adding clear qualifiers such as "where supported," "where enabled," or "coverage varies by market or program," and remove any jurisdiction-specific statement you cannot verify from current policy sources.
Run compliance-adjacent copy through a claim registry and last-verified check before publication. One failure mode is later edits that remove qualifiers to sound stronger, so keep this language in a required review lane.
Traffic-only reporting hides whether authority is actually working. Organic search can matter, but traffic alone is not proof of authority, and Domain Authority is a comparative 0-100 proxy signal, not a KPI to manage in isolation.
Report against buying-progress signals, then add an AI visibility checkpoint. Content can hold a top-three SERP spot and still miss AI-generated answer surfaces, so reporting is incomplete without citation or answer-surface presence tracking.
Technical content that only shows the happy path can read like promotion. Add one short "what fails and how to respond" block to key assets so readers can see how operations hold up outside the happy path.
Keep that block concrete and bounded to what is documented and what evidence supports the statement. If the detail is not documented, say less instead of guessing.
For a finance-ops view, Lean Accounting for Payment Platforms: How to Run Efficient Finance Ops Without a Big Team is a relevant follow-on read.
Authority is not a traffic metric first. It is a decision-confidence metric. Measure whether content helps buyers move from early questions to deeper evaluation.
Track a small set of outcome signals tied to buying progress. Focus on clearer technical progression and stronger engagement with deeper material. Keep the tracking simple at first and review trends consistently so you can trust what changed.
Look for whether questions shift from basic clarifications to fit and implementation questions. In technical B2B, decision makers research thoroughly before choosing, so progression from reading to requesting deeper material can be a stronger signal than pageviews alone.
Add operational fields to every content review. At minimum, capture where the content is distributed, whether it aligns with real engineering and operational realities, and whether it supports deeper technical evaluation.
Do not label a piece "high authority" if it is polished but not operationally usable. Credibility with technical buyers depends on content that reflects real engineering capabilities and operational reality.
Separate visibility inputs from trust outcomes in reporting. LinkedIn reach and SEO visibility are inputs. Buyer progression and depth of technical engagement are outcomes.
Use channel metrics to diagnose distribution, not to prove authority. Targeted distribution on channels like LinkedIn can improve engagement with technical decision-makers, and basic visibility hygiene still matters, including submitting an XML sitemap in Google Search Console.
Prioritize relevance over volume. Chasing broad high-volume keywords often weakens lead quality, while specific long-tail topics are more likely to match real buyer questions.
Run a regular authority checkpoint and make portfolio decisions from it. Retire low-proof content, expand high-proof assets, and refresh sensitive pieces when coverage changes.
If performance stalls, check strategy clarity before scaling output. When teams are unclear on what they create, who it serves, how it is distributed, and how it is measured, even well-produced content tends to underperform.
If you want content that builds trust in payments, keep it simple: publish in buyer decision order, prove claims with concrete evidence, and qualify sensitive finance or compliance language early. That is what separates authority content from generic volume publishing in an environment saturated with AI filler.
For your next launch brief, use this copy-paste checklist:
Pick one reader and one decision the article should help them make. If the draft tries to serve multiple audiences, narrow it before writing.
Start from source material, not opinion, and include implementation-level references, such as concrete technical details or transcript material. A claim is not ready until a skeptical buyer can trace it to evidence.
For KYC, KYB, AML, VAT, or tax workflows, use precise qualifier language from the first draft. Avoid implying universal support or outcomes your reviewers cannot verify.
Lead with content that helps buyers verify something concrete and shows real tradeoffs. Technical audiences reward domain fluency, and non-technical writing often misses that bar.
Measure whether the piece supports technical evaluation, not just traffic. If attention is high but implementation questions remain, tighten scope and increase proof density.
That is the practical path: fewer claims, stronger evidence, better sequencing. When each article helps a buyer make a real operating decision, authority becomes an outcome instead of a slogan.
Related reading: Tiered Pricing Strategies for Payment Platforms with Basic Pro Enterprise. If you want this authority framework to translate into a real launch sequence with implementation constraints, start with the integration and operations details in the Gruv docs.
The core difference is the proof burden, not just tone. In fintech, content needs to combine education, trust-building, and compliance-aware communication. Authority comes from demonstrated expertise, including clear tradeoffs and cases where your solution is not the best fit.
There is no universally validated, payments-specific “first five” sequence. Start with a practical mix you can substantiate with internal expertise, such as explainers, blog posts, videos, and comparison content that includes tradeoffs. If support is thin for one asset, move it later and publish what you can confidently back now.
Prove claims with evidence, not broad assurances. Keep promotional statements clear, fair, and accurate, and narrow or remove claims you cannot verify. In fintech marketing, mistakes can create legal and reputational risk.
Prioritize bottom-of-funnel SEO pages first, then work upward. This focuses on converting existing demand before expanding into broader awareness topics. Queries with modifiers like “platform,” “software,” “solution,” or “system” can signal higher intent, but they still need expert-backed content to build trust.
There is no evidence-backed rule in this source set for agency versus in-house. What is supported is that authority weakens when content is created without internal expertise, and fintech promotions must stay clear, fair, and accurate. Use the operating model that can reliably meet those conditions.
Track conversion-oriented signals, not just volume. Measure how well high-intent pages capture commercial-intent searches and support evaluation-stage behavior. Also monitor trust quality: comparison pieces should remain balanced, and promotional claims should stay clear, fair, and accurate.
A former product manager at a major fintech company, Samuel has deep expertise in the global payments landscape. He analyzes financial tools and strategies to help freelancers maximize their earnings and minimize fees.
With a Ph.D. in Economics and over 15 years of experience in cross-border tax advisory, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Includes 4 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
Many talented freelancers stay trapped in a feast-or-famine cycle because they compete on price for work that looks interchangeable. The problem usually is not talent. It is strategy. A stronger portfolio or a bigger social following can help at the edges, but neither fixes the core issue on its own.
If your SaaS link building still feels like a string of disconnected asks, treat that as an operating problem, not just a marketing gap. You can usually see the pattern in practice. Outreach happens in bursts. Links land on whatever page is easiest to pitch. Anchor text is vague. Nobody owns link quality after placement. Reporting stops at referring domains instead of asking whether those links support authority, credibility, discoverability, and the pages buyers actually visit. That is why the work often fails to compound.
If you work independently, you do not need another gallery of polished examples. You need a way to produce B2B SaaS case studies that help a buyer trust the result, help a client feel fairly represented, and hold up in review when someone asks, "Where did this number come from?"