This is an example with a test account in an example app. It describes the case flow, without a measured result.
The user tries a swap. The app reports a failure. The user opens Help In testing and asks what happened.
The widget shows what the team will see before the user sends. The user chooses whether to share their wallet and transaction.
Never share a private key or recovery phrase.
The team inbox In testing shows the message and the wallet label. A wallet reported by the app says Attached wallet. Signing in proves control and changes the label to Verified wallet.
The app's failure details say what the app reported. A transaction check In testing adds evidence from the chain.
The check separates the app's report, chain evidence, Templ's reading and what is unknown. The team can inspect the evidence before answering.
In this example, the manager keeps the shared-transaction setting on. Sharing a transaction moves AI answers to AI drafts only In testing. AI off stays off. The AI draft stays with the team until a person chooses to send an answer.
The team replies in the same chat. The user sees the person's chosen name with a Team tag. The user can ask for a person at any time.
The team explains what the evidence supports. It asks for missing details when the check cannot answer the question.
The user taps Solved after a team reply. Templ records the resolution and applies the resolved-case rules.
Your first 3 eligible resolved cases are free. Then $8 per resolved case, $4 after 100 in a month. Pay only for resolved cases with a transaction check, a verified wallet, or an AI answer. No seats.
A case your AI agent resolves costs the same as one your team resolves.
The fee for a case your team resolves is a software fee.
Resolved cases use your prepaid stablecoin balance.
Custom pricing for bigger teams. Talk to us.
This example uses an excluded test case. It uses none of the free start or balance.
In testing means the feature is built and not yet open to every workspace. See availability.
| Check | Question to answer |
|---|---|
| Entry | Can users ask beside the failed action? |
| Wallet proof | Does the team see the difference between a connected address and a signed-in wallet? |
| Evidence | Can the team check the public transaction and the app's reported error? |
| Privacy | Does each read check the user's or team's current access? |
| AI review | Can the team choose drafts and review an answer before sending? |
| Handoff | Can the user reach a person in the same case? |
| Reporting | Do measurements separate AI replies, team replies and reopens? |
| Payment | What unit bills, and what other charges apply? |
Wallet sign-in, transaction checks and in-app support are capabilities to test. They do not establish a difference by themselves.
Choose a small set of test cases before the test starts. Include a wallet problem, a failed transaction and a repeat question.
Remove one test person's team access while their case is open. Check that old pages and file links stop working.
Ask the AI a question whose answer needs a person. Check the draft, handoff and the user's next-step message.
Never share a private key or recovery phrase.
Record the sample size, missing responses and your team's working hours. Review unresolved cases alongside resolved cases.
In September 2026, Pylon's guide separates response time, later replies and follow-up time. Read each tool's timing rules before comparing its reports.
Intercom's March 2026 article describes completed configured actions as outcomes. Zendesk's August 2026 guide describes automated resolution tiers with answer checks.
Intercom Fin charges $0.99 per outcome, plus $29 or more per helpdesk seat on Intercom, or a 50-outcome monthly minimum on another help desk (fin.ai/pricing, September 2026).
Mava's monthly plans include 100 support requests for $39 and 10,000 for $599 (mava.app/pricing, September 2026). Templ's $8 is per resolved case, so the units differ.
We checked both price pages on September 30, 2026.
The units differ. Estimate totals using the same cases and include the other charges. Recheck these September 2026 comparisons after 90 days.
Templ charges per resolved case. Signed order forms set any agreed price. Read Pricing before your test.
Signing in proves control of the wallet at that time, for that site. It does not prove a person's identity or their right to a refund.
A standard sign-in message names the site, wallet, network and expiry. The site checks the signature and the message together.
Templ also ties the message to the intended workspace. A message copied from another site or case cannot grant access here.
Ethereum's October 2021 sign-in standard describes these checks. Phantom's August 2023 guide describes a standard sign-in message for Solana.
Some signatures allow token spending. A sign-in message and a token permission have different effects.
Read the site name and the full message before signing. Stop if the wallet asks for spending permission during a support sign-in.
Templ's support sign-in sends no transaction and costs no network fee. Chat cannot start a payment or a signature.
Never share a private key or recovery phrase.
| Label | What your team knows |
|---|---|
| Guest | The user has no wallet proof. |
| Attached wallet | The app reported the wallet. The user chose to share it. |
| Verified wallet | The user signed in with that wallet. |
Ask the user to verify before a step that needs proof of wallet control. Keep questions about the failure in the same case.
A guest who verifies later keeps their case linked to the wallet. If that wallet has a case, both stay linked.
Solana sign-in In testing follows the same site and workspace checks.
Smart wallet sign-in
In testingneeds its own supported verification. Do not treat a connected smart wallet as proof.
In testing means the feature is built and not yet open to every workspace. See availability.
Put Help beside the action that failed. Link to that same place from your docs and your app's official site.
Tell users how to check your site address. A copied logo or team name does not prove who sent a message.
Real support never needs a private key or recovery phrase. Support messages should never ask users to approve spending or send funds.
A public transaction hash helps the team check a failure. It does not grant wallet access or prove who is chatting.
Uniswap Labs warned about fake WhatsApp and Telegram support in February 2025. Discord warned about scam bot messages in June 2023.
Phantom's support guide says its team does not start private social messages. Check the official route before opening a support link.
These warnings do not show how often teams move support away from Discord. Some teams use Discord cases, in-app support or both.
A February 2024 governance discussion asks about support scope, scam reports and escalation. Those questions describe a proposed service, not evidence of adoption.
| Route | What the team checks |
|---|---|
| Discord case bot | Private channel permissions, bot access and a clear official support entry. |
| In-app support | Site approval, case permissions and wallet labels that distinguish proof from a claim. |
A Discord case bot can give users private channels for help. The team still needs to collect the relevant wallet and transaction evidence.
An in-app widget puts Help beside the failure. Users still need to check the app's real address.
Templ's support widget In testing is a private corner chat inside your app where fake helpers can't reply. Chat cannot sign or send transactions.
Never share a private key or recovery phrase.
In testing means the feature is built and not yet open to every workspace. See availability.
Copy the install prompt into your coding tool inside your app's code.
The prompt asks the tool to use the widget reference and inspect your app's wallet connection. It asks for a small adapter that opens Help.
The tool should reuse your wallet connection. It should save failure details for the user to review before sharing.
Check the widget loader, wallet adapter and Help button the tool adds. Check where the tool calls openSupport in the failure handler.
The app can pass the action, network, visible error and public transaction hash. The user sees the details and chooses what to share.
A failed action should keep its normal result and error handling. Opening Help should not repeat the transaction.
Review the wallet adapter's sign-in message and network for both EVM and Solana wallets. Each network's sign-in follows its release checks.
For a configured workspace, its manager approves the exact site address in Widget. Add a test account before sending the test question.
Load the page, open Help and send a question. Read the case in your team's inbox. Reply and check that the user sees the answer.
Use Check my install In testing to review the install checks.
| Sample setup | Run date | Local checks |
|---|---|---|
| Next.js, wagmi and RainbowKit | 2026-09-29 | Type check, build and integration tests |
These local runs check sample installs. They do not prove hosted availability or the current prompt's full acceptance checks.
Other stacks: not tested yet.
Remove the Help adapter and the widget loader. Remove the call from each failure handler.
Remove the site approval if the site should stop sending cases. Check the page and its failure paths after the change.
Never share a private key or recovery phrase.
In testing means the feature is built and not yet open to every workspace. See availability.
A case your AI agent resolves costs the same as one your team resolves.
The fee for a case your team resolves is a software fee.
Resolved cases use your prepaid stablecoin balance.
Custom pricing for bigger teams. Talk to us.
Resolved means your team marked the case resolved or the user said it was solved. A billable case needs a team reply and no exclusion when it opened.
An AI answer counts as a team reply. An automatic greeting or handoff alone does not count. Silence does not count as a resolution.
Final means the charge has passed the time allowed for a reopen.
A team resolution becomes final after 7 days without a reopen.
A user's “solved” answer becomes final after 24 hours.
A billing manager can dispute a final charge within 30 days.
| Case | What counts |
|---|---|
| AI resolves | A reply and an explicit resolution count toward the free start or the balance. |
| Your team resolves | The same price applies when your team resolves the case. |
| The user sends a message within 7 days | The case reopens and its pending charge is cancelled. If the case is resolved again, it keeps the same charge. |
| An excluded test case | The case uses none of the free start or balance. |
Excluded cases never bill. Test accounts and install previews have limits. Duplicate cases from the same user follow the resolved-case rules.
Your first 3 eligible resolved cases are free. This applies once per billing owner and app domain.
Pay from Plan with a direct stablecoin transfer In testing. Templ credits the balance after it verifies the transfer is final. Templ never asks for payment in chat.
Payments use the stablecoins and networks shown in the app. Supported tokens include USDC and USDT where official on configured EVM networks and Solana.
Never share a private key or recovery phrase.
In testing means the feature is built and not yet open to every workspace. See availability.
Intercom's March 2026 article defines an outcome as a completed configured action. That action can end with a person taking over.
Zendesk's August 2026 guide describes automated resolution tiers and an answer verification step. Its automated resolution unit differs from a Templ resolved case.
Intercom Fin charges $0.99 per outcome, plus $29 or more per helpdesk seat on Intercom, or a 50-outcome monthly minimum on another help desk (fin.ai/pricing, September 2026).
Mava's monthly plans include 100 support requests for $39 and 10,000 for $599 (mava.app/pricing, September 2026). Templ's $8 is per resolved case, so the units differ.
We checked both price pages on September 30, 2026.
Compare the unit and all fixed charges before estimating a monthly total. Recheck these September 2026 comparisons after 90 days.
Confirm that the explorer uses the right network. Check whether the wallet or app sent the transaction.
A lookup with no result cannot tell you why the transaction is missing. The app may have stopped before sending it.
Keep the visible error and the time of the attempt. The app's team can check those details beside the public transaction reference.
Pending means the transaction has not entered a block. An explorer may mark it dropped when its nodes stop holding it. A replacement transaction can take its place.
Check the wallet's transaction history and any replacement hash. Ask the app's team what happened before trying the action again.
On Solana, a recent blockhash has a limited life. The network can reject a transaction after that blockhash expires.
The error BlockhashNotFound can involve an expired blockhash or a lagging provider. The app's team needs evidence to distinguish them.
No fixed confirmation time covers every transaction. Avoid retrying until the app explains what happened to the existing attempt.
EVM networks and Solana can charge a fee when execution fails. The failed action can leave no completed transfer while the fee remains.
The explorer may show an error, logs and fee. Send the public transaction reference to the app's team.
A wallet can refuse the action. The app can detect a failure before sending anything.
An insufficient-fee error means the paying account cannot cover the required fee. Some Solana actions also need funds for account storage.
There is no fixed minimum wallet balance for every action. Read the wallet's fee estimate and the app's explanation.
Send the public transaction hash or signature, network, action, visible error and time. Explain what you expected to happen.
Never share a private key or recovery phrase.
Templ's EVM transaction checks In testing and Solana transaction checks In testing show chain evidence to your team. The check separates that evidence from the app's report and what remains unknown.
A check cannot prove wallet control or promise recovery. The team asks for more details when the evidence is incomplete.
In testing means the feature is built and not yet open to every workspace. See availability.
An EVM explorer may show pending, failed, successful, dropped or replaced. Pending means the transaction has not entered a block.
Dropped means the explorer's nodes stopped holding the pending transaction. A replacement can take its place.
A failed transaction can still cost a network fee. The network may have done work before the failure.
On Solana, a transaction can confirm, fail or expire. A blockhash can expire before the transaction reaches a block.
A lookup that finds nothing does not establish why the transaction is missing. The team needs the network and the app's reported failure.
Success on a source chain does not prove that a bridge delivered on another chain. Check the destination evidence and the bridge's status separately.
A public April 2026 support question reports source-chain success and missing destination funds. The report is an example, not a verified diagnosis.
Ask which asset and network the user expected. Compare that answer with the public transaction details.
Do not promise that funds can be recovered. A successful transaction does not prove the app has a fault.
Templ's EVM transaction checks In testing and Solana transaction checks In testing show evidence to the team.
The panel separates what your app reported, what the chain shows, what Templ thinks and what is unknown.
The manager can set shared transactions to move AI answers to AI drafts only In testing. With that setting on, the AI drafts for team review. AI off stays off.
Ask for the public transaction hash, the action and the visible error when details are missing. A public hash does not prove wallet control.
Never share a private key or recovery phrase.
In testing means the feature is built and not yet open to every workspace. See availability.
Record results from your current support tool. Separate wallet problems, pending transactions and product questions.
Keep the same team hours and case categories during the pilot. Count real cases, waiting cases and time spent asking for missing details.
Record incidents separately. Include unresolved cases in the results.
Count users who open Help, send a question and verify a wallet when asked. Record why wallet checks fail.
Measure the AI's answer separately from a person's answer. Do not count automatic greetings as answers.
| Measure | What to record |
|---|---|
| Ready cases | Share of cases with a wallet and a checked transaction. |
| AI-resolved cases | Share of resolved cases that the AI answered. |
| Reopens | Cases reopened within 7 days. |
| User feedback | The Yes rate for Did this solve it? |
| Team response | Time from the user's question to the next reply from a person. |
Ask the user whether the answer solved their problem. A closed case does not prove that the problem is solved.
Transaction checks
In testingand
AI answers and drafts
In testingsupport these checks.
Use separate test accounts to check that one user cannot open another's case. Remove a person's team access while their case is open.
Check that old pages and file links stop working. Notes your team adds must stay out of user exports.
Never share a private key or recovery phrase.
Read the security guide and the inbox guide with your team.
Agree what to measure before the pilot starts. Record the sample size, missing responses and changes in team hours or case categories.
Your first 3 eligible resolved cases are free. Then $8 per resolved case, $4 after 100 in a month. Pay only for resolved cases with a transaction check, a verified wallet, or an AI answer. No seats.
A case your AI agent resolves costs the same as one your team resolves.
The fee for a case your team resolves is a software fee.
Resolved cases use your prepaid stablecoin balance.
Custom pricing for bigger teams. Talk to us.
Reviewed founding credit In testing can cover more resolved cases. Read Pricing for the price and credit rules.
In testing means the feature is built and not yet open to every workspace. See availability.