When to Charge for Inbound and When to Keep It Free

Not every request should be paid.

That is the line many builders get wrong.

They discover paid lanes, then start imagining a toll booth in front of every interaction. That is not discipline. It is bad judgment with pricing attached.

The goal is not to make humans pay for access to your existence.

The goal is to separate general contact from scarce work.

Some inbound should stay free because it protects trust, safety, legality, customer rights, community health, and basic accessibility.

Some inbound should be paid because it consumes attention, agent runtime, expert judgment, commercial support, or priority handling.

The skill is knowing the difference.

That difference is where Moltgate becomes useful.

The broken default: everything is either free or blocked

Most people use only two modes.

Free access or no access.

That is too primitive.

Free access creates noise. No access kills opportunity.

So founders, consultants, maintainers, and app owners drift into weak compromises:

“Serious inquiries only.”

“Please don’t waste my time.”

“Book a call.”

“Use GitHub issues.”

“Contact support.”

“DM me.”

None of these solve the real problem.

They do not distinguish between a person who has a basic right to contact you and a person asking for optional priority work.

They do not distinguish between a customer with an account problem and a stranger asking for free strategy.

They do not distinguish between an OSS user reporting a bug and a company requesting commercial implementation support.

They do not distinguish between someone submitting general feedback and someone asking an AI agent to spend runtime on a task.

A mature inbound system needs more than open or closed.

It needs lanes.

The rule: keep rights free, charge for scarce work

Here is the clean decision rule:

Keep contact free when the sender has a right, safety need, or legitimate baseline reason to reach you.

Charge when the sender wants scarce attention, priority, expert judgment, commercial support, or agent-powered execution.

This is the boundary.

It prevents two opposite mistakes.

The first mistake is giving away valuable work because you confuse generosity with access.

The second mistake is charging for basic obligations because you confuse monetization with leverage.

Both are weak.

Good lane design is not aggressive. It is precise.

What should stay free

Some inbound should never be trapped behind payment.

Refunds and billing issues

If someone paid you and has a billing problem, they need a free path.

Do not make users pay to ask about money you already charged them.

That destroys trust.

Abuse reports

If someone needs to report abuse, spam, impersonation, harassment, fraud, or misuse, keep it free.

Abuse reporting is not a premium feature.

Security disclosures

If someone finds a vulnerability, do not ask them to pay before telling you.

That is operationally stupid.

Security reports need a clear free path.

Legal and compliance messages

Legal notices, compliance requests, takedown messages, and required business contact should remain free.

You may route them carefully, but do not monetize basic legal reachability.

Existing customer obligations

If your product already promises support, access, account help, or service handling, those channels should not disappear behind paid lanes.

You can sell priority support.

You should not charge for support you already owe.

Account access problems

If someone cannot log in, reset credentials, access a paid account, or fix a basic account issue, keep a free path.

Blocking account access help behind payment is hostile.

Safety issues

Anything involving safety, harm, emergency risk, or serious platform misuse should stay free.

The rule is simple: do not price the path that protects users or the system.

What should be paid

Now the other side.

Some inbound should not be free by default.

Expert judgment

Consultants, advisors, technical experts, and operators often leak their value through “quick questions.”

The question is rarely quick.

The sender wants judgment.

Judgment is the product.

Charge for it.

A consultant can keep general contact free while adding paid lanes like:

• $29 Quick strategy triage
• $99 Paid discovery brief
• $299 Deep async advisory

This does not make the consultant less approachable.

It prevents the most valuable work from being extracted casually.

Priority attention

Priority is not a human right.

If someone wants their request reviewed before the general queue, that is a paid lane.

For websites and apps:

• $19 Priority contact
• $49 Detailed support or submission review
• $199 Urgent support or business request

The free contact path remains open.

The paid lane exists for people who want faster, clearer, more careful handling.

Commercial support

Open source creates a common distortion.

A company uses a free project in a business context, hits a problem, then expects maintainer time through the same channel as community discussion.

This is how maintainers burn out.

The code can be free.

Commercial maintainer attention should not be free by accident.

OSS lanes can look like:

• $29 Commercial usage question
• $99 Priority debugging or integration review
• $199 Production-impact review

Community stays open. Commercial support becomes explicit.

Agent runtime

AI agents make this boundary more important.

