DEV Community: Sushil Barwal

Human Handoff for Website AI Chatbots: A Spec You Can Actually Build From

Sushil Barwal — Wed, 11 Nov 2026 07:38:37 +0000

Most website chatbot projects spend weeks on the model, the prompt and the knowledge base, then bolt on "talk to a human" in the last sprint. That's backwards. For a business site, the handoff is where leads are won or lost: the visitor who asks something the bot can't answer is usually the one with a real, specific need.

This is the handoff spec we start from when we build a chatbot for a client's website. It's stack-agnostic: it works whether the bot runs on OpenAI, Claude or Gemini, and whether the human side is Intercom, Zendesk, Slack, email or a plain CRM task.

1. Decide what triggers a handoff

Write the triggers down before you write any code. We use five:

The visitor asks for a person. Phrases like "speak to someone", "human", "agent", "call me". Detect these with a simple classifier or a keyword list; don't leave it to the main model's mood.
Low confidence. The retrieval step found nothing relevant above your threshold, or the model says it doesn't know. Log the score so you can tune the threshold later.
Restricted topics. Refunds over a set amount, complaints, legal questions, medical or financial advice, anything about a specific account. These go straight to a person, with no attempt to answer.
Buying signals. A quote request, a booking, a "how soon can you start?". The bot can collect details, but a person should follow up quickly.
Loops. The same question rephrased three times, or three "that didn't help" replies in a row.

Make each trigger a named reason (USER_REQUEST, LOW_CONFIDENCE, RESTRICTED_TOPIC, BUYING_SIGNAL, LOOP). You'll need the reason later for routing and reporting.

2. Collect the minimum before you hand over

A handoff with no context makes the visitor repeat themselves. A handoff that demands ten form fields loses them. Ask for only what the person picking it up needs:

name
the best contact method (email or phone) and consent to be contacted
a one-line summary of the problem, which the bot can draft and the visitor can confirm

Store consent as a boolean with a timestamp and the wording shown. If you serve visitors in the UK or EU, this is the kind of record your privacy team will ask for.

3. Business hours change the promise, not the flow

The bot must never promise "someone will be with you shortly" at 2 a.m. on a Sunday. Keep the flow the same, but change the message:

{
  "timezone": "America/Chicago",
  "hours": { "mon-fri": "09:00-18:00" },
  "in_hours_message": "I'm passing this to the team now. Most replies arrive within 15 minutes.",
  "out_of_hours_message": "The team is offline right now. I've saved your question and they'll reply by email on the next working day."
}

If your team covers several markets (say Dallas and Toronto), keep one schedule per queue rather than one global schedule.

4. The handoff payload

This is the contract between the bot and whatever your team uses. Keep it boring and versioned:

{
  "version": 1,
  "conversation_id": "c_8f2a...",
  "reason": "BUYING_SIGNAL",
  "summary": "Wants a WhatsApp chatbot for 3 clinics, asks about timeline",
  "visitor": {
    "name": "Jordan",
    "email": "jordan@example.com",
    "consent": { "given": true, "at": "2026-11-11T09:12:44Z", "text_id": "consent-v3" }
  },
  "page_url": "https://example.com/pricing/",
  "utm": { "source": "google", "campaign": "brand" },
  "transcript_url": "https://internal.example.com/conversations/c_8f2a",
  "retrieval": { "top_score": 0.41, "sources": ["/services/", "/faq/"] }
}

A few rules we follow:

Send a link to the transcript, not the whole transcript, when the destination is email or chat. It keeps personal data in one place and lets you apply access controls.
Include the page URL and UTM data. Sales teams care which page and campaign produced the conversation.
Include the retrieval score. When you review handoffs weekly, low scores show you which questions your content doesn't answer yet.

5. Route by reason

Reason	Destination	Target response
BUYING_SIGNAL	CRM deal + sales channel alert	same working hour
USER_REQUEST	support inbox or live chat	per your support SLA
RESTRICTED_TOPIC	named owner (e.g. billing)	same working day
LOW_CONFIDENCE	support inbox, tagged for content review	same working day
LOOP	support inbox, tagged "bot failure"	same working day

A webhook to an automation tool (n8n, Make or Zapier) is usually the simplest way to fan this out, because routing rules change more often than bot code.

6. Tell the visitor what happened

After the handoff, the bot should say exactly three things: that a person has the conversation, when they can expect a reply, and where the reply will arrive. Then stop answering new questions in that thread, or clearly mark further answers as automated, so the visitor isn't confused about who is talking.

7. Measure it

Track these weekly:

handoff rate by reason
time to first human reply, split by in-hours and out-of-hours
share of BUYING_SIGNAL handoffs that became a booked call or quote
top 20 LOW_CONFIDENCE questions, which become your next content updates

If the LOW_CONFIDENCE list keeps shrinking, the bot is getting better. If the BUYING_SIGNAL reply time keeps growing, the bot is working and your team isn't keeping up, which is a good problem but still a problem.

FAQ

Should the bot try once before handing off on a restricted topic?
No. For complaints, refunds and anything legal or account-specific, a fast handoff is better than a confident wrong answer.

Can the handoff happen inside the same chat window?
Yes, if your live-chat tool supports it. Many teams start with email and a CRM task, then add in-window live chat once volume justifies staffing it.

What confidence threshold should we use?
There's no universal number. Start conservative, log every score, and review 50 handoffs after the first two weeks to tune it.

Do we need consent before collecting an email address?
Ask for consent to contact the visitor and record it. The exact wording depends on where your visitors are; check it with whoever owns privacy in your business.

We design these flows as part of our AI chatbot development work for US businesses, from the handoff rules to the CRM routing.

Shopify Checkout Customisation by Plan: What Developers Can Build Without Plus (and What Needs It)

Sushil Barwal — Tue, 10 Nov 2026 05:49:13 +0000

Sooner or later a merchant asks for something inside checkout: a delivery-date picker, a gift message, a rule that hides a payment method for certain orders, a wholesale discount nobody sells as an app. The first question isn't "how do we build it?" but "which Shopify plan does this need?", because the answer decides whether the job costs a few days or a plan upgrade.

Here's how we map checkout requests to plans, based on Shopify's developer docs as of November 2026.

