This guide walks through the complete process, along with a troubleshooting section covering an issue that took several hours to diagnose.

Publishing an OData Web Service

Business Central allows any published Page or Query object to be exposed through an OData endpoint.

Navigate to:

Search → Web Services

Create a new line:

For example:

Once published, the endpoint becomes immediately available through OData.

Finding the Page ID

The easiest way to determine the Page ID is from the URL while viewing the page inside Business Central.

For example:

https://businesscentral.dynamics.com/<tenant>/Production/?company=AM60%20Property%20Trust&page=20

The important part is:

page=20

meaning the object is Page 20.

Another example:

https://businesscentral.dynamics.com/<tenant>/Production/?company=AM60%20Property%20Trust&page=29

Here,

page=29

corresponds to Vendor Ledger Entries.

This works for most standard pages throughout Business Central.

Constructing the OData URL

The endpoint format is:

https://api.businesscentral.dynamics.com/v2.0/<tenant>/<environment>/ODataV4/Company('<company>')/<service-name>

Example:

https://api.businesscentral.dynamics.com/v2.0/e7509dc1-fefb-4789-8563-7df05946f26e/Production/ODataV4/Company('AM60%20Property%20Trust')/Vendor_Ledger_Entries

Notice that the endpoint uses the Service Name, not the page name or page ID.

Connecting from Excel

In Excel:

Data
→ Get Data
→ From Other Sources
→ From OData Feed

Enter the endpoint URL.

When prompted for authentication:

• Choose Organizational Account
• Sign in using your Microsoft 365 account

Business Central Online no longer supports Web Service Access Keys, so OAuth authentication is required.

Connecting from Power BI

Power BI uses the same OData endpoint.

let
    Source =
        OData.Feed(
            "https://api.businesscentral.dynamics.com/v2.0/<tenant>/<environment>/ODataV4/Company('AM60%20Property%20Trust')/Vendor_Ledger_Entries",
            null,
            [Implementation="2.0"]
        )
in
    Source

The same M query also works in Excel.

Troubleshooting

“The odata.context url is invalid”

One issue I encountered after publishing new web services was the following error in Excel:

DataFormat.Error:
The odata.context url
'https://.../$metadata#Company('ABC%20Company%20Inc')/GLEntriesTest'
is invalid

Interestingly:

• Existing web services continued to work.
• Newly published web services failed.
• Power BI loaded the same endpoints successfully.
• Excel Online also loaded the same endpoints successfully.

Initially this looked like a Business Central problem, but after a lengthy investigation, the issue turned out to be on the Excel side.

Resolution

Clearing permissions from Excel’s main Data Source Settings was not sufficient.

The issue was resolved by:

1. Opening Power Query Editor.
2. Opening Data Source Settings from within the editor.
3. Clearing the Business Central data source permissions.
4. Reauthenticating using Organizational Account.

After doing this, the newly published web services loaded correctly.

If you encounter the same error after publishing new OData services, this should be one of the first things you try before assuming there’s an issue with Business Central.

A Few Practical Tips

• Use descriptive service names. These become part of the URL and make integrations easier to understand.
• Prefer exposing only the pages you actually need instead of publishing everything.
• If you’re building reports in Power BI, the same endpoints can usually be reused in Excel and other OData consumers.
• If a newly published service doesn’t load in Excel but works elsewhere, clear the Power Query data source permissions before spending hours debugging Business Central.

Publishing standard Business Central pages as OData web services is surprisingly straightforward once you know where to look. Hopefully this saves someone else the several hours of troubleshooting it took me to discover that the problem wasn’t the endpoint at all—it was a stale Power Query cache.

Not just chatbots, but agents that search the web, modify files, interact with Linux terminals, schedule cron jobs, orchestrate MCP tools, and automate real work.

Like many people, I initially evaluated models using the usual metrics:

• Benchmark scores
• Coding ability
• Reasoning capability
• Context window
• Cost
• Speed

Those metrics are useful.

