L1 Support — Policies & Operating Standards
Podium Support
L1 Support Playbook
Policies, Procedures & Operating Standards
01
Professionalism and conduct
▶
Camera standards
Camera on for all meetings where you're expected to speak, share, or contribute. Includes one-on-ones, pod sessions, team syncs, and customer calls. Backgrounds can be blurred — a black screen is not acceptable in a participatory meeting.
Camera onOne-on-ones · Pod meetings and syncs · Team stand-ups · Customer calls · Any meeting where you speak or contribute
Camera optionalLarge all-hands or town hall-style meetings. When in doubt — camera on.
Call first — always
The default when following up with a customer is a phone call — not an email. Emails are easy to ignore. A call gets it done faster and makes it easier to explain exactly what you need and why.
This applies when advising teammates too. If a rep needs more information from a customer, encourage them to call — even for screenshots. A two-minute call explaining what you need to see gets better results than an email asking for it.
Email is the follow-up to a call — not the replacement for one.
02
Communication standards
▶
Clear, human, confident — not robotic or over-apologetic.
Approved templates exist for common scenarios. Always personalise before sending.
"I can't" and "that's not possible" are banned. Replace with what you can do and what comes next.
If a ticket will take longer than expected, update the customer before they chase.
03
Pod structure and skill routing
▶
AI
AI-related products and features
Phones
Phone products and call-related features
Integrations & automations
Third-party integrations, workflows, and automation tools
Podium products
Inbox, payments, surveys, feedback, web chat, leads — and all other products
Handle first, reassign after. Any rep who receives an engagement handles it live regardless of pod. Resolution on first contact is always the goal.
Post-engagement reassignment. When the engagement ends and moves to a Salesforce case, if it falls outside the rep's pod, reassign to an L1 rep in the correct pod. That rep owns it end to end — all comms, escalation, and closure.
How to find the right rep to assign to. First, check the Org's existing cases to see if someone from that pod already has an open ticket for this customer — if so, assign to them. If not, check the AU Latest Support Dashboard in Salesforce and assign to the rep in that pod with the fewest open cases.
Reassignment carries context. Include a full summary of what was discussed, tried, and found. No cold handoffs.
04
First contact troubleshooting guide
▶
This section is your reference for handling the first engagement on a case — from the moment you greet the customer through to collecting everything you need to investigate or escalate. The general principles apply to all cases. The product-specific sections below give you the right questions and checklist for each area.
Greeting the customer
Acknowledge quickly and warmly. The customer's first impression of support is set in the first reply. Use their name, confirm what they've reached out about, and let them know you're on it. Don't make them repeat themselves if context is visible in the case.
Set a clear expectation upfront. Let the customer know what you're going to do — "I'm going to look into this now and will have an update for you shortly" is better than silence. If you need more information before you can investigate, say so immediately rather than going quiet.
Example opening
"Hi [name], thanks for reaching out! I can see you're having trouble with [X] — I'm looking into this now and may need a couple of details from you to help investigate. I'll come back to you shortly."
Gathering information
Before you troubleshoot, make sure you understand the full scope. Is this one user or all users? Has it always been this way or did it stop working? Has anything changed recently — new devices, updates, integrations added? These questions shape everything that follows.
Ask for specifics, not descriptions. "It's not working" is not enough to troubleshoot. You need names, numbers, timestamps, error messages, and screenshots. Be specific about what you need and why — customers are more likely to send the right thing if they understand how it helps.
Who is affected?One user, some users, or all users at the org? Has it ever worked? When did it stop?
What does it look like?Error messages, red banners, console errors. Screenshot of the full browser — not a crop.
What device / platform?Mobile or browser? If mobile: device model and app version. If browser: which browser and version.
Example contactsSpecific customer names and phone numbers where the issue occurred — not generic descriptions.
Troubleshooting before you escalate
Try the common fixes first and document each one. Every troubleshooting step you take needs to be logged in the case — what you tried, what happened, what you ruled out. This is what TPS and the customer will read.
Clear cache / cookiesAsk the customer to clear browser cache or app cache. Note whether it made a difference.
Update the app or browserConfirm they are on the latest version. Outdated apps cause a significant proportion of reported issues.
Disconnect and reconnectFor integrations and Facebook — disconnect the connection and reconnect. Log the outcome.
Try to replicateAttempt to reproduce the issue from your side. Note whether you can replicate it — this is key information for TPS.
Check scopeTest whether the issue affects one location, all locations, one user, or all users. Scope determines priority.
Check console errorsFor browser-based issues, ask the customer to open developer tools and share any console errors.
Communication during troubleshooting
Keep the customer informed at every step. If you're trying something, tell them what you're doing and what you expect to happen. If something doesn't work, tell them what that means and what you're trying next.
Never go quiet. Even if you're waiting on something — a screenshot, a response from TPS, a system check — send a brief update so the customer knows you haven't moved on.
Be honest about complexity. If the issue needs escalation, say so in plain language. "This is something our technical team needs to look at — I'm escalating it now and will keep you updated" is far better than vague reassurance.
Integrations — first questions to ask
Before troubleshooting, establish the scope. Is the full integration down, or just one automation? Is it authorisation-related (the connection has broken) or a data issue (the connection is active but something isn't syncing or triggering)?
What integration?Get the exact name — Shopify, simPRO, JobAdder, ServiceM8, etc.
Scope of issueFull integration down · Authorisation issue · Contact sync only · Single automation affected
Which automation?If a single automation, get the exact name as it appears in Podium.
When did it stop?Has it ever worked? Did something change — update, reconnection, new team member?
Example customersName, phone number, and Job/Appointment ID for each customer who should have received a message but didn't.
CRM / system screenshotScreenshot of the job, appointment, or customer record in the external system — showing it was in the correct status to trigger the automation.
Always ask for a CRM screenshot alongside the Podium screenshot. The screenshot needs to show the record in the triggering system — the job status, appointment status, or customer details — confirming that everything was in the right state for the automation to fire. Without this, TPS cannot determine whether the issue is on the Podium side or the integration side.
Required information — Integration case template
Integration Support Case — required fields
Integration app name *
Exact name of the integration — e.g. Shopify, simPRO, JobAdder
Extent of issue *
Contact sync · Single automation · Authorisation issue · Full integration down
Automation name
Exact name of the affected automation as it appears in Podium
Describe the issue *
Full description of what is and isn't happening
Example customer 1 *
Name, phone number, and Job/Appointment ID — a specific customer who should have received a message but didn't
Example customer 2
Second example — name, phone number, and Job/Appointment ID. More examples = faster diagnosis.
Podium screenshot *
Full browser screenshot — not cropped. Show the entire Podium interface including automation monitoring for the example customer.
CRM / external system screenshot *
Screenshot of the job, appointment, or customer record in the external system — must show the record was in the correct status to trigger the automation (e.g. job marked complete, appointment confirmed, order fulfilled). Include the record ID and customer details visible in the screenshot.
Gong / recording link
Link to any call recording with timestamp if relevant
Troubleshooting done *
Every step attempted and its outcome — e.g. "Checked automation monitoring for sample user — no trigger found. Other automations via same app are working."
Common first troubleshooting steps — integrations
- Check whether the integration is still connected — look for an authentication error or disconnected status
- Check automation monitoring for the specific affected user — is the trigger firing? Is it getting stuck at a step?
- Confirm whether other automations via the same integration are working — isolates whether it's the whole integration or one flow
- Get a CRM/system screenshot showing the specific job or appointment record — confirm it was in the correct status to trigger the automation, with the Job/Appointment ID and customer details visible
- Get a Podium screenshot of automation monitoring for the same example customer — showing whether the trigger was received or not
- Check if the contact exists in Podium and that their phone number is correctly formatted
- If confirmed it's an authentication issue — disconnect and reconnect the integration, then test with a sample record
- If unable to resolve — raise to TPS using the integration case template above. All fields marked * are mandatory before submission.
Pod resource — AU Ecosystem Directory
Not sure if a particular integration is supported, how it connects, or what it does? Check the AU Ecosystem Directory before troubleshooting or escalating. It lists all integrations available in the AU market with details on how they work.
📋 AU Ecosystem Directory — Confluence
Phones — first questions to ask
Establish whether the issue is with inbound calls, outbound calls, the webphone, the mobile app, or a phones configuration (call routing, IVR, business hours). Each has a different diagnostic path.
Issue typeIncoming · Outgoing · Webphone · Mobile app · Phone features / configuration
Affected numberWhich phone number is affected? Is it all numbers or one specific number?
Initiating from where?Contact drawer · Blue 'New' button · Mobile app · Webphone
Webphone activated?Confirm the webphone has been activated in settings before troubleshooting webphone issues.
Required information — Phones case
Phones Support Case — required fields
Issue type *
Incoming · Outgoing · Webphone · Mobile app · Phone features / config
Affected number *
The specific phone number affected, or confirm all numbers
Call example *
Screenshot of failed call or specific call example with timestamp
Call initiated from *
Where was the call initiated — contact drawer, New button, app, webphone?
Config change
If requesting an update or change — specify which Call Experience / configuration needs updating
Webphone activated?
Confirmed yes/no
Troubleshooting done *
Steps taken and outcomes — e.g. "Tested outbound call from contact drawer — call failed with no error message. Tested from New button — same result."
Common first troubleshooting steps — phones
- Confirm whether the issue is inbound, outbound, or both — test each direction
- Check whether the webphone has been activated in Admin settings
- Ask customer to try from a different browser and confirm browser version
- Have them clear browser cache and retry
- Get a screenshot or recording of what happens when the call fails — error message, dropped call, no audio
- Confirm whether the issue affects one user or all users — check if other team members can make/receive calls
- For mobile app issues — confirm device model and app version, ask them to update app if not current
Inbox — first questions to ask
Inbox issues are often scope-related — a problem affecting one conversation vs. all conversations, or one team member vs. all users, points to very different causes. Establish scope before you troubleshoot.
All contacts or limited?Is the issue affecting all conversations in inbox or only specific contacts / threads?
How was it initiated?Was the message inbound or outbound? Sent via bulk, automation, or manual send?
One user or all?Can other team members see/send messages normally? Isolates user-level vs. org-level issues.
Error messages?Any red banners, failed message indicators, or error codes visible in Podium?
Required information — Inbox case
Inbox Support Case — required fields
Scope *
All contacts / conversations or limited to specific ones?
How initiated *
Inbound or outbound? Manual send or automation?
Users affected *
One user, some users, or all users at the org?
Sample contacts *
Names and phone numbers of specific contacts where the issue occurred
Error messages
Any red banners or error codes visible — screenshot the full browser
Full browser screenshot *
Screenshot of the full Podium browser showing the issue — not cropped
Troubleshooting done *
Steps taken and outcomes
Common first troubleshooting steps — inbox
- Confirm scope — test with a specific contact and with a new contact to isolate the issue
- Ask the customer to clear browser cache and retry
- Try a different browser or incognito mode — rules out browser-specific issues
- For message deliverability issues — get specific contact names, numbers, and whether it's inbound or outbound. Note any error codes.
- Check if other team members can send/receive messages normally to rule out user-level permissions
Payments — first questions to ask
Payments issues need specific transaction details — vague descriptions of "payment not working" cannot be diagnosed without knowing how the payment was sent, who it was sent to, and what happened.
How was it sent?Through the Inbox or through the Payments page? Via payment request or Tap to Pay?
What failed?Payment failed · Not received · Stuck processing · Tap to Pay error
Customer detailsSpecific customer name and phone number for the failed transaction
Invoice linkLink to the specific invoice or payment request in Podium
Required information — Payments case
Payments Support Case — required fields
Payment method *
Payment request via Inbox · Payments page · Tap to Pay
Issue description *
What failed and what the customer saw — error message, stuck screen, not received
Customer name & number *
Specific customer the payment was attempted with
Invoice / link *
Link to the specific invoice or payment request in Podium
Screenshot / recording *
Full browser screenshot or screen recording showing the issue
Tap to Pay — device *
Mobile device model and app version. For Apple devices — has the Account Owner set up Tap to Pay on an Apple device?
Troubleshooting done *
Steps taken and outcomes
Common first troubleshooting steps — payments
- Confirm how the payment was sent — Inbox, Payments page, or Tap to Pay. Each has a different diagnostic path.
- Get a link to the specific invoice and review its status in Podium
- For Tap to Pay — confirm device model, app version, and ask to update app if not current
- For Tap to Pay on Apple — confirm the Account Owner has set up Tap to Pay on an Apple device first
- Ask for a screenshot or screen recording of the exact error — "Authorising" screen, error message, or what the customer sees
- Check if the issue is with a specific customer or all customers — test with a different contact if possible
Webchat — first questions to ask
Webchat issues usually come down to one of three things: the widget isn't appearing, messages aren't coming through, or the script isn't correctly installed. Establish which problem you're dealing with before troubleshooting.
Is the widget appearing?Can you see it on the website? Check whether the script is present in the site's source code.
What CMS?WordPress, Squarespace, Shopify, custom? Install process varies by platform.
URL in AdminIs the correct URL entered in Podium Admin? Common source of widget not appearing.
Messages stuck?Widget appears but messages aren't being received in Podium? Or customers can't send?
Required information — Webchat case
Webchat Support Case — required fields
Website URL *
The URL where the widget should appear
URL in Admin correct? *
Confirmed yes/no — does the URL in Podium Admin match the site URL?
Script in site code? *
Is the Podium script visible in the site's source code? Yes/no + screenshot
Widget set up in Podium? *
Confirmed the widget is configured in Podium Admin
CMS platform
WordPress, Shopify, Squarespace, custom, etc.
Issue description *
Widget not appearing · Messages not received · Messages stuck sending
Troubleshooting done *
Steps taken — e.g. removed and reinstalled script, cleared site cache, confirmed URL
Common first troubleshooting steps — webchat
- Check the URL is correctly entered in Podium Admin — exact match including http/https and trailing slashes
- Check the Podium script is present in the site's source code — view page source and search for "podium"
- Ask the customer to clear / purge their site cache — most common reason widget appears after script is added
- Try removing the script and reinstalling it — particularly if it was installed a while ago and stopped working
- Confirm the widget is configured in Podium Admin and is set to active
- For messages stuck sending — check whether the issue is specific to webchat conversations or also affecting SMS
Reviews — first questions to ask
Which review site?Google, Facebook, or other? Each has a different connection and permission structure.
Who is logged in?Which Podium user is logged in? Their permissions may affect what they can see or do.
Connected and reconnected?Has the review site been disconnected and reconnected recently? Has anything changed on the Google/Facebook side?
Required information — Reviews case
Reviews Support Case — required fields
Review platform *
Google · Facebook · Other — specify
Issue description *
Reviews not coming in · Invitation not sending · Disconnected · Review site not showing
Podium user *
Which user is logged in and experiencing the issue
Reconnected recently?
Has the review site been disconnected and reconnected? When?
Screenshot *
Full browser screenshot showing the current connection status
Troubleshooting done *
Steps taken and outcomes
Common first troubleshooting steps — reviews
- Disconnect and reconnect the review site — this resolves the majority of review connection issues
- Confirm the correct Google/Facebook account is being used to connect — must be an account with admin access to the business page
- For Facebook — check permissions on the Facebook Business Integrations page. Confirm the client has page access and all required permissions are enabled.
- Check whether the issue affects all users or just one — permissions vary by user role
- Confirm which Podium user is logged in and whether they have the correct role to manage review sites
Bulk messages — first questions to ask
Bulk message issues need specific details about how the message was set up and sent. Establish whether it's a marketing or standard bulk message, how the audience was built, and whether there were any error messages during or after sending.
Message typeMarketing message or standard bulk message? Each has different sending rules and opt-out requirements.
Audience methodCSV upload, tags, or other method? If CSV — get a copy.
What failed?Messages not sent · Some delivered, some not · Error during setup · Unsubscribes unexpected
How was it sent?Walk through the exact steps the customer followed to set up and send the message.
Required information — Bulk messages case
Bulk Messages Support Case — required fields
Message type *
Marketing message or standard bulk message?
Audience method *
CSV upload, tags, or other method?
CSV copy
Provide a copy of the CSV used if applicable
Sending process *
Describe exactly how the message was set up and sent — step by step
Issue description *
What happened — not sent, partial delivery, error message, unexpected opt-outs
Screenshot *
Full browser screenshot showing the bulk message send screen and any error messages
Sample contacts
Names and numbers of specific contacts who did or didn't receive the message
Troubleshooting done *
Steps taken and outcomes
Common first troubleshooting steps — bulk messages
- Confirm whether it's a marketing or standard bulk message — marketing messages have opt-in/opt-out rules that affect delivery
- Check how the audience was built — CSV, tags, or other. If CSV, review the file for formatting issues (missing numbers, incorrect format)
- Walk through the exact sending process step by step with the customer — errors often occur in setup rather than sending
- Check whether some contacts received the message and some didn't — partial delivery narrows the cause
- Confirm the contact numbers in the audience are correctly formatted with country code
- If unable to resolve — raise to TPS with the full template above including a copy of the CSV and sending process details
LeadDrive (Email Leads)
For Email Leads issues, the most common problems are the connected email being incorrect or the MX records not being configured properly.
LeadDrive — required fields
Connected email *
Is the correct email connected and pointing to the right source email?
To / from addresses *
Which email address do leads go to? Which address do they come from?
MX Toolbox result *
Run MX check at mxtoolbox.com and provide the results
Test form submitted?
Has a test lead been submitted via the client's contact form? What was the result?
Mobile App
Mobile App — required fields
Platform *
iOS or Android
Device model *
Specific device — e.g. Samsung Galaxy S22, iPhone 14
App version *
Current app version — confirm it is up to date before troubleshooting
Issue description *
What is happening and when — crash, feature not working, login issue
Facebook & Instagram
Facebook & Instagram — required fields
Permissions *
Check permissions on the Facebook Business Integrations page — all required permissions allowed?
Page access *
Does the client have admin access to the Facebook/Instagram page?
Error screenshots *
Screenshots of the permissions page and any error messages shown
Reporting
For reporting issues, first establish whether the problem affects this user only or all users for the org/location. User-level vs. org-level issues have different causes and solutions.
05
Tiering and escalation
▶
Stage 1 — First contact (any L1 rep)
Any rep handles the engagement live regardless of pod. If resolved, close it. If not, the case moves to Salesforce and pod ownership applies — reassign to the correct pod L1 rep if outside your pod.
Stage 2 — Pod L1 ownership
End-to-end ownership. The pod L1 rep owns the ticket from assignment — all customer comms, escalation decisions, and closure.
Pod assist. More experienced pod members help and coach — they do not take over the ticket. Every assist is a coaching moment to build the L1 rep's skills.
Stage 3 — TPS
L1 owner raises a Jira to TPS when unresolvable within the pod. Case status moves to "pending backline assistance."
TPS investigates with L1 — bug, fixable, or knowledge gap? TPS resolves (target state). Engineering escalation is the exception, not the default.
The two-day rule — no exceptionsAny ticket pending backline assistance must have a customer-facing update within the last two days. The pod L1 owner is responsible for this — even while TPS or engineering holds the ticket.
06
Case hygiene standards
▶
Do this on every new ticket before anything else.
Subject line
Rewrite the subject to clearly describe the issue. Anyone reading it should know what the case is about without opening it — enables trend tracking and searching.
❌ Vague"Inbox not working" · "Help needed" · "Issue with payments"
✓ Specific"Inbox — Inbound SMS messages delayed and taking a long time to appear in inbox." · "Payments — Tap to pay not working after iOS update"
Taxonomy — product, component, reason — all three, every time
ProductThe Podium product — Inbox, Payments, Web Chat, Phones, AI, Automations.
ComponentThe specific feature — Message routing, Card reader, Review requests, Call recording.
ReasonNature of ticket — This will usually be Issue, Question/Training or Update/Change.
Org assignment
Confirm the case is assigned to the correct Org before progressing. If missing or incorrect, fix it first.
TRT countdown — target 72 hours
Resolution is always the priority. The target is 72 hours. If a case cannot be resolved within that window — complex investigation, pending backline, or customer going quiet — continue pushing for resolution beyond 72 hours rather than closing prematurely. The 72-hour target is a resolution target, not a deadline to close.
Cases pending backline still have TRT running. Keep pushing TPS for movement and keep the customer updated. If a customer goes quiet, follow the non-responsive process (section 07) before considering closure.
Case notes
Post notes after every significant action. Write as if someone else needs to pick this up tomorrow: what was reported → what was tried → what was found → what was communicated → next step and owner.
Knowledge base
Search the KB before composing any response from memory. If an article is missing or outdated, request it.
# cx_helpcenter_requests
New ticket checklist
- Subject updated — clearly describes the issue
- Product, component, and reason all set correctly
- Description updated if it doesn't reflect the actual issue
- Case assigned to the correct Org
- TRT countdown checked and factored into prioritisation
- Case notes posted after every significant action
- KB searched — update requested in #cx_helpcenter_requests if needed
07
Non-responsive customers
▶
A case cannot be closed as customer non-responsive without at least two documented call attempts — minimum four hours apart — in the case notes.An email must be sent after any call that isn't answered, or where the rep was unable to reach the right contact.
The process
1
Call attempt 1 — no answer or wrong contact Send a follow-up email immediately. Explain what you need and why. Ask for a good time to call. Log in case notes with time and outcome. If you reached someone but not the right contact, note who you spoke to and send the email to the correct contact.
1b
Call attempt 1 — connected with right contact Explain what you need and why. Follow up with an email that summarises the call and makes it easy for the customer to send what's needed.
2
Wait at least four hours. Give the customer time to finish what they were doing and come back to you. Two calls close together do not count as two genuine attempts.
3
Call attempt 2 — no answer or wrong contact Send a second follow-up email. Log in case notes with time and outcome.
4
Final email — AM looped in AM required Let the customer know the case will be temporarily closed. CC the AM on this email. Post in #au-support-escalations using the AM Escalation from Support Workflow.
5
Close as customer non-responsive Only after all above steps are complete and documented.
Email templates
After call — no answer
Missed call follow-up
Hi [name],
I just tried to reach you by phone but wasn't able to connect.
I'm following up on your case regarding [brief issue description]. To help us get this resolved as quickly as possible, we need:
[List exactly what is needed — be specific and simple]
If you could reply to this email or let me know a good time to call, that would be great.
[Your name]
I just tried to reach you by phone but wasn't able to connect.
I'm following up on your case regarding [brief issue description]. To help us get this resolved as quickly as possible, we need:
[List exactly what is needed — be specific and simple]
If you could reply to this email or let me know a good time to call, that would be great.
[Your name]
After connected call
Post-call follow-up
Hi [name],
Thanks for taking my call. As discussed, to help us investigate, could you please send through:
[List exactly what was discussed on the call]
You can reply directly to this email with the information attached. Once we have it, we'll pick this straight back up.
[Your name]
Thanks for taking my call. As discussed, to help us investigate, could you please send through:
[List exactly what was discussed on the call]
You can reply directly to this email with the information attached. Once we have it, we'll pick this straight back up.
[Your name]
Temporary closure CC the AM
Final email — AM looped in
Hi [name],
I've tried to reach you a couple of times over the past few days but haven't been able to connect.
If you're still experiencing [brief issue description], please send through some more details and recent examples, or let me know a good time to call.
I'll temporarily close this ticket, but please reach out when you have time to help us troubleshoot this issue. Replying to this email will reopen the ticket and allow us to keep investigating.
I've copied in [AM name] so they're across this as well.
[Your name]
I've tried to reach you a couple of times over the past few days but haven't been able to connect.
If you're still experiencing [brief issue description], please send through some more details and recent examples, or let me know a good time to call.
I'll temporarily close this ticket, but please reach out when you have time to help us troubleshoot this issue. Replying to this email will reopen the ticket and allow us to keep investigating.
I've copied in [AM name] so they're across this as well.
[Your name]
08
Pending backline — customer update standards
▶
Every two-day update serves two purposes: keeping the customer informed, and collecting fresh examples that help the investigation. Updates must not feel tokenistic.
Every update must include
1
Acknowledgement of progress — team is actively investigating. Be specific where possible.
2
Request for fresh examples — screenshots, recordings, or a description of the latest occurrence. Read the customer — skip if they're fatigued by the ask.
3
Clear next step or timeline — give the customer something to hold on to.
Templates by customer tone
Cooperative
Cooperative customer
Hi [name],
Just wanted to reach out with a quick update — our team is still actively investigating your case and working toward a resolution. I appreciate your patience while we work through this.
If you've experienced the issue again since we last spoke, it would be really helpful to have a fresh example to pass on to the team. Even a quick screenshot, a screen recording, or a description of exactly what happened and when can make a real difference.
I'll be back in touch by [date]. Feel free to reach out if anything changes.
[Your name]
Just wanted to reach out with a quick update — our team is still actively investigating your case and working toward a resolution. I appreciate your patience while we work through this.
If you've experienced the issue again since we last spoke, it would be really helpful to have a fresh example to pass on to the team. Even a quick screenshot, a screen recording, or a description of exactly what happened and when can make a real difference.
I'll be back in touch by [date]. Feel free to reach out if anything changes.
[Your name]
Frustrated — skip the examples request
Frustrated customer
Hi [name],
I wanted to check in and make sure you know this hasn't been forgotten. I understand this has been open for a while and I genuinely appreciate your patience.
Our team has everything they need and are continuing to work through it. I'll make sure you're the first to know as soon as we have something to share.
I'll follow up again by [date].
[Your name]
I wanted to check in and make sure you know this hasn't been forgotten. I understand this has been open for a while and I genuinely appreciate your patience.
Our team has everything they need and are continuing to work through it. I'll make sure you're the first to know as soon as we have something to share.
I'll follow up again by [date].
[Your name]
Unresponsive
Unresponsive customer
Hi [name],
Just a quick update to let you know we're still working on your case — I didn't want you to think it had slipped through the cracks.
If the issue has cropped up again and you have a moment to send through a fresh example, that would be great — having fresh examples will help our team keep working on the resolution.
If this has resolved itself on your end or is something you'd like to come back to at a later date, just let me know.
[Your name]
Just a quick update to let you know we're still working on your case — I didn't want you to think it had slipped through the cracks.
If the issue has cropped up again and you have a moment to send through a fresh example, that would be great — having fresh examples will help our team keep working on the resolution.
If this has resolved itself on your end or is something you'd like to come back to at a later date, just let me know.
[Your name]
After three unanswered updates: flag to your team lead for a ticket status review.
09
Duplicate case handling
▶
A duplicate case handled incorrectly creates confusion for the customer, the active case owner, and reporting. The approach depends on whether you can resolve the issue during the live engagement.
Scenario 1 — you resolve the issue on the live engagement
If you resolve the issue for the customer during your live engagement, assign all previous active cases for the same issue to yourself and close the additional ones as duplicates. You worked it, you own it.
Scenario 2 — you cannot resolve it on the live engagement
If you cannot resolve the issue, reassign the case to the rep who holds the existing active ticket. It is then that person's responsibility — as the owner of the active case — to close all duplicate tickets. You should never close other tickets as duplicates if you are not the one working the active case.
Only the active case owner closes duplicates. If you are not working the active case, do not close other tickets as duplicates. Reassign to the active case owner and tag them — they take it from there.
If the previous case is closed
If the previous case is closed, your case is not a duplicate — it is a new active case. Treat it as brand new: get fresh examples, troubleshoot it properly from scratch, and own it end to end. Do not close it as a duplicate of a closed case.
The process — when closing duplicates as the active case owner
1
Confirm you are the active case owner — only proceed with closing duplicates if you hold the active case.
2
Tag the rep who identified the duplicate in a Salesforce post — acknowledge receipt and include any new information or examples they passed on.
3
Update the subject line of each duplicate to:
DUP: [Subject of original ticket]4
Set the taxonomy — all three fields required:
Product: Internal · Component: Case Update · Reason: Update/Change
Product: Internal · Component: Case Update · Reason: Update/Change
5
Close as duplicate — not as resolved. The closure reason must be Duplicate, not Resolved.
Taxonomy for duplicate cases
Required fields when closing as duplicate
Subject *
DUP: [Subject of the original active ticket]E.g. "DUP: Inbox — Inbound SMS messages delayed and taking a long time to appear in inbox."
Product *
Internal
Component *
Case Update
Reason *
Update/Change
Closure reason *
Duplicate — never Resolved
Assigned to *
The rep working the active case — not the rep who identified the duplicate
What not to do
✓ DoResolve on live engagement and close duplicates yourself if you fixed it · Reassign to active case owner if you couldn't resolve it · Only close duplicates if you own the active case · Tag the identifying rep in a SF post · Use DUP: prefix in subject · Close as Duplicate not Resolved · Treat a closed previous case as a new active case
✗ Don'tClose other reps' tickets as duplicates if you're not working the active case · Leave a duplicate untagged and unassigned · Close as Resolved instead of Duplicate · Close as a duplicate of a closed case · Skip the taxonomy update · Fail to pass on new examples the customer provided
10
Jira escalation standards
▶
TPS must be able to open the Jira and begin investigating immediately — without going back to Salesforce, without messaging you, without any additional context. The SF case links automatically when the Jira is associated. Everything else must be in the Jira.
A summary is not enough.Full picture required: what's happening, who it's happening to, what's been tried, and what TPS needs to identify or reproduce the issue.
Required fields
TPS Escalation Jira — required structure
Summary *
Specific one-liner matching the SF subjectE.g. "Inbox — Inbound SMS messages delayed and taking a long time to appear in inbox. | Org: [Name]"
Customer / Org *
Org name, account ID, contact detailsFull org name, SF Org ID, affected customer name and contact.
Issue description *
Full plain-language descriptionWrite as if TPS has never seen the case. Consistent or intermittent? All users or specific ones? When did it start?
Business impact *
How it's affecting the customer day-to-dayBlocking workflow? Revenue impact? Multiple users? Urgency and severity must be clear.
Steps to reproduce *
Numbered exact steps TPS can followInclude settings and conditions required. If can't reproduce, list known triggers.
Troubleshooting done *
Everything already tried — with outcomesDo not make TPS repeat your work. Every step attempted, what was ruled out, what was found.
Examples *
Specific timestamped instancesMessage IDs, contact names, timestamps, transaction IDs. Attach screenshots and recordings directly.
Expected vs actual *
What should happen vs what is happeningClearly state correct behaviour and exactly how current behaviour differs.
Environment / config
Integrations, automations, plan tier, device/OS if relevant
Attachments
Screenshots, recordings, logs, error messages — attached here, not referenced elsewhere
✓ DoSpecific IDs, timestamps, contact names. Numbered troubleshooting steps with outcomes. Attachments directly in Jira. Written so a new TPS team member can action it immediately.
✗ Don't"See SF case for details." Submitting without examples. One or two sentence descriptions. Steps without outcomes. Vague impact. "Intermittent" without specific instances.
Self-check before submittingRead it as a TPS engineer seeing this for the first time. Can you understand the issue, find the examples, and start investigating without any additional context? If no — it's not ready.
11
Daily expectations
▶
Omni time — scheduled on-channel availability
Inbound engagements take absolute priority. Two non-negotiables: volume up, Omni visible on a second screen at all times.
✓ Expected during Omni downtimeRespond to customer emails · Review and update open cases · Check for notes from TPS or pod · Progress any ticket with actionable next steps
❌ Not acceptableMissing an inbound engagement because of case work · Volume off or Omni not visible · Sitting idle
Case management time — scheduled daily
Scheduled daily for every rep. Amount varies by pod — pods with more investigative work have a higher allocation. Not optional, not overflow time.
End of day standard
Two non-negotiables at end of every day1. Zero cases in New or In Progress not touched today.
2. Zero cases pending customer response for more than two days without a documented call attempt.
2. Zero cases pending customer response for more than two days without a documented call attempt.
Daily queue review — every ticket, every day
- New emails or messages from customer — action or acknowledge same day
- Notes or updates from TPS, pod, or AM — review and respond if needed
- Pending customer response — call attempt documented within last two days? If not, call now
- Awaiting internal help — tag the relevant person and ask for a status update
- Ticket status and notes current and accurate
Extreme ownership
TPS updatesTag directly if a Jira has no movement. Don't wait.
AM updatesTag on credit and retention cases. Know where things stand.
Pod helpAsk early. Expected behaviour, not a weakness.
Customer updatesDon't wait for them to chase. Proactive comms is part of the job.
12
SLAs and response standards
▶
Priority
Definition
First response
Resolution target
P1
Critical — service down or data loss
1 hour
4 hours
P2
Major feature impaired, business impact
4 hours
1 business day
P3
Non-critical, workaround available, general enquiry or feature request
1 business day
3 business days
Priority is determined by business impact — not by customer tone or urgency of language. SLA breaches trigger a post-mortem.
13
Slack, adherence and availability
▶
Slack — active for the full duration of your shift
For the entire duration of your shift you are expected to be active and responsive on Slack. Messages are seen, tags are actioned, and you are reachable by your pod, TPS, and team lead. A missed tag can slow down a resolution for your customer.
✓ On shift — no status neededAvailable and responsive. Checking Slack regularly alongside your case and Omni work.
⚠ On break or lunchUpdate your Slack status. No status = available. If you're not reachable, the team needs to know.
Stepping away brieflySet a status if you'll be more than a few minutes. Over-communicate availability rather than leave the team guessing.
Getting help via Slack
Post in the AU support troubleshooting channel for help from team members across pods. Search the channel first — your issue may already have been solved.
# au-support-troubleshooting
# cx_helpcenter_requests
Acknowledging team updates
When updates or announcements are shared in team channels, acknowledge them with a ✅, 👍, or relevant emoji. There is no wrong way to acknowledge — the only wrong response is none at all.
Omni adherence — 85% target
0%Target: 85% of rostered Omni time100%
Adherence is a team metric. When one rep is offline during rostered Omni time it affects queue coverage for everyone. Be logged in at the start of your window, manage breaks within allocated times, and flag schedule issues to your team lead in advance — not after the fact.
14
Quality assurance
▶
QA is not about catching reps out — it is about making sure every customer gets a great experience and every rep has the support they need to keep improving.
Case audits — random, without notice
Any case — open or closed — may be reviewed at any time. Every case should be handled as if it will be audited. The best preparation is consistent practice.
Audits are not punitive. A flagged case becomes a coaching conversation, not a disciplinary one. Auditors look for: resolution quality, clarity of communication, correct escalation steps, and accurate case notes.
CSAT scores
When a case is marked resolved, the customer receives a satisfaction survey. Scores are reviewed at team and individual level. Low scores are discussed in one-on-ones — with context, not defensiveness.
Pod training sessions
New features & product updatesShared before customers see them. Stay ahead of your queue.
Troubleshooting techniquesNew ways to diagnose and resolve issues in your pod's area.
Case coachingWork through difficult case types together with experienced team members.
Training is also a space to surface patterns — types of questions you don't have good answers to, issues you're noticing in your queue. Raise them.
One-on-ones with your team lead
Bring your hard cases. One-on-ones are working sessions — not just check-ins. Your team lead will help you work through difficult tickets, review CSAT scores, and discuss queue health.
One-on-ones cover: CSAT scores, any audit findings, queue health, and direct case assistance. Use them proactively — before a difficult case becomes a problem for the customer.
15
AM relationship & customer comms ownership
▶
Default rule — support owns all customer communicationThe rep manages all customer contact on their cases from open to close. The AM assists where their involvement adds value — not as a substitute for the rep engaging directly. Looping in the AM is not a way to offload a difficult case.
Who handles what
Situation
What the rep does
AM involvement
Standard troubleshootingBug, error, feature not working
Handle end to end — diagnose, communicate, escalate to TPS if needed
Rep only
Reconnecting integrations / reconfiguring call routing
Provide step-by-step instructions. Offer to walk through it live on a call
Rep only
Complex setup — best practice guidance needed
Handle the technical how-to. Flag to AM for best practice and strategic input. Post in #au-support-escalations.
Loop in AM + Slack
Credit request
Acknowledge, loop AM into email, post in #au-support-escalations
AM owns + Slack
Cancellation request
Acknowledge. Convert to retention case. Email customer looping in AM. Post in #au-support-escalations
AM owns + Slack
No Contact Needed flag
Work the case — no outbound customer contact. Document thoroughly. Post in #au-support-escalations.
Tag AM + Slack
No Contact Needed — what this means
When a case is marked "No Contact Needed," the rep does not reach out to the customer. All updates go into the case notes. Tag the AM so they are across it — they are the customer's point of contact for this case.
Do not apply this flag yourself. It reflects an existing agreement between the AM and the customer, not a workaround for a case that feels hard to reach.
Customer requests to speak to their AM
If a customer asks to speak to or be contacted by their account manager, acknowledge the request, let them know their AM will be in touch, and post in #au-support-escalations using the AM Escalation from Support Workflow. The AM will then follow up directly with the customer.
📣 #au-support-escalations
Self-serve guidance — rep's job, not AM's
When a customer needs to reconnect an integration or reconfigure call routing, provide step-by-step instructions and offer to walk them through it live. This is a support task.
Only loop in the AM when the question goes beyond technical how-to and into how the customer should use the product strategically for their business.
The distinction in plain terms"How do I reconnect my CRM integration?" → Rep answers it.
"How should I structure my integrations across five locations?" → Rep handles the how-to, AM brought in for the strategic layer.
"How should I structure my integrations across five locations?" → Rep handles the how-to, AM brought in for the strategic layer.
Credits — acknowledge, loop in the AM, and follow up
Support never comments on, promises, or processes credits — no exceptions.No opinion, no amount, no likelihood. The AM owns it from the moment they are looped in.
Acknowledge receipt and loop the AM into the email thread. Do not just assign and walk away — follow up with the AM to make sure they have been in touch with the customer before you close the ticket out.
Post in #au-support-escalations using the AM Escalation from Support Workflow to notify the AM and create a record of the handoff.
📣 #au-support-escalations
Move the case to Waiting on Internal Party while the AM is handling it. Check the case daily and ask the AM for an update — do not let it sit unattended.
Only close the ticket once the AM has followed up with the customer. You are responsible for making sure the handoff is complete, not just initiated.
Cancellation requests — retention case process
1
Acknowledge — confirm received, without confirming cancellation is underway.
2
Convert to a retention case in Salesforce — not a standard support case.
3
Email the customer looping in the AM. Support hands over the conversation — do not continue it.
4
Post in #au-support-escalations using the AM Escalation from Support Workflow. This notifies the AM and logs the escalation.
📣 #au-support-escalations
📣 #au-support-escalations
5
AM takes the retention call. All negotiation, offers, and outcome managed by the AM.
16
Metrics and reporting
▶
Metric
What it measures
CSAT
Post-resolution customer satisfaction. Reviewed weekly at team and individual level.
First reply time
Time to first meaningful reply, tracked per priority tier.
Resolution rate
% resolved vs escalated. Identifies L1 capability gaps.
Pod reassignment rate
% of cases reassigned post-engagement. Rising rate signals routing or training gaps.
Retention case volume
Cancellation requests routed to AMs — tracked as a churn signal.
Repeat contact rate
% contacting again within 7 days. High rate = poor resolution quality.
Two-day update compliance
% of pending backline tickets with a customer update in the last 48 hours.
Omni adherence
% of rostered Omni time actually available. Target: 85%.
17
Incident and outage response
▶
A clear threshold exists for declaring an incident — volume of reports, error rates, or severity of impact.
Support owns the customer-facing status page. Updated within 10 minutes of incident declaration.
During an incident, incoming tickets are triaged but not resolved individually — linked to the incident.
After resolution, affected customers receive a summary and what was done to prevent recurrence.