Small distributed teams are often worried about working remotely when selling to their first customers.
Here are several tips you need to know.
A Client Shouldn’t Care
Technically speaking, a client shouldn’t care whether an agency is distributed or not. In a B2B transaction, the deal happens between both parties, based on a set of terms, requirements, and milestones (or deadlines). But there are some perks that I’ll explain further.
Given that the work has been outsourced (i.e. not everyone works at the same office all the time), communication must be streamlined anyway. Meetings are to be scheduled accordingly, the rest is aligned according to the work process.
A Truly Distributed Team
In a truly distributed team, meetings may be a bit trickier to happen. For instance, our marketing team is dispersed across North America, Europe, and Asia. Our editor is in Canada, several folks are in Macedonia and Bulgaria, and we have three more in the Philippines. We have some freelance writers in the US, too.
So getting everyone in a meeting is nearly impossible. That’s why internal processes happen in different manners, e.g. with weekly sprints and recurring assignments, or a pipeline-based model that relies on less internal communication.
Whenever meetings have to happen, it’s usually the client, an account/project manager, a technical/project lead, probably one or two more people tops. The account manager is in charge of syncing everything else internally.
Certain Client-Facing Benefits
On the upside, distributed companies bring certain benefits, especially when they cover a broader set of countries/cultures:
- Uptime monitoring and management — instead of running a 24/7 support team, a distributed agency may cover for most incidents or unexpected events with a pretty decent overlap. The agency’s business hours are quite broader than those of an on-site 9-to-5 team.
- Cultural assistance — some of our publishers target specific demographics or religions, and having a distributed team has set us up for acceptance and understanding cultural specifics across the board, what’s appropriate and what not.
- Multilingual development — we often step in for teams in the US/UK building multilingual platforms. What we consider “common sense” (having been raised and born with) is often counterintuitive for native US and UK developers, which often causes problems for international platforms. Aside from understanding time zones and cultures, we speak a number of languages, including Bulgarian (Cyrillic) and Arabic (a right-to-left language) which cause some interesting problems unless you know where to look for.
- Communication and QA — related to the multilingual point above, multinational clients often have to deal with content, activities, vendors and 3rd parties across the globe. We have occasional meetings with Russian project managers, QA Arabic content for our Dubai-based partners for a client, and review original specifications in German for our automotive clients as an extra check as occasionally, essentials are “lost in translation”.
- Day-to-day sync with vendors and partners — our clients also work with other vendors around the world; creative teams, ad performance companies, booking platform providers, QA teams, support staff, regional managers, consultants. Occasionally, there’s a good match between someone in an odd timezone here who happens to live nearby someone important who has to participate in a project.
- Holiday availability — if your office is generally closed for Christmas, Hanukkah, Ramadan, Diwali, ours isn’t. Which can be truly instrumental for handling different emergencies or simply stepping up for a quick fix while nobody else is around, without asking for taking shifts on a major holiday.
I’ve elaborated on these in a video on YouTube:
There’s a lot more to that, of course, but while distributed companies have to be on par with their on-site counterparts, there are also the added benefits coming as a result of that collaboration.