1. Purpose
This document defines the Salesforce Support Model used by Merfantz to manage customer support cases — the queues, fields, and process flow from case creation to closure.
Goal: No case should be missed, unattended, or delayed without visibility.
2. Queues
| Queue | Purpose |
|---|---|
| Admin Cases | Administrative/internal requests |
| Customer Support | General customer issues and queries |
| Business System | Business system related requests |
| Professional Services-SA | Standard Account Paid service engagements |
| Professional Services-GA | Growth Account Paid service engagements |
| Merfantz Lab | R&D / internal lab requests |
| HR | HR-related cases |
| Sales | Sales-related requests |
| Marketing | Marketing-related requests |
| Helpdesk | General helpdesk queries |
3. Case Fields & Purpose
| Field | Purpose |
|---|---|
| Queue | Identifies the team responsible for the case |
| Assigned To | Individual accountable for progressing the case |
| Support Tier | Indicates complexity/type of support needed (see Section 4) |
| Case Type | Classifies the nature of the request (Issue / Question / Feature Request / Amendment) |
| Priority | High / Medium / Low — drives SLA and escalation |
| Tentative Due Date | Initial estimated completion date, set by the assigned person before scrum discussion |
| Due Date | Final committed completion date, confirmed by PM in scrum; includes QA buffer time |
| Status | Current stage of the case in its lifecycle (see Section 5) |
| Case Comments | Running log of the latest updates/communication on the case |
| Estimated Hours | Initial effort estimate |
| Dev Spent Hours | Actual development hours logged by the Dev team at closure |
| QA Spent Hours | Actual QA hours logged by the QA team at closure |
| Billing Hours | Final billable hours, updated at closure |
4. Support Tiers & SLA
| Tier | Definition | SLA |
|---|---|---|
| Tier 0 | Admin cases | |
| Tier 1 | Query-related | Must be resolved and closed within 4 hours of case creation. |
| Tier 2 | Small Fixes | Must be resolved and closed within 8 hours of case creation. |
| Tier 3 | Feature development | Must be acknowledged with the first response within 4 hours of case creation. The case must then be regularly updated with the Estimated Effort, Tentative Due Date, and Due Date. |
5. Case Status Lifecycle
| Status | When to Use |
|---|---|
| New | Case created, not yet started; also the status immediately after assignment |
| In Progress | Change from New only when work actually begins |
| Testing | Case moved to QA for validation |
| Waiting for Response | Awaiting input/confirmation from customer |
| Escalated | SLA breached or requires higher-level attention |
| On Hold | Paused for a valid, documented business reason |
| Re Open | Case reopened when response received from the customer for input/confirmation |
| Testing Completed | After QA completed their testing in Sandbox/Production |
| Closed | All closure requirements met (Section 8) |
6. Support Process Flow
Step 1 — Case Intake Case is received via customer email, website form, or job inquiry.
Step 2 — Review & Assignment Customer Support team reviews the case and assigns it to the respective Queue/team. Case status is set to New.
Step 3 — Initial Analysis The assigned person analyzes the case and sets the Tentative Due Date & Updae the Estimated Hours.
Step 4 — Scrum Review PM reviews the case in scrum and confirms the final Due Date, including QA buffer time.
- Due Date changes require proper approval — it should not be changed without sign-off.
Step 5 — Work Begins Status is changed from New to In Progress only when work actually starts. All updates are logged in Case Comments as they happen.
Step 6 — Handover to QA Case moves to Testing with adequate buffer time before the Due Date.
Step 7 — Delivery to Customer Resolution is delivered to the customer. Reply/communication must correctly and completely address the customer’s request.
Step 8 — Closure Before closing a case:
- Dev team updates Dev Spent Hours
- QA team updates QA Spent Hours (After Completion of Testing)
- Dev team updates Estimated Hours
- Billing Hours is updated
Case is moved to Closed only after all the above are completed.
7. Escalation Rules
| Condition | Action |
|---|---|
| Case remains New and unassigned beyond 8 hours | Auto-escalate |
| Due Date changed | Notify PM and Project Owner |
| No activity beyond defined threshold | Notify owner → escalate to Team Lead |
| SLA breached / case overdue | Escalate to Support Management |
8. Waiting for Response — Follow-up & Closure
| Environment | Rule |
|---|---|
| Sandbox | 3 follow-ups at 3 working-day intervals; no response after 3rd → case may be closed |
| Production | Completion email sent after deployment; no response in 3 working days → case closed, billing hours recorded |
9. Code Review & Release Notes (Mandatory)
- Tier 2 and Tier 3 developments must undergo a code review before deployment.
- Tier 2 and Tier 3 developments must have Release Notes prepared and updated as part of the release process.
10. Closure Checklist (Mandatory)
- [ ] Final Resolution documented
- [ ] Estimated Hours recorded
- [ ] Dev Spent Hours recorded
- [ ] QA Spent Hours recorded
- [ ] Billing Hours recorded
- [ ] Correct closure status/reason selected
- [ ] Required customer communication completed