How to Build a Support Handoff for a Two-Person Team

A good support handoff answers five questions:

1. Who owns the inbox now?
2. Which customers are still waiting?
3. What has already been tried or promised?
4. What must happen next, and when?
5. What requires help from the other person?

For a two-person team, that is usually enough. You do not need an enterprise workflow. You need one visible owner, a shared queue, consistent ticket notes, and a short transfer routine.

Give the inbox one owner at a time

Assign one person as the primary support owner for a defined period. The other person remains available for escalation but does not routinely work the same queue.

This avoids two common problems:

• Both people assume the other will answer.
• Both people begin answering the same customer.

Google’s Site Reliability Engineering guidance uses a similar principle for operational interruptions: one primary engineer owns the work and escalates when necessary. Google says this reduces interruptions across the team and helps avoid the bystander effect. Although customer support is not the same as production incident response, the ownership principle transfers well to a small support team. (Google SRE: Dealing with Interrupts)

Your ownership schedule might be:

• One person per day
• Alternate mornings and afternoons
• One person per week
• Fixed days based on development schedules

Choose the longest shift that still fits your ticket volume. Switching every hour creates unnecessary coordination. A daily or half-day rotation is often easier to understand.

Write the current owner somewhere both people already look, such as the shared inbox description, team calendar, or pinned internal note.

Define what ownership includes

“In charge of support” is too vague. Agree on the responsibilities attached to the role.

The primary owner should normally:

• Check all supported channels
• Triage new messages
• Send routine replies
• Keep ticket status and internal notes current
• Escalate issues that meet agreed criteria
• Prepare the next handoff

The backup should normally:

• Respond when explicitly tagged
• Help with technical investigation or sensitive replies
• Cover planned breaks or unexpected absence
• Avoid taking unassigned tickets silently

If the backup needs to take over a ticket, ownership should be changed visibly. A private message such as “I’ll handle this” is easy to miss later.

Use a small set of ticket states

A two-person team rarely needs a complicated taxonomy. Start with four states:

| State | Meaning | |---|---| | New | No one has reviewed the message | | In progress | The current owner is investigating or drafting | | Waiting on customer | The customer must provide information or confirm something | | Waiting on us | The team owes an answer, fix, refund decision, or other action |

Add Resolved when no further action is expected.

The important distinction is between “waiting on customer” and “waiting on us.” A generic pending state can hide who must act next.

If your support tool cannot create custom states, use tags such as customer-reply-needed, engineering-check, or follow-up-date, but keep the list short and document what each tag means.

Agree on priorities before a difficult ticket arrives

Priority should reflect customer impact and required response, not how forcefully a message is written.

A simple model is:

• Urgent: A security concern, suspected data loss, widespread outage, or customer unable to use a critical paid function
• High: A serious problem affecting one customer, a billing error, or a time-sensitive account issue
• Normal: A standard bug report, product question, or configuration problem
• Low: Feedback, feature requests, and non-blocking suggestions

Decide what each priority changes. For example, urgent tickets may require an immediate interruption and direct notification to the backup. Normal tickets can remain with the scheduled owner.

Do not promise 24/7 coverage unless the team can reliably provide it. Publish response expectations that match the hours and capacity you actually have.

Record context inside the ticket

The next person should not have to reconstruct the case from chat messages, memory, or a long email thread.

For any unresolved ticket, leave an internal note containing:

Issue:
Customer impact:
What we know:
What has been tried:
What we told the customer:
Next action:
Owner:
Follow-up time:
Relevant links:

Keep the note factual and compact. Record uncertainty explicitly:

Cause is not confirmed. The failure started after the customer
changed their DNS settings, but we have not shown that the change
caused the problem.

This is more useful than presenting a guess as a conclusion.

Always capture commitments. If someone told a customer, “We will update you by Thursday,” that promise belongs in the handoff even when there is no technical progress.

Use a fixed handoff routine

At the agreed transfer time, the outgoing owner should:

1. Clear or classify every new message.
2. Update the state of each open ticket.
3. Add notes to tickets that cannot be understood from the customer-visible thread.
4. Highlight deadlines, promises, and urgent risks.
5. Transfer ownership visibly.
6. Send a short handoff summary.
7. Have the incoming owner acknowledge receipt.

Google’s SRE Workbook describes a comparable practice: the incoming on-call engineer reads the previous handoff, while the outgoing engineer sends a handoff at the end of the shift. It also recommends keeping response guidance in maintained playbooks. (Google SRE Workbook: On-Call)

The acknowledgment can be as simple as “Received; I own the queue now.” Its purpose is to remove ambiguity, not create ceremony.

Keep the summary focused on exceptions

The shared inbox should remain the source of truth. The handoff message should point out what needs special attention rather than duplicate the entire queue.

A practical summary looks like this:

Support handoff — Tuesday, 17:00

Queue owner: Morgan → Sam

