Why the timezone is the whole argument, and what to screen for beyond English

For a US East Coast company, CEE support covers the morning before your own team is awake. A ticket raised at 6am is answered by 7. That is the argument, and it is a better one than cost. Screen for written English and product curiosity, not for accent or scripts.
For a US East Coast company, CEE support covers the morning before your own team is awake. A ticket raised at 6am Eastern is answered by 7. That is the argument, and it is a better one than cost.
Support is the role where geography does the most work, and Latvia, Lithuania and Poland happen to sit in a useful place relative to the US East Coast.
CEE runs six to seven hours ahead of US Eastern.
A support person starting at 9am in Riga is online at 2am Eastern. By the time your US team logs on, they have worked most of a day. The overnight queue is cleared, the easy tickets are closed, and what remains has been triaged.
Then their afternoon overlaps your morning. Three to four hours where both sides are working - enough for real handover, escalation, and the conversations that stop the same question being answered twice.
That combination is the thing. Coverage without overlap is a queue you inherit each morning with no context. Overlap without coverage means the night still goes unanswered. CEE gives both.

Compare the alternatives honestly. Asia-Pacific gives excellent overnight coverage and almost no overlap - you communicate in writing across a gap. LATAM gives strong overlap and little overnight coverage, because their day mostly matches yours. CEE sits between, which for East Coast hours is the useful position.
For a US West Coast company the maths is worse and the argument is different.
Two roles, routinely conflated in the job ad.
Customer support handles usage, billing, account questions, and how-do-I. The skill is clarity, patience and knowing when to escalate.
Technical support diagnoses. Reads logs, reproduces bugs, works out whether something is broken, misconfigured or misunderstood. Closer to engineering, costs more, and is the right hire if your product is technical enough that most tickets need investigating rather than answering.

The expensive mistake is hiring the first and expecting the second. A customer support person facing technical tickets becomes a forwarding service, and every ticket takes two people instead of one.
Written English, tested in writing. Most support is written, so test the channel you use. Send a real ticket - ideally an annoyed one with incomplete information - and ask for a reply. One written response tells you more than an hour of conversation: tone under pressure, clarity, and whether they ask the right question before answering.
English is the working language of the tech sector across CEE and written fluency is high. Spoken confidence varies more. If you run phone support, screen for that specifically rather than assuming it follows.
Product curiosity. The difference between a support person who is fine and one who is genuinely good is whether they want to understand the product. The curious ones learn the edge cases, spot patterns, and start telling you what is wrong with the product rather than just reporting it.
Ask what they liked about a product they supported before, and what they would change. The answer separates people fast.
Judgement about escalation. Escalate everything and you are a router. Escalate nothing and customers wait while someone guesses. Ask how they decide. You want a rule of thumb, not a policy.
Tolerance for repetition. Much of support is answering the same question. Someone who finds that unbearable will leave, and someone who enjoys turning it into documentation is worth keeping.
Close enough to engineering that a hard question gets an answer the same day.
Support isolated from the product team becomes a queue that forwards things. Every non-trivial ticket waits for someone in another department to have time, and the customer waits behind that.
Practically: support in the same channel as engineering, present when a release goes out, and able to raise a bug directly rather than through a manager. Their pattern data is the most direct product feedback in the company, and it is usually wasted.
Less than a US hire, for reasons that are not complicated - lower cost of living, and a sector where support is a career rather than a stopgap.
But cost is the weaker argument. The reason to hire support in CEE for a US East Coast company is that the hours line up, and you would want that even if it cost the same. If your only motivation is price, there are cheaper regions, and you will pay for it in overlap.

Most companies think about offshore hiring as engineering, then discover the bottleneck is somewhere else - support drowning, no QA, nobody running delivery.
Support is one of the easier roles to place well remotely, because the work is naturally documented, the output is visible, and the timezone advantage is real rather than something to be worked around.
We place support alongside engineers and QA, and it is often the hire that makes the biggest difference to how a team feels day to day.
Tell us the role and team size. We'll send an honest read on whether Talzy is the right partner - and if it is not, we'll tell you that too.