.png)
.png)
.png)
.png)
Many infrastructure companies face the same problem: they sell what people need, not what people are looking for. A domain or a professional email address is the foundation of an online business. But an entrepreneur isn't looking for a domain. They want to sell, look professional or find customers.
Akky, a division of NIC México, the organization that has run the .mx domain since 1989, with about 1.38 million registered domains, faced exactly that problem. It wanted to reach a user it doesn't capture today: the person who has never put their business online. The platforms that person finds offer too many options and too much technical language. They don't know what they need, get overwhelmed and give up, especially at checkout.
The underlying problem wasn't the screens, it was the system. The catalog was organized around what the provider sells. Our research showed that users don't come for the infrastructure: they come for a result. For them, the domain isn't what they're looking for or what draws them in, and many don't know what one is.
The second challenge came from the pace of the project itself. Between May and September, the PRD went through at least five versions, and each one left its own scripts, glossaries and rules. Iterating fast was necessary, but without a rule for deciding which source was in charge, every new decision would have to be pieced together across versions instead of derived from the system.
We approached PonteOnline as a rules problem, not an interface problem. Before designing screens, we consolidated a single source of truth and decided what the product's AI, MagIA, should do at each moment of the conversation. Two of those decisions defined the product.
What was on the table. The existing rule was that MagIA should always suggest the domain. For a registrar, that made sense: the client's dependency matrix recommended it right after almost any product.
What we saw. Our strategy research had already shown that the domain isn't the hook in any segment and that many users don't know what it is. As we built the product, we saw it show up in three places:
What the client decided. We put that evidence in front of Akky, and their team reached the conclusion on their own: the domain came out of the conversation in every journey. MagIA now recommends getting online with a free temporary address, and the domain is offered at checkout, where it's a purchase step rather than a barrier to entry.
The upside. The decision improves the product on three fronts:
What we did next. We turned the decision into rules the product's AI can follow without ambiguity. If the user wants a new domain, there's a dedicated journey. If they already bought one elsewhere, MagIA doesn't sell them another: it helps them connect it. Transferring a domain from another provider lives in the Panel, outside the initial conversation. And since a professional email needs its own domain, adding email at checkout adds the domain automatically, visible in the summary and easy to undo.
The team's AI. We wrote the scripts and the final matrix with AI, but the tool didn't decide the rules. We checked every script against the matrix, and that's where deviations showed up: MagIA suggested the domain again in journeys where it no longer should, and jargon the product dictionary bans, like "password", "SSL" or "hosting", slipped in. The fix wasn't editing script by script. We changed the method: the rules went in as constraints from the start, not as corrections at the end.
The product's AI knew what to sell; what it didn't know was when to stay quiet. We supplied that judgment, as rules.
Akky asked for short journeys. The literal reading was to trim script by script. But the problem wasn't length: an AI sales assistant tends to recommend everything that makes sense, and every extra recommendation pulls the user away from the result they came for.
We turned the request into a limit for the AI: in the chat, MagIA recommends at most one thing, and it can be nothing. Everything else moves to the Panel, which keeps offering what's pending until nothing is left. The rule lives in the matrix, so every new journey inherits it without renegotiating it.
Phase 1 closed with the deliverable accepted by the client. In five months, with a two-person team, Akky received a product that is defined and ready to build. We delivered it as a living system, and the client's development team already iterates with the matrix and the guide without depending on us.
PonteOnline didn't end with an AI that sells more, but with one that knows when not to sell. That judgment no longer depends on us: it lives in rules the client runs.
Defined what the product should do and, above all, what its AI should not do. Turned the research into 8 journeys organized by user intent, brought the evidence that led the client to take the domain out of the conversation, and wrote the rules that govern MagIA. Directed the team's AI with those rules as constraints and documented every decision with its reasoning, so the client can build and operate without depending on Axented.
Turned the system's rules into interface. Built the Design System from the brand brief and delivered it in HTML and Markdown, ready for people and for AI agents. Designed the interface states and the ideal-route demo, which serve as the reference for what development should build.
Milestone-based delivery with validation sessions with the client's Product, Marketing and technical teams. The backlog lives in Jira, using the same structure the client uses to manage the project, and every session closes with minutes and a deliverables package.
.svg)
Thirty minutes with a founder or a senior engineer, not a sales rep, booked straight into their calendar in your time zone. No pitch deck: if none of our services fit, we'll say so.
WhatsApp is answered Monterrey hours, Monday to Friday, in Spanish or English, usually within the hour.
Or write to bernardo@axented.com.
%20(1)-2.svg)
