Approval Inbox

• A request comes in — from a webhook, an internal form, or a staff command — with what it's for, who's asking, the amount, and the reason
• AI turns that into a short brief so your approver doesn't have to read raw request data
• Everyone tagged as an approver gets notified the moment a request is pending
• The approver opens the bot, sees the latest pending request and its brief, and taps Approve or Reject — no typing, no ambiguity
• Both the original request and the final decision are written to your Google Sheet automatically, so there's always a record of what was asked and what was decided

• Send /start or /approvals to the bot to open the approvals inbox and act on the latest pending request. Remember: it's one pending request at a time, and a new incoming request replaces the previous pending one.
• Connect Google Sheets and map the audit columns — for example date, request ID, type, requester, amount, status and summary. Decisions get logged as a second row with the decision, who approved it, and when.
• Point the intake at your real source — replace the webhook's example fields with your actual form, CRM, billing, or internal system fields.
• Only wire up a real refund/discount/access action after your team has confirmed which operations are safe to automate and with what credentials.
• Tag your reviewers with the tag you chose during setup (approver, by default) on the Contacts page — that's how the bot knows who to notify.

Good to know

• Notifications go to whoever's tagged as an approver (you choose the tag during setup) — never hardcoded chat IDs, so you can add or swap approvers just by managing tags on the Contacts page.
• This inbox holds one pending request at a time. If a new request comes in while one is still pending, it replaces it as the request approvers see. If you need several requests open in parallel, treat this template as the starting point rather than the final system.
• Every request and every decision get written to Google Sheets as a simple audit trail — you choose the spreadsheet and map the columns (request ID, type, requester, amount, status, summary) during setup.
• Out of the box this only records a decision — it doesn't call any refund, discount or access system on its own. Wiring it up to actually execute an approved refund or grant access is worth adding once you know exactly which system and permissions are involved.
• Approve and Reject are real buttons, not free text, so a decision only counts if someone actually taps one — never guessed from a vague reply.

Common questions

• What kinds of requests should come through this inbox — refunds, discounts, purchases, access, something else?
• Which contact tag should receive approval notifications?
• Should approvals only be recorded, or should an approved request also trigger a real refund, discount, or access change?
• Where should the audit trail live — this Google Sheet, or somewhere your team already uses?

Keep in mind

• Don't wire this up to automatically issue refunds, grant access, or change billing until you've confirmed the exact API and policy for doing so safely.
• Don't treat a vague reply like "looks good" as an approval — only the Approve/Reject buttons should count as a decision.
• Keep this pointed at your internal approvers only — it isn't built to be shown to customers.
• Avoid putting sensitive payment details directly into variables or spreadsheet rows; keep the audit trail to what your team actually needs to see.