The three tools you'll use

Since checkout.liquid was retired, checkout is customised with three things:

Checkout UI extensions: React-style components rendered at defined extension targets in checkout, the Thank you page and the Order status page.
Shopify Functions: server-side logic (compiled to WebAssembly) that Shopify runs for discounts, delivery customisations, payment customisations, cart validation and more.
Checkout branding: colours, fonts, corner radius and so on, via the checkout editor or the GraphQL Admin API.

Each one has its own plan rules.

Rule 1: UI in the information, shipping and payment steps is Plus-only

Shopify's docs are explicit: Checkout UI extensions for the information, shipping and payment steps are available only to stores on a Shopify Plus plan.

So these are Plus jobs:

a delivery-date or time-slot picker on the shipping step
a "gift message" field that writes to an order metafield
an upsell block or loyalty-points banner inside checkout
B2B purchase-order number fields on the payment step

On standard plans you can still add extensions to the Thank you and Order status pages. That's often enough for post-purchase surveys, tracking links or a "join our loyalty programme" prompt. Ask whether the field has to be collected before payment. If it can be collected after, you may not need Plus.

// Thank you page extension: works on non-Plus stores
// (React syntax; newer API versions use Shopify's Preact-based components, same targets)
import {reactExtension, Banner, Link} from '@shopify/ui-extensions-react/checkout';

export default reactExtension('purchase.thank-you.block.render', () => (
  <Banner title="Track your order">
    You'll get tracking by email. Questions? <Link to="/pages/contact">Contact us</Link>.
  </Banner>
));

Rule 2: Functions from public apps work on all plans; custom Functions need Plus

This is the one that catches teams out. Shopify Functions run on every plan except Starter, but only when they ship inside a public app from the Shopify App Store. Shopify's docs state that only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs.

In practice:

Request	Non-Plus route	Plus route
Tiered volume discount	Public discount app	Custom discount Function
Hide COD above a threshold	Public payment-customisation app	Custom payment Function
Rename or reorder shipping rates	Public delivery-customisation app	Custom delivery Function
Block checkout if cart breaks a rule	Public validation app	Custom cart/checkout validation Function

Before quoting custom work for a non-Plus store, spend twenty minutes in the App Store. If a public app already implements the Function you need, the merchant gets it without upgrading. If the logic is truly bespoke (customer-tag pricing tied to an ERP, say), you're looking at Plus or a public app you'd have to build and list.

A minimal discount Function input query looks like this:

query RunInput {
  cart {
    lines {
      quantity
      merchandise {
        ... on ProductVariant { id }
      }
    }
    buyerIdentity {
      customer { hasAnyTag(tags: ["wholesale"]) }
    }
  }
}

The logic is the same on any plan. What changes is how it can be distributed.

Rule 3: API-driven checkout branding is Plus

All plans can use the checkout editor's branding settings. Applying deeper branding through the GraphQL Admin API (checkoutBrandingUpsert) is a Plus capability. If a brand needs pixel-level control (custom typography scales, section-level colour schemes), plan for Plus.

Other limits that push stores to Plus

Checkout isn't the only reason. From Shopify's plan comparison:

API rate limits: standard on Basic and Grow, up to 2x on select APIs on Advanced, up to 10x on Plus. Heavy ERP or inventory syncs feel this first.
B2B catalogs: up to 3 on standard plans, unlimited on Plus.
Headless storefronts: 1 on standard plans, 25 on Plus.
Staff accounts: 15 on Advanced, unlimited on Plus.

A quick triage checklist

When a checkout request comes in:

[ ] Does it need UI before payment (information, shipping or payment step)? If yes, it needs Plus.
[ ] Can it live on the Thank you or Order status page instead? Then it works on any plan.
[ ] Is it discount, shipping, payment or validation logic? Search the App Store for a public app with a Function first.
[ ] Is the logic bespoke to this merchant? Then it's a custom app with Functions, which needs Plus.
[ ] Does it involve API-level branding, more than 3 B2B catalogs, or higher API limits? Those also need Plus.

Getting this right at the scoping stage saves an awkward conversation halfway through a build. If you'd rather hand the whole thing to a team that does this every week, our Shopify development services cover checkout extensions and Functions on every plan, including Plus.

FAQ

Can I still edit checkout.liquid?
No. Shopify replaced checkout.liquid with checkout extensibility (UI extensions, Functions and branding). Stores that used it had to upgrade.

Do Shopify Functions work on the Basic plan?
Yes, when they come from a public App Store app. Custom apps containing Functions need Plus.

Is a Thank you page extension enough for a post-purchase survey?
Usually yes, and it works on non-Plus plans.

Where do I check the current rules?
Shopify's docs on checkout customisation technologies and Checkout UI extensions. Plan availability changes, so check them before quoting.

Written by Sushil Barwal at Dzimark, a web, Shopify and AI development company working with businesses in the USA, UK, Canada and Australia.

Magento 2 to Shopify: a data-mapping checklist for developers

Sushil Barwal — Mon, 09 Nov 2026 05:48:21 +0000

Moving a store from Magento 2 (Magento Open Source or Adobe Commerce) to Shopify is mostly a data problem. The theme gets rebuilt anyway; what decides whether launch week goes well is how carefully the products, customers, orders and URLs were mapped. This is the checklist we use when we plan a Magento to Shopify move for stores in the US, UK, Canada and Australia.

1. Take an inventory before you map anything

Export counts first, so you can check them after the import:

Products by type: simple, configurable, bundle, grouped, virtual and downloadable.
Number of attribute sets and attributes actually used on the storefront.
Categories, CMS pages and blog posts (if a blog extension is installed).
Customers, orders, and active gift cards or store credit.
Store views and websites: each one may become a separate Shopify market, language or even a separate store.

These numbers become your acceptance tests. If Magento has 4,812 enabled products and Shopify shows 4,790 after import, you have something to chase before launch, not after.

2. Map the catalogue model

Magento and Shopify think about products differently.

Magento 2	Shopify
Configurable product + child simples	One product with variants
Configurable attributes (size, colour)	Product options
Custom attributes (material, care)	Metafields (or metaobjects for shared data)
Categories (tree)	Collections (manual or automated by rules)
Bundle / grouped products	Bundles app or Shopify's bundle features; check what fits
Tier and customer-group prices	B2B catalogues / price lists, or an app

