DEV Community: Rickard Collander

Ticketing system for customer service: what it must handle

Rickard Collander — Sat, 10 Oct 2026 07:04:18 +0000

Short answer: A ticketing system for customer service turns every customer contact into a ticket with an owner, a status and a history, from any channel. The core requirements are one inbox for every channel, ticket types in fixed fields, assignment, response time targets and reporting. What separates a system in 2026 from one from 2020 is that the knowledge base is the core: the same reviewed answers serve every channel.

Anyone searching for a ticketing system for customer service usually has a concrete problem: the emails sit in a shared inbox where nobody knows who replied, the chat is logged in another tool and nobody can say how many tickets came in last week. This article is a buyer's guide for a team with a few hundred tickets a week. We develop such a system ourselves, so read it as a vendor's checklist and test the requirements against your own operation.

What is a ticketing system for customer service?

A system where every customer contact becomes a ticket with an owner, a status and a history, and where every channel lands in the same place. Gartner calls the category customer engagement center and defines it as software built around case management, which creates, assigns, routes and escalates cases and holds the conversation with the customer together.

That differs from two things that often have to do instead:

A shared inbox in Outlook or Gmail. It has no owner per ticket, no status, no history per customer and no statistics. It works until two people reply to the same customer or nobody does.
A CRM system. It holds the customer record, contracts and deals, but not the flow of a ticket: who has it, what has been promised and when it should be resolved. The two should be connected, not the same thing.

The word ticket is the important one. A ticket has a beginning, an owner, a type and an end, and that is what makes customer service measurable and improvable.

Which functions are core requirements?

Seven things, and most systems have them. The difference lies in how they fit together:

Function	What it should do	What to check
One inbox for every channel	Email, forms, chat and phone notes as tickets in the same view	That the chat and the form are not separate tools with their own logs
Ticket type and fields	Fixed values for type, cause and outcome	That the fields are mandatory at closing and can be reported on
Assignment and status	An owner per ticket, statuses such as waiting for customer, waiting for us, resolved	That a ticket cannot be without an owner
Response time targets	Targets per channel and ticket type, with alerts when they are breached	That the target is measured from the customer's first message, not from assignment
Customer history	All previous tickets and purchases for the customer in the same view	That it fetches customer data from your systems, not just from previous emails
Templates and suggested replies	Reviewed answers the agent starts from	That the templates come from the same source as the help centre, not from a separate list
Reporting	Tickets per type, channel, hour and agent; response time and resolution rate	That the report answers what customers ask about, not only how many

How the ticket types are built so the reports can actually be used is described in the article on categorising tickets. A system that lets tags grow freely produces data that looks like data but is not.

What separates a system in 2026 from one from 2020?

The knowledge base is the core, not an add-on. A ticketing system from 2020 was built around the inbox; the answers lived in the agent's head and in a template list. A system in 2026 should rest on reviewed source material that the same answer is drawn from in three places: as an article in the help centre, as an answer in the chat and as a draft in the inbox. What such a knowledge base is, and why an FAQ is not enough, is in the article on knowledge bases.

This is an excerpt. The full article continues on the Supportifier blog.

Where is my order? Cut e-commerce's most common question

Rickard Collander — Sat, 10 Oct 2026 07:04:04 +0000

Short answer: The question "where is my order?" arises when the customer wants to know something the company already knows but has not shown: whether the order has shipped, when it will arrive and what happens if it is late or missing. It shrinks when notifications answer that and when the help centre and chat can look up the order and the carrier's status.

Anyone who runs customer service for an online store with a few hundred orders a week knows which question tops the inbox: where is my order? It arrives by email, chat and phone, it comes back two days later from the same customer, and it takes time from the tickets that actually need a person. The question cannot be abolished, but it can be made rare. This article shows where it comes from, what the customer is entitled to and how to build it away without hiring more people. A broader overview of e-commerce support, covering all five ticket types, is in the article on e-commerce customer support.

Why is "where is my order?" e-commerce's most common question?

