Reducing Incident Response Time from 6.0 Days to 0.8 Days in Just Two Months: Lessons from Matsuri Technologies on Building a Strong Development Organization 

With the cooperation of: Mr. Satoru Hanada, Manager, Development Section, Development Department, Matsuri Technologies Co., Ltd. / Mr. Tomoya Oshima, SIC Team

Key Points of This Article

• Reduced lead time by 1/7 in two months (from 6.0 days to 0.8 days)

• The key lies in the decision to "prioritize recording over automation"

• Three Factors Behind Our Success: Support from the Product Owner, a "One Team" Culture, and a Sense of Urgency Sparked by Key Personnel Changes

• Improvement Measures: Notion-centric knowledge management × AI stack centered on Datadog MCP

• Insight: It is the small, unassuming steps that lead to major organizational transformation.

In this series, "Building Strong Development Organizations: Lessons from Resilient Companies," we will present case studies of companies that are taking a proactive approach to common challenges in incident response, such as reliance on individual expertise and manual detection processes. Our goal is to provide readers who are undertaking organizational reforms with practical, actionable insights based on the logic behind decision-making and the realities of organizational transformation.

Our first feature focuses on matsuri technologies Inc., a company that develops and operates a labor-saving platform for lodging and short-term rentals. With its m2m series at the core, this technology company has sustained growth for nine years by supporting both its own lodging business and external customer acquisition platforms (such as Sumyca and Ichiji-koku.com).

In just two months, that development team reduced the lead time for handling inquiries from 6.0 days to 0.8 days — a reduction of approximately sevenfold.

The key to success was neither the latest AI tools nor the creation of a dedicated SRE team, but rather a fundamental decision to prioritize documentation over automation. In this article, based on interviews with Mr. Hanada, who leads development at matsuri technologies, and Mr. Oshima, who leads the SIC team, we explore the reasoning behind that decision and trace the evolution of the organization.

From Individual Competence to Organizational Structure: Matsuri Technologies on the Eve of Transformation

Before we dive into the success story, let’s first take a look at the nature of matsuri technologies’ business and the challenges it faces.

Our suite of products, which has been in operation for nine years, integrates asynchronously with OTAs such as Airbnb. Given the nature of our business—which relies on minimal staff—system failures are never just mere bugs; they carry significant weight and create a sense of urgency, as a single failure can directly impact service delivery and customer satisfaction—potentially leaving guests unable to check into their rooms tonight. Furthermore, matsuri technologies’ products are used daily not only by external customers but also by our internal business units.This creates a unique structure where engineers serve users both inside and outside the company.

Given the nature of this business, the development team faced two major challenges.

Issue 1: Reliance on individual expertise

"Matsuri Technologies’ development structure originally began with a system where each person was responsible for a single product," explains Mr. Hanada, who leads the TS Team. "As the business expanded, we realized that continuing this way was unsustainable—no one would be able to take time off. That’s why we gradually shifted to a team-based structure."

After we formed the team, we made steady progress in organizing our knowledge base and documentation, but it wasn’t quite sufficient. The fact that we were able to handle things without any major issues was due to the high skill levels of our individual engineers.

“In fact, it was not uncommon in the field to find that ‘the older the system, the more likely it was that you couldn’t figure it out without checking with specific team members,’” commented Mr. Oshima, who leads the SIC team.

Reliance on individual expertise is a factor that affects organizational stability. This is especially true for a company like matsuri technologies, where services and technology are closely intertwined; the impact is immeasurable.

Challenge 2: Reliance on manual detection

Another structural challenge was our reliance on manual detection. As mentioned earlier, the product developers and the business units that used the product were all based within the same company, so initial reports of issues often came from the business units via Slack. While this proximity allowed for a rapid initial response, it also meant that if the business units didn’t notice a problem, it wouldn’t be detected—a significant vulnerability.

“Could there be some issue occurring somewhere that we on the development team haven’t noticed?” (Mr. Hanada)

Mr. Hanada commented that such anxiety had always lingered over the team.

The turning point in addressing the challenges we were facing came when Mr. Hanada, a key figure, was transferred to another team. The realization that “the business won’t be able to function if things continue this way” fostered a strong sense of ownership throughout the entire organization.

Three Factors That Drove the Transformation

Many organizations face challenges similar to those faced by matsuri technologies and tend to start with “AI-driven automation.” However, matsuri technologies chose to do the opposite: it went back to basics by first “establishing a robust record-keeping system.”

Mr. Oshima, who joined the company in 2026, had a simple motivation.

“When an inquiry came in, we often found ourselves asking, ‘What is this?’ We didn’t know how to handle it unless we checked with our predecessors or key personnel. We felt this was a problem, so our starting point was, ‘At the very least, let’s make sure we document what we’ve done!’” (Mr. Oshima)