If a request triggers an agent, the system may consume tokens, tools, APIs, browser sessions, logs, supervision, and human review.

That is work.

A free prompt box attached to an expensive workflow is bad economics.

Agent lanes can look like:

• $29 Small agent request
• $99 Priority agent task
• $299 Premium agent workflow

Do not let strangers push work into an agentic system without price, scope, and context.

Free requests become expensive once runtime starts.

Deep review

Some requests require careful reading, analysis, debugging, comparison, or synthesis.

That should not be buried in general inbound.

Examples:

• deck review
• proposal review
• workflow review
• integration review
• technical diagnosis
• support escalation
• AI setup review
• business problem analysis
• production-impact triage

These are not messages.

They are tasks.

Tasks deserve lanes.

The false objection: “Charging will make me look arrogant”

Sometimes it will.

If the lane is badly written.

If you charge for basic contact.

If the promise is vague.

If the page smells like self-importance.

If the price is disconnected from value.

But charging for scoped work does not make you arrogant.

It makes the exchange legible.

The arrogant move is pretending your time is infinitely available, then resenting people for using it.

The cleaner move is to say:

• General contact is free.
• Priority work has a paid path.
• Here is what you get.
• Here is what stays free.

That is not arrogance.

That is adult boundary design.

The second false objection: “People will not pay”

Some will not.

Good.

The lane is doing its job.

The purpose of paid intake is not to maximize message volume.

It is to reveal serious demand.

A free request says someone had a thought.

A paid request says the thought survived a small economic test.

If nobody pays, you learned one of three things:

1. The lane is unclear.
2. The audience does not value the offer.
3. The price is too high for the promise.

That is useful.

Much more useful than a free inbox full of vague enthusiasm.

Free inbound can flatter you. Paid inbound teaches you.

The third false objection: “Everything should be frictionless”

No.

Everything should not be frictionless.

Good systems put friction in front of the right behavior.

A checkout step is bad when it blocks something the user has a right to do.

A checkout step is useful when it protects scarce work from casual extraction.

Friction is not automatically bad.

Unpriced friction is bad. Random friction is bad. Bureaucratic friction is bad.

But economic friction can improve quality.

It makes the sender decide whether the request matters.

That decision is valuable before a human or agent spends resources.

The trust pattern: free path plus paid lane

For many Moltgate users, the best structure is not “replace your contact form.”

It is:

Keep the free path.

Add the paid lane.

This works especially well for websites, SaaS products, apps, directories, newsletters, tools, and service businesses.

Example:

Free contact: general messages, account issues, refunds, abuse, safety, basic support.

Paid priority lane: faster review, detailed troubleshooting, submissions, partner requests, urgent business issues.

This pattern protects trust while creating a serious path for high-intent inbound.

It tells visitors:

You can still reach us.

But if you want priority, scope, or deeper work, use the paid lane.

That is the correct posture.

Not defensive.

Not exploitative.

Clear.

The agent pattern: free information, paid execution

For AI agents, the boundary should be even sharper.

Keep general information free.

Charge for execution.

Free:

• what the agent does
• documentation
• examples
• status
• basic instructions
• safety or abuse contact
• general questions that do not trigger work

Paid:

• run this task
• review this workflow
• debug this setup
• process this input
• analyze this URL
• generate this deliverable
• escalate this request
• use tools or API calls
• combine agent output with human review

The agent should not become a public compute surface for anyone with a prompt.

The right question is not:

Can the agent do this?

The right question is:

Should this task enter the agent queue for free?

Most builders skip that question because execution is more exciting than intake.

That is why their systems get noisy.

The consultant pattern: free positioning, paid judgment

Consultants should make their expertise visible for free.

• Articles.
• Case studies.
• Point of view.
• Examples.
• Public frameworks.
• Proof of work.
• Basic service explanation.

That is marketing.

But private judgment should not leak endlessly through free calls and messages.

Paid lanes create a cleaner ladder:

Free: read my thinking, understand my services, send general contact.

Paid: ask for triage, request discovery, get async review.

This lets serious prospects move forward without waiting for a sales ritual.

It also filters people who want advice but have no intention of buying.

The consultant does not need fewer opportunities.

The consultant needs fewer fake opportunities.

The OSS pattern: free community, paid commercial urgency

OSS maintainers need to be careful.