The question arises because the customer wants to know something the company already knows but has not shown, at the moment the customer wonders. The industry calls it WISMO, from "where is my order". According to Salesforce these are questions about order status and delivery that arrive in every channel, each one simple but together so numerous that they take a large share of customer service's time; as a worked example Salesforce states that a retailer shipping 5,000 orders a month can receive around 1,200 such questions.

The volume comes from a gap. Between the order confirmation and the delivery the order passes through several systems, each with its own status: the store's order system says "processing", the warehouse says "picked", the carrier says "in transit". The customer sees one of them, usually the last, and it is rarely updated. The longer the gap, the more people ask. That is also why the question peaks in November and December, when delivery times grow and customers are more numerous; what that means for staffing is covered in the article on preparing for the Christmas season.

What is the customer entitled to when the parcel is late or lost?

The company that sold the item is responsible for it until the customer has received it, and that applies even when the carrier caused the problem. According to the Swedish Consumer Agency the customer should direct their claims to the company they bought from if the delivery is late or disappears in transit, regardless of whether the shipping company caused it. The same applies according to the agency when an item breaks during transport: the risk passes to the customer only on receipt.

For delays there is a time limit. If no delivery time was promised, the item counts as delayed after 30 days from the purchase, according to the Swedish Consumer Agency's page on late delivery of goods. If you promised a delivery time, that applies. When a delivery is late the customer can demand that the item be delivered or, if the delay matters a great deal to the customer, cancel the purchase and get their money back.

Two things follow for customer service. The answer "contact the shipping company" is wrong; the customer is entitled to turn to you, and you in turn take it up with the carrier. And a delivery time promised at checkout is a promise that Swedish consumer sales law holds you to, so it should match what logistics can actually deliver.

Why is the carrier's tracking link not enough?

Because the tracking link shows where the parcel has been, not when it will arrive or what the customer should do if it does not. A Gartner survey shows the pattern: only 13 percent of customers say they receive proactive service, and 90 percent of those who did found it valuable, yet two thirds still contacted the company afterwards, most often because they needed more information or a confirmation. A notification that does not answer the next question creates a contact instead of preventing one.

This is an excerpt. The full article continues on the Supportifier blog.

A GEO Checklist for B2B Sites: robots.txt, llms.txt, Schema and Citability

Rickard Collander — Fri, 09 Oct 2026 18:52:49 +0000

A GEO Checklist for B2B Sites: robots.txt, llms.txt, Schema and Citability

What actually gets a site cited by AI search engines, and which popular advice is still just a hypothesis

Short answer: a B2B site gets cited by AI search engines when three things are true at once. AI crawlers can fetch the content and the site is indexed; the content is machine-readable (server-rendered HTML and consistent structured data); and every page gives an answer that can be lifted out verbatim. There is no requirement for special "AI markup", a particular text length, or an llms.txt file.

Generative Engine Optimization (GEO) isn't a new profession or a new list of rules. The foundation is the same as ordinary search. But many sites with solid SEO still miss a few of the points below, usually without anyone noticing. A misconfigured robots.txt, or a company name spelled three different ways, can be enough for a model to pick a competitor as its source.

Requirement, method or hypothesis?

GEO advice mixes three different kinds of claims. Keep them apart:

Category	Meaning	Checks
Documented requirement	The search engines describe it in their own docs. Google says AI Overviews and AI Mode use the regular index, need no special AI optimisation, and require pages to be indexable and snippet-eligible.	1, 2, 5 (for rich results), 11
Working method	Not required, but formats that in practice recur in what gets cited, overlapping with Google's advice on useful content	6, 7, 8, 9, 10, 12
Hypothesis	Conventions AI companies haven't confirmed they use. Low cost, unclear effect.	3, 4

Crawlability

1. Explicit AI crawler rules in robots.txt. Training crawlers (e.g. GPTBot, Google-Extended) collect data for future models; search/fetch crawlers (OAI-SearchBot, ChatGPT-User, PerplexityBot) retrieve pages that can be cited right now; Bingbot feeds the Bing index that Copilot builds on. If you want to appear in AI answers, the search crawlers must get in. ClaudeBot handles crawling for Claude. Also check your firewall and CDN: a WAF rule returning 403 to an unfamiliar user agent never shows up in an SEO report. Look for 403/429 responses in server logs.