Needs action:
- T-184: Customer cannot export invoices. Logs are attached.
  Sam to reproduce before 10:00 Wednesday.
- T-191: Refund request needs Morgan’s approval.
  Customer was promised an update by Wednesday afternoon.

Waiting on customers:
- T-177: Asked for browser version and screen recording.
- T-180: Asked customer to confirm whether the workaround helped.

Watch item:
- Three reports of delayed notification emails today.
  No confirmed common cause yet.

No other urgent or overdue tickets.

Notice what the summary does not contain: complete conversations, speculative diagnoses, or a list of every resolved message.

Define escalation rules

The primary owner should know when to involve the second person without debating it during each case.

Escalation may be appropriate when:

• There may be a security or privacy issue
• Data could be lost or exposed
• Several customers report the same failure
• A customer is completely blocked
• A refund, credit, or contract decision exceeds the owner’s authority
• The response deadline is at risk
• The issue remains stuck after an agreed investigation limit
• The customer is threatening legal action or making a formal complaint

For urgent operational problems, use a channel that actively notifies the backup. Do not rely only on a tag that nobody may see until later.

Clear escalation paths and defined incident procedures are among the resources Google identifies as important for reducing stress during on-call work. (Google SRE: Being On-Call)

Create short playbooks for repeated situations

When the same type of ticket appears several times, document the response process.

A useful playbook can be brief:

Problem: Password-reset email has not arrived

Check:
1. Confirm the email address on the account.
2. Check email delivery status.
3. Ask the customer to inspect spam and filtering rules.
4. Confirm whether they requested multiple reset links.

Escalate when:
- Delivery records show repeated failures.
- Several customers report the problem.
- Account ownership is disputed.

Reply requirements:
- Do not reveal whether an unrelated email address has an account.
- Explain that only the newest reset link is valid.

Reusable replies can also reduce repetitive typing, provided that the owner checks and adapts them before sending. GitHub, for example, documents saved replies as reusable responses for recurring issue and pull-request conversations. (GitHub Docs: About saved replies)

The same review principle applies to AI-generated drafts. In SupportMe’s documented workflow, a draft is created from the connected channel and knowledge base, but a person reviews, edits, or rejects it before anything is sent. For a two-person handoff, the draft can save writing time, while the ticket owner remains responsible for accuracy, promises, and final approval.

Handle tickets that cross several shifts

Do not force every open case to change hands. Some complex tickets are better kept by one person, especially when that person has already developed substantial context.

Use two distinct concepts:

• Queue owner: Responsible for new messages and general coverage
• Case owner: Responsible for a particular ongoing ticket

A case can remain with its original owner across several queue rotations. The current queue owner still monitors it for new customer replies and alerts the case owner when action is needed.

If the case owner will be unavailable, perform a full transfer. The incoming owner should receive the current evidence, decisions, commitments, next step, and relevant technical links.

Prepare for absence and overlap

A two-person system is fragile if it assumes both people are always available.

Agree in advance on:

• Who announces a planned absence
• How queue ownership changes
• Which tickets must be transferred before leave
• What happens when the backup is also unavailable
• Whether support is paused, reduced, or covered externally
• Which customer-facing response expectations need updating

If both people are available during a short overlap, reserve five minutes for questions about unusual tickets. Routine cases should not require a meeting.

Review the workflow using simple evidence

Once a week or once every two weeks, inspect a small set of operational signals:

• Tickets that had no clear owner
• Duplicate or conflicting replies
• Missed follow-up dates
• Customer promises not recorded internally
• Tickets transferred without enough context
• Issues repeatedly escalated for the same reason
• Common questions that need a playbook or documentation update

This is not an employee scorecard. It is a way to find weaknesses in the workflow.

Google’s SRE guidance recommends examining significant incidents through blameless postmortems focused on events, contributing conditions, and corrective actions rather than individual blame. A two-person support team can apply the same principle on a smaller scale: improve the state, note, playbook, or escalation rule that allowed the mistake. (Google SRE: Being On-Call)

A minimum viable handoff checklist

A two-person team can begin with this checklist:

Before handoff
[ ] Every new message has been reviewed
[ ] Every unresolved ticket has a clear state
[ ] Every ticket waiting on the team has an owner
[ ] Promised follow-up dates are recorded
[ ] Unusual cases contain a current internal note
[ ] Urgent issues were escalated directly
[ ] The handoff summary lists only actionable exceptions

After handoff
[ ] The incoming owner acknowledges the transfer
[ ] The shared queue shows the new owner
[ ] Any unclear ticket is discussed immediately

References

• Google SRE Book: Dealing with Interrupts
• Google SRE Book: Being On-Call
• Google SRE Workbook: On-Call
• GitHub Docs: About saved replies

Conclusion

A reliable support handoff does not require complex software or constant meetings. Give the queue one visible owner, use a few unambiguous states, record unresolved context inside each ticket, and transfer deadlines and promises explicitly. For a two-person team, consistency matters more than sophistication.