Ask a communications leader why they picked a platform and you get a story about their team. Ask a software engineer and you get a spec.
The account of how EPAM Systems chose ContactMonkey comes from Lotus Biswas, a Software Engineer. That’s unusual for an internal comms story, and it’s the most useful thing about it.
Because he doesn’t describe the decision the way a comms team would. There’s no language about culture, storytelling, or employee experience anywhere in it. What there is instead is a requirements list.
“ContactMonkey was selected because it provided the best overall fit for our requirements, including native Outlook/Gmail integration, advanced email analytics, ease of use, reliable support, strong security and compliance, and competitive pricing compared to alternative solutions.”
Consider this a decision record, rather than a testimonial.
Read the spec, not the sentence
Each of those six is a familiar line item to anyone who has evaluated a technical dependency.
Native Outlook and Gmail integration comes first, and first position is a tell. The goal was explicitly not to introduce a new surface where communication happens. It was to instrument the one already in use. An engineer reaches for that instinct automatically: don’t add a system, extend the system.
Security and compliance appear as a named requirement rather than a procurement box checked late. At 62,750 employees, this is arithmetic. Internal email carries organizational information that has nothing to do with marketing consent frameworks, and tools built for customer campaigns aren’t architected around that distinction.
Reliable support is on the list, which comms teams rarely name out loud and engineers always do, because they’ve all inherited something unsupported before.
Ease of use sitting alongside the other five is the tension worth noticing. It’s the one requirement that isn’t about capability or risk at all. It’s about whether the person building Tuesday’s newsletter will actually use the thing. A platform that satisfies security review and defeats its daily user hasn’t been implemented, it’s been purchased.
“Largely manual” is how an engineer says technical debt
Here’s the before-state, and it’s the sentence that gives the whole story away.
“Before ContactMonkey, we lacked reliable email analytics, efficient email creation tools, audience segmentation, and actionable engagement insights. Communication performance was difficult to measure, and reporting was largely manual.”
Read this as an observability gap. EPAM was shipping internal communication into production with no telemetry on it.
An engineer would never accept that for a service. You don’t deploy something that thousands of people depend on and then assemble the performance report by hand, once a quarter, when someone senior asks. But that’s the standard condition of internal comms at most organizations, and because the work is called communication rather than infrastructure, nobody labels it as debt.
The compounding cost is the part that gets missed. Manual reporting doesn’t just consume hours. It determines what gets measured at all, because anything that takes half a day to compile gets compiled rarely, and only for the sends someone asked about. Everything else ships blind. Absence of tooling becomes absence of knowledge.
“ContactMonkey streamlined the process and provided the visibility needed to improve internal communications.”
The spec produced a comms outcome
Now the part that makes this story worth publishing. A requirements list containing nothing about engagement produced engagement.
“Since adopting ContactMonkey, we’ve improved email engagement, gained actionable analytics, streamlined the email creation process, enhanced audience targeting, and reduced the time required to create, send, and report on internal communications. This has resulted in more effective and measurable employee communications.”
There’s a sequence in there, and it runs in one direction. Time to create, send, and report came down. Targeting sharpened, because segmentation exists now. Engagement improved as a consequence of the first two, not as a thing anyone intervened on directly.
And then the final clause, which is the most engineer-shaped phrase in the entire response: “more effective and measurable.” Not effective alone. Measurable is carrying separate weight in that sentence, deliberately, as a distinct achievement. Most comms testimonials would have stopped at effective. An engineer knows that a result you can’t observe is a result you can’t defend or repeat.
Borrow the engineer’s questions
If you run internal comms, the useful exercise here isn’t admiring EPAM’s process. It’s asking their four questions about your own stack.
- Does your comms tool extend the email system your people already live in, or add another one?
- Could you produce last quarter’s performance report right now, or does it need a person and an afternoon?
- Is your employee data segmented, or is every send going to everyone?
- Would your security team have opinions about the tool your employee communications currently run through?
None of those are communications questions. All four determine whether your communications work. Book a demo today to learn more!
