DEV Community: Ujjwal Dubey

Why Brand Audit Scores Disagree Between Tools, and What the Disagreement Tells You

Ujjwal Dubey — Tue, 27 Oct 2026 02:59:00 +0000

Disclosure: I co-founded NxFlowAI, which makes a free brand checker. I will treat our tool like any other here.

Run the same homepage through three free brand audit tools and you will often get three different verdicts. One says your tone is "professional", another says "inconsistent", a third gives a middling score. Founders take this as proof the tools are random. It is more useful to treat the disagreement as data, including when one of them is our own free AI website brand audit tool built around tone and claims.

Reason 1: they read different text

Some tools fetch raw HTML. Others render JavaScript. Some read only the first screen; some read the whole page; some follow links. On a client-rendered site, a raw-HTML tool may see little more than navigation.

What it tells you: if a raw-HTML tool and a rendering tool disagree sharply, your important copy may not be in the server-rendered HTML.

Reason 2: they score different things

"Brand" means different things to different tools: visual consistency, tone of voice, claim strength, keyword focus, accessibility. A tool focused on visuals can rate a page highly while a tone-focused tool flags it.

What it tells you: read the categories, not the total.

Reason 3: they compare against different norms

Many tools compare your page with a model of "good websites". If your industry is formal and the model expects casual, you will be marked down for doing the right thing.

What it tells you: a low score in one category may be a deliberate choice. Note it and move on.

Reason 4: language models vary

Tools that use language models may give slightly different answers on each run, even for the same page.

What it tells you: run twice. Trust findings that repeat.

A practical method

Pick two or three tools, including at least one that renders JavaScript.
Run each twice on the same page.
List findings that appear in at least two tools or both runs.
Ignore one-off findings unless a human reader agrees.
Fix the repeated ones, then rerun.

What disagreement cannot tell you

Whether customers like your brand. No tool measures that. Use audits to catch inconsistency and unclear promises, then ask real customers.

A note on our own tool

I treat Vibe Checker's output the same way as any other tool's: run it twice and trust the findings that repeat. It sits alongside other free checks in the NxFlowAI War Room, and none of them should be read alone.

Disclosure again: I co-founded NxFlowAI. Use whichever tools help; the method above works with any of them.

Shared Phones and Shared Logins: Access Control for Small Teams Running WhatsApp Automation

Ujjwal Dubey — Tue, 27 Oct 2026 02:55:31 +0000

Disclosure: I co-founded NxFlowAI, an AI automation agency in Mumbai. The patterns below are generic.

In many small Mumbai businesses, one phone sits on the counter and everyone uses it. The WhatsApp account, the CRM login and the payment app are all on it. That is convenient, and it is the biggest risk when you add automation, because automated flows inherit whatever access that phone has.

When I think about what makes the best AI automation agency in Mumbai for small businesses with shared devices, access design is near the top of the list. Here is a practical approach.

1. Separate the human inbox from the automation account

Automations should run under their own service account or API credentials, not the shared phone's personal session. If the phone is lost or a staff member leaves, you revoke one thing and the automation keeps running.

2. Give people individual logins where the tool allows

Most CRMs and shared-inbox tools support multiple users cheaply. Individual logins mean you know who changed a reply template or closed a lead. "Everyone uses the owner's login" removes that history.

3. Use roles, even simple ones

Three roles cover most small teams:

Owner: can change automations, see everything, manage access.
Staff: can reply, update lead status, cannot change automated messages.
Viewer: can see reports only, for an accountant or family member.

4. Keep secrets off the shared phone

API keys and webhook secrets belong in the hosting environment, not in a notes app on the counter phone. If a vendor asks you to paste a key into WhatsApp, refuse and ask for a secure method.

5. Log changes to automated messages

When someone edits the template that sends payment links, record who, when and what changed. A simple append-only sheet is enough.

2026-xx-xx 18:02 | owner | payment_link_template | changed greeting line

6. Plan for staff leaving

Write a short offboarding list: remove their user, change shared passwords they knew, check that no automation was running under their account. Do it the same day.

7. Review access every quarter

