Hello. Thanks for joining me for today's Webinar. Today's topic is super important. It's the timeline of a successful web design project. Timeline to me really means two things. First, it means how long does the project take, which everyone wants to know before they begin, and more importantly, it means phases.
You know, the timeline is a series of phases that all need to happen for a successful project. This webinar is inspired by, I think possibly our most popular blog post ever of the same title. So, we know there's a lot of interest about this topic, and without much ado, let's dig right in.
Okay, everybody, thanks again for joining me. I know it's hard to take a half an hour, or an hour out of your day to listen to a guy like me talk on, and on, and on, and I do appreciate it, so thank you for joining us. Today's topic again, the timeline of creating a successful website. So let's dig right into it.
First of all, what are you going to learn today? Well, first we're going to talk about the phases of a web design, and CMS implementation project, it's really what we're going to focus on today. We're going to have some assumptions, which I'm going to go over in just a second. We're going to talk about how each phase is executed, and then we're going to talk about how you can mitigate your risk throughout the project, each phase, starting with the beginning discovery, through design development, all the way to a deployment.
A little bit about who we are, The New possibilities Group. My name is Peter Czech, I'm the founder of the company. We're a full service digital agency. We specialize in custom web design, custom web development, and we work across a variety of platforms, whether it be open source, or licensed content management systems, we can help.
Here's just a sampling of our services, strategy, design, development, maintenance, and then marketing growth, and ongoing maintenance. A couple of assumptions before I go too far into the topic. All projects are different, there are similarities on almost every project we do, but they are all a little bit different.
So, I'm going to assume as I talk through these phases that we're building a informational type of website. This is something if you're a marketer, a CMO, a marketing manager, B, to B, B, to C, whatever it may be, the type of project I'm envisioning here is maybe something with 10, to 15 different templates, a blog, maybe some simple functionality like that.
While the steps I'm going to tell you apply to so many different projects, it could be app development, could be a web app development, anything like that, I do want to focus this one a little bit more geared towards marketers. I'm going to be talking about custom design, I'm not going to really talk about theming. There's a big difference between the two. In a quick description, theming is when you might download a content management system like WordPress, and then you just license a theme, and just modify it until you're done, that's not what I'm talking about here.
I'm talking about a custom design made for you based on your objectives, and your brand guidelines. So, that's the type of project we're going to be talking about. I will be talking to CMS implementation, I might refer to WordPress, or Drupal, or Kentico, or whatever throughout the conversation, but I'm going to try to stay mostly platform agnostic.
So with that said, let's talk about the phases in a custom web design project. It starts with planning, and architecture, then we proceed, and let me break up each one a little bit, although I'm going to go into them in detail, but planning, and architecture is where you obviously come up with a blueprint for what your project is all about.
It's a little bit of internal work, it's a little bit of work with vendors. Design is where we actually go into a design phase, and start to visualize some of the things that your site is going to need, deliverables, templates, prototyping, things like that. Development is really your CMS implementation for the purposes of this project, and again this is applicable across almost any type of a development project.
So, if you were building a custom app, well it's not going to be a CMS we're going to implement, but we might just build custom code. A huge thing on informational sites, a big phase, and what everybody seems to forget, including agencies, content migration, content development, there's a lot that happens there.
The next phase, which sort of happens throughout the process, but needs to have it's own step as well towards the end is testing, testing quality assurance. So, we're going to talk about that. Obviously deployment, no one ever really mentions that when they're bidding web design work, or talking about the project, but your goal should be seamless deployment, and with a bunch of things considered like security, and SEO, so we'll talk about that, and post-launch, post deployment from a continuous improvement perspective, what's happening there, so we're going to talk about that as an entirely separate phase.
So, let me go to the next slide here. Phase one, planning. I consider this the most important phase. There's a series of steps that I'm going to go through for phase one, and I've actually separated out the slides for this one. I'm trying to keep these webinars with a minimal amount of slides, because it's boring I know, but I broke out each one of these steps, because this is so important, and this lays the foundation for your success.
So real briefly, it's identifying stakeholders, creating an internal team, it's gathering requirements, setting goals, procuring a partner to help you, and then building out a specification via discovery, a blueprint for your project. These are all the phases that go, or the steps that go into the first phase of planning. So in digging in, let's talk about identifying stakeholders.
We have a separate blog post for this, which is actually one of our top 10 of all time. It's very important to identify who the people are within your company that are going to have a say, or should be involved in the web design project. This is something I ask the minute you fill out my contact form, and you get a needs assessment for me, I ask who should be involved in the project.
Whoever is spearheading this, the primary stakeholder, if they need to find all those essential parties. In a typical web design project, we're going to see marketing, we're going to see IT, sales, and almost always we're going to see some sort of executive involvement. Those are just more standard groups that we might see, there might be others depending upon your company, but this needs to be considered, and from that group, if you don't know who it is, yeah, there should be a primary stakeholder.
I'm assuming it's probably you, the person who's watching this, because that makes the most sense, but when you're working through a project, you need one point of contact for your partners, which is your design, and development partner. Maybe you have a marketing, like a advertising agency as well, that one person needs to sort of serve as the funnel, the one point of contact for the entire company, so this is a super crucial step.
Step two, requirements gathering. So, now you've identified who the stakeholders are. So, you need to start to work on figuring out, 'Well, what are the requirements for the project?' The best way to do this is to have internal meetings. I don't want to turn this into an exercise of everybody's like having 30 meetings that are five hours long, and everyone's kind of burned out before the project begins, but you do have to meet with everybody internally to figure out what's important to them about the initiative you're about to undertake.
It could take a couple of meetings to identify, and prioritize. You know, we give tips before you go into that, some of the things that I like to do is have an initial meeting and gather high level requirements, and then have the point person sort of aggregate it into a single list, find commonalities, find outliers, and then turn that into wishlist items like must have, would be nice to have, and then tertiary considerations.
So, that's pretty much requirements gathering. I made it sound a whole lot simpler, but that's a top level view. Goal setting. You know, a lot of people come to us, it's weird, they come to us, they don't necessarily have a goal for what they want the site to accomplish other than to look good, and that's not a good enough goal.
So, you really have to have an introspective moment, and understand what do you want users to perform? So, on my site for example, I mean, it's all about the contact form. How can I get people to fill out the contact form, have a consultation with me, and then I have secondary conversions, signing up for a webinar, downloading an ebook, something like that.
So, you need to sort of figure out what's the idea of the site, what's it trying to accomplish, and work backwards from there, and a great question I ask just to determine the value of the project is what would have to happen for the project to pay for itself, because that gets us into a discussion of value, and return on an investment. So, I really encourage everybody to think about that question, because that's so important, and did I miss something there? Yeah, primary, and secondary goals. So, we talked about that.
Agency procurement. This is where you reach out, and you talk to a guy like me, and I have a ton of thoughts about this, and I should do a whole nother webinar just about hiring agencies. I've been doing this for 18 years from an agency perspective, and the business has definitely changed. It's inundated with players, lots of people saying they can do X, Y, and Z, and they don't even know their ABC's, but I digress, I digress.
What you do to find an agency, this is going to be determined by how detailed, and specific your requirements are. If you have very, very, very specific requirements, and you know exactly what platform you want to use, and you have all those goals identified, you should be able to narrow it down to potential agencies a little bit easier, than if you're coming in a little bit blind, and you're like, 'Oh, well I want a website'.
I mean, there's a thousand agencies that you might be able to reach out to, but if you say, 'I want a custom modular, informational site built on WordPress', well then you're probably going to find a guy like us, because for example, that's one of our specialties. So again, the more time you spend detailing what you want to do, the easier it will be to find a partner.
I encourage you to consider a micro engagement, which is, I'm going to talk about this in the next stage, consider doing the discovery as an initial project for a lower price point to get to know the agency, see if you like them, a lot of this is personal, it's relationship based, and also get a sense of their deliverable, and how much thought they're putting into it.
So a micro engagement, breaking out discovery into an initial project makes a lot of sense. The one key there if you do that, make sure that when you do the micro engagement, that you're not going to be priced out of what they find. So, talk to an agency, I like to give customers a sense of a range, a budget range, because I don't want to go, and do a micro engagement, and then not have an opportunity to get the work, because our budget is too high.
So ask the agency, 'If we do this micro engagement, where do you think our project will fall?' And do yourself a favor, and don't bother with the RFP. I mean, I see it all the time, and I know everyone's gonna say, 'Oh, he's an agency guy, he doesn't want to deal with RFP's', I don't think it really serves any of the parties well.
The best agencies don't want to deal with it anyway. They're going to try to interrupt the process regardless, they're just not interested in doing it. The ones that are really suffering, and looking to get as much work as possible, they're going to answer a ton of RFP's, but they're not going to put a lot of thought into it anyway.
So, your best thing is to find three, or four agencies that you like, and try the micro engagement, because I think it's actually going to be easier for you, and you're going to learn more, versus going through an RFP process, which oftentimes is just going to leave you a little bit more confused than you began.
There's probably another webinar in that too that we could do in the future. So finally, discovery, and specification, this is the all important blueprint. This is the development of a technical, and creative specification as it right here to guide your project. Everything that comes out of discovery is what you're going to build, and what the end deliverable is going to look like.
So what you're gonna do, how you're going to do it, and how long it's going to take, and also what will it cost. That is what you're trying to accomplish through a discovery process. This is crucial with an agency, or consultant, or designer, or whoever you're working with. Again, you can conduct it before, you can conduct it after you've signed the big deal. If you're really confident in the agency that you've chosen, do it after, if you've worked with them before, then obviously, yeah, do it after you already know them.
Again, I do though, if you're coming in blind, recommend trying to do it beforehand if you can, but regardless of when you do it, make sure you get a concrete deliverable, even if you've already signed the big deal, get a findings document, get an outline of the content, the information architecture, the templates, or modules, how they're going to build it, what plugins they're going to use, have all that documented as quickly as you can, because that document is sort of like the agreement between the parties, and it's the roadmap, it keeps everybody aligned, so that's a very important step.
So, all that was phase one planning. I promise the rest of the phases go a little bit quicker. Phase two is design. So, when you're doing a custom web design project for the client, this is the most fun. This is where an agency will, or a designer will present you with many options.
You'll have version one, two, three. We like to do three versions for most customers, we'll pick a key page like a homepage, or a product page, and then we'll design maybe a conservative model, a trendy one, one in the middle, and we'll send that to the client. It's a lot of fun, because you get to make choices. So, expect to be involved in this process, expect to be involved in the revision, and approvals that are going to happen.
You know, we're going to be sending mock ups, the designer will, hopefully it's me. We'll be sending you mock ups, and then you'll tell us, 'Oh, I like this', or, 'I don't like this', 'I like part of one, I like part of two', and we'll take it, aggregate it, and get the whole thing whittled down to one version that you like.
I ask you to challenge the designer, ask them why they did what they did, because their answers are going to be telling about how much they're keeping in mind, the discovery, the goals, the objectives, and the things that you worked so hard in phase one. At the end of the design phase, the deliverable should be a series of mock ups of all the templates identified, or if you're doing a modular web design, designs of modules.
One bonus step that we're doing more, although more time consuming, is to do prototyping. Prototyping is where we actually take the mock ups, and then put them into an environment where they click around, and you can sort of get a sense of the experience before the development actually happens, very cool. One thing I left out of here, I'm going to mention really quick, wire framing.
A lot of clients ask, 'Do you do it? Should we do it?' It's really a personal preference thing. It's not necessary if you do the prototyping, you could actually do a simple prototype before you do a design, and that sort of takes the place of wire framing. So, there's a lot of different approaches. I'm not always a fan of wire framing, because it's not really a tangible design, it's just a series of boxes, and it tends to confuse people more than it should.
So that's your design phase. Going into development, which would also be in this case, implementation. You know, this is where you can take a breath, and speaking of that, I'm going to get a sip of coffee here, because I've just been talking the whole time.
So, you could take a breath here during development, a brief, brief breath. Development falls into a couple of parts. For a website informational, you have front end development which is taking those designs, coding it into HTML, CSS, JavaScript, all that cool front end technology that browsers will interpret, then you take that, and you integrate that into the content management system.
So, if you're involved in the process, you can definitely ask your team, your agency to show you those front end files. They can show you how they all came out, and were coded, and work in a browser, I know we tend to show people that. For backend development, your CMS integration, this is where the developers take that HTML, and then integrate that into the content management system, so that you can log in, and change content on the fly.
Finally, there's testing, and QA. This is an ongoing thing, it should happen during the front end development where you do cross browser testing. It should happen during backend implementation where you again are testing functionality, and also testing the HTML front end to know that it's still working the way that it was, and at the end of this process, clearly there's a whole nother round of testing, and we're going to talk about that as phase five.
So next phase, very important, content, content, content. It means a lot of things. Content creation, content migration, before that planning what the content layout, the information architecture looks like. It sort happens throughout the entire process, yet so many overlook this. So many people think about content just as being, 'We'll write up some Word documents, send it to the agency, they'll put it in', and that's not a comprehensive way to approach this.
Some things to consider, during discovery, develop an information architecture. That's a fancy way of saying basically a flow chart where you have your homepage, and then you have the pages that fall underneath it, yeah, you should work on that from the beginning. I do it as part of discovery, because from that AI, information architecture, I can identify templates, and then that's what I use in a contract to say what we're going to build, so it should happen early.
If you're redesigning from an old site, to a new, do a content audit, find out exactly what you have. I mean, do you have a thousand pages? Do you have 200? You're going to need to understand what you have, how it's going to live within the new navigation, and also, are you going to have to redirect some things, are some things going to change locations, and so the content audit is important.
I personally like going into Excel, putting in an old URL, putting a new URL, and using that to manage the process. Migration, very often overlooked, very often. You know, when you go from one CMS, to the same CMS, let's say I go from an old version of WordPress, and you're redeveloping onto a new one, that's a little bit easier obviously, because the data is the same, but when you're going from say, a proprietary CMS from 2008, to WordPress 5.1, it gets confusing.
So, every single project migration needs to be approached differently, based on what's the platform you're coming from, where are you going, how much content is there? There are some automated tools out there that we can use. A lot of times, it's a mixture of automated scripts, and possibly a little bit of manual labor.
So, you need to really think about this the moment that you determine you're going to be doing this project, and also SEO considerations. Remember how I just said having a document that has your old URLs, versus your new, well the reason I want to know that, is cause I want to redirect.
So, one of the things you have to be aware of is when you redo a web design, there is inevitably a little bit of a hit to organic search. You know, we try to minimize that as much as possible, we try to mitigate that risk, and the way we do it is through the audit, and then obviously making sure Google knows things have moved from place one, to place two. So, you have to think about that during your entire process.
For me, we're redoing our site right now. I'm extremely conscious of this, because organic is an important traffic source. So, we're being very, very careful with it, you should be too. Phase five, testing. Testing is always fun. It should happen throughout. So, the minute you're going through the front end, or more so once development is underway, 'cause there's really not a ton of testing you can do during design, unless you've prototyped, and you're doing some user testing.
Front end development. During that, you should be testing cross browser, backend integration, you should be testing functionality, plus again, maintaining that the front the front end code is working cross browser as you had tested earlier, and then you need to test how does this all work together when the implementation is done.
I include this as a separate phase, even though it should be happening, because I see this as being an acceptance phase, and that is the time for you the client to spend time reviewing, and making sure that everything identified in the discovery has been accomplished.
So for you as a client, what can you do? Well first off, you can go, and you can browse around page, to page on multiple devices, and make sure everything looks as intended. You should go into the admin, whatever content management system you have, and start performing the tasks you're going to, adding pages, adding forms, creating landing pages, little things like that just to make sure it's all working as it needs to for you to be impactful in your in your initiatives.
You have to be careful as the point person, I'm going to assume that you're the point person within your organization. This is not the forum to debate design. I hate to say that ship has sailed, because it hasn't, you can always go back, and look again, but if you start debating design at this part, and point, you're looking at all sorts of work orders, and starting over again in terms of design, and the development, and testing, it all happens over, and over.
So in this phase, this is not a time to go send it to your team, and have someone say, 'I really don't like this color. I don't like how the logo came out'. You know, unless it absolutely is unavoidable, unless it's the chairman of the board that's putting it out there, try to stick with what you have. You've already got consensus, and approval there.
So, that's just a word of warning. As an agency, we love work, we'll do the work, but we want your project done more. So, we want it out there. We want people to see the great things that we've delivered, so be on the lookout for that. The next phase is deployment. I'm technically minded, so I think about this. A lot of marketers, they really just want to know that it's going to be live on the date that it's going to be live, but it takes proper planning.
Proper planning ensures a smooth deployment. My goal on every deployment is the flip of a switch. We go from the old, to the new at 10:00 AM, and it's done. This is achievable with proper planning. So, what we have is a long, exhaustive checklist of things we have to get through, it's kind of like a pilot before landing. We go item, by item, you should do this as well. Your list as a client is different, than say our list as the developer, but there's things that are going to be important to you that you want to verify.
So, you should go, and go through that process now, and in terms of what to check, and verify, well actually I'm going to talk about that in the followup, but for marketers, statistics, and metrics gathering, and things like that, integrations, making sure leads are flowing into the right places like from your site, to your CRM, and that all those workflows are properly installed.
That's important for you to test, and verify, and a thought just came to mind by the way, cause this is something that came up recently, you can't outsource 100 % of your testing. You really have to do some of it yourself. The agency is always going to work as hard as they can to make sure everything's working properly, but ultimately you have to take a look, and make sure it was done properly to your satisfaction, just because again, this is your project, and the deliverable's there for you.
Finally, security scans, sweeps, preparedness. I don't want to say that this is solely for WordPress. It's for everything, but if you're doing a WordPress project in particular, you need to make sure you're doing some security scans, making sure it's hardened. So regardless of the project platform, try to spend a little bit of time making sure that everything is tight, secure, I know unauthorized access can happen.
Finally, you've deployed, I treat this as another phase, the ongoing phase. What happens right after, post deployment. Well in the first couple of hours, triple check everything. I don't think you can be too OCD after a site's been deployed, check everything, triple check.
One of the things I like to do in the first hour, or two, or even the first day, cause it doesn't update that quick. If your URLs have changed, go to Google, go to your listing, and just click on links, and make sure you're redirected to the right spot, I think that's a very quick, efficient test. It makes people feel better instantly knowing that everything's working the way it should. In the days following deployment, verify in your statistics tools that all the data is there.
So verify that you're being tracked correctly, conversions are being tracked. You do not want to show up six months after a project, first time looking at your stats, and seeing that, 'Oh no, we haven't gotten conversion data for the last six months'. I've actually seen that happen. So, make sure that you check everything. As an agency, sometimes we have access to those statistics, sometimes we actually don't. So, it is important that you go in, and make sure in the following days that they're working.
A month after, you're going to have a pretty good sample of data, so start to look at performance factors in metrics. Try to check, and see have things improved, have they decreased? I hope not, and from there, take that data, and we can start to think about various improvements that we might be able to do to sharpen the saw, and improve performance.
So, very important to do all those things following deployment. So, at the end of all that, we're through our phases, inevitably someone's going to have a question for me. How long does one of these projects take? It depends. I hate to say it, but it depends, every project is different.
I can tell you a couple of things that are common across projects. The longest phase, and the most intensive for you is always design. Design again, is something where we're producing mock ups, we're sending it to you, you're giving us feedback, we're doing revisions. There's a lot going on through a design process. So, that's an area where it depends on the politics, and workflows of your organization, and I'll skip ahead really quick.
I say custom design, less than one, to two months. I mean, that's somewhat aggressive actually. I probably should have put two, to three, but I've seen customers where we're done with an entire design phase in three, or four weeks, and I've seen customers, some of which, I don't want to say who they are, but bureaucratic organizations where design can take a year.
So, it really depends upon your politics. The one thing I've noticed, every client says they're going to be quick, but it's often not the case. So, one of the things you can do before the project is sort of come up with an internal process for what to do when these designs come in, so you can turn around feedback quicker, that would be a very good thing to do. The phase with the most room for error is typically in implementation.
I think that, that's because you're filling in blanks on the designs. Maybe something is not quite the way the client, or the agency had thought it would be, so there is testing that happens, and that's where things, sometimes, you know, not major things, but 'Oh, I thought it would work this way'. So, those types of things pop up during implementation, more so than design.
My thing there, my recommendation would be try to keep up with the implementation, check in on it once a week, have a standing call throughout the project, so that you could see progress, and catch these things before they become a major issue. So again, generic timelines I think are somewhat reasonable. Custom design on the aggressive side, one month, I'd say the average on the design is about two months, two, and a half months, but again, it depends on your organization.
For the most part, given our assumption of a marketing site, maybe 10, to 15 templates, development, and implementation, one, and a half, to two months is about right. Testing, and that again, I should label that acceptance testing, you should plan to spend a week, or two on that, and if you find significant things, don't forget there might be a little bit of time needed to make adjustments.
Content creation should go on the whole time, it should happen throughout the entire process. It should start during discovery, and it should go all the way through to migration, and deployment should be like a day, or two worth of actual work, but it should be seamless when you flip the switch, and I just realized when I'm talking about this, I actually left out how long for discovery. It was kind of hard for me to figure out how long discovery should totally take, because the first couple of steps are all in house, and internal.
So, you should plan accordingly for how long it'll take you guys to, you know, sit down, and analyze, do the meetings, figure out requirements. Now, once you get to the agency, and the discovery process, it's typically about two, to four weeks from the discovery session where you get deliverables, so build that in as well.
So by looking at this, you could see how a project could take anywhere from three, to six months for a simple informational, depending upon your organization. So here we are, let's say it's January, or February, you could be looking at Labor Day until your site has done. So, these are things that are important to consider. A couple of tips I can give you, based on everything that I've said, and the fact that I've been doing this for a while.
When you build an internal schedule, pad it. I mean, absolutely pad it, because it's always going to go longer. It's very rare, one in 20 projects that goes faster, very rare. I hate to say this as an agency guy, and we have all sorts of steps we do to kind of prevent there from ever being a budget overrun, you should prepare that when you go through the project, you're almost inevitably going to find this, or that that you're going to want to add, or change.
I know doing work on my house, you know how often this happens when the guy's like, 'Hey, you know what would look nice?', and next thing you know he's working for another week. The way that we try to mitigate the actual overrun of a budget is, we always do like a flexible time arrangement on every project.
So, let's say we bid the project, we know this is the spec, I might throw in like a block of hours, like 40, or 50 hours for unknowns, and the way that we handle it is if you use it before deployment, okay, it's used. If you don't, then you can keep it as a sort of a maintenance retainer after.
So, if you're working with us, or working with someone else, consider something like that, so that you don't have to go back to the well on your side to get more funding when those inevitable changes pop up. Plan for post deployment tactics prior to deployment. So after deployment, the tactics I'm referring to are continuous improvement, and maintenance. You need to understand maintenance of any website is going to be a line item on your budget.
Depending upon the platform, it could be a more intense, or it could be a little bit simpler. WordPress needs maintenance, you need to plan for that. You need updates, upgrades, security scans, emergency response. So I hate to say it, but a project is never quite done. You're going to want to improve it, and you're going to have to respond to issues as they arise, you need to plan for that, and budget for it, and finally, this most important step.
Don't skip the discovery, and architecture with whoever is doing your site. Don't just jump in, and have them go, and produce mock ups, it's not good enough. They need to understand why you're doing it, what those goals are, and remember that question, the key question that posed before is what has to happen for the project to pay for itself?
So, does that mean increasing leads by X percent? Does it mean closing more loose conversions, top of funnel conversions? You have to come up with a actual quantifiable goal, cause if you don't do that, you'll never really know if you were successful, or not.
So final thoughts, and thanks for hanging in with me the whole time. Web design projects, they are super complex, they really are. There's all these tools are out there to try to simplify, but in fact, I think they've made it more complex, because it used to be a website, series of pages, you put it out there, but now you have your templates wrapped into a content management system integrating to all these tools that marketers use, automation, marketing automation, sales CRM, statistics gathering, landing page tools, call tracking.
I mean, there's so many things that go into this with a lot of moving parts. You have to recognize this is a serious undertaking you're about to be doing. All these phases, if done poorly can impact your company, whether it be profitability, or the services you provide, and it can impact the return on the investment.
A poorly run discovery is going to just mess up everything. A poor design, or design fatigue, or just settling for what the person sent without challenging the designer, that can have negative effects. A poor implementation can mean you gotta rebuild again a year later, and not maintaining that could be catastrophic. So, all these phases need to be seriously considered.
So preparation is important in each step, and success, I know this sounds cheesy, really cheesy, but you have to stay on task, and stick to your plan. So, the old 80, 20 rule, 80 % of in this case, I believe your success will be determined by just properly planning, going through that discovery, and then sticking with what you got.
So, that wraps up the presentation here. Here's where you can find us. There's our web address. If you have any further questions, everybody got an invitation to this through email, you can just reply, it goes right to me. Thanks again for joining us. I kept it pretty short, I didn't use up the whole hour, so thank you, and I'll talk to you soon.