2. Be in Google's and Bing's index, and allow snippets. Google's AI features need an indexed page that's eligible for a snippet and not restricted by nosnippet or a low max-snippet. Many teams have never opened Bing Webmaster Tools, even though ChatGPT search has leaned on Bing's index and Copilot is built on it. Verify the domain, submit the sitemap and compare site: counts.

llms.txt (hypothesis)

llms.txt is a proposed standard (llmstxt.org) for a root-level Markdown file describing a site for language models. Be clear about what's known: Google has said it doesn't use it as a search signal, and OpenAI, Anthropic and Perplexity haven't documented that their crawlers read it. The case for it is low cost when generated automatically, some tools and agents fetch it, and writing it forces you to define what the site is.

3. Structure it correctly: an H1 with the site name, a blockquote summary, optional context paragraphs, H2 sections with - [Title](URL): description lists, and an Optional section. A curated short list beats hundreds of URLs.

4. Generate it automatically. llms-full.txt holds the full content of linked pages as Markdown. Hand-maintained files go stale, so build both into your publishing pipeline: when an article is published, it appears in the next build.

Structured data that builds entities

5. Organization, Person and Article/BlogPosting as JSON-LD in <head>, with datePublished and dateModified matching the visible dates. Organization gets sameAs links to profiles; Person gets jobTitle, worksFor and a LinkedIn sameAs.

6. FAQPage, BreadcrumbList and stable @ids. Give the organisation a fixed id like https://www.example.com/#organization and each author their own, then reference the same ids from publisher, author and worksFor on every page. One entity each, not twenty partial copies. Only mark up FAQs that are visible on the page.

Citable content (methods)

7. A short answer first — two or three sentences under the H1 that hold up out of context — and one clear definition per page.

8. Question headings, Q&A sections, tables and sourced figures. If a figure has no source, label it as experience or as a clearly marked example rather than guessing. Producing this consistently at scale is a content-operations problem; Successifier covers it in its guide to AI-driven content marketing for B2B (in Swedish).

Entity consistency and freshness

9. Same company everywhere. Compare name, one-line description, location and category across your About page, LinkedIn, directories and business profiles, and fix every mismatch. Add real author pages; they're also the home of your Person schema.

10. Freshness. Show honest update dates, run a quarterly review of your key pages, set sitemap lastmod from the same field as dateModified (not build time), and enable IndexNow. If every deploy bumps every lastmod, the signal becomes worthless.

Technical foundation and measurement

11. Self-referencing canonicals, hreflang for language versions, green Core Web Vitals, descriptive alt text and, critically, server-rendered HTML. Content that only exists after JavaScript runs is invisible to several AI crawlers. Test with curl. Most of this overlaps with classic technical SEO, covered in SEO for B2B companies (in Swedish).

12. Measure per engine. Run a fixed list of buyer prompts monthly in ChatGPT, Perplexity, Gemini and Copilot; segment GA4 referrals from AI domains; and track mention rate over time with a dedicated tool. Prompt testing is described in AI visibility in marketing (in Swedish).

Where to start

Checks 1, 2 and 11 are the documented requirements, they block everything else, and they can be verified in an afternoon. Then do structured data in a sprint and build the content format into your editorial routine. Add llms.txt if it can be generated automatically, but don't let it get in the way of the rest.

Originally published at https://www.successifier.se/blog/geo-checklista-for-b2b-sajter-2026-llms-txt-schema-och-citerbarhet (in Swedish)

Chatbots That Don't Guess: Grounding AI in Customer Service

Rickard Collander — Fri, 09 Oct 2026 18:52:14 +0000

Chatbots That Don't Guess: Grounding AI in Customer Service

A support bot should answer only from reviewed content, cite its source, and say so when it doesn't know. Here's how to design and test for that.

If you build or buy a chatbot for customer service, the single most important design decision is not the model. It's where the bot is allowed to get its answers. A bot that answers freely can sound confident and still be wrong, and the company, not the vendor, has to stand behind every answer it gives a customer.