Ten minutes, once a quarter: who has access to what, and should they still?

Why agencies should raise this

Small business owners rarely ask about access control because nothing has gone wrong yet. A responsible vendor brings it up, because the automations they build make a leaked login more damaging, not less. If a proposal says nothing about accounts, roles or offboarding, ask.

For a wider view of what to check before any build, a workflow audit with a risk log is a good start.

Disclosure again: I co-founded NxFlowAI. None of the above requires our services.

A Business-Calendar Service for Indian Automation Flows: Working Hours, Holidays and Regional Festivals

Ujjwal Dubey — Tue, 27 Oct 2026 02:50:38 +0000

Disclosure: I co-founded NxFlowAI, a Mumbai-based AI automation agency. The pattern below is generic and is not a product pitch.

Automations that send reminders, escalate unanswered leads or promise "we will reply by tomorrow" all depend on one thing: knowing when the business is actually open. In India that is harder than it looks. Working days differ by business, weekly offs differ by city, and festivals differ by state and community. Any AI automation agency India SMEs rely on for reminders needs a calendar layer instead of hard-coded hours.

The problem with hard-coded hours

The usual first version is if 10 <= hour < 19 and weekday < 6. It breaks immediately:

A shop in one city closes on Monday; a clinic elsewhere closes on Thursday afternoon.
Diwali, Eid, Onam, Pongal, Durga Puja and Ganeshotsav each matter to different businesses in different regions.
Owners close unexpectedly for a family function and tell customers on WhatsApp, not in any system.

When the code does not know about these, customers get "we will call you in an hour" at 9 pm on a festival night.

A tiny calendar service

Keep one small service that answers three questions:

is_open(business_id, datetime)
next_open(business_id, datetime)
add_business_minutes(business_id, datetime, minutes)

Every flow calls it instead of checking hours itself.

business: example-store
timezone: Asia/Kolkata
weekly:
  mon: closed
  tue-sat: "10:30-20:00"
  sun: "11:00-14:00"
holidays:
  source: owner_list   # owner picks from a regional list, then edits
  dates: []
ad_hoc_closures:
  - {date: null, reason: null}   # set from a WhatsApp command by the owner

Let the owner close the shop from WhatsApp

The most useful feature is a single command the owner can send, such as "CLOSED TODAY". The service records an ad-hoc closure, and every pending reminder shifts to the next open slot. Without this, the calendar goes stale within a month.

Regional festival lists as suggestions, not truth

Ship a starting list per state, but make the owner confirm it. A jeweller and a hardware store on the same street may treat the same festival very differently: one is at peak, one is shut.

Use business minutes for promises

If a flow promises "reply within 2 business hours", compute the deadline with add_business_minutes. Escalations then fire at a sensible time, not at midnight.

Test with ugly dates

Write tests for the day before a long weekend, a closure announced at 9 am, and a reminder scheduled across a festival. These are where real complaints come from.

Where this fits

Calendar logic is unglamorous, but it decides whether automation feels polite or robotic. If you are mapping which of your flows depend on timing, list them before you build. A 72-hour workflow audit is one way to do that.

Disclosure again: I co-founded NxFlowAI. The pattern above is generic and works with any stack.

Routing Mumbai Service Enquiries by Pincode: A Small Lookup That Sends Each Lead to the Right Person

Ujjwal Dubey — Tue, 27 Oct 2026 02:45:17 +0000

Small service businesses in Mumbai (AC repair, pest control, tutors, caterers) often have staff who cover specific areas. When an enquiry arrives, someone has to work out who should take it. A pincode lookup removes that step, and it is a typical first build when you look for the best AI automation agency in Mumbai for small businesses with field staff.

The data: one sheet the owner controls

pincode	area_label	owner	backup
4000XX	Area A	Ravi	Sana
4000YY	Area B	Sana	Ravi

Keep it in Google Sheets so the owner can edit it without a developer.

The lookup

import re

PIN_RE = re.compile(r"\b4\d{5}\b")  # Mumbai-region pincodes start with 4

