The Customer Service (CS) organization is a major component of Mercari, supporting the service that is used daily by so many people. At the foundation of all CS-related work is the CS Tool, as well as the steady development and improvement of its features. Team collaboration is an indispensable factor of building that foundation and enhancing CS operations. As needs for new businesses emerge often within Mercari Group, how does CS keep up with such a changing environment, and what mechanisms and technologies do they employ to solve one fresh problem after another?

Up until now, we have focused on the Engineering organization when it came to the topic of building foundations. This time, we will shift our attention to Yuki Hirano (@hirano) of the CS Tech Solutions Team, Alain Bariel (@alain) of the CS Product Management Team, Yuto Matsukubo (@Peranikov) of the CS Foundation Team, and Eunsu Jang (@Unsu) of the CS Tool Team to ask them about team collaboration through the processes of feature development and improvement.

The Importance of Considering Speedy Business Launch in Parallel to CS Work

――I would like to start off by asking what sort of issues come up in the CS area that relate to the ever-continuing expansion of Mercari Group.

@hirano：Right now, we’re seeing growth in Mercari Group’s existing businesses and the launch of new businesses at the same time. This is, in turn, growing the scale of our operations and making them more complex. For Mercari especially, speed is key when launching new businesses. This requires that the development of CS-related tools and the building of operational structures also proceed swiftly. As a result of this, we’ve taken the route of developing new tools and implementing external ones in addition to those already in use. These tools may have been put to use initially in a state that covers the bare minimum needs, but as the scale of our work grows, some components become hard to use, or don’t mesh well with existing systems.

This past year, while we were taking on tasks for new businesses, we were also focused on coming up with new feature proposals necessary for CS, as well as automating our work. As a result, we have managed to increase our productivity and improve our operations.

Yuki Hirano（@hirano）

――You mentioned working with tools built in a hurry when handling tasks related to new businesses. How do you set priorities when adding new features?

@hirano：We first formulate a CS structure for the new business, and sculpt out the operations necessary within that structure. For example, we consider whether the best means to support users is via phone or email, and also come up with the appropriate system for each. We try to come up with ways to make as much use of existing tools as possible, but still search for the best methods to support users, and list out features in a way that will also keep our operations simple and successful. All of these are collected into a set of requirements, which we deliver to Alain’s team.

I think the company is now able to consider CS operations an inseparable component of launching a new business.

――Alain, in your team, CS Product Management, how do you turn the requests you receive into projects and progress them?

@alain：We put the objectives into numbers, such as fewer inquiries, higher operational performance, and fewer transfers, and search for ways to produce the maximum effect. In other words, we think of what would be most effective in terms of improving UX and reducing costs. Especially since engineering resources are limited, we prioritize matters with speed and effectiveness in mind.

When I joined the company, the CS operations for Marketplace, Souzoh, and Merpay were all disconnected from each other. In July this year, an organization was formed, called “JRCS”, which now includes all of the CS teams. I think this unified our operations quite a bit. However, as there are new businesses currently in the process of being launched, one of our focus points is to make sure operations don’t become disconnected again. Time and time again, the topic of “speed vs. maintainability” shows its head when it comes to prioritizing work.

Alain Bariel（@alain）

@hirano： It is good to be sensitive about current issues and problems that users are facing, and to want to resolve them. However, sometimes when you build something too quickly, it leads to needing more development work down the line. In that sense, listening to only CS’s requests can result in losing sight of certain important points. We consult on such matters with Alain’s team, clarify disadvantages, and try to break things down as much as possible.

@unsu：Up until a year ago, the CS Tool was put in code freeze. We weren’t able to add any new features for a long time. Because of that, other tools or screens were built during that time to fulfill certain needs. We need to change that culture of temporary resolutions through creating separate tools. The change has already started in the way the members of these teams think.

@Peranikov：As the company was going through a huge transition phase, where we were breaking down our gigantic and monolithic application into microservices, we decided to put CS Tool into code freeze, and focus our resources on the migration project. However, the Mercari service is so big and complex that it was very difficult separating and redesigning its many components. That is why we started the Robust Foundation for Speed (RFS) project, where the objective was to make the app itself maintainable.

We have since finished RFS as well, and the frontend has slowly become able to include other businesses. The way we have evolved during that time is that instead of creating a new tool for the CS work of new/other businesses, we are now looking into ways of utilizing our existing tools to their maximum potential.

Finding the Right Balance of Benefiting CS and Delivering Engineering Value

――Alain, what do you pay the most attention to when collaborating with engineers while you are promoting projects as PM?

@alain：I try to find the balance between “Let’s do it now,” and “What happens if we do it now?”. For example, a project that is just migration does not affect CS work, and inversely, something that only benefits CS in the short term without any engineering value is not something that we should do. We balance achieving business impact with delivering engineering value.

――I don’t imagine it to be easy. How do PMs and engineers collaborate for it?

@unsu：We want to improve upon the CS work that requires immediate attention, but leaving the systems as they are leads to tech debt and difficulties down the line when trying to fix them. We always strive to proceed in a way that balances delivering value to CS and creating something well-engineered.

@Peranikov：I think we have gotten better at it recently. Up until a while ago, we were focused on building microservices and reusing old systems to repay tech debt. Now, however, we are able to hold discussions about how to repay tech debt specifically to benefit CS.