But after spending enough time with autonomous agents, I’ve come to believe they don’t measure the thing I care about most.

Operational reliability.

The morning that changed my mind

Recently I was using Mimo 2.5 as the reasoning model behind my Hermes agent.

Within the span of about an hour, I encountered three separate incidents that completely changed how I think AI models should be evaluated.

None of them were catastrophic.

None of them involved complex reasoning.

Yet all three exposed behaviors that would concern me far more than a low benchmark score.

Incident 1 — A timezone that wasn’t

My Linux server reported:

Time zone: Asia/Manila (PST, +0800)

The model interpreted PST as Pacific Standard Time instead of Philippine Standard Time.

It ignored the authoritative information immediately beside it:

• Asia/Manila
• +0800

From that single incorrect assumption, it concluded:

• my server was running in Pacific Time,
• cron jobs would execute 16 hours differently,
• reminders would trigger at unexpected times,
• I should reconfigure the server’s timezone.

The interesting part wasn’t the mistake.

The interesting part was how confidently the rest of the reasoning grew from that incorrect assumption.

Incident 2 — Correcting me before checking

Later we were discussing Wimbledon.

The model stated that Barbora Krejčíková was the defending champion.

I questioned it.

Instead of checking the web—despite having web search available—it confidently explained why I was mistaken.

Only after I supplied the official Wimbledon website did it search, verify the facts, and admit that I had been right.

The problem wasn’t that it got a tennis fact wrong.

The problem was the sequence.

Instead of:

Verify → Respond

it followed:

Respond → Verify

For sports trivia, that’s annoying.

For an autonomous agent managing infrastructure or financial systems, that’s a much bigger concern.

Incident 3 — A source that never said it

Curious about what had happened, I asked the model what search result originally led it to believe Krejčíková was the defending champion.

It replied that an ESPN article contained the phrase:

“guarantees new Wimbledon champion”

I asked for the link.

It found the ESPN article.

I opened it.

The phrase wasn’t there.

When I pointed this out, the model admitted that it had conflated multiple sources and incorrectly attributed the wording to ESPN.

Again, this wasn’t merely a factual mistake.

It was a failure of source attribution.

None of these incidents were extraordinary

Every frontier model makes mistakes.

I’ve seen factual errors from multiple models.

That’s not the point.

What caught my attention was that all three incidents followed the same behavioral pattern.

The model tended to:

• make an early assumption,
• express it confidently,
• build additional reasoning on top of it,
• verify only after being challenged.

That pattern is much more important than whether the original mistake involved Linux, sports, or something else.

Is this a Mimo 2.5 problem?

Not necessarily.

These incidents all occurred while I was using Mimo 2.5, so it’s fair to document them as observations from that model.

However, I don’t think it’s intellectually honest to conclude from a handful of incidents that Mimo 2.5 is categorically worse than every competing model.

I’ve seen similar behaviors—though not always with the same frequency—from other modern LLMs.

The takeaway isn’t:

“Mimo 2.5 is bad.”

The takeaway is:

Operational reliability deserves to be evaluated independently from intelligence.

Those are two different qualities.

Benchmarks don’t measure this

Traditional benchmarks answer questions like:

• Can the model solve this problem?
• Can it write this code?
• Can it answer this question?

What they rarely measure is:

• Does the model know when it might be wrong?
• Does it verify before disagreeing?
• Does it use available tools appropriately?
• Does it recognize authoritative evidence?
• Does it revise its beliefs when new information appears?
• Does it attribute information to the correct source?

Those questions matter far more once an AI starts acting autonomously.

From bug log to incident database

These incidents convinced me to stop keeping ad hoc notes.

Instead, I’m building an AI Agent Reliability Database.

Rather than recording isolated mistakes, I’m documenting failure patterns.

Examples include:

• Anchored on ambiguous terminology
• Corrected the user before verification
• Failed to verify assumptions
• Ignored authoritative evidence
• Preferred internal memory over available tools
• Incorrect source attribution
• Overconfidence despite uncertainty