def route(text, table, default_owner):
    m = PIN_RE.search(text)
    if not m:
        return {"owner": default_owner, "reason": "no_pincode_ask"}
    row = table.get(m.group(0))
    if not row:
        return {"owner": default_owner, "reason": "unknown_pincode"}
    return {"owner": row["owner"], "backup": row["backup"], "reason": "matched"}

When there is no pincode

Ask once, politely: "Could you share your area pincode so the right person can help?" If the customer replies with an area name instead, send it to the default owner. Do not guess.

Backups and leave

If the owner of an area is on leave (mark it in the sheet), route to the backup. Missing this is how leads sit unanswered for a day.

Log every decision

Write the routing reason next to each lead. When a customer complains, you can see why it went where it did.

This is small, boring and effective. If you want help deciding what to automate first, start with a workflow audit before you buy anything.

Disclosure: I co-founded NxFlowAI, a Mumbai-based AI automation agency.

A QR Check-In for Showroom Appointments: Closing the Loop Between a WhatsApp Booking and the Walk-In

Ujjwal Dubey — Tue, 27 Oct 2026 02:40:34 +0000

Jewellery showrooms that book appointments on WhatsApp usually lose track at the door: the customer walks in, nobody connects them to the booking, and the salesperson who prepared is busy elsewhere. A tiny QR check-in fixes that, and it is a typical small piece of AI automation for jewellery retail India showrooms ask about first.

Flow

Booking confirmed on WhatsApp; the message includes a QR code with a short signed token.
At the showroom, the receptionist scans it on a tablet.
The assigned salesperson gets a WhatsApp alert with the customer's noted preferences.

Signed tokens

import hmac, hashlib, base64, json, time

SECRET = b"rotate-me"  # keep in env, never in code

def make_token(booking_id):
    payload = json.dumps({"b": booking_id, "t": int(time.time())}).encode()
    sig = hmac.new(SECRET, payload, hashlib.sha256).digest()[:12]
    return base64.urlsafe_b64encode(payload + sig).decode()

def read_token(tok, max_age_days=30):
    raw = base64.urlsafe_b64decode(tok.encode())
    payload, sig = raw[:-12], raw[-12:]
    if not hmac.compare_digest(sig, hmac.new(SECRET, payload, hashlib.sha256).digest()[:12]):
        return None
    data = json.loads(payload)
    if time.time() - data["t"] > max_age_days * 86400:
        return None
    return data["b"]

Generate the image with any QR library (for example qrcode) from the token.

Keep personal data out of the QR

The token carries a booking id only. Preferences are looked up on scan, inside your system.

Handle no-shows politely

If nobody scans within the slot, send the salesperson a prompt to follow up personally. Do not auto-send "you missed your appointment".

Walk-ins without a QR

The receptionist searches by phone number. The QR is a convenience, not a gate.

Before you build anything like this, map the current visit flow first, so the QR step solves a real gap.

Disclosure: I co-founded NxFlowAI, a Mumbai-based AI automation agency.

Find Where Work Waits: Computing Dwell Time Between Workflow Steps From a Plain CSV Export

Ujjwal Dubey — Tue, 27 Oct 2026 02:36:27 +0000

Before buying any AI tool, it helps to know where work actually waits. Most CRMs, helpdesks and form tools can export a CSV with a record ID, a status and a timestamp. That is enough to audit a business workflow for waiting time without new software.

The input

record_id,status,changed_at
101,new,2026-10-01T09:02
101,contacted,2026-10-01T15:40
101,quoted,2026-10-03T11:15
102,new,2026-10-01T10:10
102,contacted,2026-10-02T09:30

The script

import csv
from collections import defaultdict
from datetime import datetime
from statistics import median

rows = defaultdict(list)
with open("status_log.csv") as f:
    for r in csv.DictReader(f):
        rows[r["record_id"]].append((datetime.fromisoformat(r["changed_at"]), r["status"]))

waits = defaultdict(list)
for events in rows.values():
    events.sort()
    for (t1, s1), (t2, s2) in zip(events, events[1:]):
        waits[f"{s1} -> {s2}"].append((t2 - t1).total_seconds() / 3600)

