Taking a monday.com customer portal from discovery to launch

Deviniti was known for Atlassian apps and wanted to grow its portfolio on the monday.com marketplace. The question was simple and open: which app should we build?

A product manager and I started as a two-person team before any developers joined. We split the discovery between us: I took service management, and the PM explored a second area.

On a limited budget, I combined several sources to understand what monday.com customers lacked:

• 3–5 expert interviews with monday.com implementation partners. They deploy and customise monday.com for many companies, so they see patterns across clients.
• Contextual inquiry at one client's office, where I watched users work in monday.com on site.
• Community research on monday.com forums and competitive analysis of existing portal apps.
• Desk research on the platform, its users and its ecosystem.

We chose service management for two reasons. Customers, implementation partners and desk research all pointed to it as the stronger need. Deviniti also had deep service management experience from its Atlassian products, so we could build on what we knew.

Three problems came up again and again. They became the "north star" needs for the product.

1. Insight

   • MVP

   Scattered workflows. Support agents kept switching between monday.com, email and third-party tools, losing focus and time.

   What I designed: One portal as the single entry point for all request types, with agents working on requests inside monday.com.

2. Insight

   • MVP

   Customer confusion. Customers struggled to find the right form across many boards and fell back on email.

   What I designed: A central view where customers see all their requests in one place.

3. Insight

   • MVP
   • After launch

   Zero visibility. Native forms offered no branding, and customers couldn't see what happened to a request after sending it.

   What I designed: Portal customisation (copy, theme) so it looks like the client's own; real-time status updates. Customisation in MVP; updates after launch.

After launch we added in-app messaging and file sharing, so agents and customers could resolve an issue without leaving the portal.

Midway through, the launch date moved forward. As a monday.com partner, we had a business reason to get to market sooner.

The PM and I had to decide what the first version must do. We kept only what solved the core problem of a scattered, invisible request process:

We prioritised with MoSCoW. Value came from our experience with other ITSM systems and from desk research; developers estimated the effort of each feature. Feedback after launch confirmed the order: the gaps customers reported were the features already next on our roadmap.

A third-party app on monday.com has to work within strict API and UI rules. Every flow started with a technical check of what the platform allowed.

Example: the verification code. The ideal design assumed full integration of monday.com's native forms with our app: a customer's form data would flow straight into our app, with no extra steps. monday.com didn't allow it. We had to add a verification code to link a requester to the system. I accepted one extra step and designed it to be as short and clear as possible, so data stayed accurate without losing customers at the door.

Other constraints followed the same pattern. We built our own secure login outside the native framework, and some flows needed more steps than a native feature would. I kept them feeling native by building every component on monday.com's Vibe design system. The app was fully consistent with it.

Working with developers. I was part of the sprint team from the start. I often ran ideation sessions together with the developers, so we knew early what was feasible and didn't design dead ends.

Support Pulse went live on the monday.com marketplace and won its first customers in its first week. Feedback was positive, and the gaps customers reported matched our roadmap. We kept shipping the post-MVP features based on that feedback.

In March 2024, monday.com unexpectedly announced a native customer portal. We decided to stop developing Support Pulse the same month. A platform building the same capability itself confirmed that our research had found a real, valuable need, even on a limited budget.

• Platform risk is part of the design problem. We reviewed monday.com's public roadmap and talked with our partner manager, but service management wasn't on it. A partner never sees the whole roadmap. Next time I would treat platform risk as an explicit assumption from day one: watch the monday.com community closely, especially replies from monday.com staff. There may have been signals we missed.
• Constraints sharpen design. When the API said no, I had to find the simplest workable flow instead of the ideal one.
• Early developer involvement saves time. Ideating with developers kept every concept buildable.