One of the easiest ways to make support look smarter than it really is involves asking it simple questions. “Do you have an annual plan?” “Can I cancel anytime?” “Do you support WordPress?” Give the system a good knowledge source and these are usually straightforward. There is a fact somewhere, the question points at that fact, and the answer comes back.
Things get more interesting when the exact same words can mean different things depending on who is asking them.
Imagine two people both type: “Can I add another user?”
The first person is on a plan that allows ten users and currently has two. The second is on a plan that allows three and already has three. A generic help article can explain how invitations work perfectly well, but if both people receive the same response, one of them is going to get an answer that misses the actual problem.
This is where I think support becomes genuinely interesting. The question itself is only one piece of information. The situation around it can matter just as much.
A sentence rarely arrives alone.
When we talk to another person, context is everywhere. Most of it is so obvious that we barely notice ourselves using it.
If a friend standing beside a broken-down car asks, “Do you think this will work?”, you do not answer by asking them which broad category of “this” they mean. You look at what they are holding. You remember what happened thirty seconds earlier. You know they are trying to start the car. The sentence is almost meaningless by itself, yet the conversation is perfectly understandable.
Websites lose a lot of that naturally available information. A text box receives a sentence. Unless the surrounding system deliberately provides more, that sentence can arrive almost completely detached from the situation that produced it.
That is a strange way to communicate when you think about it.
The visitor is looking at a product, perhaps logged into an account, maybe halfway through a specific task, and then we ask them to explain everything again inside a little support box.
The customer already has context. The support system either receives some of it or forces the customer to reconstruct it manually.
The page somebody is viewing can already tell you a lot.
Page context is one of the simplest examples because it does not require personal information at all.
Imagine someone asks: “Does this include installation?”
If they are currently looking at a pricing page and have selected a Business plan, the likely meaning is fairly obvious. They want to know whether setup help comes with that plan.
Ask the same question from an article about WordPress integration and the meaning changes. They may be asking whether the integration installs the widget automatically.
On an agency services page, “installation” might refer to something else again.
The sentence did not change. The page did.
I like this example because it shows that context does not need to mean collecting some enormous customer profile. Sometimes the current URL is enough to make a vague question much easier to understand.
Previous messages are context too.
This sounds obvious, yet bad support systems regularly behave as if every message is the beginning of a new conversation.
A customer asks: “Can I export my conversations?”
They receive instructions.
Then they ask: “What about after I cancel?”
The second sentence makes almost no sense without the first one. “What about” could refer to anything. A human reads it instantly as a follow-up about export access after cancellation.
This becomes especially important when customers speak naturally, because natural conversation is full of shortcuts. We stop repeating nouns once both sides know what we are discussing.
“And on mobile?”
“What if there are five of us?”
“Does that change on annual?”
“Even after the trial?”
These are completely normal questions. They only look incomplete when the system forgets the conversation every time a new message arrives.
Account context changes answers much more dramatically.
This is where the gap between general knowledge and customer-specific support becomes impossible to ignore.
Suppose a service offers three plans: Core, Business and Scale. The customer asks: “Can I use this feature?”
A public product page says the feature exists. That is useful information, but the real answer might depend on the customer’s plan.
If the feature belongs to Business and Scale, someone on Core needs a very different response from somebody already paying for Business.
The Core customer may need an explanation of availability and what an upgrade would change. The Business customer probably needs setup instructions. Sending both people the same generic feature page makes the customer do the final bit of interpretation themselves.
That final bit is exactly the sort of thing a good support system should be capable of handling.
Usage limits make this even clearer.
Imagine a plan includes a fixed number of conversations each month.
Customer asks: “Why can’t I start another conversation?”
Public knowledge can explain that the plan has a monthly allowance. It can explain when the allowance resets and whether additional usage is available.
The part that determines what is happening right now lives in the customer’s account.
Maybe they have reached the limit.
Maybe they still have plenty remaining and something else is wrong.
Maybe automatic top-up is disabled.
Maybe a payment for additional usage failed.
Those situations can all produce something that looks like the same question from the customer’s side.
This is why I find generic support answers increasingly frustrating once a customer is logged in. The system is often surrounded by information that could resolve the problem quickly, yet the customer is asked to describe everything as if the business knew nothing about them.
Order support is probably the easiest example in the world.
E-commerce makes context feel obvious because everyone has experienced the difference.
“Where is my order?”
A shipping policy cannot answer that question.
It can tell you that orders usually leave the warehouse within two business days. It can explain which carriers are used. It can describe delivery windows. All of that may be correct.
The customer asked about one order.
If support can see that the order shipped yesterday, has a tracking number and is currently at a local sorting centre, the conversation becomes very short.
If the order has not shipped because payment is awaiting review, the same question needs a different answer.
If the order was delivered three days ago according to the carrier, now we have a different problem again.
None of this is complicated conceptually. The difficult part is giving the support system access to the right context safely and making sure it uses that context correctly.
Context does not mean dumping every available field into the conversation.
Once people recognise how useful context can be, there is a temptation to provide everything.
Customer ID. Billing history. Browser. IP address. Account age. Previous tickets. Internal notes. Device type. Every event from the last six months.
That is rarely necessary.
More information creates its own problems. Some of it is irrelevant. Some of it is sensitive. Some can distract from the actual question. Some may be perfectly appropriate for a human employee and completely inappropriate to expose through an automated response.
I think useful context should have a reason for being there.
If plan name changes the answer, plan name is useful.
If the current order state changes the answer, order state is useful.
If the current page helps interpret a short question, page context is useful.
If the customer’s home address has nothing to do with the conversation, there is no reason for the support system to receive it.
Context is much easier to trust when every piece has a clear job. “The model might find it useful” is a weak reason to pass private customer data around.
The customer should not have to become an API response.
There is another extreme that appears in support forms.
Rather than giving the system useful context automatically, we make the customer supply it manually.
Account number.
Plan.
Order number.
Product.
Issue category.
Operating system.
Browser.
Description.
Sometimes those fields are necessary. Often they exist because the support infrastructure cannot easily see information the business already has.
That is a terrible reason to make the customer do administrative work.
If somebody is logged into the account, the business probably knows which plan they use.
If they opened support from an order page, the business probably knows which order they are looking at.
If the support widget runs on a specific page, it definitely knows the URL.
Asking people to repeat information already available somewhere in the system makes support feel more bureaucratic than it needs to.
Context can explain what the customer means before they finish explaining it.
One of the more subtle benefits appears with short, casual questions.
Suppose someone is looking at a page for a specific camera lens and opens support: “Does this fit the R6?”
The literal message contains no product name. If the system has no idea which page they are viewing, it has to ask: “Which lens are you referring to?”
That clarification is reasonable.
It is also unnecessary if the page context already says the visitor is looking at the exact lens in question.
A person working in a physical shop would naturally look at the product the customer is pointing toward.
Page context is the online version of that glance.
The same thing happens inside software.
Imagine a user is staring at an error inside a billing screen and opens chat: “Why is this disabled?”
Without context, the system needs a screenshot or a longer explanation.
With carefully provided interface context, it may already know which control is disabled and which conditions apply to the account.
Maybe the account is in a trial state.
Maybe only an administrator can change billing.
Maybe an invoice is overdue.
The user experiences a grey button.
The support system needs enough of the surrounding state to explain why that grey button exists.
Permissions are where context becomes especially important.
“How do I delete this workspace?”
A help article can describe the process perfectly.
If only workspace owners are allowed to delete it, the customer’s role suddenly matters.
Giving a team member instructions for a button they will never see is one of those support experiences that makes people question their own eyesight.
They open Settings.
There is no delete button.
They search again.
The article insists it exists.
Eventually they contact somebody.
All because the answer ignored one field: role.
A context-aware response can simply say that deletion is available only to the workspace owner and explain what the current user can do instead.
That feels obvious after you see it. Without role context, the support system cannot know.
Timing is context too.
I do not think context is limited to static account properties.
What just happened can matter enormously.
A customer asks: “Did that work?”
If they have just clicked “Cancel subscription”, the question is probably about cancellation.
If they have just attempted a payment, it means something else.
If they have just uploaded a file, it means something else again.
Recent actions can make otherwise vague messages completely understandable.
Of course, this kind of context needs care. There is no reason to stream every click a person makes into a support conversation. A handful of deliberate, relevant events can be enough.
Good context should reduce questions rather than create surveillance.
This is an important line for me.
There is a version of “personalisation” that becomes creepy very quickly.
A customer asks about changing their plan and the support system casually mentions that they visited the pricing page four times yesterday, opened an email at 2:14 AM and spent eleven minutes comparing Enterprise features.
Even if the business technically collected those events, using them in the conversation would feel bizarre.
Useful context should feel like the support system understands the current situation, not like it has been following the customer around with a notebook.
Plan.
Current page.
Relevant account state.
Current order.
Role.
Recent action when it directly explains the issue.
These make intuitive sense because a human support agent would likely need the same information.
There is another kind of context: what the business knows privately.
The public website might explain that refunds are available within fourteen days.
Internally, the company may have a rule that customers affected by a verified service outage can receive an exception.
If a customer asks for a refund after sixteen days and their account shows the relevant outage, a generic answer based solely on the public page may reject them.
Someone with internal knowledge and account context could recognise that an exception applies.
This is where the quality of support starts depending on relationships between information.
Public policy says one thing.
Internal procedure describes an exception.
Customer state determines whether that exception applies.
The final answer comes from combining all three correctly.
Context can also tell the system when to stop answering.
Imagine a support system knows that a payment is currently flagged for manual review.
The customer asks: “Why is this taking so long?”
Having context does not automatically mean the system should expose whatever it sees internally.
The correct behaviour may be to say that the payment is still being reviewed, give the expected timeframe and offer a human handoff if that timeframe has already passed.
Internal risk labels, staff notes or fraud signals may need to remain hidden.
This is why I think context permissions deserve as much attention as context access.
What may the system know?
What may it use to decide?
What may it say explicitly?
Those can be three different sets of rules.
Personalisation is a misleading word for some of this.
When people hear “personalised support”, they often imagine using the customer’s name or remembering their preferences.
That can be pleasant, but it is not the part I find most useful.
I care much more about situational accuracy.
Tell me the instructions that apply to my plan.
Tell me the delivery information for my order.
Tell me why a setting is unavailable to my role.
Tell me whether the action I just attempted succeeded.
Calling me by my first name while giving me a generic answer adds very little.
Understanding the situation adds a lot.
Context can make answers shorter.
This is something I really like.
Without context, support often needs to cover every possibility.
“If you are on Core, do this. If you are on Business, do this. If you are an administrator, use this option. If you are a team member, ask your owner. If your subscription is annual, this applies. Monthly subscriptions work differently.”
The answer becomes long because the system does not know which branch belongs to the customer.
Once the relevant state is known, most of those branches disappear.
“You’re on Business, so this is already included. Open Settings → Team and choose Invite member.”
Much nicer.
Context makes support feel smarter partly because it allows the system to say less.
It can also prevent upselling people who already bought the thing.
This sounds funny until you see it happen.
Customer: “How do I use priority support?”
Generic response: “Priority support is available on our Scale plan. You can upgrade here.”
Customer is already on Scale.
Now the support system has managed to advertise a product the person is currently paying for instead of explaining how to use it.
Context fixes this instantly.
It also prevents the opposite problem: telling somebody to use a feature that their current plan does not include.
These are small mistakes. They make the whole system feel disconnected from the business.
Logged-in support should know that the customer is logged in.
I have always found it slightly absurd when support on an authenticated dashboard behaves exactly like support on the public homepage.
The customer has already proved who they are.
They are inside a specific workspace.
The application knows their plan, role and account state.
Then the support window opens and asks: “Are you an existing customer?”
This is an infrastructure problem disguised as conversation.
The better experience begins before the first message. The support layer receives enough safe context to know where the conversation is happening.
That does not require giving it unrestricted access to the application.
The business can pass a small, deliberate set of values that are useful for support.
This is one of the reasons we designed Reesponder around context separately from knowledge.
When we started thinking seriously about Reesponder, I did not want “knowledge” to become a bucket where every kind of information gets thrown together.
A product page and a customer’s current plan are different things.
One describes the business generally.
The other describes the current situation.
Keeping that distinction matters because context can change constantly. Somebody upgrades. A payment succeeds. An order ships. A role changes. A customer moves from one page to another.
Reesponder is designed so a business can provide useful context to the support agent without rewriting that information into static knowledge every time something changes.
That sounds like a technical implementation detail, but the reason for it is very human: I want the response to make sense for the person who is actually asking.
Good context should be boring to the customer.
Ideally, the customer never thinks: “Wow, this system successfully retrieved my account plan.”
They just get an answer that fits.
That is how context works in ordinary human conversation too.
You do not congratulate a shop employee for noticing which product you are holding.
You do notice when they completely ignore it.
The technology should disappear into the usefulness of the response.
The nicest use of context is the one the customer experiences as simple competence.
There are limits, and they matter.
A support system should never assume that because some data exists, using it is automatically appropriate.
Businesses need control over what is supplied. They need to know why it is useful. Sensitive values should stay out unless there is a genuine support reason for them. Internal information needs clear rules around what can reach the customer.
There is also a practical limit.
Too much context can become noise.
If somebody asks how to change their password, their order history from last year probably contributes nothing. If they ask about a specific failed payment, that payment state matters enormously.
Relevance should win over volume.
Context is especially valuable when something goes wrong.
Happy-path questions are often easy.
The customer asks how to invite somebody.
You explain how.
The harder conversations begin when the expected thing did not happen.
“I paid but I still cannot use it.”
“I invited them but they never received anything.”
“The order says delivered but there is nothing here.”
“I changed my plan and the limit still looks the same.”
These questions require state.
What happened?
When?
What does the account currently show?
Did the previous action succeed?
Is there an error?
A general help article often cannot resolve that kind of issue because the customer is asking why reality differs from the normal instructions.
This is also where human handoff becomes much better.
Suppose automated support reaches the edge of what it can safely solve.
A human needs to take over.
The handoff is much better if the context travels with the conversation.
The human can see which plan the customer has, which page they were on, which order is involved and what has already been discussed.
The customer does not need to explain the whole situation again.
This is one of those details that sounds operational until you are the person repeating the same story for the third time.
Then it becomes very important.
Context can reveal that the support question is actually a product problem.
Once conversations can be connected to pages, features and account states, patterns become more useful.
Maybe a large number of customers ask for help from the same screen.
Maybe nearly everyone on one plan misunderstands the same limit.
Maybe people repeatedly ask what happens after clicking a specific button.
Without context, these are simply a collection of support messages.
With context, they can point toward an interface problem, confusing plan wording or a workflow that needs better explanation.
I like this because support becomes a way of observing the product through customer confusion.
Sometimes the right long-term fix is a better answer.
Sometimes the right fix is making sure nobody needs to ask the question next month.
A correct answer can still leave the customer stuck.
Imagine a user asks: “Can I add another website?”
The support system replies: “Business supports up to five websites.”
That statement may be completely correct.
The customer currently has five.
They are still stuck.
The answer they needed was closer to: “Your Business workspace currently has five websites, which is the plan limit. You can remove one before adding another, or move to Scale if you need more.”
Same product knowledge.
One extra piece of account context.
Completely different usefulness.
This is why I care less about whether support sounds clever.
A support agent can write beautifully and still be unhelpful.
It can use warm language, elegant formatting and perfectly natural sentences.
If it does not understand the customer’s situation, the polish only hides the problem for a little longer.
I would much rather receive a plain answer that knows which order I mean than an impressive paragraph explaining the company’s shipping policy.
The thing I want support to feel like is awareness.
Awareness of what I am doing.
Awareness of what already happened.
Awareness of the parts of my account that actually affect the answer.
That is what makes the interaction feel connected to the product instead of bolted onto the side of it.
There is a surprisingly simple test.
Take an answer and ask: “Would this still make sense if it were sent to every customer?”
If yes, you probably have a general answer.
General answers are useful. Plenty of questions need exactly that.
Then ask: “Is there anything about this customer’s current situation that would change what I say?”
That is where context begins.
Plan.
Role.
Page.
Product.
Order.
Previous messages.
Current usage.
Recent action.
Most conversations need only a few of these.
The useful part is choosing the right few.
I think support gets much better once the system knows where it is standing.
Public knowledge gives the system an understanding of the business.
Context gives it an understanding of the moment.
A person asks a question from a specific place, in a specific account, after specific things have happened. Those details often determine which part of the business knowledge actually applies.
This does not need to become complicated for the customer. In fact, the whole point is usually to make the customer’s side simpler.
Fewer forms.
Fewer repeated explanations.
Fewer generic answers that require another question.
Fewer moments where the customer wonders whether the support system has any connection to the product they are currently using.
If the necessary context can be supplied safely, support can meet the customer much closer to where the problem actually is.
That is the standard I find much more exciting than simply generating a technically correct sentence.