Each incident links to one or more reusable patterns.

That way, if a future model exhibits the same behavior, I can compare it objectively rather than relying on memory or anecdotes.

Engineering can mitigate many of these problems

One unexpected lesson is that many reliability issues aren’t solved by changing models.

They’re solved by improving the surrounding system.

For example:

• Pass IANA timezone identifiers (Asia/Manila) instead of ambiguous abbreviations like PST.
• Provide structured data instead of free-form text.
• Require verification before contradicting the user.
• Let deterministic software perform scheduling and time calculations.
• Prefer authoritative sources whenever tools are available.

Good orchestration reduces the opportunity for language models to make reasoning mistakes.

A different way to evaluate AI

I’ve become less interested in asking:

“Which model is the smartest?”

Instead, I’m asking:

• Which model is the easiest to trust?
• Which one verifies before acting?
• Which one admits uncertainty appropriately?
• Which one recovers gracefully after making a mistake?
• Which one behaves predictably in autonomous workflows?

Those aren’t benchmark questions.

But I suspect they’ll become some of the most important questions as AI agents move from demonstrations to production systems.

And ironically, I have Mimo 2.5 to thank for making me realize that.

What Is OpenCode Go?

A $5 first month, $10/month after subscription that gives you access to 13 top open coding models. No per-token charges — just a flat fee with usage limits.

Subscribe to OpenCode Go

The Models

• DeepSeek — V4 Pro, V4 Flash
• GLM — 5.2, 5.1
• Kimi — K2.7 Code, K2.6
• Qwen — 3.7 Max, 3.7 Plus, 3.6 Plus
• MiniMax — M3, M2.7
• MiMo — V2.5, V2.5 Pro (with vision!)

How I Use It

Three tools, one subscription:

• OpenCode — terminal coding agent. MiMo V2.5 Pro scored 83/100 on benchmarks, beating Claude Opus on agentic tasks.
• Hermes — my AI agent on Telegram. Uses OpenCode Go as its provider, so it has access to 13 models for $10/month.
• n8n — workflow automation. OpenCode Go works as an OpenAI-compatible endpoint, so you can build AI workflows without per-token costs.

The Honest Math

Here’s where I need to be real: the monthly budget is the real constraint, not the 5-hour window.

The limits are:

• 5-hour window: $12 budget equivalent
• Weekly: $30 budget equivalent
• Monthly: $60 budget equivalent

If you max out the 5-hour window, you’ve burned 20% of your monthly cap in one session. Do that a few times and you’re looking at the monthly limit fast. The 5-hour window sounds generous, but it’s really just a throttle — the monthly cap is what matters.

For light-to-moderate use (a few coding sessions, some agent queries, occasional automation), the monthly cap is plenty. But if you’re running heavy agentic workflows or long coding sessions daily, you’ll feel it.

What $10 Gets You vs Pay-As-You-Go

The value is still there — just not unlimited:

• MiMo V2.5 Pro at Zen API rates: ~$1.74/1M input. The subscription gives you ~3,000 requests per 5h for $10/month flat.
• DeepSeek V4 Flash: ~$0.14/1M input. Budget-friendly but still draws from the same monthly pool.
• You’re getting 20-60x more value than pay-as-you-go for moderate usage.

My Verdict

Worth it if you:

• Use AI tools regularly but not excessively
• Want to try 13 models without per-token costs
• Run AI agents or automations that need reliable access
• Want flat pricing with no surprise bills

Might not be worth it if you max out the 5-hour window regularly — you’ll hit the monthly cap and need to wait or top up credits.

Architecture

Claude Code
  └── stdio
      └── npx @automattic/mcp-wordpress-remote
              └── HTTPS (Application Password auth)
                      └── WordPress REST API (/wp-json/mcp/...)
                              └── MCP Adapter plugin
                                      └── WordPress Abilities API

Requirements

• WordPress 6.9+
• Node.js (installed via nvm)
• MCP Adapter plugin activated on the WordPress site