It is said that the initiative began with this idea, starting with the collection of information in a specified format.

That said, this “natural choice” was underpinned by our company culture. Whether in a physical office or a virtual one, we’ve long had a “one-table” culture where we gather immediately whenever we encounter a problem. This time, we applied that same approach to incident response.

Organizational support was also a key factor in establishing this unprecedented initiative. The product owner’s attitude was particularly influential.

Typically, product owners are in a position where business pressures lead them to want to tell team members to “keep working on their own tasks at the same time.” However, at matsuri technologies, that wasn’t the case.

“Our product owner told us that it was perfectly fine for one person to simply observe the process of investigating and resolving issues. They said they really wanted the whole team to tackle the more difficult ones together. Given that some product owners might ask team members to keep working on their own assigned tasks, I think this was a huge boost for us.” (Mr. Oshima)

This is a method known as "swarming," in which the entire team works together on the highest-priority task.

Organizational support for product owners, a corporate culture centered on teamwork, and a sense of urgency stemming from key personnel changes —these three factors combined transformed a modest initiative focused on “starting with documentation” into a major movement that changed both the team and the organization.

How to Build an Operational Infrastructure That Solves Problems: Knowledge Management and the AI Stack

We addressed the challenges we faced through two main initiatives: knowledge and document management, and AI tools and automation.

Knowledge Management and Operations Centered on Notion

We consolidated the investigation results, which had previously been scattered across various platforms such as Slack, Google Docs, and Notion, into a single database. “We started by creating a system where users could simply look at this page to find the investigation results for any given issue,” explains Mr. Oshima. We logged all inquiries in Notion and centrally managed the summaries, response details, and investigation histories.

We’ve also implemented specific measures to ensure consistency. By leveraging Notion’s template feature, we prepared pre-designed forms. We encouraged users to fill in required fields and implemented measures to maintain consistent formatting, thereby standardizing the structure of the accumulated data. To collect inquiry information, some teams have piloted autonomous AI agents like Claude Cowork, automating the process of “collecting inquiries from Slack and storing them in Notion” to the point where “no human intervention is required.”

The design is based on the idea that "when we receive the same inquiry, we want to be able to respond immediately by referring to past cases." Mr. Oshima adds, "In the future, it would be great if AI could use this information to handle such inquiries on its own."

AI and Automation Stack

What transformed our approach to fault detection—which had previously relied on inquiries from business units—was an AI pipeline for fault detection and response.

At Matsuri Technologies, we had previously been using the system monitoring tool "Datadog," the autonomous AI agent "Devin," and the AI development assistants "Claude Code" and "Codex" separately. However, with the introduction of Datadog MCP, we are now able to integrate these tools and utilize them as a unified incident detection pipeline.

Datadog MCP acts as a bridge that passes logs and error information from Datadog to AI and other tools. The AI pipeline that leverages this feature is as follows:

First, we configured Devin, an autonomous AI agent, to automatically check Datadog’s error logs on a regular basis. We set it up so that when an anomaly is detected, it automatically creates an issue on GitHub (where development tasks are logged). Furthermore, by building a system that even provides AI-generated fix suggestions, we established an end-to-end pipeline that handles everything from detection to proposed solutions without human intervention.

However, automatic detection has not yet been rolled out to all products, and it appears they are still in the process of trial and error as they prepare for full-scale implementation.

Claude Code and Codex are being utilized for incident investigations, and the plan is to accelerate the process of narrowing down the cause by feeding logs and APM data directly to the AI via Datadog MCP.

Apparently, these practical ideas naturally emerge from the “consultation sessions” held every day at 3:00 p.m. There is a system in place for sharing recently tested tools and newly acquired insights, and a cycle of incorporating new tools into daily operations is constantly in motion.

Lead time reduced from 6.0 days to 0.8 days. What disappeared was the "waiting time" before work began.

The median lead time for handling inquiries (from ticket creation to completion) was 6.0 days in February 2026, immediately after the introduction of task-based management and swarming. This was reduced to1.0 days in March and 0.8 days in April. This represents a dramatic improvement, with the lead time falling to approximately one-seventh of its original level in just two months.

Mr. Hanada analyzes the mechanisms behind the numbers as follows.

"In the past, there was a tendency to think, 'Let's just create the form for now and deal with it later.' Now, the mindset has shifted to, 'Since the form has been created, let's get it done right away.' I think this is a major change." (Mr. Hanada)

Mr. Hanada reportedly reexamined historical data on response times (from start to completion) and made the following discovery.

“Actually, when it comes to response times from start to finish, there hasn’t been much difference between the past and the present in terms of either the average or the median. Previously, one of the main characteristics was that ‘response times varied widely,’ but with this improvement, that variation has disappeared. We no longer have a situation where tasks tend to pile up because it’s unclear who is handling them; instead, work now proceeds at a steady pace.” (Mr. Hanada)