In other words, even when you successfully repay tech debt, if it doesn’t impact the business in a positive way, it is considered a wasted cost. For our part, when planning our work, we tried to figure out which debt would make CS members happy in the future when repaid appropriately. However, because the purpose of “repaying tech debt” was so prominent on its own, I was unsure about whether I could have full confidence in the effectiveness of every single thing we intended to do.

Recently, we have been holding more constructive discussions, with Alain at the helm, that emphasize business-side requests and CS needs at the same time. We are able to voice the bottlenecks in CS operations, and specify what debt needs to be repaid so that we can keep supporting the service.

Yuto Matsukubo (@Peranikov)

@unsu：Instead of just wanting to replace old technology, the mindset that has taken root amongst team members is to develop things that CS can use easily and that allow for future expansions in line with business growth.

Improving CS Operations Enriches User Experience

――Well then, how does the CS Tech Solutions Team approach the projects for developing and implementing new features?

@hirano：First, we put the newly developed features to use in operations, and then provide feedback to CS Product Management. If a feature requires changes in operations, we estimate the impact on operational productivity, properly report it, and analyze how much has improved due to the new feature. We also take roles in the preparation phase before the users of the tool have a go at the new features for the first time, such as by compiling and organizing instruction manuals.

――How is Mercari’s CS work different from any other customer service?

@hirano：The fact that it’s a C2C service makes it special. We have different affiliations of users, namely buyers and sellers. If we don’t respect these positions equally, resolving problems between users becomes close to impossible.

@unsu：Additionally, the main users of CS Tool are the CS members who support Mercari users. When working on the CS Tool, we always keep in mind making it easy to use for CS members. It is the privilege of CS developers to enrich Mercari’s UX by way of improving CS operations.

Eunsu Jang（@Unsu）

@Peranikov：The fact that our end users are other CS members is a unique situation even among other service teams. I personally feel like we are building a B2B SaaS. I sometimes look at other B2B SaaS’s for research purposes, too. (laughs)

For C2C services like Mercari, it is a given that an indeterminate number of people must be able to pick it up and intuitively understand how to use it right away. However, building a B2B tool, especially one aimed at CS, you have room to implement onboarding, which means the tool doesn’t necessarily have to be a simple-to-use app. In fact, we get many requests from CS members, such as adding as many keyboard shortcuts as possible, that tell us the demand for CS Tool is to make it a piece of software intended for professionals that can ensure shorter average handling time (AHT).

@alain：Recently we have also been taking on improvement projects that arise from things noticed during daily work, such as people suggesting less confusing layouts for new screens and fixes that can allow for faster response times.

@hirano：It is important to not just keep adding new features, but to also keep the productivity of experienced operators high. The experienced operators are major contributors, so little changes in their flow can actually have a large impact on the whole.

Wanting to Build the Service Both Safely and Speedily

――Listening to you all, it seems to me like things are going in an overall positive direction. Are there any bottlenecks you are facing at the moment?

@Peranikov：Not exactly a bottleneck, but right now we are focusing on integrating the CS operations for the new HR business into the existing CS Tool. We initially thought to create an original CS Tool, but considering multiple aspects including security, eventually decided to integrate it into the current one. Our purpose as the CS Foundation Team is to integrate the CS Tool with other tools. Two aspects that may lead to risks during that process are permission management and monitoring. Such aspects can easily fall by the wayside when all you’re trying to do is to put out a minimum viable product (MVP).

However, it is better to properly establish from the beginning who will own what kind of operation and perform what function with the tool from a monitoring perspective. A service at the scale of Mercari needs to be paying attention to these matters all year round.

I know I’ve said this a number of times already, but one of our recent topics is to provide support without slowing the business down. Our team members are also proactively joining up with the development team of the new HR business and following up with what they can. We want to make sure that we can keep building the service both safely and speedily.

@unsu：The CS Tool Team is taking on the challenge of mounting the CS Tool on a new common platform. The way it is now, it takes a lot of time to deliver new features for the CS Tool when they are requested. We expect that this new platform will not only alleviate our tech debt, but also make it possible for us to focus on proactively delivering necessary features and propose new ones that can automate complicated CS operations.

――Then for my last question, I would like to ask you the most fun part of being an engineer that is involved in feature development and improvement for CS at Mercari.

@Peranikov：On behalf of the CS Foundation Team, I can say that engineers who are interested in creating foundations that will support development, instead of simply making whatever CS requests, would have a good time working in our team. Because we work with a central system upon which multiple CS-related tools converge, and are involved in aspects like security and monitoring, if one does not stay vigilant and always practice thorough development, it can easily lead to a major incident. That is why I think engineers who have a sense of responsibility toward stable operations would find it worthwhile here.

@unsu：For the CS Tool Team, I can say that the most fun part is to be able to think of new UI/UX and make it a reality in products and features using the latest technology. Moreover, those who enjoy thinking about how to build new features that are highly reusable across multiple use cases and user teams will find our work very motivating.

@Peranikov：During the startup period, the most important thing is to keep the business on an upward trajectory, instead of trying to build common platforms and so on. However, Mercari is beyond that phase now. Our mindset has shifted from maintaining an upward trajectory to strengthening our defenses with a common platform without slowing down development. I personally feel like it’s a wholly different game. You don’t often find yourself in such circumstances. Major tech companies already have their platforms established, but Mercari is now in the phase of figuring out its own platforms in the most Mercari-like way possible.