Step 1: Install the MCP Adapter Plugin

Via WP-CLI on the server:

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

Or install manually from the GitHub releases page and activate in WP Admin → Plugins. Once active, the following REST API routes should be present:

/wp-json/mcp/
/wp-json/mcp/mcp-adapter-default-server

Step 2: Create a WordPress Application Password

1. Log into WP Admin → Users → Profile
2. Scroll to Application Passwords
3. Enter a name (e.g. claude-code) and click Add New Application Password
4. Copy the generated password — it is shown only once

Step 3: Install Node.js via nvm

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.nvm/nvm.sh
nvm install --lts

Step 4: Add the MCP Server to ~/.claude.json

Add the following under mcpServers in ~/.claude.json:

{
  "wordpress": {
    "type": "stdio",
    "command": "/home/user/.nvm/versions/node/v24.x.x/bin/npx",
    "args": ["@automattic/mcp-wordpress-remote"],
    "env": {
      "WP_API_USERNAME": "your-wp-username",
      "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx",
      "WP_API_URL": "https://yourdomain.com/wp-json/mcp/mcp-adapter-default-server",
      "PATH": "/home/user/.nvm/versions/node/v24.x.x/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    }
  }
}

Two critical details:

• WP_API_URL must be the full endpoint path, not a bare domain. Passing just https://yourdomain.com triggers legacy mode in the package, which targets the deprecated /wp-json/wp/v2/wpmcp endpoint and returns a 404.
• PATH must include the nvm Node path. Claude Code sessions do not source .bashrc or nvm, so without this, npx fails with env: 'node': No such file or directory.

Note: XML-RPC (/xmlrpc.php) is not used — the MCP Adapter uses the REST API exclusively. It can stay disabled.

Step 5: Restart Claude Code and Verify

MCP servers connect at session startup. After editing ~/.claude.json, start a new session. To verify the endpoint is reachable beforehand:

curl -s https://yourdomain.com/wp-json/mcp/ | python3 -m json.tool

Should list /mcp and /mcp/mcp-adapter-default-server routes. Once connected, WordPress tools will appear alongside any other MCP tools in the session.

Notes

• The @automattic/mcp-wordpress-remote package is downloaded on first use by npx and cached in ~/.npm/.
• For additional WordPress sites, add new entries under mcpServers with different keys (e.g. wordpress-staging).
• MCP servers only connect at session start — always start a new Claude Code session after changing MCP configuration.

Why MCP Instead of CLI

The CLI (mnemosyne store, mnemosyne recall) is a manual tool — you run it yourself and paste results back. The MCP integration makes Mnemosyne a first-class tool Claude can call directly, just like any other tool in a session.

Concretely, with MCP:

• Claude automatically stores and retrieves memories during a conversation without any manual intervention
• Memory reads and writes happen inline, so context is enriched transparently
• No copy-pasting: Claude calls mnemosyne_remember or mnemosyne_recall the same way it calls any other tool

The CLI remains useful for inspection (mnemosyne stats), backup (mnemosyne export), and manual management — but it is not a substitute for the MCP integration when Claude is the one that needs to remember things.

Step 0: Disable Claude Code’s Built-in Auto-Memory

Claude Code has its own file-based memory system that writes to ~/.claude/projects/*/memory/. It runs in parallel with Mnemosyne if not suppressed, duplicating everything. Disable it by adding the following to ~/.claude/CLAUDE.md (create it if it doesn’t exist — this file is loaded in every session regardless of working directory):

## Memory

**Use Mnemosyne exclusively for persistent memory.** Call `mnemosyne_remember` and `mnemosyne_recall` via MCP tools.

**Never write to the file-based auto-memory system** at `~/.claude/projects/*/memory/`. Do not create or edit files there. Do not create or update any `MEMORY.md` index files. That system is not used.

Step 1: Install via pipx

pipx install mnemosyne-memory

This installs the mnemosyne CLI to ~/.local/bin/mnemosyne.

Step 2: Install the Hermes Tool Schemas

The MCP server depends on mnemosyne-hermes for its tool definitions. It must be injected into the same pipx venv:

~/.local/share/pipx/venvs/mnemosyne-memory/bin/python -m pip install mnemosyne-hermes

Skip this and mnemosyne mcp will start and complete the protocol handshake but advertise zero tools — silently broken.

Step 3: Register the MCP Server

claude mcp add --scope user mnemosyne   -e MNEMOSYNE_DATA_DIR=$HOME/.local/share/mnemosyne   -- ~/.local/bin/mnemosyne mcp

This writes the entry to ~/.claude.json, which is where Claude Code 2.x reads MCP server definitions. Do not add it to ~/.claude/settings.json — that file is not used for MCP configuration.

Step 4: Set the Data Directory in Your Shell

So that the CLI uses the same database as the MCP server, add to ~/.bashrc:

export MNEMOSYNE_DATA_DIR="$HOME/.local/share/mnemosyne"

Then run source ~/.bashrc.

Step 5: Restart Claude Code and Verify

MCP servers connect at session startup. After completing the above, start a new Claude Code session, then check:

claude mcp get mnemosyne   # should show Status: ✔ Connected
mnemosyne stats            # confirms CLI hits the right database

Step 6: Install the Mnemosyne Dashboard (Optional)

The Mnemosyne Dashboard is a local-first web UI for browsing, visualising, and maintaining your memory store. It’s intentionally minimal: Python standard library server, static HTML/CSS/JS frontend, no external JS runtime, no cloud calls, and read-only by default.

Install via Hermes

hermes plugins install wysie/mnemosyne-dashboard --enable
hermes gateway restart

Run as a persistent systemd service (Linux)

If you want the dashboard to survive Hermes restarts, run it as a systemd user service instead. Create ~/.config/systemd/user/mnemosyne-dashboard.service:

[Unit]
Description=Mnemosyne Dashboard
After=network.target

[Service]
Type=simple
WorkingDirectory=%h/.hermes/plugins/mnemosyne-dashboard
ExecStart=python3 server.py --host 0.0.0.0 --port 8765 --db %h/.local/share/mnemosyne/mnemosyne.db
Restart=on-failure
RestartSec=5
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=default.target

Then enable and start it:

systemctl --user daemon-reload
systemctl --user enable mnemosyne-dashboard
systemctl --user start mnemosyne-dashboard

The dashboard will be available at http://localhost:8765/ (or your machine’s LAN IP if you bound to 0.0.0.0).

Configuration

Config lives at ~/.hermes/plugin-data/mnemosyne-dashboard/config.json. Key fields:

{
  "host": "0.0.0.0",
  "port": 8765,
  "db_path": "~/.local/share/mnemosyne/mnemosyne.db",
  "auth_enabled": false,
  "memory_admin_enabled": false
}

Memory admin (supersede, expire, importance updates) is disabled by default. If you enable it on a non-localhost bind address, password auth is required. Admin actions create a SQLite backup and append to an audit log — no hard deletes or raw overwrites are exposed.

Data Locations

Troubleshooting

MCP server connects but no tools appear

The mnemosyne-hermes package is missing from the pipx venv. Run Step 2 above. You can confirm by checking the tools/list response — if "tools":[], the package is missing.

CLI uses wrong database

The CLI default is ~/.hermes/mnemosyne/data/. Set MNEMOSYNE_DATA_DIR in ~/.bashrc (Step 4) to point it at the same path the MCP server uses.

Tools missing after restart

The config is probably in the wrong file. Claude Code 2.x reads MCP servers from ~/.claude.json, not ~/.claude/settings.json. Run claude mcp get mnemosyne — if it says “not found”, re-run Step 3.

A cleaner alternative, if your machines are already on Tailscale: skip the public internet entirely.

The Problem with Cloudflare and MCP

The @automattic/mcp-wordpress-remote package connects to WordPress via the REST API using HTTP Basic Auth (Application Passwords). Any edge layer that interferes with those REST API calls can silently break the connection. Common culprits when routing through Cloudflare:

• Bot Fight Mode blocking REST API POSTs
• Page caches returning stale or HTML responses on JSON endpoints
• Host WAFs blocking requests based on User-Agent strings
• Security plugins blocking access to the MCP endpoint

The Tailscale Approach

Since Claude Code runs the MCP client locally, it only needs the WordPress server to be reachable from the local machine — not from Anthropic’s servers. If both machines are on the same Tailscale network, you can route traffic directly over Tailscale by pinning the domain in /etc/hosts:

100.x.x.x        yourdomain.com
fd7a:xxxx::xxxx  yourdomain.com

Both IPv4 and IPv6 entries are needed. Without the IPv6 entry, DNS can still return Cloudflare’s AAAA records and route around the pin.

With this in place, yourdomain.com resolves to the Tailscale IP, traffic goes peer-to-peer, and none of the Cloudflare/WAF/cache layers are involved. The SSL certificate remains valid because the hostname matches.

The Plugin

The active WordPress MCP plugin is WordPress/mcp-adapter (not the older wordpress-mcp repo, which is deprecated). The endpoint lives at:

https://yourdomain.com/wp-json/mcp/mcp-adapter-default-server

Authentication is WordPress Application Passwords (Users → Profile → Application Passwords) via HTTP Basic Auth. XML-RPC is not involved.

MCP Client Configuration

In your Claude Code MCP config (~/.claude.json):

{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": ["@automattic/mcp-wordpress-remote"],
      "env": {
        "WP_API_URL": "https://yourdomain.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "your-wp-username",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx",
        "PATH": "/home/user/.nvm/versions/node/v24.x.x/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      }
    }
  }
}

Two critical details:

• WP_API_URL must be the full endpoint path, not just the domain. Passing a bare domain puts the package into legacy mode, where it targets /wp-json/wp/v2/wpmcp — the old deprecated plugin’s endpoint — returning a 404.
• PATH must be set explicitly if Node is installed via NVM. Claude Code’s environment doesn’t inherit your shell’s NVM paths, so without this the npx call fails to find Node.

Result

A successful MCP handshake returns a session ID and server info:

{"protocolVersion":"2024-11-05","serverInfo":{"name":"MCP Adapter Default Server","version":"v1.0.0"}}

No tunnels, no WAF exceptions, no cache exclusion rules — just a direct Tailscale connection to your own server.

Meralco is a utility company. It is not a bank, an e-wallet provider, or a financial institution holding customer funds. The information it needs to protect—customer name, service address, and billing amount—is important, but it does not carry the same risk profile as banking credentials or stored monetary value. The security approach should reflect that difference.

A Bill You Can See but Not Easily Get

When Meralco notifies customers that a monthly bill is available, the notification already displays the bill amount. That means the information is already deemed safe enough to transmit. Despite that, the actual PDF copy of the bill is not included.

To obtain it, customers must log in to the website, navigate through several pages, dismiss pop-ups, and repeat the process for each registered account each month. All this just to download a document that could have been emailed to me in the first place. Encrypt the PDF if you want—I do not care. Just send it.

Login Restrictions That Add Friction, Not Security

The login experience also raises questions about proportionality.

Pasting a password is allowed, but keyboard-based autofill—commonly used by password managers to populate both email address and password—is blocked. This forces manual entry of the email address while offering no meaningful improvement in security. It prevents convenience, not misuse.

Logging in from a different device also requires a one-time password sent to a registered mobile number. This is reasonable for high-risk actions, but for viewing or downloading a bill, it feels misaligned with the nature of the transaction. There are no funds to move—only a balance to view.

Repeating the Same Process, Every Month

For users managing multiple Meralco accounts under one profile, this experience is multiplied. Using the website for account administration is understandable. Being required to go through the same multi-step process every month, for every account, just to download bills is not.

This is a problem with workflow design, not user behavior.

A Simpler, More Balanced Approach

Emailing the monthly bill as a PDF would resolve most of these issues immediately. The website can remain the place for account management and changes. Routine access to a billing document should not require repeated navigation through a heavily restricted interface.

Good digital security should be based on balance—strong where risk is high, and simple where it is not.

Platform	GitHub Stars	Self-hosted	Focus / Best Use Case
n8n	159k	Yes	General-purpose workflow automation with powerful code node. Ideal for complex multi-service automations and ETL tasks.
Activepieces	19.3k	Yes	Low-code/no-code automation with occasional custom JS support. Good for lighter, simpler workflows.
Windmill	15.2k	Yes	Developer-centric automation using scripts (Python/TypeScript/Go). Great for internal tools and backend workflows.
Automatisch	13.4k	Yes	Simplified Zapier-style automation. Best for small, straightforward tasks when ease and self-hosting matter.

Summary: n8n remains the most powerful and versatile, while Activepieces and Windmill offer lighter or more code-centric alternatives. Automatisch is best if you just need simple self-hosted automations.

The whole ecosystem—themes, plugins, and even the support culture—has turned into a marketplace. Everywhere you go, there’s an upsell. Basic features sit behind paywalls. And if you just want to build a straightforward blog, the experience is frustrating.

Finding a minimalist theme with a clean two-column layout, no widget blocks, no theme blocks, no Gutenberg clutter, and no upgrade prompts used to be easy. Now it feels like searching for something that shouldn’t be rare. Most themes are bloated with builders, bundled features, and aggressive pro-version hooks.

The open-source spirit that made WordPress welcoming has given way to commercial noise. WordPress is still free at its core, but the culture around it has shifted. For someone who simply wants a clean, honest blogging theme, it’s hard not to feel like WordPress has lost its soul.

Paying bills has never been easier, thanks to the advent of mobile payment solutions like GCash and Maya. However, my recent experience with GCash highlighted a significant issue that needs addressing.

The Issue with Spam SMS

Recently, I was paying for my Globe Postpaid plan and decided to use GCash for the transaction. However, in the past few days, I’ve been inundated with spam marketing SMS from GCash. The frequency and irrelevance of these messages were frustrating, so I decided to block GCash in my Google Messages app.

The Unintended Consequence

When I attempted to pay my bill via GCash, I didn’t receive the OTP (One-Time Password) required to complete the transaction. It quickly dawned on me that GCash was blocked, preventing the OTP from coming through. I unblocked GCash temporarily, but the OTP still took too long to arrive. This delay was unacceptable, especially when trying to complete a time-sensitive transaction.

Switching to Maya

Frustrated by the inconvenience, I turned to Maya for my payment. The process was smooth, and I received the OTP without any issues. This experience was a stark contrast to the one I had with GCash and highlighted a crucial lesson for businesses: customer satisfaction is paramount.

The Impact of Spam SMS

Spam SMS not only annoy customers but can also lead to significant business losses. When customers are overwhelmed with irrelevant messages, they’re likely to block the sender, missing out on important communications like OTPs. This leads to frustration and can drive customers to competitors, as it did in my case.

A Call to Action for Businesses

For businesses utilizing SMS for marketing, it’s crucial to strike a balance. While reaching out to customers is essential, bombarding them with spam can backfire. One effective strategy is to limit marketing messages to a separate account, distinct from the one used for important communications like OTPs. Additionally:

1. Opt-in Preferences: Allow customers to choose the type of messages they want to receive.
2. Frequency Control: Limit the number of marketing messages sent within a certain period.
3. Relevance: Ensure that messages are relevant to the customer’s interests and needs.

Conclusion

My experience underscores the importance of thoughtful and strategic communication with customers. By respecting customer preferences and reducing spam, businesses like GCash can improve customer satisfaction and retain their user base.

In the end, the key takeaway is clear: respect your customers’ communication preferences, or risk losing them to competitors who do.