Demand Letters for Software Development Disputes: Bugs, Delays, and Scope Creep
If you are reading this, there is a good chance you paid a developer or an agency to build something important – a SaaS platform, a mobile app, a custom integration – and what you received is late, broken, or nowhere near what was promised.
At this stage you have usually tried the polite route. You have sent emails. You have gone back and forth on Slack, WhatsApp, or Upwork. You may have given second, third, and fourth chances. Now you are tired of excuses and you want to put real pressure on the developer without immediately jumping into an expensive lawsuit.
That is exactly where a well-structured demand letter becomes useful.
This article explains how software development disputes typically go wrong, what a demand letter can realistically achieve, how to avoid common mistakes, and how to frame your position in a way that gets attention instead of being ignored. At the end, you will find a free demand letter template and twenty common questions I am asked by clients in this situation, with practical, experience-based answers.
Why Software Development Disputes Feel Different From Other Business Disputes
On paper, a software development dispute is “just” a breach of contract. In reality, it feels very different from a simple unpaid invoice or a one-time product sale.
You are not arguing about a single physical item. You are arguing about something complex and intangible: features, performance, reliability, scalability, design, integrations, and user experience. The product often lives in a GitHub repository controlled by the developer, on servers you do not fully control, and in code you cannot read.
This creates three problems for non-technical clients.
First, it is hard to describe what is “wrong” with the project in a way that does not sound emotional. You know the app crashes, the integration does not work, or the store is too buggy to launch, but turning that frustration into a clear narrative the other side (and eventually a judge or arbitrator) will respect is not easy.
Second, your leverage is not only about money. The developer may still control the server accounts, code repository, deployment pipeline, and API keys. Even if they refund part of the fee, that does not help if you still cannot access your own product or data. A good demand letter has to address money and access in the same breath.
Third, many projects are cross-border. You might be in California, your developer in Eastern Europe or Asia, and the contract governed by U.S. law but practically very difficult to litigate abroad. Your demand letter needs enough legal backbone to be taken seriously, but also enough practicality to acknowledge that your main leverage may be reputational and business-centric rather than purely courtroom-centric.
Before You Write: Get Clear On What You Actually Want
Clients often come to me saying “I want my money back and I want the app finished.” Sometimes that is possible. Often, it is not.
Before you draft a demand letter or ask a lawyer to do it, take time to decide what a realistic win looks like for you. That decision will drive the tone of the letter and the remedies you demand.
Common goals include one or more of the following:
You may want a full or partial refund so you can walk away and hire someone else. This is especially common where the codebase is such a mess that any new developer will insist on rebuilding from scratch, or where the project is still in a very early, unusable state.
You may prefer completion by the current developer under a stricter structure. In that case the letter is less about “pay me back” and more about “here is a firm, detailed completion plan, backed by consequences if you do not hit these milestones.”
You may care most about a clean handover: access to all repositories, code, documentation, and accounts so that a new developer can salvage what has been built. When time is critical, sometimes the main priority is “give me the keys and get out of the way” rather than squeezing every last refund dollar out of the old team.
You might want a combination: partial refund, handover, and a mutual release where both sides agree to walk away and not pursue each other further. For some clients, especially busy founders, closure and clarity are more valuable than eking out a slightly better theoretical outcome after months of fighting.
When your goal is fuzzy, the letter tends to wander and threaten everything at once. When your goal is clear, the letter becomes focused and much more persuasive.
Turning a Messy Project Into a Clear Story
One of the most valuable things a demand letter can do is turn an emotional, messy situation into a calm, chronological story.
Start with the basic building blocks: what you agreed to, what actually happened, what you paid, what you received, and how things went off the rails.
You do not need to write a technical manual. You do need a timeline that a non-technical judge could follow. It usually looks something like this when I work with clients:
You identify the contract and scope of work. This may be a formal master services agreement plus a statement of work, an Upwork contract description, a proposal email the other side sent, or even a series of messages where they clearly described what they would build and for how much.
You list the major milestones that were promised. That usually includes dates such as “prototype ready,” “beta available for internal testing,” “MVP ready for public launch,” or specific feature deliveries.
You line up the actual payments made against those milestones. Many clients have continued to approve milestones or pay invoices long after they were already uncomfortable. That does not mean you have no case, but the letter should acknowledge that pattern and explain why, at some point, enough was enough.
You describe, in plain language, the main defects. For example: “the iOS app crashes when a user attempts to check out,” “the Stripe integration does not actually charge customers,” or “the data imported from the old system is incomplete and cannot be searched.”
You avoid turning the letter into a Slack transcript. Instead, you choose a few key examples of emails or messages where the developer insisted the project was “nearly done,” promised specific fixes, or set specific dates and then failed to follow through.
That factual narrative is the backbone of your demand letter. Only after that is clear do I usually shift into legal framing.
Common Patterns: Bugs, Delays, and Scope Creep
Most disputes fall into some combination of three themes: the product is too buggy to use, the project is unreasonably delayed, or the scope of the project expanded in a way neither side handled well.
Bugs and non-functional features
Bugs are inevitable in any real software project. The question is whether bugs are at the level of “a handful of cosmetic issues” or “the store cannot process orders” or “the app constantly crashes.”
In a demand letter, you rarely have to catalogue every minor glitch. You focus on the critical issues that make the product unfit for its intended purpose. When you state those issues, you want to avoid abstract language (“it is garbage”) and stick to objective problems (“customers cannot create an account,” “search returns no results,” “payment cannot be completed”).
A common pattern I see is where the developer continually patches one bug at a time but never stabilizes the system. The client feels as if the project is stuck in endless “bug purgatory.” A good letter explains that pattern: repeated attempts, repeated assurances, and still no usable product.
Unreasonable delays and missed launch dates
Software schedules slip all the time. That alone does not guarantee a strong legal claim. The delay becomes a serious breach when it is excessive compared to what was promised, when it defeats the whole purpose of the project, and when the developer cannot justify it by reference to forces outside their control.
If you hired someone in January on a promise of a March launch and you are still waiting in October with no realistic completion date in sight, a judge or arbitrator is going to sympathize. Your demand letter should show the promised dates, the actual dates, the extensions you granted, and the business opportunities you reasonably planned around those dates.
In many contracts, “time is of the essence” is not explicitly written in. Even without that language, however, a delay can be material if it destroys the value of the bargain. For example, missing a crucial conference, marketing campaign, or investor pitch because the product was not launch-ready.
At the same time, you should acknowledge where you contributed to delay. If you were weeks late providing content, branding, or feedback, it is better to admit that up front and draw a line between those delays and the bigger, unjustified ones on the developer’s side. That kind of honesty increases your credibility.
Scope creep and moving goalposts
Scope creep is probably the single most common source of friction in software projects. It happens when the client keeps asking for “just one more small feature” and the developer keeps saying “sure, no problem,” but no one updates the actual scope, budget, or timeline in writing.
In a demand letter, you do not have to pretend that every single new idea was within the original scope. Instead, you can separate the “core scope” from the “extras.” You make the point that, even if every enhancement is treated as out-of-scope, the developer still has not delivered the core features that were clearly promised.
When I draft letters, I often explicitly say something along the lines of: “Over time, the parties discussed additional enhancements and upgrades. Even if those enhancements are treated as separate from the original scope, the core deliverables set out in Exhibit A have not been delivered in working condition.”
This turns scope creep from a weapon the developer can use against you (“you kept changing your mind”) into a controlled variable that you have already accounted for.
What Makes a Strong Demand Letter in a Dev Dispute
A strong demand letter does not have to sound like a law review article. In fact, when you over-lawyer it, it can come across as hollow. The best letters in this space are written in plain, direct English, but with a clear structure and an unmistakable sense of seriousness.
In most software disputes I handle, the letter includes the following elements in one form or another.
It clearly identifies who you are, who you represent (if written by a lawyer), and what the project is. The recipient should immediately know which client, which software, and which contract the letter is about.
It summarizes the contract, scope of work, and major milestones in neutral language, before accusing anyone of anything. That section is there to show that you understand the deal and that you are not trying to rewrite the arrangement after the fact.
It explains, with dates and facts, how the project failed: critical bugs that remain unfixed despite repeated chances, milestones missed by months, or core features never delivered.
It frames those failures as a breach of the contract and of the basic obligation to perform services competently. You do not necessarily have to cite statute numbers, but you do need to make it clear that you view these failures as more than just “disappointing.”
It sets out, in concrete terms, what you want the other side to do. That might be refunding a specific dollar amount, delivering specific features by specific dates, or handing over the complete codebase, documentation, and access credentials so you can move on.
It sets a realistic deadline for response and performance. Ten to fourteen days is common. The letter should make clear that if you do not receive a satisfactory response by that date, you will consider your options, which may include arbitration, litigation, small claims, or platform complaints.
Finally, it maintains a professional tone. You can be firm without being insulting. You can point out inconsistencies and broken promises without calling the other side a scammer or fraudster in every sentence. That balance is not just about politeness; it is about protecting yourself from defamation claims and keeping the door open to settlement.
Free Demand Letter Template For Software Development Disputes
Below is a general-purpose template you can adapt. It is designed for situations where a business has hired a developer or agency for a SaaS build, mobile app, or custom integration, and the project has serious bugs, delays, or scope issues.
You will need to customize it for your own jurisdiction, contract, and facts. This is not legal advice for your particular situation, but it gives you a solid starting point to work from.
[Your Name / Company Name]
[Street Address]
[City, State ZIP]
[Email Address]
[Phone Number]
[Date]
Via Email [and Certified Mail, if used]
[Developer / Agency Name]
[Contact Person, if any]
[Street Address]
[City, State ZIP]
[Email Address]
Re: Software Development Agreement for [Project Name] – Demand for Cure and Refund
To [Name],
I am writing regarding the software development engagement for “[Project Name]” under which you agreed to design, develop, and deliver [brief description, for example: “a web-based SaaS platform and companion mobile application for [business purpose]”] for [Your Company Name] pursuant to our agreement dated [Contract Date] (the “Agreement”).
Under the Agreement and related statements of work, you represented that you would deliver, among other things, the following core features and milestones: [briefly describe key scope elements and promised dates, using the contract’s own language where possible].
Since entering into the Agreement, [Your Company Name] has paid you a total of [total amount paid] in fees, including the following invoices/milestones: [describe at a high level, for example: “an initial deposit of $X on [date], milestone payments of $Y on [date] and $Z on [date], and additional charges of $W on [date]”].
Despite these payments and the substantial time that has passed, the project remains in an unusable and incomplete state. By way of example only:
[Describe a few key failures in paragraph form. For instance:
“The production checkout flow fails whenever a user attempts to submit payment, preventing any customers from completing orders.”
“The ‘Create Account’ feature does not function on mobile devices and returns errors on desktop.”
“The promised integration with [system or API] has not been implemented and no data sync occurs between systems.”]
We have repeatedly raised these issues with you and provided you with opportunities to correct them. On [dates or approximate timeframes], we notified you that the application remained non-functional for its intended purpose, and you assured us that fixes were forthcoming. To date, however, the critical defects remain unresolved and the core deliverables identified above have not been provided in working condition.
The combination of ongoing critical bugs, failure to deliver the agreed-upon features, and substantial delays well beyond the original timelines constitutes a material breach of the Agreement and of your obligation to perform the services in a competent and workmanlike manner. As a result, [Your Company Name] has not received the benefit of its bargain and has suffered losses, including but not limited to the development fees already paid and the additional costs required to engage a new developer to complete or rebuild the project.
In an effort to resolve this matter without further escalation, [Your Company Name] demands that you take the following actions:
[Here you insert your preferred resolution. Examples:
“Refund [dollar amount] of the total fees paid within ten (10) days of the date of this letter; and
Transfer to [Your Company Name] full access and ownership of all code, repositories, project files, and related documentation for the project, including administrator-level credentials to all hosting, version control, and deployment accounts currently used for the project.”
or
“Substantially complete and deliver the core features listed above, in working condition, no later than [date], together with full handover of source code and documentation, in exchange for [Your Company Name] agreeing to treat the remaining issues as out-of-scope enhancements under a new, separately agreed change order.”]
Please confirm in writing by no later than [deadline date, typically ten to fourteen days from the letter date] whether you will comply with the demands above and, if so, provide a specific timeline and process for doing so. If we do not receive a satisfactory response by that date, [Your Company Name] will consider all available options, including but not limited to initiating legal proceedings, pursuing arbitration or small claims where applicable, and asserting any claims it may have for damages and other relief.
Nothing in this letter is intended as a complete statement of all facts or law, or as a waiver or limitation of any rights, remedies, claims, or defenses of [Your Company Name], all of which are expressly reserved.
Sincerely,
[Signature]
[Your Name]
[Title]
[Your Company Name]
Frequently Asked Questions About Demand Letters For Dev Disputes
Do I need a written contract before I can send a demand letter?
No. A written contract helps, but it is not absolutely required. In many disputes I see, the “contract” is a combination of emails, proposals, platform messages, and invoices that clearly show what was promised and for how much. In a demand letter, you can treat those communications as your agreement and quote the key language. Courts routinely enforce these kinds of “informal” agreements, especially when one side has already paid and the other has already started work.
If you truly have nothing in writing at all, your position is weaker, but not hopeless. In that case your letter will lean more heavily on what was said in calls, what was reasonably understood, and what the developer actually delivered. The more you can reconstruct in writing now, the better.
What if my developer is in another country?
Cross-border disputes are very common in software. The developer might be halfway around the world, working under a contract that says U.S. law governs, or sometimes under their own local law. A demand letter is still useful, even if litigation abroad would be impractical.
First, it shows you are serious and organized. Many developers depend on platforms, payment processors, and reputation. A calm, well-documented letter can push them to propose a settlement even if they know you are unlikely to sue them in their home court.
Second, your letter can be used later if you escalate the dispute through a platform or payment channel that does not care where the developer is located. For example, when you submit complaints or disputes, having that letter and evidence shows you made a real attempt at resolution.
Third, even if you never go to court, a lawyer-drafted letter from your jurisdiction can sometimes nudge an agency to involve their own counsel or insurer, which often leads to a more realistic conversation.
My project is buggy but technically “delivered.” Do I still have a case?
Possibly, yes. Delivery of a broken or unusable product is not truly “delivery” in the legal sense if what you received is not fit for the purpose both sides contemplated. The key question is whether the problems are minor annoyances or serious defects that make the product unfit for its advertised or agreed purpose.
In your demand letter, focus on how the bugs impact real-world use. “The system produces an error when a user attempts to register, so no new customers can sign up” is far more persuasive than “there are many bugs.” If you repeatedly reported these issues and gave the developer chances to fix them but the project never stabilized, that pattern strengthens your position considerably.
What if I approved milestones on Upwork or another platform even though I was unhappy?
Approving a milestone or paying an invoice does not automatically waive all rights, especially if you approved under pressure, based on promises of future fixes, or in order to keep the project moving. It does, however, complicate the story.
In your letter, you can acknowledge the approvals while explaining why they did not mean you were satisfied. For example, you might say that you approved a milestone because the developer insisted it was necessary to unlock further work, or because key issues were supposed to be resolved “in the next sprint.” The more clearly you explain that context, the easier it is to overcome the argument that “you approved everything so you must have been happy.”
Courts and arbitrators look at the entire course of dealing, not just a single button click. If your messages show ongoing complaints and requests for fixes, that often carries more weight than the formal milestone status.
Can I send a demand letter myself or does it have to come from a lawyer?
You are allowed to send your own demand letter, and in smaller disputes many people do that as a first step. A well-written letter from a non-lawyer is better than no letter at all, and in some cases it is enough to get a refund or a compromise.
That said, there is a difference in impact when the letter comes on law firm letterhead from someone who clearly understands the legal issues. It signals that you are willing to take the next steps if necessary, that the facts have been organized and evaluated, and that you are not simply venting. It also ensures that you do not accidentally say something that weakens your position, such as over-admitting fault or making legally risky threats.
In higher-value projects, or where the situation is especially messy, it is usually worth at least having a lawyer draft or review the letter before you send it.
How detailed should I be about the technical problems?
You do not need to turn the letter into a technical specification, but you should be detailed enough that a non-technical decision-maker can understand the seriousness of the issues. Think in terms of real user flows: what your customer is trying to do and where that breaks.
For example, instead of saying “the code is bad,” describe that when a user adds an item to the cart and clicks “checkout,” the app freezes or returns an error and no order is created. That is easy for everyone to understand, from a judge to a project manager to a company executive.
If you have a technical advisor or a new developer who has looked at the code, their input can help you describe the problems in plain language. You can also attach a short, separate list of representative defects as an exhibit, while keeping the main body of the letter focused and readable.
Can I accuse the developer of fraud or scamming me?
You should be very careful about calling something “fraud” unless you have strong, specific evidence. Ordinary breach of contract and bad project management is not the same as fraud. Fraud involves intentional misrepresentation of material facts that you relied on, such as lying about credentials, fabricating portfolios, or knowingly charging for work that was never done.
Throwing around words like “scam,” “fraud,” and “criminal” in a demand letter can backfire. It can escalate emotions, make settlement harder, and potentially expose you to defamation claims if the accusations are not well-founded and you send the letter broadly.
A more strategic approach is to focus on provable facts and broken promises. If there are serious red flags that might justify reporting to a platform or regulator, your lawyer can help you decide how to phrase that and which channels are appropriate, rather than turning the demand letter itself into a criminal indictment.
What if I contributed to the problem by changing requirements?
Most software disputes involve some degree of shared responsibility. Clients often change their minds or add features; developers often say “yes” without updating scope, budget, or timeline. The fact that you requested changes does not give the developer a license to deliver nothing useful.
In your letter, it is often better to acknowledge that the project evolved and then refocus on the core promises. You might, for example, say that while additional enhancements were discussed over time, the central deliverables in the original scope – such as a working payment flow or functioning core integration – were never delivered in usable form.
That framing prevents the developer from using scope creep as a blanket excuse, while showing that you are not trying to hide your own role in the project’s complexity. Decision-makers tend to trust parties who acknowledge nuance.
How do I decide between asking for a refund versus asking them to finish the project?
Ask yourself two questions. First, do you still trust this team to deliver a usable product if you give them one last, tightly defined chance? Second, would a new developer realistically be able to salvage the existing code, or will they insist on starting from scratch?
If trust is broken and every interaction feels like a struggle, forcing completion may just prolong your pain. In that case, a refund-plus-handover demand is usually more sensible. You want as much money back as you can reasonably get, plus ownership of whatever work product exists, so you can hand it to someone else or at least learn from it.
If the relationship is strained but salvageable, and you have reason to think the current team can actually finish under clearer structure, you can offer a conditional path: a concrete set of deliverables, deadlines, and acceptance criteria, with a backup demand for refund if they miss those terms. Your letter can present that as a businesslike proposal to avoid escalation.
What if the contract has a limitation of liability clause that caps their exposure?
Many development contracts include clauses that limit the developer’s liability to some multiple of the fees paid, and that exclude “consequential damages” such as lost profits or lost business opportunities. Those clauses are not always iron-clad, but they do matter.
In a demand letter, you do not usually have to argue every nuance of enforceability. You can acknowledge that the contract contains certain limitations while still insisting on a fair outcome within that framework. For example, if the cap is “fees paid,” your primary demand may focus on recovering a substantial portion of those fees, rather than claiming millions in speculative damages.
There are situations where limitations may not apply, such as intentional misconduct or certain statutory claims, but those depend heavily on jurisdiction and facts. A lawyer can help you decide when to push on those boundaries and when to lean into a more pragmatic settlement within the contractual limits.
How long should I give them to respond to the demand letter?
In most cases, ten to fourteen calendar days is reasonable. That window is long enough for a professional organization to read the letter, confer internally, and respond, but short enough to convey urgency.
If there is an imminent deadline – for example, you are about to file in small claims court or a platform’s dispute window is closing – you might choose a shorter period and explain why. On the other hand, if the dispute is large and you want to leave room for more thoughtful negotiations, you can extend the deadline, but you should still put a date on the calendar.
The important part is to avoid open-ended demands like “respond as soon as possible.” A clear deadline makes it easier to justify taking the next step when the other side stays silent or sends a non-response.
Should I mention that I’ll complain to Upwork, Stripe, or other platforms?
This is very fact-specific. Threatening every possible channel in one letter can make you look more interested in punishment than resolution. It can also be misread as extortion if you are not careful about how you frame it.
A better approach is to focus your demand letter on the contract dispute itself. You can mention, in restrained language, that you will consider whatever remedies are available, including platform or payment disputes, if the matter cannot be resolved. You do not need to list every platform by name.
If you are dealing with a developer who depends heavily on a particular marketplace, your lawyer may choose to privately reference the possibility of platform complaints during negotiation, rather than blasting that threat in the first letter. This keeps the tone more professional and less retaliatory.
Can I send the demand letter by email, or do I need certified mail?
Email is increasingly common and often the primary channel in tech engagements. In many cases, I send demand letters by email and, depending on the situation, also by certified mail or another trackable method. The goal is to be able to prove that the other side actually received the letter.
If your contract specifies a particular notice method and address, it is wise to follow that instruction as well, even if everyone has been communicating informally elsewhere. You can do both: send it to the formal notice address by mail and send a PDF copy to the contact’s usual email.
If the developer primarily communicates via a platform, you may also upload or reference the letter through that platform’s messaging system, while understanding that platform support may or may not get substantively involved.
What if the contract requires arbitration?
If your contract includes an arbitration clause, your realistic “next step” after an unsuccessful demand letter may be arbitration rather than court. That does not make the letter less important; in fact, it makes it more important, because arbitrators often look at the pre-dispute correspondence to understand the history and see which side has been reasonable.
In your letter, you can simply note that if the dispute is not resolved informally, you are prepared to pursue your claims through the agreed dispute resolution process. You do not have to explain arbitration procedures in the letter itself.
A lawyer familiar with arbitration will help you think about filing fees, venues, and whether your claims are more suited to arbitration or small claims court if you have a choice. Sometimes the arbitration clause itself has flaws or exceptions that can be used strategically.
Is it worth pursuing smaller disputes, like five or ten thousand dollars?
It can be, especially when you have clear documentation and a strong sense of principle. For smaller disputes, the economics may favor a combination of a lawyer-drafted demand letter and, if needed, small claims court rather than full-blown arbitration or litigation.
A structured demand letter can frequently unlock a partial refund or negotiated settlement even on modest amounts, simply because the developer understands that ignoring you may lead to more hassle than paying a fair portion back. In other cases, sending the letter and then filing in small claims, where available, is still far more efficient than walking away in silence.
The key is to balance the amount at stake against the time, stress, and costs. One advantage of involving a lawyer who regularly handles these matters is that you can get a realistic sense of your options and likely outcomes at the outset.
Will sending a demand letter “kill” any chance of a friendly resolution?
It depends on how you write it. A demand letter can be aggressive and insulting, or it can be firm, clear, and still constructive. In many of my matters, the letter is actually the moment when the conversation becomes more serious but also more productive.
If your tone is “here are the problems, here is what the contract says, here is what we are asking for, and we would prefer to resolve this without further escalation,” you are not slamming the door. You are simply setting boundaries and consequences.
Of course, some developers respond poorly to any formal communication, no matter how polite. You cannot control that. What you can control is how you present yourself. A well-crafted letter actually increases the odds of an orderly settlement because it shows you are a rational actor, not just an angry client.
What if the developer ignores the letter completely?
Silence is a response. It usually tells you that voluntary, informal resolution is unlikely. Once the deadline passes with no meaningful reply, you decide whether to escalate or to cut your losses.
Your options may include filing in small claims court if the amount is within the limit, initiating arbitration if required, pursuing platform disputes within their timelines, or simply moving on and treating the loss as a learning experience. The right choice depends on the size of the dispute, your budget, and how strong your case is.
Importantly, even if you ultimately decide not to sue, the exercise of organizing your facts into a demand letter has value. It clarifies your own understanding of what went wrong and often informs how you structure future development agreements to avoid repeating the same mistakes.
How can I avoid ending up in this situation again?
As painful as a bad project is, it can be an excellent teacher. After a dispute, I often help clients redesign their development contracts and processes. The improvements usually include more detailed scopes of work, clearer acceptance criteria, explicit testing and bug-fix periods, formal change-order procedures, and better milestone structures.
For non-technical founders, having an experienced lawyer review or draft the next development agreement pays for itself many times over. The goal is not to prevent every possible dispute – that is impossible – but to reduce the likelihood of serious misunderstandings and to give you cleaner leverage if things go sideways.
A strong contract also makes any future demand letters easier to write and harder for the other side to ignore. When expectations are precise on paper, it becomes much clearer when those expectations have not been met.
Used correctly, a demand letter in a software development dispute is not just a piece of angry correspondence. It is your opportunity to present a calm, structured account of what went wrong, to propose a realistic path to resolution, and to show that you are ready to take the next step if necessary. Whether you draft it yourself using a template like the one above or ask a lawyer to do it for you, the key is the same: clear facts, clear asks, and a professional tone that keeps the focus on solving the problem.