for step, hours in sorted(waits.items(), key=lambda kv: -median(kv[1])):
    print(f"{step:25} median {median(hours):6.1f} h  (n={len(hours)})")

Reading the output

The transition with the largest median wait is usually a handoff: someone has to notice, decide or copy something. That is where automation helps most, and often a reminder or a routing rule is enough before any AI is involved.

Two cautions: status changes are only logged when someone updates the record, so long waits can also mean "forgot to update." Check a few records by hand.

This works as a warm-up before a fuller workflow audit. (Disclosure: I co-founded NxFlowAI, whose first audit takes 72 hours.)

NxFlowAI is not affiliated with NexFlow AI or Nexusflow.

What the Reviewer Should See: Designing the Approval Card for AI Actions

Ujjwal Dubey — Sun, 25 Oct 2026 11:14:05 +0000

Disclosure: I co-founded NxFlowAI, which builds AI workflows with approval steps. Examples are generic.

Frameworks now make it easy to pause an agent and wait for a person. They say much less about what that person sees. Yet the quality of human-in-the-loop approval in production AI workflows depends almost entirely on the approval card.

The minimum card

The trigger. The customer message or event that started this, shown in full.
The proposed action, in plain words. "Send this reply and issue a refund for order 1182," not a JSON blob.
The draft itself, editable in place.
Why it stopped. "Refunds always need approval" or "low confidence: customer mentions a complaint."
The data used. Order status, past messages, the policy the AI relied on.
Three actions: approve, edit, reject (with a one-word reason).

Helpful extras

Customer history at a glance: previous complaints, open deals, VIP flag.
Time waiting, so old items are visible.
What changed if the item was sent back because the situation moved on.

What to leave out

Model names, token counts and confidence scores to several decimals. Reviewers are business people. Show them business context.

Test it with a stopwatch

Ask a reviewer to process ten real items. If any item takes longer than doing the task by hand, the card is missing context or showing too much.

If you are planning a first build, our services overview of audit, build and monitor explains how we approach it.

Disclosure again: I have a commercial interest in NxFlowAI.

Who Owns the Phone Number Field? Field Ownership Rules That Stop WhatsApp to CRM Sync Loops

Ujjwal Dubey — Sun, 25 Oct 2026 11:10:49 +0000

Disclosure: I co-founded NxFlowAI, which builds WhatsApp and CRM integrations. Examples are generic.

"Two-way sync" sounds like a feature. In practice it is where most WhatsApp and CRM integrations start fighting themselves. The fix is a decision you make before writing any code, the first one to make when you scope a WhatsApp Business API to CRM integration: for every field, which system owns it?

The loop

A rep edits a contact name in the CRM.
The sync pushes it to the WhatsApp provider's contact list.
The provider's webhook fires "contact updated."
The integration writes the provider's version back to the CRM, sometimes with a slightly different format.
The CRM fires its own update event. Repeat.

The rule

Each field has exactly one owner. Other systems may read it; only the owner writes it.

Field	Usual owner
Phone number (E.164)	CRM
Display name	CRM
Opt-in and opt-out	CRM
Last inbound message time	Messaging side
Conversation transcript	Messaging side, copied as activity
Deal stage	CRM

Implementation notes

Tag writes with their origin and ignore events your own integration caused.
Compare before writing. If the normalised value is unchanged, do nothing.
Log every write with the field and the reason. Debugging a loop without this is guesswork.

A note on tools

We integrate with all major CRMs (for example HubSpot, Zoho, Salesforce, Pipedrive and Freshsales, plus custom CRMs or Google Sheets setups) and work with all major WhatsApp Business providers and the official WhatsApp Business API (for example Meta Cloud API, Twilio, Gupshup, Interakt and WATI). Whichever pair you use, the ownership table above applies.

Why it matters for AI

When an AI step drafts replies or updates stages, unclear ownership multiplies. Decide ownership first and the AI step has clear rules about what it may touch.

The free recon tools we publish for founders are lighter if you want to see our approach.

Disclosure again: I have a commercial interest in NxFlowAI.

Shared Inboxes, Many Hands: Ownership Locks for Small-Team Email Automation