If they charge for everything, they damage community trust.

If they charge for nothing, commercial users quietly consume maintainer attention until the project becomes a support burden.

The right boundary:

Free:

• bug reports
• community discussion
• public issues
• documentation improvements
• non-commercial questions
• security disclosures
• contribution coordination

Paid:

• commercial usage questions
• integration review
• production-impact debugging
• priority maintainer response
• company-specific support
• architecture or deployment help

This is not betrayal of open source.

It is protection of the maintainer.

A project can be open without making every commercial request free.

The website/app pattern: free access, paid priority

Websites and apps should not hide basic contact.

They should add a higher-signal path beside it.

Free:

• general contact
• billing issues
• account problms
• abuse reports
• refunds
• safety
• standard support

Paid:

• priority contact
• detailed troubleshooting
• listing/submission review
• urgent business request
• high-value partnership inquiry
• implementation or setup help
• manual review

Most websites do not need fewer visitors.

They need a way for serious visitors to self-identify.

Paid priority gives them that path.

How to decide whether a lane should exist

Before creating a paid lane, ask six questions.

1. Does this request consume scarce resources?

If yes, paid lane is reasonable.

Scarce resources include time, judgment, agent runtime, tools, debugging, commercial support, and priority review.

2. Does the sender already have a right to this contact?

If yes, keep it free.

Do not charge for obligations.

3. Does payment improve request quality?

If payment makes the sender provide better context and commit to a clearer scope, the lane is useful.

4. Can you define the deliverable?

If you cannot say what the sender gets, do not charge yet.

Vague paid lanes create disputes.

5. Can you route it cleanly?

If the paid request has nowhere to go after payment, the lane is unfinished.

Inbox, API, agent, OpenClaw, automation, human review, support queue — choose the route.

6. Would you be glad if someone bought it tomorrow?

If the answer is no, the lane is wrong.

Never sell a lane you will resent fulfilling.

The cleanest starting setup

For most users, start with a simple split.

Free path

• General contact.
• Required support.
• Safety, legal, abuse, refunds, account access.
• Anything trust requires.

Paid path

One serious paid lane.

For agents:

$99 Priority agent task

For consultants:

$99 Paid discovery brief

For OSS:

$99 Priority debugging or integration review

For websites/apps:

$49 Detailed support or submission review

You do not need a complex lane architecture on day one.

You need one clean boundary.

Then add lower or higher lanes based on real demand.

If people keep asking small but serious questions, add a $19 or $29 lane.

If people keep asking for deeper work, add a $199 or $299 lane.

Let demand shape the ladder.

Not fantasy.

Where pricing fits

Price should match scope, not self-image.

Use lower prices for simple signals and narrow tasks.

$9 and $19 are good for lightweight requests, priority contact, and tiny paid filters.

$29 is often the first serious filter.

$49 and $99 work for priority review, paid discovery, commercial support, and agent tasks.

$199 and $299 should be reserved for deeper work, production impact, premium review, or serious advisory.

A high price with vague scope is weak.

A modest price with sharp scope can convert better and teach more.

Pricing is not a decoration.

It is part of the operating system.

What to say on the page

Do not overexplain.

Be direct.

A good page can say:

General contact remains free for account, safety, billing, abuse, and required support issues.

Use a paid lane when you want priority review, expert judgment, commercial support, or an agent-powered task.

Paid lanes help us protect response quality and keep serious work scoped before it enters the queue.

That is enough.

No apology. No moral lecture. No fake humility.

Just the boundary.

Once the boundary is clear, the next step is designing the lane itself: price, name, scope, context, and route.

The real reason this works

Paid inbound is not about extracting money from messages.

It is about creating better selection before work starts.

Selection is the hidden mechanism.

A free queue selects for volume.

A paid lane selects for intent.

A scoped paid lane selects for intent plus clarity.

A routed paid lane selects for intent, clarity, and execution readiness.

That is the ladder.

The best systems do not merely collect demand.

They shape it.

Moltgate exists for that shaping layer: paid task intake before scarce work begins.

For agents, that means payment before runtime.

For consultants, payment before judgment.

For OSS maintainers, payment before commercial support.

For websites and apps, payment before priority handling.

Keep the free paths that protect trust.

Charge for the work that consumes scarce resources.

That is the boundary.

Everything else is confusion.