Two practical points:

Options and variants have limits. Shopify caps the number of options per product and the number of variants. The limits have changed over time, so check the current numbers in Shopify's docs before you promise a product structure to the client. Products with very large attribute combinations may need splitting.
Decide metafield definitions up front. Create the definitions (type, validation, storefront access) before importing, so the theme can rely on them.

3. Customers: plan for the password reset

Magento stores customer passwords as hashes, and Shopify can't import them. Every migrated customer needs to activate a Shopify account or set a new password. Plan it as a communication task:

Import customers with their marketing consent status (important under UK GDPR / PECR and Canada's CASL).
Send account activation invites in batches after launch, not all at once from a new sender.
Put a short "We've moved, please reset your password" message on the login page.

4. Orders: history, not live data

Historical orders are useful for customer service and lifetime value, but they're read-only in Shopify. Decide how far back to bring them, and make sure imported orders don't trigger confirmation emails or inventory changes. Most import tools have a flag for that; test it on a development store first.

5. URLs and redirects

This is where most migrations lose traffic. Shopify uses fixed path prefixes:

/products/{handle}
/collections/{handle}
/pages/{handle}
/blogs/{blog}/{article}

Magento URLs such as /mens/shirts/oxford-shirt-blue.html won't exist anymore. Build a redirect map:

Export every indexable Magento URL (from the sitemap and from a crawl).
Pull the top landing pages from Search Console for the last 12 months.
Map each old URL to the closest new URL, one to one. Avoid sending everything to the homepage.
Import the map through Shopify's URL redirects CSV import.
After launch, crawl the old URL list and check every one returns a 301 to a 200 page.

Redirect from,Redirect to
/mens/shirts/oxford-shirt-blue.html,/products/oxford-shirt-blue
/mens/shirts.html,/collections/mens-shirts
/customer-service,/pages/customer-service

6. Extensions to replace

List every Magento extension and decide: Shopify native feature, Shopify app, custom app, or drop it. Typical ones: layered navigation (Shopify Search & Discovery filters), reviews, loyalty, ERP connectors, B2B quoting, and custom checkout fields (now Checkout UI extensions, some only on Shopify Plus).

7. Launch-day checks

Product, customer and order counts match the inventory from step 1.
Ten random products: price, tax setting, images, variants, metafields.
Taxes and shipping for each market (US states, UK VAT, Canadian GST/HST, Australian GST).
Redirect crawl passes; no redirect chains.
Analytics and Search Console: new sitemap submitted.

FAQ

Can I keep my Magento URLs exactly? No. Shopify's path prefixes are fixed, so plan 301 redirects instead.

Do customers keep their passwords? No. Passwords can't be migrated; customers activate their account or reset the password.

Should I migrate all order history? Only as far back as support and reporting need. Older data can stay in an archive export.

How long does it take? It depends on catalogue size, extensions and integrations. Map first; then estimate.

If you'd like a second pair of eyes on a migration plan, our Shopify migration team at Dzimark handles Magento, WooCommerce and BigCommerce moves for stores in the USA, UK, Canada and Australia.

Vetting a Shopify development agency: 8 technical questions for store owners and their developers

Sushil Barwal — Sun, 08 Nov 2026 12:07:09 +0000

Most "how to choose a Shopify agency" articles talk about portfolios and price. Those matter, but they don't tell you whether the code you get will still work in two years. If you run a store in the US, UK, Canada or Australia and you're about to hire an agency (or you're the in-house developer asked to vet one), these are the technical questions I'd ask.

1. Do they build on Online Store 2.0 sections, or hard-code templates?

Modern Shopify themes use JSON templates and sections, so merchants can rearrange pages in the theme editor without a developer. Ask to see a recent theme. If every page layout is fixed in Liquid, every future change becomes a paid ticket.

2. How do they handle theme code: Git, CLI and Theme Check?

A good agency keeps the theme in Git, uses Shopify CLI to push to a development theme, and runs Theme Check (Shopify's linter, built into the CLI as shopify theme check) before release. Ask for a sample pull request. "We edit in the online code editor" is a red flag for anything beyond small fixes.

3. What is their stance on apps?

Every app adds scripts, and many leave code behind after they're uninstalled. Ask:

Which apps would they remove, or replace with native features?
Do they check theme files for leftover snippets after an app is removed?
Will a custom app be built on Shopify's current APIs (the GraphQL Admin API), and who owns it?

4. Checkout: do they know Checkout Extensibility?

Checkout customisation now runs through Checkout UI extensions and Shopify Functions, not through editing checkout.liquid, which Shopify has retired. An agency that still promises checkout.liquid edits is out of date. Ask what they'd use for a delivery-date picker, a custom discount rule, or hiding a payment method for some customers.

5. Performance budget

Ask how they measure speed: Core Web Vitals field data, not one Lighthouse run. Ask what they do about large images, third-party scripts and app embeds, and ask for before/after numbers from a past project.

6. Accessibility

For UK, EU-facing and US stores, ask whether they test with a keyboard and a screen reader, and which WCAG level they aim for. A theme that fails keyboard navigation loses sales and invites complaints.

7. Migrations and SEO

If you're moving from WooCommerce, Magento or BigCommerce, ask for their redirect plan: a URL map, Shopify's URL redirect import, and a check of your top landing pages in Search Console after launch.

8. Handover

At the end you should get admin access that stays with you, the theme repository, app credentials in your name, and a short document of what was customised.

A quick scoring sheet

Question	Good answer
Theme architecture	OS 2.0 sections, merchant-editable
Workflow	Git + Shopify CLI + Theme Check
Apps	Fewer apps, clean removal
Checkout	UI extensions + Functions
Speed	Field data, before/after numbers
Handover	Repo + docs + your ownership

If you want to see how we answer these, here is Dzimark's Shopify development team page. We build for stores in the USA, UK, Canada and Australia.

FAQ

Is a Shopify Partner badge enough?
It shows the agency has a partner account. It doesn't show code quality, so still ask the questions above.

Should my agency edit the live theme?
No. Work should happen on a duplicate or development theme and be published after review.

Do I need Shopify Plus for checkout changes?
Checkout UI extensions on the information, shipping and payment steps are a Shopify Plus feature; the thank-you and order status pages can be extended on other plans. Check Shopify's current docs for your plan.

Letting an AI agent act, but not alone: designing human approval steps for agent tool calls

Sushil Barwal — Sat, 07 Nov 2026 05:51:53 +0000

Most AI agent demos end at the moment the agent decides to do something: send the email, refund the order, update the CRM record. In a real business, that moment is where the engineering starts. The question a client asks us most often after "can it do this?" is "what stops it doing the wrong thing?"

This post is the pattern we use when we build agents for small and mid-sized businesses in the USA, UK, Canada and Australia: sort every tool the agent can call by risk, and put a person in front of the risky ones. The examples use n8n because it has human review built into its AI agent tooling, but the design works in any framework.

Step 1: list every tool and give it a risk level

An agent is only as dangerous as the tools you give it. Before writing a prompt, write a table:

Tool	What it changes	Who sees the result	Can it be undone?	Risk
search_orders	nothing	the agent	n/a	low
draft_reply	nothing until sent	staff	yes	low
send_email	the customer's inbox	the customer	no	high
update_crm_stage	one record	sales team	yes	medium
issue_refund	money	the customer	partly	high
delete_contact	one record	everyone	no	high

Three questions decide the level: does it leave the building (a customer, a supplier, a regulator)? Does it move money? Can it be undone in one click? Any "yes" puts the tool in the high column.

Read-only tools (search, look up, summarise) can usually run freely. Tools that write internal data can run with logging. Tools that send, pay or delete wait for a person.

Step 2: make the agent propose, not perform

For high-risk tools, the agent's job changes from "do it" to "prepare it". The tool call becomes a proposal with everything a reviewer needs on one screen:

{
  "action": "issue_refund",
  "order_id": "10482",
  "amount": "the full order total",
  "reason_from_customer": "Item arrived damaged, photo attached",
  "agent_reasoning": "Policy allows a refund for damage reported within 14 days; reported on day 3",
  "source_documents": ["refund-policy.md#damaged-items"]
}

Two fields matter more than they look. agent_reasoning lets the reviewer check the logic, not just the output. source_documents points at the policy the agent relied on, which is how you catch an agent that has misread a rule.

Step 3: put the approval where people already work

An approval step nobody sees is a queue that never empties. Send it to the place the team already watches: a Slack or Teams channel, an email, or a simple internal form.

In n8n, there are two ways to do this:

Human review on agent tools. n8n's documentation describes a human-in-the-loop option for AI agent tools: you can require a person to approve a tool call before it runs. This is the cleanest option, because the gate sits on the tool itself rather than in your prompt.
Send-and-wait steps. Several n8n messaging nodes can send a message and pause the workflow until someone responds. That suits approvals outside the agent loop, such as a weekly batch of proposed CRM updates.

Whichever you use, the gate must live in the workflow, not in the system prompt. "Always ask before sending emails" in a prompt is a request; an approval node is a control.

Step 4: decide what happens on "no" and on silence

Every approval has three outcomes, and teams usually design only one:

Approved: the tool runs with exactly the proposed values. Don't let the agent regenerate the action after approval; run what the person saw.
Rejected: record the reason and return it to the agent or to a person. A rejection reason is the best training data you will get for improving prompts and policies.
No answer: set a timeout. After it, escalate to a second person or close the request with a holding reply. Never default to "approved".

Step 5: log every step

For each agent run, keep: the user's request, the tools called with their inputs, the proposals made, who approved or rejected them and when, and the final result. n8n's execution history covers part of this; for anything customer-facing, also write a row to your own log table so the record outlives the tool's retention settings.

The log is what turns "the AI did something odd" into a ten-minute investigation instead of a guess.

Step 6: loosen the gate with evidence, not optimism

Approval steps cost staff time, so teams want to remove them. Do it with numbers. After a few weeks, look at each high-risk tool: how many proposals were approved unchanged? If a tool's proposals are almost always approved as-is, consider moving it to medium risk with a value limit (for example, refunds under a set amount run automatically and are reviewed afterwards). If people keep editing or rejecting them, the agent needs better instructions or better data, not more freedom.

A minimal checklist

Every tool has a risk level written down.
High-risk tools produce a proposal with reasoning and sources.
Approval happens in a channel people already watch.
Approved actions run with the exact values shown.
Rejections and timeouts are handled, and silence never means yes.
Every run is logged outside the agent framework.
Gates are relaxed only from approval data.

We build agents this way for clients at Dzimark, and the AI agent development page shows the kinds of customer service, sales and operations agents we put these guardrails around.

FAQ

Doesn't human approval defeat the point of an agent?
No. The agent still does the reading, looking up and drafting, which is most of the time spent. The person spends seconds checking a prepared action instead of minutes doing the task.

Can I enforce approval in the prompt instead?
Not reliably. Prompts guide behaviour; they don't block it. Put the gate in the workflow or the tool layer.

Which tools should never run without a person?
Anything that sends a message to a customer, moves money, or deletes data, at least until you have weeks of approval history showing the agent gets it right.

Does this work outside n8n?
Yes. In code-first frameworks the same idea is a tool wrapper that returns "pending approval" and resumes when a person responds.

Background reading on the Dzimark blog: AI chatbot vs AI agent.

Test your prompts like code: a Node.js prompt test sheet for AI students

Sushil Barwal — Fri, 06 Nov 2026 06:24:37 +0000

Most students learning generative AI write a prompt, try it twice and move on. Developers test. Here is a weekend project that turns prompt testing into code: a tiny Node.js script that runs one prompt over a list of test inputs and checks each answer against simple rules.

It doesn't depend on any one AI provider. You plug in whichever API you have access to.

What you will build

cases.json: 10 test inputs, each with rules the answer must pass
test.mjs: sends each input with your prompt, checks the rules, prints a pass/fail table

Step 1: the test cases

[
  { "input": "Library closes at 6 pm on Saturday from next week.",
    "mustInclude": ["6 pm", "Saturday"], "maxWords": 25 },
  { "input": "Fee deadline for semester 5 is extended to 20 November.",
    "mustInclude": ["20 November"], "maxWords": 25 }
]

The prompt's job here: summarise a college notice in one short sentence without losing dates and times. Write at least 10 cases, including awkward ones (two dates, Hindi-English mixed text, an empty notice).

Step 2: the checker

// test.mjs  (Node 18+; .mjs so import and top-level await work)
import fs from "node:fs";

const PROMPT = "Summarise this college notice in one sentence. Keep every date and time exactly as written.";
const cases = JSON.parse(fs.readFileSync("cases.json", "utf8"));

async function ask(text) {
  // Replace with your provider's API call. It must return the model's reply as a string.
  throw new Error("connect your AI API here");
}

function check(answer, c) {
  const problems = [];
  for (const word of c.mustInclude || []) {
    if (!answer.includes(word)) problems.push(`missing "${word}"`);
  }
  const words = answer.trim().split(/\s+/).length;
  if (c.maxWords && words > c.maxWords) problems.push(`${words} words`);
  return problems;
}

let passed = 0;
for (const c of cases) {
  const answer = await ask(`${PROMPT}\n\nNotice: ${c.input}`);
  const problems = check(answer, c);
  if (problems.length === 0) passed++;
  console.log(problems.length ? "FAIL" : "PASS", "|", c.input.slice(0, 40), "|", problems.join(", "));
}
console.log(`${passed}/${cases.length} passed`);

Keep your API key in an environment variable, never in the file, and never commit it to GitHub.

Step 3: improve the prompt, not the tests

Run it, look at the failures, change one thing in PROMPT, run again. Write down each change and the new score. After three or four rounds you will have a short, honest record like "v1 7/10, v2 9/10 (added 'keep dates exactly')". That record is a far better interview story than "I know ChatGPT".

Ideas to extend it

Run each case 3 times, because AI answers vary.
Add a mustNotInclude rule to catch made-up details.
Save results to a CSV and compare two models.

I put this together for students at Dzimark Training in Mohali, where the AI programmes cover prompt engineering, AI agents and AI-powered full-stack work. If you are in the Tricity and want the structured version, the course outline is on the Dzimark Training AI programmes page.

Building a bilingual AI chatbot for Canadian users: English, French and the privacy checks in the code

Sushil Barwal — Fri, 06 Nov 2026 06:24:18 +0000

A chatbot that works well for a shop in Dallas can still go wrong in Toronto, Montreal or Ottawa. Canadian users expect French as a first-class language (and in Quebec the law expects it), and the privacy rules that apply to the data flowing through the chat window are different from the US ones.

This post is the checklist we work through when we build an AI chatbot for a Canadian business. It is written for developers, not lawyers, so treat the legal notes as pointers to read, not advice.

1. Decide where the language comes from

You have three signals, in order of reliability:

An explicit choice. A visible EN | FR toggle in the chat header. Always offer it, and remember it (a cookie or local storage key is fine).
The page language. If the chat is embedded on /fr/ pages, start in French. Read document.documentElement.lang when the widget loads.
The browser. navigator.languages gives you the user's preferred list. Use it only as a hint for the first greeting.

function initialLocale() {
  const saved = localStorage.getItem('chat_locale');
  if (saved) return saved;
  const pageLang = (document.documentElement.lang || '').slice(0, 2);
  if (pageLang === 'fr' || pageLang === 'en') return pageLang;
  const pref = (navigator.languages || ['en'])[0].slice(0, 2);
  return pref === 'fr' ? 'fr' : 'en';
}

Then pass the locale to the model on every turn, in the system prompt, rather than hoping it copies the user's language. If a user switches language mid-conversation, follow them and update the stored value.

2. Keep two knowledge bases, not one translated on the fly

If the bot answers from your own content (retrieval-augmented generation), index the English and French versions of each page separately and tag each chunk with its language. Retrieve in the user's language first and fall back to the other language only when nothing relevant comes back.

Translating English chunks into French at answer time looks cheaper, but it produces inconsistent terms (product names, legal wording, prices written with the wrong decimal separator) and it makes it hard to show the source link in the right language.

A practical schema for each chunk:

{
  "id": "returns-policy#2",
  "lang": "fr",
  "url": "https://example.ca/fr/retours/",
  "title": "Politique de retour",
  "text": "...",
  "updated": "2026-10-01"
}

3. Format money, dates and phone numbers per locale

Use Intl instead of string templates:

new Intl.NumberFormat('fr-CA', { style: 'currency', currency: 'CAD' }).format(1499.5);
// "1 499,50 $"
new Intl.NumberFormat('en-CA', { style: 'currency', currency: 'CAD' }).format(1499.5);
// "$1,499.50"

Do the same for dates. Ask the model to return structured data (amount, date) and format it in your code, so a hallucinated format never reaches the user.

4. The privacy checks that change the code

PIPEDA applies to private-sector organisations that collect personal information in the course of commercial activity in most of Canada. Alberta, British Columbia and Quebec have their own private-sector laws for activity inside those provinces. In practice the same engineering controls cover all of them:

Tell people what happens to the chat. A one-line notice under the input box ("Chats are stored for 30 days to improve answers. Privacy policy") plus a link.
Collect less. Do not ask for a date of birth or a full address in chat unless the task needs it. Mask card numbers and health card numbers with a regex before anything is logged or sent to a model provider.
Know where the data goes. List your model provider, vector database and logging tool, and the region each one stores data in. Your client will be asked.
Retention. Put a TTL on chat logs and actually delete them.

Quebec's Law 25 adds two things developers notice:

If a decision about a person is made exclusively by automated processing, the person has to be informed. A bot that only answers questions is not making decisions, but one that approves refunds or pre-qualifies leads may be. Route those to a human or disclose it.
Before personal information is communicated outside Quebec (for example to a US model API), the organisation has to assess the privacy impact. Your client's privacy lead will want the data-flow list from the previous section.

The Office of the Privacy Commissioner of Canada has also published principles for generative AI (December 2023) that are worth a read before you write the system prompt. The federal AI bill (AIDA, part of Bill C-27) did not become law: it died when Parliament was prorogued in January 2025.

5. French is not a feature flag in Quebec

Quebec's Charter of the French Language, as amended by Bill 96, requires businesses to serve and inform consumers in French. For a chatbot this means French must be available, of equal quality, and not hidden behind an English-only first message. Test both languages with the same test set:

Test	EN	FR
Opening hours, holidays	✅	✅
Refund policy question	✅	✅
Handoff to a person	✅	✅
Prices and taxes (GST/HST/QST) formatted correctly	✅	✅

6. Handoff and logging

Every Canadian business we work with asks the same question: what happens when the bot can't answer? Give it a tool that creates a ticket or sends the transcript to a shared inbox, in the user's language, and say so in the reply ("Je transmets votre question à notre équipe…").

Log, for each conversation: locale, retrieved chunk IDs, whether a handoff happened, and the model version. That is enough to debug most bad answers without storing more personal data than you need.

FAQ

Do I need a separate model for French? No. Current general models handle Canadian French well. What matters is French source content and a French test set.

Can I host the chatbot data in Canada? Many cloud providers offer Canadian regions for databases and logs. Model APIs vary, so check the provider's data-residency options and write down where data goes.

Is a chatbot disclosure required? Telling users they are talking to an automated assistant is good practice and expected under the OPC principles. Put it in the first message.

If you are scoping a chatbot like this for a Toronto, Ottawa or Montreal business, this is the work our team does on AI chatbot development in Canada, from bilingual content indexing to the handoff into your CRM.

Building an AI receptionist for a small business: the call flow, the tools and the handoff

Sushil Barwal — Thu, 05 Nov 2026 05:49:35 +0000

Most "AI receptionist" demos show a voice answering a phone and sounding human. That part is now the easy bit. What decides whether a plumber in Texas or a dental clinic in Ontario keeps using it after the first week is everything around the voice: what it is allowed to do, how it books, and how it hands a caller to a person.

This post walks through the architecture we use when we scope an AI receptionist for a small business, with the decisions you need to make before writing any code.

1. Start with the call log, not the model

Before choosing a speech or LLM provider, export a month of call data (most phone systems can give you call times, durations and outcomes) and listen to 20 to 30 recordings if the business already records calls lawfully.

Sort the calls into buckets:

Answerable from a fixed source: opening hours, service area, prices that are published, parking, what to bring.
Transactional: book, reschedule or cancel an appointment; take a quote request.
Needs a human: complaints, emergencies, anything about money already owed, anything clinical or legal.

The first two buckets are what the AI receptionist handles. The third bucket defines your handoff rules. If the third bucket is more than half the calls, an AI receptionist is probably the wrong first project.

2. The pipeline

A typical inbound call goes through five stages:

Caller -> Telephony (SIP / phone number)
       -> Speech-to-text (streaming)
       -> Dialogue engine (LLM + tools + guard rails)
       -> Text-to-speech (streaming)
       -> Caller

Two practical notes:

Latency budget. Callers notice a pause of more than about a second. Stream everything: partial transcripts into the model, partial model output into speech. Several providers now offer speech-to-speech models that collapse the middle stages; they are faster, but they make logging and guard rails harder, so check what you can inspect.
Barge-in. People interrupt. Your stack has to stop speaking when the caller starts, and the dialogue state has to cope with half-finished sentences.

3. Tools, not free text

The model should never "promise" a booking in prose. Give it a small set of functions and make it call them:

[
  {"name": "find_slots", "parameters": {"service": "string", "date_from": "date", "date_to": "date"}},
  {"name": "book_slot", "parameters": {"slot_id": "string", "name": "string", "phone": "string"}},
  {"name": "lookup_faq", "parameters": {"question": "string"}},
  {"name": "transfer_to_human", "parameters": {"reason": "string", "urgency": "low|normal|urgent"}}
]

Rules that save you later:

book_slot only accepts a slot_id that find_slots returned in the same call. No invented times.
Read the booking back to the caller and get a "yes" before calling book_slot.
lookup_faq answers only from the business's approved content. If there's no match, the model says it doesn't know and offers a callback.

4. The handoff is the product

Write the transfer rules as code, not as a hope in the system prompt:

Keywords and intents that always transfer (emergency, complaint, "speak to a person").
A maximum number of failed turns (two "I didn't catch that" in a row means transfer).
Business hours: outside hours, take a message with a structured summary and send it to the right inbox or CRM.

When you transfer, pass a summary (caller name, number, reason, what was already tried) to the human. Nothing annoys a caller more than repeating everything.

5. Consent, disclosure and recording

This is where small-business projects get into trouble:

Tell callers they are talking to an AI, at the start. It is the honest default, and it avoids confusion when the call is transferred.
Recording and transcripts. Some US states, including California, require the consent of everyone on the call before recording. In Canada, PIPEDA expects you to tell callers a call is recorded and why. In the UK, recorded calls and transcripts are personal data under UK GDPR. Australia also has federal and state rules on recording calls. Play a short notice and keep only what you need.
Outbound calls are a different matter. In February 2024 the US FCC ruled that AI-generated voices count as "artificial" voices under the TCPA, so outbound AI calls need prior express consent. Keep the receptionist inbound-only unless you have a lawyer involved.

6. Logging and review

Store, for each call: the transcript, tool calls with arguments and results, the transfer reason, and the outcome. Review a sample weekly with the business owner for the first month. Most improvements come from adding FAQ entries and tightening transfer rules, not from changing models.

7. A one-week pilot plan

Day 1: FAQ source agreed and loaded; tools wired to a test calendar.
Day 2–3: internal test calls with scripted edge cases (interruptions, accents, wrong dates, angry caller).
Day 4–5: live on overflow only (calls that would otherwise go to voicemail).
Day 6–7: review transcripts, fix FAQ gaps, decide whether to widen it to all calls.

Starting on overflow means the worst case is "slightly better than voicemail", which is a much easier conversation with the business owner.

FAQ

Can an AI receptionist replace a front-desk person?
For routine calls it can take a large share of the load, especially after hours. It should not replace the person who handles complaints, emergencies and anything that needs judgement.

Which calendar systems can it book into?
Anything with an API: Google Calendar, Microsoft 365, Calendly and most practice-management or field-service systems. If the system has no API, the receptionist takes a structured message instead.

What does it cost to run?
Running costs are per minute (telephony, speech and model usage) plus the build. Ask for an estimate based on your real call volume.

At Dzimark we build these for small businesses in the USA, UK, Canada and Australia. If you want to see how we scope them, our page on AI voice agents and AI receptionists has the details.

A PHP + MySQL attendance register: a weekend project for PHP training students

Sushil Barwal — Thu, 05 Nov 2026 05:46:35 +0000

Most students in PHP training write a "student management system" as their first project. It's a good idea, but it usually ends up as 30 files of copy-pasted SQL. Here is a smaller, cleaner version you can finish in a weekend: a class attendance register with PHP 8 and MySQL, using PDO and prepared statements from the first line.

1. The database

CREATE TABLE students (
  id INT AUTO_INCREMENT PRIMARY KEY,
  roll_no VARCHAR(20) NOT NULL UNIQUE,
  name VARCHAR(100) NOT NULL
);

CREATE TABLE attendance (
  id INT AUTO_INCREMENT PRIMARY KEY,
  student_id INT NOT NULL,
  class_date DATE NOT NULL,
  present TINYINT(1) NOT NULL DEFAULT 0,
  UNIQUE KEY one_mark_per_day (student_id, class_date),
  FOREIGN KEY (student_id) REFERENCES students(id)
);

The UNIQUE KEY stops anyone marking the same student twice on one day. Let the database enforce rules like this instead of hoping your PHP gets it right.

2. One connection file

<?php
// db.php
$pdo = new PDO(
    'mysql:host=localhost;dbname=register;charset=utf8mb4',
    'root',
    '',
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
     PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC]
);

3. Marking attendance (safely)

<?php
require 'db.php';

$date = $_POST['class_date'] ?? date('Y-m-d');
$present = $_POST['present'] ?? []; // array of student ids that were ticked

$students = $pdo->query('SELECT id FROM students')->fetchAll();

$stmt = $pdo->prepare(
  'INSERT INTO attendance (student_id, class_date, present)
   VALUES (:sid, :d, :p)
   ON DUPLICATE KEY UPDATE present = VALUES(present)'
);

foreach ($students as $s) {
    $stmt->execute([
        ':sid' => $s['id'],
        ':d'   => $date,
        ':p'   => in_array((string)$s['id'], $present, true) ? 1 : 0,
    ]);
}

Prepared statements mean a student name like O'Brien (or something nastier) can never break your query. ON DUPLICATE KEY UPDATE lets the teacher re-save the same day without errors.

4. The monthly report

<?php
require 'db.php';
$month = $_GET['month'] ?? date('Y-m');

$stmt = $pdo->prepare(
  'SELECT s.roll_no, s.name,
          SUM(a.present) AS days_present,
          COUNT(a.id)    AS days_marked
   FROM students s
   LEFT JOIN attendance a
     ON a.student_id = s.id AND DATE_FORMAT(a.class_date, "%Y-%m") = :m
   GROUP BY s.id
   ORDER BY s.roll_no'
);
$stmt->execute([':m' => $month]);

foreach ($stmt as $row) {
    $pct = $row['days_marked'] ? round($row['days_present'] * 100 / $row['days_marked']) : 0;
    echo htmlspecialchars("{$row['roll_no']} {$row['name']}: {$pct}%"), "<br>";
}

Note the htmlspecialchars on output: escaping on the way out is the other half of basic security.

5. What to add next

A login for teachers (password_hash and password_verify, never plain text).
A CSV export of the monthly report.
Rebuild it in Laravel: migrations, Eloquent models and a Blade view. You'll see how much the framework does for you.

Put it on GitHub with a README and screenshots. In fresher interviews in Mohali and Chandigarh, being able to explain why you used a unique key and prepared statements matters more than the size of the project.

I run Dzimark, and this is one of the starter projects we use at Dzimark Training in Mohali, where the full PHP and Laravel syllabus is listed.

PWA or native app? A developer's checklist for the 'web app vs mobile app' question

Sushil Barwal — Wed, 04 Nov 2026 05:54:40 +0000

Clients rarely ask "should we build a PWA or a native app?". They ask "do we need an app?", and the developer in the room has to turn that into a technical decision. This is the checklist we use when we scope that question for businesses in the USA, UK, Canada and Australia. It's written for developers and tech leads, and the business-facing version is linked at the end.

Start with usage frequency, not technology

The most useful single question is: how often will a typical user open this?

A few times a year (quotes, renewals, one-off bookings): build for the web. Every page is indexable, nothing has to be installed, and you ship fixes the moment they merge.
Weekly or daily (ordering, field work, fitness, banking): an installed app starts to pay for itself, because a home-screen icon, saved sessions and reliable notifications matter at that frequency.

Everything else on this list refines that first answer.

What a PWA can actually do in 2026

A progressive web app is a normal web app plus a web app manifest and usually a service worker. That gets you:

Install to home screen with its own window and icon.
Offline and flaky-network support through a service worker caching shell assets and data.
Push notifications, including on iPhone. Since iOS/iPadOS 16.4, Home Screen web apps can receive Web Push. Two constraints matter in practice: the user must add the app to the Home Screen first, and the permission prompt must follow a user gesture.

A minimal manifest looks like this:

{
  "name": "Acme Field Jobs",
  "short_name": "Acme Jobs",
  "start_url": "/?source=pwa",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0b5fff",
  "icons": [
    { "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

And the iOS-safe way to ask for push permission is from a click handler, never on page load:

document.querySelector('#enable-alerts').addEventListener('click', async () => {
  const permission = await Notification.requestPermission();
  if (permission !== 'granted') return;
  const reg = await navigator.serviceWorker.ready;
  const sub = await reg.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: VAPID_PUBLIC_KEY, // Uint8Array
  });
  await fetch('/api/push/subscribe', { method: 'POST', body: JSON.stringify(sub) });
});

Where the web still falls short

Every browser on iPhone runs on Apple's WebKit engine, so iOS support sets the ceiling. Check each "must-have" feature against MDN's compatibility tables before you promise it. Typical deal-breakers:

Requirement	Web / PWA	Native or cross-platform
Bluetooth devices, wearables	Web Bluetooth: Chrome/Edge only, not Safari or Firefox	Yes
Reliable background location	No	Yes (with store-policy justification)
Large offline datasets	Limited by browser storage quotas	Yes
Health data, widgets, wallet passes	No	Yes
Push on iPhone without "Add to Home Screen"	No	Yes
Camera, mic, geolocation (foreground), file upload	Yes	Yes

If any row in the "No" column is on the day-one list, you're building an app.

Don't ship a wrapped website

The tempting shortcut is a WebView shell around the existing site. Apple's App Review Guideline 4.2 (Minimum Functionality) expects more than a repackaged website, so thin wrappers risk rejection. If you go to the stores, give the app real native value: offline mode, notifications, device features or a faster task flow.

The architecture that keeps both doors open

Whatever you build first, put the business logic behind an API:

Backend + API first (auth, data, payments, admin).
Responsive web app / PWA on top. Ship, measure what people actually use.
Cross-platform app (Flutter or React Native) on the same API for the frequent users, when the numbers justify it.

Because the second client reuses accounts, data and rules, it costs noticeably less than the first. The mistake to avoid is business logic inside the web front end. That makes the later mobile app a rewrite.

The six questions to put in the brief

How often will a typical user open it: yearly, monthly, weekly?
Where do new users come from: search and links, or store browsing?
Which device features are essential on day one?
How critical are notifications, and on which devices?
What's the budget for version one, including yearly store fees (Apple's developer program is US$99 a year, Google Play a one-time US$25)?
Who releases updates, and how often?

"Weekly", "Bluetooth or background location" or "notifications are essential" point to a mobile app. Otherwise start on the web. If you'd like a second opinion on a scope, our mobile app development team writes up both options with estimates.

FAQ

Can a PWA be listed in the App Store? Not as a PWA. You'd need a native wrapper with real native features to pass review. Google Play accepts PWAs packaged as Trusted Web Activities.

Do iPhone web apps get push notifications? Yes, since iOS 16.4, but only after the user adds the app to the Home Screen.

Is Flutter or React Native "native enough"? For most business apps, yes. Both reach Bluetooth, background tasks and platform APIs through plugins or native modules.

Originally published on the Dzimark blog.

A college notice board in React: a first project for web design students

Sushil Barwal — Wed, 04 Nov 2026 05:43:35 +0000

If you're a student learning web design and you've just finished HTML, CSS and some JavaScript, React can feel like a big jump. The best way across is a small project that you'd actually use. Here's one we give students: a college notice board.

What it does

Shows a list of notices (title, department, date).
Lets you filter by department.
Lets you add a notice through a form.
Saves notices in localStorage so they survive a refresh.

That's enough to touch components, props, state, events, forms, lists and effects, without a backend.

Step 1: Set up

npm create vite@latest notice-board -- --template react
cd notice-board
npm install
npm run dev

Step 2: Model the data

const starter = [
  { id: 1, title: "Mid-sem exams start 18 Nov", dept: "CSE", date: "2026-11-04" },
  { id: 2, title: "Placement talk in Seminar Hall", dept: "All", date: "2026-11-05" },
];

Step 3: State that persists

import { useEffect, useState } from "react";

function useNotices() {
  const [notices, setNotices] = useState(() => {
    const saved = localStorage.getItem("notices");
    return saved ? JSON.parse(saved) : starter;
  });
  useEffect(() => {
    localStorage.setItem("notices", JSON.stringify(notices));
  }, [notices]);
  return [notices, setNotices];
}

Step 4: Components

Split it into NoticeList, NoticeCard, DeptFilter and NoticeForm. Pass data down as props, and pass functions like onAdd down so the form can update the list.

function NoticeCard({ notice }) {
  return (
    <article className="card">
      <h3>{notice.title}</h3>
      <p>{notice.dept} · {notice.date}</p>
    </article>
  );
}

Step 5: The filter

const visible = dept === "All"
  ? notices
  : notices.filter(n => n.dept === dept || n.dept === "All");

Step 6: Make it look good

Use CSS Grid for the card layout and a single media query for mobile. Check it on your phone. Most people who view your portfolio will.

Stretch goals

Sort by date, newest first.
Mark notices as "important" with a badge.
Deploy it and put the live link on your CV.
Later, replace localStorage with a small API.

What this teaches

By the end you have used every core React idea a junior interview asks about, and you have something finished to show. That matters more than a long list of half-done tutorials.

We teach this project in the React module of our web designing course for students in Mohali and Chandigarh. The full module list is on the Dzimark Training course page.

3 beginner n8n automation projects for students learning AI

Sushil Barwal — Tue, 03 Nov 2026 08:27:15 +0000

If you're learning AI, building a chatbot is the obvious first project. Automation is the less obvious one, and it's often what employers actually need: AI steps inside a workflow that saves someone time. n8n is a good place to start because you can self-host it free and see every step.

Here are three projects we give students, in order of difficulty.

1. Form to spreadsheet to email

Trigger: a form submission (n8n's Form Trigger, or a Google Form).

Steps: append the row to Google Sheets, then send a confirmation email.

What you learn: triggers, credentials, mapping fields between nodes, testing with sample data.

2. Inbox sorter with an AI step

Trigger: new email in a test Gmail account.

Steps: send the subject and body to an LLM node with a short prompt ("Classify as: enquiry, invoice, spam, other. Reply with one word."), then route with a Switch node to different labels or a Slack/Telegram message.

What you learn: prompting for structured output, handling unexpected answers (add a default branch), not sending more data to the model than needed.

3. Weekly summary with human approval

Trigger: a schedule, every Monday.

Steps: pull last week's rows from a sheet, ask the model to write a five-line summary, send it to yourself for approval, and only then post it to a channel.

What you learn: scheduled workflows, aggregating data, and the most important habit in AI automation: a person approves anything that goes out.

Tips

Use test accounts, never your personal inbox.
Keep API keys in n8n credentials, not in node fields.
Export each workflow as JSON and commit it to a GitHub repo with a README and a screenshot. That's your portfolio.

We teach these at Dzimark Training in Mohali as part of our AI course in Chandigarh and Mohali.