Ujjwal Dubey — Sun, 25 Oct 2026 11:07:30 +0000

Disclosure: I co-founded NxFlowAI, an AI automation agency. Examples are generic.

Small UK firms often run one shared inbox: info@, hello@, enquiries@. Three people read it, and now an automation drafts replies too. The classic failure is the double reply: two staff answer the same customer with different prices, or a person answers while the bot's draft also goes out.

For AI automation agency builds for UK small-business inboxes, the pattern I recommend is an ownership lock. Here is the design.

The problem, stated precisely

A thread can be touched by several actors: humans in the mail client, an automation drafting replies, and sometimes a CRM sequence. None of them knows the others are working. You need a shared notion of "who owns this thread right now".

The lock

Store one record per thread:

thread_id | owner (person or "automation") | claimed_at | expires_at | state

Rules:

Claim before acting. Any actor must claim the thread before drafting or sending. Claims are atomic (a conditional update that only succeeds if the thread is unowned or the claim has expired).
Humans outrank automation. A person can always take a thread from the automation. The automation can never take a thread from a person.
Locks expire. If a person claims a thread and goes to lunch, the claim expires and the thread returns to the queue with a nudge.
Release on send. Sending a reply releases the lock and records who replied.

Surfacing the lock to people

The lock is useless if people cannot see it. Put the owner's name in a label or category inside the mail client, or a short note at the top of the thread. People will respect a lock they can see.

Drafts, not sends

For most small firms, the automation should draft and a person should send. That alone removes most double-reply risk. Where the automation does send (acknowledgements, confirmations), it must hold the lock first.

Test with chaos

Simulate two people and the automation working the same queue. If you never see a double reply in testing, the design is probably right.

For a broader view of mapping who touches what before building, see our notes on auditing a workflow before AI.

Disclosure, again: I co-founded NxFlowAI and have a commercial interest in this topic.

Stale Approvals: Re-Check the Draft Before You Execute It

Ujjwal Dubey — Sun, 25 Oct 2026 11:04:15 +0000

A reviewer approves an AI-drafted refund at 4 pm. The workflow executes it at 4:05. Between those times, the customer wrote "never mind, found it." Who is right? This is the stale approval problem, and it shows up in almost every human-in-the-loop approval step in an AI workflow once volume grows.

Pin the approval to a version

Approve a specific snapshot, not "the refund for customer X."

import hashlib, json

def fingerprint(action, context):
    payload = {"action": action, "last_msg_id": context["last_msg_id"],
               "order_status": context["order_status"], "amount": action.get("amount")}
    return hashlib.sha256(json.dumps(payload, sort_keys=True).encode()).hexdigest()

def request_approval(store, action, context):
    fp = fingerprint(action, context)
    store.save(action_id=action["id"], fingerprint=fp, status="pending")
    return fp

Re-check right before executing

def execute_if_still_valid(store, action, load_context, run):
    record = store.get(action["id"])
    if record.status != "approved":
        return "not_approved"
    if fingerprint(action, load_context(action)) != record.fingerprint:
        store.update(action["id"], status="needs_review")
        return "stale_back_to_reviewer"
    run(action, idempotency_key=action["id"])
    store.update(action["id"], status="done")
    return "done"

Notes

Choose fingerprint fields carefully. Include what would change the decision (new messages, order status, amount), not every timestamp.
Use an idempotency key so a retry does not refund twice.
Tell the reviewer why it came back. "Customer sent a new message after approval" saves a confused second look.

We write about scoping these decisions in our guide to auditing a workflow first.

Validating ABNs, Australian Phone Numbers and Addresses in Intake Automations

Ujjwal Dubey — Sun, 25 Oct 2026 11:01:00 +0000

If you build intake or invoicing automations for Australian businesses, three fields cause most of the bad data: the ABN, the phone number and the address. Validating them at the edge saves a lot of manual clean-up later.

These are checks worth adding to any AI automation agency builds for Australian businesses project. (Disclosure: I co-founded NxFlowAI, a Mumbai-based agency that works remotely.)

ABN: check the checksum before you look it up