What "grounded" means

A grounded chatbot may only answer with content from a defined source, usually the company's knowledge base, and must be able to show where each answer came from. In practice:

It answers only from published articles. Asked about the return period, it retrieves your returns article and phrases the answer from it. If the knowledge base says nothing about returns, it must not invent a period.
It cites its source. The customer can see which article the answer is built on and click through.
It admits missing material. "I don't have an answer to that, let me connect you" is a correct answer. A guess is not.

The usual technique is retrieval-augmented generation (RAG): retrieve relevant passages first, then let the model write an answer from exactly those passages. A general-purpose model without that link answers everything, whether or not it has your terms in front of it. That's why a reviewed knowledge base is a prerequisite, not an option. It also needs to cover exceptions: if delivery terms differ by country, the bot should ask which country applies rather than pick one.

General questions vs. personal cases

An article is enough for general questions. A personal case needs data about that specific customer.

Customer asks	Bot needs
How do I make a return?	A current, approved returns article
Where is my refund?	Verified identity and live payment data
Does this feature work on my plan?	The product rule and possibly account data
Can you make an exception?	A clear limit and a human who decides

If a required piece of data can't be fetched, the bot should say so and show the next step. Keep three levels apart and decide per flow which one applies: a draft an agent reviews, an automatic answer sent straight to the customer, and an executed action such as a refund. Each level needs more data and tighter permissions. Supportifier's integrations page shows the kind of system connections that personal answers depend on.

Why models hallucinate, and why RAG alone isn't the fix

A hallucination is an answer that sounds credible but has no support in any material. OpenAI researchers described in 2025 how training and evaluation reward guessing over admitting uncertainty, a bit like a multiple-choice exam where a blank never scores but a guess sometimes does.

Retrieval reduces the problem but doesn't remove it. Stanford RegLab's 2024 evaluation found that commercial legal research tools built on retrieval still hallucinated on a meaningful share of test questions. The takeaway: retrieval is necessary, but the bot must also be constrained to what was retrieved and allowed to say the answer is missing.

The company owns what the bot says

In Moffatt v. Air Canada (2024), an airline's chatbot told a traveller that a bereavement discount could be claimed retroactively; another page on the same site said the opposite. The airline argued the chatbot was a separate entity. The tribunal disagreed: the bot is part of the website, and the company is responsible for its statements. In e-commerce, the same mechanism produces invented discount codes, wrong return periods or delivery promises made without checking any system.

There's also a transparency requirement: under Article 50 of the EU AI Act, people must be told they're interacting with an AI system, at the latest at first contact, from 2 August 2026. Supportifier covers the data side in GDPR and AI in customer service.

A ten-question test for any vendor

Don't ask whether a bot "uses AI". Ask what it's allowed to answer and what happens when the answer doesn't exist. Then test it with your own material:

5 questions you have clear articles for → the bot should answer and cite them.
3 questions you have no article for → it should say so or hand over.
2 questions where your own sources contradict each other → it should surface the conflict.

Also ask: Can we see the list of questions it couldn't answer? Who can publish content it uses, and is there review? How is the customer identified before personal data is shown? Can we block topics like compensation, pricing exceptions and legal assessments? How are errors measured after launch?

Design the handover

Hand over automatically when material is missing, always when the customer asks, and as a rule when money, contracts or complaints are involved. A good handover means the customer doesn't repeat themselves (the whole conversation follows into the ticket), the agent sees which article the bot used so the article can be fixed, and the contact route is visible, including outside staffed hours.

The handover is simplest when bot and humans work from the same reviewed content. The same principle applies when AI suggests replies an agent reviews before sending; see why reviewed AI drafts beat full automation at the start.

Checklist

Every top question has a published article with a named owner.
Run the ten-question test on your current bot or a vendor demo.
Write a block list of topics the bot never handles alone.
Document the handover rule: when, to whom, with what context.
Review unanswered questions weekly and write the missing articles.
Track share of answers with a source, share of handovers, and repeat contacts within a week.

Originally published at https://www.supportifier.se/en/blog/grounded-ai-chatbot-customer-service