Both in the past and now, the median response time itself is approximately one day. In other words, it appears that while the technical processing speed hasn’t changed dramatically, the waiting time between ticket creation and the start of work has improved.

And another key factor behind the dramatic surge in March was another initiative taken by the product owner.

“When we received an inquiry, the product owner suggested, ‘Let’s just get started and think it through, even if it’s just for a short time, like 30 minutes.’ The idea was that if we could solve the problem, that would be great, and if not, we could always ask someone with the right expertise. I believe that message—not to try to take on too much—led to a major change in March.” (Mr. Oshima)

Our meticulous record-keeping in February helped us visualize the types and trends of inquiries, and this coincided with the launch of our "30-Minute Proposal" service.

It seems that the shift in mindset Mr. Hanada refers to—the idea that “since the motion has been tabled, let’s get on with it”—did not arise in isolation.

• All inquiries have been visualized as tasks in Notion

• Thanks to our swarming culture, we were able to mobilize as a team instantly

• Thanks to the product owner’s 30-minute presentation, the barrier to getting started on tasks has been lowered

It seems that it was only when these factors came together that a culture of immediate response—where tasks are assigned and work begins right away—began to take shape.

　Mr. Oshima commented that the sense of psychological safety—the understanding that “you don’t have to handle everything on your own”—has taken hold, allowing new members to join the team early on. He noted that the ability to refer to past cases stored in Notion is accelerating the integration of new hires into the workforce and has led to significant qualitative improvements.

Three Upcoming Initiatives: Expanding Horizontally and Deepening External Partnerships

Matsuri Technologies has reduced its response lead time to one-seventh of what it was in just two months, but its sights are already set on the next stage.

First is the horizontal rollout of the reforms.

While this initiative was initially piloted by the SIC team (property and customer acquisition), we are now planning to expand it to the TS team (cleaning and check-in), which primarily operates on an asynchronous work model. Our next challenge will be to adapt the approach to account for these differences in team characteristics.

The second point is establishing criteria for determining severity.

Given our close relationship with the business units, we need to take a careful approach that respects the unique characteristics and diversity of each product, rather than establishing a one-size-fits-all standard. Mr. Hanada commented as follows:

"There is no consistent approach to evaluating issues based on both severity and impact. Given that product lifecycles vary, should we force a one-size-fits-all approach, or are there common elements? I believe some answers will gradually become clear as we proceed with development and business expansion." (Mr. Hanada)

In other words, Mr. Hanada believes that the correct criteria for decision-making do not come from theoretical planning, but rather emerge naturally from daily practice and the growth of the business.

Third, we are deepening our integration with external services.

While we cannot fully control integrations with external services such as OTAs, matsuri technologies does not view this as a "challenge."

“Rather than simply dismissing outages in external services as the fault of third parties, I believe it’s important to adopt an attitude of mutual improvement. If we share the issues we’ve identified with our partners, they can build up their own knowledge base, which will help advance our collaboration on automated detection. Instead of shifting the blame for outages onto others, I believe we need to foster an attitude that promotes the maturity of the industry as a whole.” (Mr. Hanada)

SIGQ Insights: Building Systems for Data Recording and Automation Through Case Studies

What we can see from the case of Matsuri Technologies is a universal pattern: only by first establishing a "recording system" can we begin to measure the effectiveness of automation.

In a survey conducted by SIGQ of 250 VPoEs, EMs, and SRE leaders, 32.4% of organizations that had undertaken incident response reforms reported that they had seen "no improvement." While many organizations fail to achieve results even after taking action, cases like that of matsuri technologies—which followed a "logging → automation" approach—offer valuable insights for the industry as a whole.

These are the key areas for future initiatives identified by Mr. Hanada

• There is no consistent understanding of incident severity across teams

• I want to automate the classification and severity assessment of error logs

These two points are challenges shared by many operating companies.

Organizations like Matsuri Technologies, which have laid the groundwork for "recording," are now focusing on precisely these two areas. At SIGQ, we too have designed Incident Lake with the same concerns in mind.

Incident Lake, provided by SIGQ, uses AI trained on past response histories to automatically assess severity and provide real-time solutions for ongoing incidents based on similar cases. By combining this with investigation histories stored in tools like Notion, the system is designed to automatically link the "records" accumulated by matsuri technologies to the "next initial response."

To all readers who share this concern: The journey of matsuri technologies teaches us that reform doesn’t start with cutting-edge tools, but with a simple, unassuming first step: “starting by keeping records.” Whether it’s a single Notion template, adopting a swarming culture, or a product owner’s encouragement to “just do 30 minutes”—these are all actions you can try in your own organization starting today. There is definitely a “first step” for your organization, too.

Reporting and Writing: Takashi Kamoda, BtoB no Shokunin Co., Ltd.