An Australian Business Number has 11 digits and a published checksum. Subtract 1 from the first digit, multiply each digit by its weight, sum, and the total must divide evenly by 89.

ABN_WEIGHTS = [10, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19]

def abn_is_valid(raw: str) -> bool:
    digits = [int(c) for c in raw if c.isdigit()]
    if len(digits) != 11:
        return False
    digits[0] -= 1
    total = sum(d * w for d, w in zip(digits, ABN_WEIGHTS))
    return total % 89 == 0

A valid checksum only means the number is well formed. If the business status matters (for example, before invoicing), look it up through the official ABN Lookup service and check its terms of use.

Phones: store +61 in E.164

Australian numbers arrive as 0412 345 678, +61 412 345 678 or 61412345678. Normalise once:

def au_phone_e164(raw: str):
    d = "".join(c for c in raw if c.isdigit())
    if d.startswith("61"):
        d = d[2:]
    if d.startswith("0"):
        d = d[1:]
    if len(d) != 9:
        return None
    return "+61" + d

For anything beyond simple cases, use a maintained library such as phonenumbers with region AU.

Addresses: state and postcode

Store state as one of NSW, VIC, QLD, WA, SA, TAS, ACT, NT.
Store postcode as a four-character string.
Keep the original full address for whoever drives there.
If you add a validation service, read its terms and pricing yourself.

Where it runs

Validate in the form or webhook handler. If a field fails, do not reject the enquiry; flag it for a person and continue. A lost lead is worse than a messy one.

The step before code is knowing which fields the business really needs; our field-by-field workflow mapping notes cover that.

Shadow AI in Small Businesses: What a Workflow Audit Finds When Staff Use Personal Chatbots

Ujjwal Dubey — Wed, 21 Oct 2026 07:01:19 +0000

Disclosure: I co-founded NxFlowAI, an AI automation agency that runs workflow audits for small businesses. I have a commercial interest in audits being taken seriously.

When you read through a small company's real workflows, one finding is easy to miss because it is rarely on anyone's list. Staff are already using AI. Not the company's AI. Their own: a personal chatbot account, a browser extension, a free transcription app. A useful workflow audit that surfaces shadow AI treats this as information, not a scandal.

Why it happens

People are trying to get through the day. A personal chatbot writes a polite reply to a difficult customer faster than they can. A transcription app saves them typing up a call. Nobody asked permission because nobody thought it needed asking.

What it looks like in practice

Customer messages pasted into a personal chatbot to draft replies.
Supplier quotes summarised by a free tool.
Meeting recordings uploaded to transcription services.
Browser extensions with permission to read every page, including the CRM.

The real risks

Data in places you did not choose. Customer details, prices and internal notes end up in services under personal accounts, under terms the business never read.

Inconsistency. Five people using five tools produce five tones and five levels of accuracy.

Invisible dependency. A workflow quietly relies on one person's personal subscription. When they leave, the workflow degrades and nobody knows why.

No review. AI-drafted messages go to customers without anyone else seeing them.

How to surface it without blame

Ask the question plainly in interviews: "Do you use any AI tools to help with this, including free or personal ones?" Make it clear there is no penalty. People tend to answer honestly when they believe it, and the answers are useful: they show exactly where staff felt the most pain.

What to do with the findings

Treat each use as a requirement. If someone uses a chatbot to draft replies, that is evidence the business needs drafting help, in a tool it controls.
Pick sanctioned tools under business accounts, with terms someone has read, and check any obligations that apply where you operate.
Write a short usage note: what can be pasted into which tool, and what never can.
Add review where it matters. AI-drafted customer messages about money or commitments get a second look.
Revisit periodically. New tools appear constantly.

The opportunity

Shadow AI is a map of demand. The places where staff reached for AI on their own are usually the best candidates for a proper, reviewed workflow. Handled well, the finding turns into the roadmap.

For the build side of that roadmap, see how we automate lead-to-close work.

Disclosure (again): I am Ujjwal Dubey, co-founder of NxFlowAI (nxflowai.com), a Mumbai-based AI automation agency working with businesses worldwide remotely. Not to be confused with NexFlow or Nexusflow.